Detecting failure of UDP multicast receive

3
votes

I have a UDP server which binds to a well-known port, adds itself to a multicast group and listens for requests for clients. (The server is on Windows, and uses WSARecvFrom to issue an overlapped receive for client datagrams.) Clients send messages to the server at its well-known port and multicast IP address.

When testing the 'server' on a laptop, I have noticed that if the laptop enters a 'sleep' state the server's receiving socket becomes 'unbound' from the multicast address (so that client sends to the multicast address are no-longer received). However, the socket is still receiving in that a send to its port at 127.0.0.1 is still received - and Windows does not indicate any error. (The server socket is bound to INADDR_ANY.)

The 'server' is part of a peer-to-peer application, used for auto-discovery - so this situation is not as unusual as might be expected.

Can you suggest a way to determine whether the server is still actively listening on the multicast address without sending to the multicast address (which would result in unnecessary traffic to all 'servers' on the network)? One possible solution would be to send to the IP address of the adapter used for multicast, but I'm not sure how to determine this.

1
windowssocketsmulticast

1 Answers

7
votes

Your network stack will periodically send out IGMP messages. Switches on your network may use IGMP snooping to determine which (if any) multicast messages your computer requires. (This is all an attempt to avoid placing excessive load on hosts due to traffic they haven't requested.)

When your laptop sleeps, it'll stop sending out the periodic messages confirming its interest in certain multicast traffic. Your switch will notice this and stop sending the traffic to your laptop.

I think you'll need to spot when your laptop resumes from hibernation and re-add membership to multicast groups. I've done this (plus coping with network adapters being enabled/disabled) in the past by calling WSAIoctl with control code SIO_ADDRESS_LIST_CHANGE. Whenever a laptop sleeps, all adapters are reported as disabled; when it resumes, adapters are reported to be enabled again. (Note that this can be slightly fiddly as the adapters may be reported as available a few seconds before they're actually capable of sending UDP datagrams so you may have to retry adding membership a few times, with small delays between each retry. Or you could just wait 30 seconds after being notified of adapter changes if you prefer.)