UDP datagram loss in my C# application level, what is wrong?

[Sin Jeong-hun]

Hi.

I need to implement a simple UDP server in C#. My PC and a device is
directly connected to each other with a short ethernet cable, so there
should be no congestion. Basically the server echoes the UDP datagram
back to the device when it got a datagram from the device.

Sending & Receiving several UDP datagrams worked very fine. But the
problem is when the device sends 20 UDP datagrams in a loop with no
delay. Sometimes my application does not get the last 7~8 datagrams
(that is, it only receives the first 12~13 datagrams). I used
WireShark (a variation of Ethereal), and found that all of the 20 UDP
datagrams had arrived to the network interface
(again, there should not be any frame drop in the middle of the
line.)

So, it must be in my application where the UDP datagrams are lost. I
used the sample code "A High Performance Asynchronous UDP Server
Framework in C#" (can be found at http://clutch-inc.com/blog/?p=4).
Could give me an advice? Are consecutive 20 UDP datagrams too many
for .NET applications?

Thank you for any advice.

 

[not_a_commie]

The default .Net UDP implementation gives you 65007 bytes in the UDP
input buffer. Fill that up and you'll drop data. And from what I can
tell, each message needs maybe 5ms to process. Send UDP packets faster
than 5ms apart and you'll miss some. UDP is made for small packets of
periodic data. Compressing your data with the DeflateStream before
shipment will help if your data size is between 8000 bytes and 200k
bytes.

 

[not_a_commie]

Yes, 65507 is correct (not 65007). As for the time between packet
sends, I'm not entirely sure what problem I was having there. When I
determined that a few milliseconds between packets was necessary I was
using packets of the full 65507 length. The only thing I was doing on
the receiving end before relistening was copying the buffer --
something that shouldn't have measured int he milliseconds.