1
RaptorNL / Re: Defining Reliable / Unreliable and Ordered / Unordered
« on: November 22, 2006, 08:15:21 am »My references are my experience and the linux man page socket (7), first paragraph:
This is an implementation of the TCP protocol defined in RFC 793,
RFC 1122 and RFC 2001 with the NewReno and SACK extensions. It pro-
vides a reliable, stream-oriented, full-duplex connection between two
sockets on top of ip(7), for both v4 and v6 versions. TCP guarantees
that the data arrives in order and retransmits lost packets. It gener-
ates and checks a per-packet checksum to catch transmission errors.
TCP does not preserve record boundaries.
It explicitly states that record boundries are not respected. The RFCs (the protocol specifications) will tell you the same.
Nagle (I spelled it wrong the first time) is an algorithm that delays outgoing TCP packets in an attempt to join them into 1 larger packet. This is done to improve bandwidth efficiency for interactive traffic. It is turned on or off with the TCP_NODELAY flag. Even if you do not use Nagle, records can get joined or split by network delays, MTU limitations, retransmissions, cpu load and so on. (if you write out 2 x 1000 bytes in rapid sequence, it will most likely arrive as 1 packet with 1460 and 1 with 540 bytes. This may or may not be presented to you as 1 read of 2000 bytes or 2 seperate reads).
About the delay sensitive, I would definatly NOT send them over the reliable channel. An example of delay sensitive data could be trajectory data of objects in your world. Retransmission would only make the delay worse. For a retransmission, the game would pause, then it would jump, in the second case, there will be a jump too, but it will be smaller. The jumps can be made smaller by sending more updates, but that would increase the chance for packet loss...
PS: As a side issue, it is the kernel that does the TCP handling, it is not the socket library itself.