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
top