multi-client server in ns-3

[Thiago Allisson]

Hi! I would like to know how to create a server that supports multiple clients. Registering a handler for each of the connections.
However SetAcceptCallback and only one of the connections registers the handler.
I'm using a scenario based on first.cc file and configuring the server on one node and clients on the remaining nodes.

[Tommaso Pecorella]

Hi,

double check the manual and the code please.

SetAcceptCallback will set the accept callback, i.e., the 2nd handler will be called when the socket is created and the Fork is complete.

The callback for received packets is set with SetRecvCallback, which can be called on the forked socket (which is passed to the above mentioned callback when the fork is complete).

IN other words, you set a RecvCallback and an Accept callback for the listening socket.

As soon as the Accept callback is fired, you grab the socket passed to the callback and you change the RecvCallback.

Hope this helps,

T.

[Thiago Allisson]

Thanks! I have attached my code. The first shows the Server class, which should accept more than one connection and register a handler for incoming mensangens from these clients. However when I set the client application, appears only the client's message to first connects to the server.

[Tommaso Pecorella]

Hi,

I guess you didn't really understood the point of forking a socket. I'd strongly suggest to double check it.

Your error is that you are substituting your listening socket with the forked (connected) one. As a consequence you destroy the listening one and it's not able anymore to accept incoming connections.

T.

[Thiago Allisson]

Hi,
I didn't understand. When I start the application invoke SetAcceptCallback and when the callback function is executed, configure the Calback the SetRecvCallback. Removed to replace the socket, but it did not work.

[Thiago Allisson]

Hi,
The two clients are connecting. Analyzed the results of the Connect function on each client sockets and they are returning 0. However the callback function associated with SetaAcceptCalback is performed only once, with the client that connects first.

[Tommaso Pecorella]

void
Server::ConnectionAccepted (Ptr<Socket> s, const Address & addr)
{
  s->SetRecvCallback (MakeCallback (&Server::ServerReceive, this));
  NS_LOG_INFO ("Connecting ...");

  // This is not necessary
  // s->SetAcceptCallback (MakeCallback (&Server::ConnectionRequested, this),
  //                             MakeCallback (&Server::ConnectionAccepted, this));

  // However, it is wise to memorze the open sockets.
  m_recvSocketList.push_back(s);
}

Try this.

m_recvSocketList is a std::list<Ptr<Socket> >

T.

[Thiago Allisson]

Hi,
I made the way you showed. It did not work. I
It seems that after the Calback function is activated, the other connections can not access and you can not configure the recv.

[Thiago Allisson]

You have some sample code?

[Thiago Allisson]

I will rely on PacketSink application

[Tommaso Pecorella]

Hi,

I don't have any sample code, sorry.

However, I'd really like to have 1$ for every time I have seen someone doing the error you did. Really, I have seen it made so many times that I'm becoming sick of it. I know that everybody is different, and that you can't really say "I told already", but I feel like Don Quixote, fighting in vain.

Anyway... let's start again from scratch.

In IP a subnet is defined as a group of hosts that can reach each other by pure means of below-IP mechanisms. I.e., every node in the subnet can "talk" to each other without a router in between, purely because the L2 layer allows that.

In a subnet you can have broadcast (not in IPv6) packets, and IP will identify two host belonging to the same subnet if they have the same network prefix.

The network prefix is defined by the IP address and the network mask. If two addresses are identical after being XOR-ed with the same network mask (the one both believe that is the subnet network mask), then they are in the same subnet. Otherwise they aren't and the packet is sent to the designated gateway.

In a point-to-point (serial) link, you usually have only TWO hosts, which raises some issues, because you need to "waste" 2 more IP addresses for something you'll never use. Basically you need a /30 subnet when you could have used a /31. Never mind, this is not relevant.

Still, if you have a 3 nodes topology and you connect them with p2p links, one node will be in the middle, and will have to either:

1) act as a router, or

2) bridge its interfaces at L2.

Otherwise what will happen is this:

A---B---C

A sends a packet to C, and it thinks they're on the same subnet. 

A sends the packet in its interface, and it reaches B. B will ignore the packet, because it's not a router. C will never receive it.

Another scenario.

A sends a packet to B, B replies to A (luck!)

C sends a packet to B, B replies to C... but sends the packet to A.

This is because for node B both links are equivalent, as they're the same subnet !

Basically.... everything goes boom.

So, what is your mistake ? IP addressing.

T.

[Thiago Allisson]

Thanks! I'll test.

[Waqas Rahman]

Hi. I wanted to know if you had any success. I was testing multi-client scenario. In my case, both the clients get connected. They are connected to different sockets. The server starts sending data to the 1st client. When the 2nd client establishes the connection, server stops sending data to the 1st client. The server only sends data to the client that establishes the connection later.  I checked that the listening socket is different from socket at which the server receives the request for data.