Please increase udp receive buffer size

Prattler Lithuania Sat 29 May 2010 03:31 PM #0

UDPsocket.cpp, line 40

/////////////////////////////////////////////////////////////////////////////
// UDPsocket member functions

void UDPsocket::OnReceive(int nErrorCode)
{
char buff [1000];
int count = Receive (buff, sizeof (buff) - 1);

...

Please increase the buffer size to 10000. Sending huge lists (like eq list) via udp from program to program seems to work incredibly well for me. Could there be any harm in this?

David Haley USA Sat 29 May 2010 08:04 PM #1

Why do you need the bigger buffer? Are you also configuring your UDP sockets to use different MTUs than the default, which is typically between 576 and 1,500?

I guess my question is not "what is the harm in this?", it's more like, "what will this be fixing?".

Nick Gammon Australia Forum Administrator Sat 29 May 2010 10:22 PM #2

David is correct. Network limits make sending more than 512 bytes fairly impractical. Here is one reference I found:

Quote:

The size in bytes of the largest UDP datagram that can be sent or received by a Windows Sockets application. If the implementation imposes no limit, iMaxUdpDg is zero. In many implementations of Berkeley sockets, there is an implicit limit of 8192 bytes on UDP datagrams (which are fragmented if necessary). A Windows Sockets implementation may impose a limit based, for instance, on the allocation of fragment reassembly buffers. The minimum value of iMaxUdpDg for a compliant Windows Sockets implementation is 512. Note that regardless of the value of iMaxUdpDg, it is inadvisable to attempt to send a broadcast datagram which is larger than the Maximum Transmission Unit (MTU) for the network. (The Windows Sockets API does not provide a mechanism to discover the MTU, but it must be no less than 512 bytes.)

http://www.sockets.com/winsock.htm

And another:

Quote:

The stack will fragment a UDP datagram when it’s larger than the network’s MTU. The remote peer’s stack will reassemble the complete datagram from the fragments before it delivers it to the receiving application. If a fragment is missing or corrupted, the whole datagram is thrown away. This makes large datagrams impractical: an 8 KB UDP datagram will be broken into 6 fragments when sent over Ethernet, for example, because it has a 1500 byte MTU. If any of those 6 fragments is lost or corrupted, the stack throws away the entire 8 KB datagram.

http://tangentsoft.net/wskfaq/intermediate.html

Possibly large datagrams may work on an internal network (there seems to be some dispute about this), however if this is for a MUD, and you are testing locally, you may find it gives much different results in the field. Large lists may not arrive at all, arrive out of order, or frequently be dropped.

Prattler Lithuania Mon 31 May 2010 09:13 AM #3

Good enough, then please just mention it in the help section of the UDP receive function :)

Thanks!

Nick Gammon Australia Forum Administrator Mon 31 May 2010 10:29 AM #4

I have amended the documentation for UdpListen to clarify that, and to comment that UDP is unreliable. This will ship with the next version (ie. 4.52).