I'm not sure if anyone has stated this or not, but I'm going through your stuff for some inspiration on my work, just went through your "developing an online engine" thing....Just some errors that I see in your documentations:
* A "short" and "ushort" both use 2 bytes, you declare in your png and doc that a "short" is 4 bytes
* An "int" and "uint" both use 4 bytes, you declare in your png that "uint" is 3 bytes and "int" is 5 bytes.
On top of this, it looks like you just incremented from left to right instead of showing the actual number of bytes used. Because "float" uses 4 bytes, and "double" uses 8 (not 6 and 7). Also, string uses 'characters+1' bytes (it appends a nil char), while 'chars' is 'characters' bytes.
* You state this:
We must make sure that we do not pass this Limit else we will get into serious trouble.
Continuing to send over limit sizes will result in hangups, but TCP will automatically throttle data on throughput methods. If a limitation is to be made, it should be much lower than the full limit of your connection.
* You say that packets are "at least 36 bytes". Close but it's actually 60 bytes minimum (40 for IP frame, 20 for TCP frame). This actually could be more considering it goes through windows sockets and adds the application layer to it. (RFC 791 for IP, RFC 793 for TCP)
* There's only 1 type of port...not 2. UDP and TCP are protocols, not port designs.
* Modern day network cards use sliding windows to constantly place data on and off the line, so Nagle's algorithm is 'almost' pointless with gaming. If the information were simply x/y locations, fine, but it's better to buffer your info prior to sending rather than use nagle.
* You state "The good about this would be that there is no need for a server to be online to play." This would be false, the server needs to be up in order to connect players together. You might be thinking of a p2p system, but a server would be needed to connect 'new' people into the loop.