Difference between revisions of "Netcode bringup"
| Line 1: | Line 1: | ||
As of 21 July 2010, this branch is dedicated to fixing some of the more serious problems in Odamex's networking system. | As of 21 July 2010, this branch is dedicated to fixing some of the more serious problems in Odamex's networking system. | ||
| − | + | === MTU (Maximum Transmission Unit) === | |
| − | + | ||
| − | + | ||
| − | + | ||
| + | Large MTU's are a problem on the internet and have existed for a long time, Odamex currently has datagrams which are 8k (8192) in size, whereas an ethernet connection has an MTU of 1500 (usually, this varies but is a fairly common value), odamex sending datagrams of 8k will cause the OS network stack to split it up into 1500 byte fragments. And because UDP is unreliable and one of those fragments gets lost, the whole packet goes with it (including the "reliable" section) | ||
| − | + | There is a solution and that is to use a mixture of a packetization layer path MTU discovery (RFC4821) technique to dynamically resize our send buffer, if that doesn't work we fall-back on a fixed size of like 1400. | |
| − | + | ||
| − | + | === Markers === | |
| − | + | ||
| + | Currently when markers are written with MSG_WriteMarker, the size of their payload is not checked against the boundaries of the send buffer, which can cause an overflow, this is the same with the reliable variants. | ||
| + | |||
| + | A simple enough solution is to pass the size of the marker and its payload to this function (strings will be a problem as they are '''null terminated''' and not of a fixed length). Check the size if it goes over, if it does, send the current packet NOW, then write the contents out into a new buffer. ''There is a problem with this solution, a marker that is more than the max buffer length will not fit obviously, this will NEED to be monitored'' | ||
| + | |||
| + | === Packets === | ||
| + | |||
| + | Packets that are out of order are not handled properly, they could cause very erratic gameplay in extreme situations and poor reliable system efficiency in others. | ||
| + | |||
| + | Any ideas on how to fix this? | ||
| + | |||
| + | === Downloads === | ||
| + | |||
| + | WAD file downloads are unacceptably slow, they also do not handle other types of downloads either (DEH/BEX files) | ||
| + | |||
| + | |||
| + | == External Links == | ||
| + | |||
| + | [http://tools.ietf.org/html/rfc4821 RFC4821] - Packetization Layer Path MTU Discovery | ||
Revision as of 22:19, 21 July 2010
As of 21 July 2010, this branch is dedicated to fixing some of the more serious problems in Odamex's networking system.
MTU (Maximum Transmission Unit)
Large MTU's are a problem on the internet and have existed for a long time, Odamex currently has datagrams which are 8k (8192) in size, whereas an ethernet connection has an MTU of 1500 (usually, this varies but is a fairly common value), odamex sending datagrams of 8k will cause the OS network stack to split it up into 1500 byte fragments. And because UDP is unreliable and one of those fragments gets lost, the whole packet goes with it (including the "reliable" section)
There is a solution and that is to use a mixture of a packetization layer path MTU discovery (RFC4821) technique to dynamically resize our send buffer, if that doesn't work we fall-back on a fixed size of like 1400.
Markers
Currently when markers are written with MSG_WriteMarker, the size of their payload is not checked against the boundaries of the send buffer, which can cause an overflow, this is the same with the reliable variants.
A simple enough solution is to pass the size of the marker and its payload to this function (strings will be a problem as they are null terminated and not of a fixed length). Check the size if it goes over, if it does, send the current packet NOW, then write the contents out into a new buffer. There is a problem with this solution, a marker that is more than the max buffer length will not fit obviously, this will NEED to be monitored
Packets
Packets that are out of order are not handled properly, they could cause very erratic gameplay in extreme situations and poor reliable system efficiency in others.
Any ideas on how to fix this?
Downloads
WAD file downloads are unacceptably slow, they also do not handle other types of downloads either (DEH/BEX files)
External Links
RFC4821 - Packetization Layer Path MTU Discovery