Udp Multicasting and buffers...

  • Thread starter Thread starter Ryan Cromwell
  • Start date Start date
R

Ryan Cromwell

I have a question concerning developing a generic multicast subscriber. How
do you go about determining a decent buffer size? Why does the
Socket.(Begin)ReceiveFrom method require an instanciated buffer instead of
requiring a stream or returning a correctly sized buffer? Aside from DOS
attack conciderations, I guess, it seems to be a major limitation.
 
Ryan Cromwell said:
I have a question concerning developing a generic multicast subscriber. How
do you go about determining a decent buffer size? Why does the
Socket.(Begin)ReceiveFrom method require an instanciated buffer instead of
requiring a stream or returning a correctly sized buffer? Aside from DOS
attack conciderations, I guess, it seems to be a major limitation.
Click to expand...

Ryan -

There are two different buffers involved in the socket
communication that you should worry about. The low-level socket buffer
will accept incoming multicast packets until it is full. You can
change the socket buffer size using the SetSocketOption() method. Your
application should try to read data at least as fast as it is coming
in, or the socket buffer will eventually fill and drop packets. Since
this is UDP, those packets will not be retransmitted.

Each call to the ReceiveFrom() method will extract one datagram
from the socket buffer. You should ensure that the data buffer you are
using in the ReceiveFrom() method is large enough to hold each UDP
datagram you are expecting to receive. The ReceiveFrom() method will
throw a SocketException if the buffer specified is smaller than the
amount of data in the next datagram in the socket buffer. The left
over data (the data in the datagram that did not fit in the data
buffer) will be lost.

If you are worried about not specifying a large enough buffer, you
might notice that the UdpClient Receive() method does not need a
specific buffer to be set. It returns a correctly sized buffer after
reading the datagram (of course if you still try squeezing it into too
small of a data buffer a SocketException will be thrown as well).
Maybe that would work better for you.

Hope this helps shed some light on the topic for you. Good luck
with your network programming.

Rich Blum - Author
"C# Network Programming" (Sybex)
http://www.sybex.com/sybexbooks.nsf/Booklist/4176
"Network Performance Open Source Toolkit" (Wiley)
http://www.wiley.com/WileyCDA/WileyTitle/productCd-0471433012.html
 
Thanks for the help Rich. Is it accurate to say that client/server
communication in an unreliable protocol require a common agreement on
datagram size such that the client knows when a particular tranmission set
is complete? I've asked this question on the framework group, but have not
yet received an answer.
 
Ryan Cromwell said:
Thanks for the help Rich. Is it accurate to say that client/server
communication in an unreliable protocol require a common agreement on
datagram size such that the client knows when a particular tranmission set
is complete? I've asked this question on the framework group, but have not
yet received an answer.
Click to expand...
Ryan -

I guess the answer is "it depends". If reliable communication is a
necessity between the client and server, then I would recommend
choosing TCP as the transmission protocol. However, in some
client/server applications dropping a packet or two along the way does
not produce catastrophic results. Such as with an audio stream - going
back and retransmitting a dropped packet in the middle of a data
stream is much worse than just living with the missing data (which may
only produce a small glitch in the audio signal).

That said, in my book I cover a couple of different scenarios of
how to compensate for problems with UDP communications, such as when
data is lost by not reading the entire packet in the ReceiveFrom()
method, or when UDP packets are dropped. Hope this explanation helps
out some.

Rich Blum - Author
"C# Network Programming" (Sybex)
http://www.sybex.com/sybexbooks.nsf/Booklist/4176
"Network Performance Open Source Toolkit" (Wiley)
http://www.wiley.com/WileyCDA/WileyTitle/productCd-0471433012.html
 
Back
Top