Increasing UDP Recieve Buffers

  • Thread starter Thread starter Chris G
  • Start date Start date
C

Chris G

Hi, My application needs to read UDP packets which are coming at a
rate of about 50Hz. (For 1 or 2 second bursts). When I examine what
has been recieved, I see holes of missing data, perhaps 10 missing
packets per second.

I believe the problem is that my (C#) synchronous UDP client cannot
reliably Recieve() from the socket at that rate, even at the highest
priority, even with the most minimal overhead.

Is there a way to increase the size of the recieve buffer for my
socket so that the tcp/ip stack doesn't discard packets when my
application gets delayed? (I know TCP would be better, but it's not
an option)

Thanks
 
(e-mail address removed) (Chris G) wrote in @posting.google.com:
Hi, My application needs to read UDP packets which are coming at a
rate of about 50Hz. (For 1 or 2 second bursts). When I examine what
has been recieved, I see holes of missing data, perhaps 10 missing
packets per second.

I believe the problem is that my (C#) synchronous UDP client cannot
reliably Recieve() from the socket at that rate, even at the highest
priority, even with the most minimal overhead.
Click to expand...

50Hz should not be a problem for fetching the packets. By CPU standards that
is quite low.

What are you doing when you receive the packets? Have you considered just
grabbing them in a thread and queing them and letting another thread process
the queue?


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com
 
Have you tried NetMon (or other) to verify the packets are making it to your
listener?
 
Remember that UDP is not a guaranteed delivery mechanism. Packets could be
discarded (even if you are doing loopback) at any time. I dont know what
kind of "holes" you are seeing, but this could explain any loss of packets
that you see.

--
Remove "user" from the email address to reply to the author.

This posting is provided "AS IS" with no warranties, and confers no rights

Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
 
I realize UDP is not guaranteed, but I am wondering if there is some
way to tweak the algorithm Windows uses for discarding packets so that
I can be 99% certain that my packets won't get discarded on the
recieving end. IE. number of spots in a recieve queue or some kind of
timeout value.

Is there some registry keys or something that can be modified for this
purpose?
 
(e-mail address removed) (Chris G) wrote in
I realize UDP is not guaranteed, but I am wondering if there is some
way to tweak the algorithm Windows uses for discarding packets so that
I can be 99% certain that my packets won't get discarded on the
recieving end. IE. number of spots in a recieve queue or some kind of
timeout value.
Click to expand...

You can increase the TCP buffer size. I havent tried it with UDP.

However its a Winsock option, not sure if System.net.sockets exposes this.

As I said previously what you need to do is have one thread just plucking
packets. It then stores them in a queue for other threads to actually process
and handle whatever the action is that you want.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com
 
You do it at the socket level. If you using UdpClient, you need to derive
from UdpClient to get access to the protected Client (socket) object. Then
you can create a method like:

public int ReceiveSize
{
get
{

return (int)this.Client.GetSocketOption(SocketOptionLevel.Socket,
SocketOptionName.ReceiveBuffer);
}
set
{
if ( value < 0 )
throw new ArgumentOutOfRangeException("ReceiveSize", value, "Invalid
size.");
Socket s = this.Client;
s.SetSocketOption(SocketOptionLevel.Socket,
SocketOptionName.ReceiveBuffer, value);
}
}

Not sure changing buffer size will fix your issue. Are you binding multiple
sockets to the same IP by chance?

--wjs
 
Even with large recieve buffers, I found that I had the same problems.
But hypothetically, even if I had been able to recieve all packets
with larger buffers, I think the solution is inherently bad since it
won't scale to higher throughputs. So I built in some primitive flow
control logic instead. So far my sending queue has grown to a maximum
of 27 packets at the 50Hz rate, with the occasional timeout-resend. I
don't know where the drops were happening, but it works great now =)
Thanks for the advice.

Chris G
 
Back
Top