Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ Suggestions ➜ Please increase udp receive buffer size

Please increase udp receive buffer size

It is now over 60 days since the last post. This thread is closed.     Refresh page


Posted by Prattler   Lithuania  (15 posts)  Bio
Date Sat 29 May 2010 03:31 PM (UTC)

Amended on Sat 29 May 2010 03:32 PM (UTC) by Prattler

Message
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?
Top

Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #1 on Sat 29 May 2010 08:04 PM (UTC)
Message
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?".

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #2 on Sat 29 May 2010 10:22 PM (UTC)
Message
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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Prattler   Lithuania  (15 posts)  Bio
Date Reply #3 on Mon 31 May 2010 09:13 AM (UTC)
Message
Good enough, then please just mention it in the help section of the UDP receive function :)

Thanks!
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #4 on Mon 31 May 2010 10:29 AM (UTC)
Message
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).

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


20,165 views.

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum


[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.