Latest revision as of 22:22, 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 ~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