3 replies to this topic

[ruin]

Hi. I recently started learning c# and just completed writing a TCP two-way asynchronous chat program using windows forms. yes very impressive i know. :-\

i would now like to try the same thing but using multicast UDP instead. My one question before proceeding is whether the UDP data received by the Socket EndReceive() function, will be a full datagram, or whether it could be segmented as in the TCP case.

Basically I want to know if EndReceive will always give me the full sent datagram or whether I might receive the datagram in chunks. It seems that because the sender is theoretically unknown at the time of the receive operation, that the asnyc callback will not be called until the entire Datagram is ready.

Even if the datagram is say, 60k long?

Thanks for any help.

- justin

[engine252]

If you are using the asynchronous methods you should pass the IAsyncResult parameter to the EndRecieve method. The EndRecieve method returns an int with the bytes that you are recieving in this method call. Only when the int returned is smaller then your buffer size you can assume your message is complete.

[ruin]

While you are correct in the case of connection-oriented protocols, I think it may work differently when using UDP.

Here is what I found on the microsoft website:

"This method is most useful if you intend to asynchronously receive connectionless datagrams from an unknown host or multiple hosts. In these cases, BeginReceiveFrom will read the first enqueued datagram received into the local network buffer. If the datagram you receive is larger than the size of buffer, the BeginReceiveFrom method will fill buffer with as much of the message as is possible, and throw a SocketException. If you are using an unreliable protocol, the excess data will be lost."
-http://msdn.microsoft.com/en-us/library/system.net.sockets.socket.beginreceivefrom.aspx

While I haven't made any test cases yet - i'm still slow at structuring in c# - it seems to suggest that UDP is an all-or-nothing go. You can't call read again to get the rest of the data - you either get it all the first time or you lose the remainder.

Of course when they say 'local network buffer' they might mean an internal buffer controlled by the system. But it's difficult to see why data read into that buffer would be given to your program in smaller bits than are available.

[engine252]

In the beginrecievefrom you actually tell it how much data you wish to recieve.

s.BeginReceiveFrom(so2.buffer, 0, StateObject.BUFFER_SIZE, 0, tempRemoteEP, New AsyncCallback(AddressOf Async_Send_Receive.ReceiveFrom_Callback), so2)

If you tell it the buffersize is 12 bytes while your actual buffer is 10 bytes you will get the SocketException and your 2 bytes will be lost.
If you recieved less data then you requested you can assume you message is complete.

For example if you wish to stream video over udp you will never be able to define a buffer large enough to get the video in 1 call.
In this case you will need to build up the video by calling the BeginRecieveFrom multiple times until you finaly recieve lesser bytes then you requested.
Then you can assume your video is final.