views:

1993

answers:

5

Overview: I have set up a server and a client, where both attempt discovery of each other using UDP. When the server starts up it sends a multicast message (239.1.1.1) that it is alive. When the client starts up it sends a multicast message (239.1.1.2) that it is alive. Both server and client are subscribed to each other's multicast messages to receive their transmissions. This way, regardless of which application (server or client) starts up first, one or the other will be notified of their existence.

On the client side I do the following:

  1. Set up a listening socket to subscribe to and receive server originated multicast messages.
  2. Set up a receiving socket to receive server responses to client's multicast
    message per #3 below.
  3. Send a muticast message (for server to receive and respond to) that client is running.
  4. Receive server response to clients multicast message sent in #3.

Question: Everything is working fine, except that both receiving sockets end up getting the server's (non-multicast) response to the client. I am not clear if this is expected behavior or not. Can I reduce the two receiving sockets to one? #1 is subscribed to the server's multicast and #2 is simply listening for a direct transmission from the server on the same port (non-multicast message from server). Can I safely remove the second receiving socket?

See source code below (I removed exception handling for simpler code presentation).

Client code:

// 1. Set up a socket and asynchronously listen for server startup multicasts.
Socket listenSocket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram,
    ProtocolType.Udp);
listenSocket.SetSocketOption(SocketOptionLevel.Socket,
    SocketOptionName.ReuseAddress, 1);
listenSocket.Bind(new IPEndPoint(IPAddress.Any, 50000));
listenSocket.SetSocketOption(SocketOptionLevel.IP,SocketOptionName.AddMembership,
    new MulticastOption(IPAddress.Parse("239.1.1.1")));
EndPoint clientEndPoint = new IPEndPoint(0, 0);
listenSocket.BeginReceiveFrom(receiveBuffer, 0, receiveBuffer.Length,
    SocketFlags.None, ref clientEndPoint,
    new AsyncCallback(OnServerMessageReceived), (object)this);

// 2. Set up socket to receive the server's response to client's multicast.
Socket receiveSocket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram,
    ProtocolType.Udp);
receiveSocket.SetSocketOption(SocketOptionLevel.Socket,
    SocketOptionName.ReuseAddress, 1);
receiveSocket.Bind(new IPEndPoint(IPAddress.Any, 50000));
receiveSocket.ReceiveTimeout = 3000; // Timeout after 3 seconds.

// 3. Send a multicast message for server to respond to.
Socket sendSocket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram,
    ProtocolType.Udp);
EndPoint multicastEndPoint = new IPEndPoint(IPAddress.Parse("239.1.1.2"), 50000);
sendSocket.SendTo(packet, packet.Length, SocketFlags.None, multicastEndPoint);

// 4. Wait for server to respond to the multicast message (timeout = 3 seconds).
byte[] receiveBuff = new byte[2048];
EndPoint serverEndPoint = new IPEndPoint(0, 0);
int bytesRead = receiveSocket.ReceiveFrom(receiveBuff, ref serverEndPoint);

Server code:

// Receive multicast message sent from client (in asynchronous callback method).
EndPoint clientEndPoint = new IPEndPoint(0, 0);
int bytesRead = listenSocket.EndReceiveFrom(asyncResult, ref clientEndPoint);

// Send response back to the client (change port to 50000).
EndPoint destination = new IPEndPoint((clientEndPoint as IPEndPoint).Address,
    50000);
Socket responseSocket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram,
    ProtocolType.Udp);
responseSocket.SendTo(response, response.Length, SocketFlags.None, destination);
A: 

Whilst I'm not sure it's addressing your issue, I would expect both client and server to talk on the same IP multicast address (e.g. 239.1.1.1). At the moment it looks like you've given the client and server one address each, and what happens if/when you introduce a new client ?

Brian Agnew
I intentionally gave the client and server different multicast addresses, so that the client does not pick up the multicast message it sends out (targeted to the server) and vice versa. The client is subscribed to multicast messages from the server and the server is subscribed to multicast messages from clients.Each time a new client is started up, it will send out a multicast message in search of the server. The server responds with its IP address and port info, which then completes the discovery process and allows the client and server to establish a TCP connection (utilizing WCF).
Elan
+1  A: 

The answer to your question is "Yes, this is expected behaviour". You don't need to open a seperate socket to recieve unicast packets on the same port.

PS

It seems like overkill to have your servers join a multicast group to listen for new clients - you could just have the servers regularly transmit a beacon to the client multicast address saying "I am here" (say, once every 30 seconds).

caf
IPAddress.Any in IPEndPonint object you send to Bind means - you can bind this socket to port 50000 on any of the network interfaces you have. If you have multiple interfaces and you want to bind to a specific interface, then you could specify the ip of that interface in place of IPAddress.Any. It does not mean the 'this socket can receive any UDP packets destined to any ip address'.
Indeera
Quite so, I have edited to resolve this.
caf
Thank you for your response. 1) I thought that subscribing to a muticast would specifically and only pick up multicasts sent out to the address subscribed to. Does the unicast message get picked up because the target address of the unicast message is the same machine listening on the same port? 2) I have one server listening for new clients. Wouldn't a repeated beacon cause unnecessary network load? Once all clients complete discovery beacon is no longer needed. Server would not know how many clients exist. Clients however could keep trying until they successfuly connect to the server.
Elan
1) Yes - just like if you set the socket options to recieve broadcasts, you'll still continue to recieve unicasts too. 2) Maintaining multicast groups creates network load too, and it would significantly simplify both the client and server logic.
caf
A: 

Better option would be to use a service discovery protocol like Bonjour or Avahi than rolling your own, as they have solved a lot of problems already.

Indeera
A: 

You have mentioned different (multicast )client address. Are you saying that client 1 will have one address and client 2 will have another one?

seekna
+1  A: 
receiveSocket.Bind(new IPEndPoint(IPAddress.Any, 50000));

Your receive sockets are binding to ANY address, which means they will receive unicast, broadcast and multicast traffic. You can bind to an interface address to just receive unicast traffic, and you can bind just to the multicast group to only receive multicast traffic.

When sending a UDP datagram you can specify the destination address which may be multicast or unicast. You can therefore reduce both the server and client code to one socket each.

Steve-o