index > .NET Framework Networking and Communication > UDP multicast sockets - how to handle link failures

UDP multicast sockets - how to handle link failures

Hi,

I'm working on a UDP Multicast library and got a question on how to properly handle link failures, disconnected/reconnected NIC cables, etc.

As an example, when I join a multicast group I start receiving data on that socket from a multicast sender. Now, when I disable the NIC to which the multicast receiver is bound, I'm not receiving any socket level errors (e.g. inSocket.ReceiveAsync). When I reenable that NIC, I'm not receiving any more data although the sender is still sending on the same multicast group.

I was hoping that the Kernel would actually handle rejoining the multicast group after a hardware link failure but looks like it doesn't. However, since I'm not getting any socket level errors either, I don't really know how to detect a link failure for a multicast receiver?

Are there certain socket options that need to be set so the kernel would rejoin a multicast group?

Thanks,

Tom

Tom Frey

Have you tried looking at the System.Net.NetworkInformation namespace? I think there are classes there that can tell you if the network got disconnected. You can use those events to rejoin the multicast group.

feroze
--
My blog

Feroze Daud

Ya I did and so far that is my workaround.

However, I'm not really sure if that's the best approach or if there is a way to handle the rejoin on the kernel level. Unfortunately I can't find any official documentation on this.

Tom Frey

Are you saying that you are not getting an exception, even though you are sending data?

Note, that you will not get the exception on the Receive() call, because as far as the client is concerned, it is still waiting for a packet to show up. UDP is not connection oriented like TCP. Packets may be dropped anywhere in the path from the source to the destination. The packet can get dropped by the network stack in your machine as well.

Are you sure that the sender is sending the packet (after reconnecting the cable) and you are still not able to receive it? To debug this, you will need to get a network sniff using Wireshark, that clearly shows the multicast packet being received by the machine, and yet not coming through to your application.

One option to detect network disconnect would be to send periodic keep-alive packets to the peers. If the send fails, then you know you have a problem.

feroze
--
My blog

Feroze Daud

No, my question is only about the receiver. The sender resides on a different machine is not affected by the link disconnect in my test scenario.

I'm sniffing with wireshark and when I initially launch the receiver I see the IGMP packet to join the multicast group:

15972 1885.074158 192.168.1.99 224.0.0.22 IGMP V3 Membership Report / Join group 239.4.5.2 for any sources

Now, when I disable the NIC and reenable it, I see a bunch of IGMP messages of other applications rejoining multicast groups but I do not see any join message for 239.4.5.2. When I restart the application, it joins again and starts receiving data again from the sending server

Tom Frey

Ah. As I said, your Receive() will not throw an exception just because the network disconnected. However, if you try to Send() during that period, it should fail with an exception.

Therefore, one thing you might try is to send keep-alive packets to your peers. That way, if a Send() fails, you will know that there iss a problem on the network.

feroze
--
My blog

Feroze Daud

imho it should throw an exception because the socket is bound to port and IP address which becomes unavailable when the link disconnects but that's besides the point probably :)

I don't really think that sending keep alives will solve my problem ,as yes I will become aware that there is a problem once the Send() fails, however I will not be able to detect when the link becomes good again as the Send() will keep failing until I rebind the sender socket and rejoin the multicast group as sender.

Right now I still think listening for NetworkAddressChange events is the only option unless there are some hidden socket opt settings that would cause auto rejoin, etc.

Just curious how other multicast applications handle this

Tom Frey

You can use google to search for other answers

Custom Search

More Threads

• JMAIL component - saving an email to disk including attachments

• Does remoting Services support mutiple IP address?

• How to catch a network failure from socket operation

• what is the best collapsible control for a mail messaging system.

• Randomly timout on WCF call with httpBinding

• EMailing errors via SmtpClient ?

• IIS - always "login window"??

• [Udp][C#]Listen to Broadcasting at any port

• A qustion about FtpWebRequest & SSL

• Sending commands to server