Problem with System.Net.UdpClient and multicast receive

I am developing a VB.NET application that needs to monitor a multicast group. To do this I am using the System.Net.UdpClient class. The multicast group messages are of a fixed size (48 bytes) and each member of the group sends the message about one every second. In my test setup I have a single device sending the group message and my application is monitoring the messages.

What I see using WireShark is exactly what I expect, a multicast message with 48 bytes in the data element of the message.

The application uses the following code to block (in a separate thread) waiting for the messages:
   listener.JoinMulticastGroup(groupAddress)
 
   While Not done
      Dim bytes As Byte() = listener.Receive(groupEP)

      ... process message here
   End While

Open in new window


Typically, the length of "bytes" is the size of the message (48 bytes), however, sometimes many more bytes are returned, even though the time delay between the previous good message and the long one is consistently about 1 second. The data in the buffer appears to be a partial message (first few bytes missing) and then many well formed messages.

As I said, I have examined the network data using WireShark and all the messages are well formed. Also, there are only messages from my single device.

Am I missing something obvious here?

Any pointers as to what may be going wrong would be much appreciated.
Sid PriceSoftware Systems Architect/DesignerAsked:
Who is Participating?
 
Sid PriceSoftware Systems Architect/DesignerAuthor Commented:
It appears that the problem was entirely of my making in the device generating the multicast messages and that there is in fact nothing wrong with the .NET UdpClient class at all. After finding a subtle bug on the device the .NET based application receiving the messages works very well.

Sid.
0
 
brutaldevCommented:
If there are a lot of messages coming in quickly then the listener will receive bytes currently flushed in the underlying stream which could contain more or less a full message. Because you messages are tiny (48 bytes) it's more than likely reading into the next message's bytes. I only know this for a fact with TcpClient when you are are receiving in a loop so it's a good starting point.
0
 
Sid PriceSoftware Systems Architect/DesignerAuthor Commented:
Thank you for the quick reply.

I don't think this is the issue for several reasons.

First, as I mentioned in my original post a message is sent about once every second.

Second, I have debug messages in the code that emit a message each time a multicast message is received. These come out at the right period, plus the period between the last good message and the very long one is also about a second. The number of messages I get under the error condition is around 30!

Third, WireShark confirms the rate of messages on the wire at one every second or so.

Sid.
0
Cloud Class® Course: Microsoft Office 2010

This course will introduce you to the interfaces and features of Microsoft Office 2010 Word, Excel, PowerPoint, Outlook, and Access. You will learn about the features that are shared between all products in the Office suite, as well as the new features that are product specific.

 
brutaldevCommented:
SUPER old article but it's directly related to what I was trying to explain but with code samples and much more detail.
0
 
Sid PriceSoftware Systems Architect/DesignerAuthor Commented:
Thanks again. I will implement a sockets level receiver and see if I get better results.
Sid.
0
 
Sid PriceSoftware Systems Architect/DesignerAuthor Commented:
The problem was in another element of the system and not in the area that the question covered.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.