Topic: Questions about the RUDP headers

[contingencyplan]

When whitelynx posted his initial ideas about the RUDP protocols, he posted the following questions (which have since been removed, so that we can discuss them without turning the wiki into a forum... :o)

• If Sequence # is 0, then this packet is unordered.
• Do we need all those flag bits?
• Is there any way we can shorten up the unreliable and unordered packets?
• Use a flag for sequenced/non-sequenced packets so we can save the sequence # byte?
• Do we really need header length?

After reading through the first part of the RUDP spec, I think I can answer a few of these (and pose a few questions of my own):

Do we really need header length?

If we look further down the spec, we can see that every segment except EAK has a fixed length in bytes (which is the unit of the value in header length). About half of the segments (ACK, RST, NUL) have header lengths of 6. SYN has the longest length at 28, and TCS has 12. Only EAK has a variable-length header, since the header contains the list of segments received out of sequence. "Its minimum value is seven and its maximum value depends on the maximum receive queue length." Thus, we need the header length to know how long the segment header is.

I suppose we can make an argument that if we know the type of segment (based on the flags at the start) that we know the size of the segment, meaning that the size is not needed. However, I'd still think the size would be necessary for determining whether additional data was included in the segment (which is expressly forbidden for certain segment types - SYN, RST, NUL - meaning that an error would be thrown), and for determining whether the whole packet made it (especially important for EAK, since we can't know the full header length).

It is worth noting that the spec refers to the data as "segments," not "packets." I think this is due to RUDP being implemented on top of the UDP protocol - the whole thing, UDP header + RUDP header + data (if any) is the whole packet. However, to UDP's standpoint, the RUDP header is simply regular data in binary form, to be interpreted in any way so chosen by the recipient. Thus, I think the spec is thinking of the RUDP headers as simply "segments" in the packet as a whole. Just an observation I thought I'd share.

Do we need all those flag bits?

As described above, the flag bits are necessary to know what kind of packet we're dealing with, so I'll take this question as "Do we have to send all of the types of packets described in the spec?" Initially, I'd say yes - they're in the spec, so we should probably use them. The only one we may not end up using is the NUL packet, which is basically the equivalent of a "ping," which the Gamdev.net forum post says can easily be accomplished (in games) by just watching the traffic going back and forth. However, I would still rather include it for completeness's sake, rather than leaving it out to save a bit and a minor bit of logic to handle it.

Is there any way we can shorten up the unreliable and unordered packets?

I want to start a separate thread on this, so we can define what we mean by reliable / unreliable and ordered / unordered, which I'm still not entirely clear on.


Two questions of my own:

• Where does channel number fit in here?
• These headers are both for sending ordered data packets? Is that why we have the 7th bit 0 for reliable and 1 for unreliable (which I would reverse, personally)?

[whitelynx]

First off, I'd like to note that I moved the Enhanced UDP information off of the Features page into its own page.

Do we really need header length?

If we look further down the spec, we can see that every segment except EAK has a fixed length in bytes (which is the unit of the value in header length). About half of the segments (ACK, RST, NUL) have header lengths of 6. SYN has the longest length at 28, and TCS has 12. Only EAK has a variable-length header, since the header contains the list of segments received out of sequence. "Its minimum value is seven and its maximum value depends on the maximum receive queue length." Thus, we need the header length to know how long the segment header is.

I suppose we can make an argument that if we know the type of segment (based on the flags at the start) that we know the size of the segment, meaning that the size is not needed. However, I'd still think the size would be necessary for determining whether additional data was included in the segment (which is expressly forbidden for certain segment types - SYN, RST, NUL - meaning that an error would be thrown), and for determining whether the whole packet made it (especially important for EAK, since we can't know the full header length).

I can agree with leaving the header length, now that I've read more of the spec. I just wanted to make sure it got discussed so we're sure what we're doing.

It is worth noting that the spec refers to the data as "segments," not "packets." I think this is due to RUDP being implemented on top of the UDP protocol - the whole thing, UDP header + RUDP header + data (if any) is the whole packet. However, to UDP's standpoint, the RUDP header is simply regular data in binary form, to be interpreted in any way so chosen by the recipient. Thus, I think the spec is thinking of the RUDP headers as simply "segments" in the packet as a whole. Just an observation I thought I'd share.

Ok, we can change our terminology to match, if we want to. The reason I'm using the term "packet" stems more from my experience with RakNet.

Do we need all those flag bits?

As described above, the flag bits are necessary to know what kind of packet we're dealing with, so I'll take this question as "Do we have to send all of the types of packets described in the spec?" Initially, I'd say yes - they're in the spec, so we should probably use them. The only one we may not end up using is the NUL packet, which is basically the equivalent of a "ping," which the Gamdev.net forum post says can easily be accomplished (in games) by just watching the traffic going back and forth. However, I would still rather include it for completeness's sake, rather than leaving it out to save a bit and a minor bit of logic to handle it.

The reason I asked that is because I want to add two flag types to the original spec: one for reliable/unreliable and one for ordered/unordered.

Where does channel number fit in here?

I modified the page to include that today.

These headers are both for sending ordered data packets? Is that why we have the 7th bit 0 for reliable and 1 for unreliable (which I would reverse, personally)?

Yes. I have actually changed the meaning of that bit in the latest version on there, using the ACK bit instead for reliable/unreliable (since ACK is only used when you're doing reliable packet transmission) and used that bit instead to signify ordered/unordered receipt.

[Jove]

Why are you including a checksum in the packet?  The UDP header already contains a checksum of both header and data.

If the UDP packet arrives, it's contents are as errorfree as a checksum can make them, so adding an extra one won't do much good. If you wish extra protection, consider adding a CRC.

[contingencyplan]

Well, the reason we are using a checksum on the RUDP packet is because the quasi-standard information regarding the protocol all require it. However, the wording in these documents is not clear when it talks about "RUDP is layered on the UDP/IP Protocols" - does that mean that it is physically layered on them (RUDP packets are sent inside UDP packets), or that the methodologies for RUDP are based off those for UDP (and thus RUDP packets are their own beast, sent and managed in their own way). I'll agree, the checksum redundancy seems to point towards the latter, but I'm still not sure.

Feel free to post more comments and information as you come across it.

[Jove]

I stand corrected. I assumed you were going to implement something on top of UDP. RUDP does not work that way. It is layered on top of IP and would indeed require a cehcksum. I found my information here, including RFCs.
From what I saw however, this protocol never really got off the ground. I cannot find implementation in the linux kernel and google didn't seem to return any references for windows either.

Are you really planning on implementing it on top of raw IP? You could indeed save some bandwidth by implementing those protocols in userspace, but is it worth it? Using UDP is easier and maybe even faster (since some networking cards have UDP checksum support built into the hardware). You can still add the necessary features inside the UDP pdu. You will also have a lot less trouble with things like routers who do NAT. Current, with your protocol unsupported by the router, this would mean it is incapable of distinguishing two different client PCs behind 1 single IP. To support it you would need do some kind of channel negotiation in the connection setup.

[contingencyplan]

So what you're saying is to do the "extension" idea - take the stuff that's already done by UDP and leave it in the UDP header, then have a secondary header for the remaining RDP stuff?

That sounds like it might work, with some tweaks to the spec...

[Morgul]

Actually, if I had understood that there was some thought of doing RUDP on top of just IP, I would have spoken up, and recommended the RUDP header inside the UDP header idea. It doesn't make sense to do all the leg work for RUDP on IP. Seriously, it just isn't worth it, imho.

[contingencyplan]

Actually, if I had understood that there was some thought of doing RUDP on top of just IP, I would have spoken up, and recommended the RUDP header inside the UDP header idea. It doesn't make sense to do all the leg work for RUDP on IP. Seriously, it just isn't worth it, imho.

Ditto.

[whitelynx]

Yeah, the original idea was to simply put a reliability layer on top of UDP, and personally I never cared much if it matched up with the RUDP spec.

I wasn't aware that UDP already included a checksum, or I would have left that out. We'll make sure we take that into account when we get around to working on the protocol some more. Thanks for the input!