G33X Nexus Entertainment > RaptorNL

Defining Reliable / Unreliable and Ordered / Unordered

<< < (2/2)

Jove:
An important difference I have not seen mentioned is that UDP is packet based and TCP stream based. For the upper layers, in TCP there is no such thing as a packet. You data will arrive as one continuous stream of bytes. From the headers i've seen in your spec, you are not prepared to handle that (since there is no way to see how long the data segment of a packet is, only the header). Also, there is no guarantee that if you receive data it will be a complete packet.

Another feature I haven't seen mentioned either is the difference between delay sensitive and not-delay sensitive data. For a game, I think that might be important. Especially if you consider mixing TCP and UDP as a transport layer. TCP can introduce extra delays because it will queue sending data in an attempt to compose larger packets (Naggle).

contingencyplan:
So what you're saying is that RaptorNL, which (for now) will sit on top of the sockets, will not have to worry about the individual TCP packets; rather, the socket library will deliver them as a stream? Can you point me to some specific sources for this information?

The delay and non-delay sensitive data is definitely a good point. I'm not sure whether we'd want to add those in or not (and if so, how we'd go about doing it - perhaps as a flag). I'm assuming that "immediate" packets (those that cannot be delayed) would only be sent over a reliable channel (either TCP or RUDP), so we could just have a flag on the reliable channels to say whether to delay packets sent over them, or have a flag in the individual message to that effect. Any further thoughts on this?

Also, what is "Naggle"?

Jove:

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.

Morgul:
Regarding 'Delay' vs 'Imminent' that's basically the same as reliable vs unreliable. In the first networking layer we wrote, we used unreliable transmissions for the 'Imminent' stuff, and reliable for the important 'Delay' stuff. With the construction of the game, we're doing everything locally, and updating as we get information from the server. That means that we can stand to miss information all together for up to a second or more without issues.

--chris

Navigation

[0] Message Index

[*] Previous page