G33X Nexus Entertainment > RaptorNL
Defining Reliable / Unreliable and Ordered / Unordered
contingencyplan:
Here is my current understanding of Reliable vs. Unreliable and Ordered vs Unordered. I'm hoping whitelynx can correct any misunderstandings I have on the subject.
Reliable vs. Unreliable: This refers to whether the packet must arrive at the destination. If a packet marked as "reliable" fails to arrive at the destination, then we must request that the packet be resent.
Ordered vs. Unordered: This refers to whether the packets must arrive (or at least be interpreted) in a specific order.
TCP is an ordered, reliable protocol, to the point that it will outright block (i.e., stop receiving data and just keep sending resend requests) if it misses something. RUDP is ordered reliable as well (I think), but it won't block if it misses a packet. Rather, it collects the numbers that it didn't receive in the past N time units and send a resend request all at once (in the EAK segment).
So assuming the above info is right (I honestly expect it to be wrong, personally, but whatever), how would an ordered, unreliable or unordered, reliable packet behave? Can we have such a thing as an unordered, reliable packet, since we have to know which packets actually made it to the destination?
These are the kinds of questions that keep me up at night... :-\
TCP is a reliable protocol, and will outright block (or at least wait) until it has received the packet it is missing. It seems to me that RUDP will not block if it fails to receive a packet; rather, it will continue receiving packets but will still request the packet from the sender.
Morgul:
From what I remember in my networking class, here's how the others would work.
Let's assume the following:
Packets sent: 1, 2, 3, 4, 5.
Packets Received: 1, 2, 4.
Unordered Reliable:
A request would be sent for packet 3 and 5. When these arrived, the data would be: 1, 2, 4, 3, 5. (No order, but we make sure we get all of them.)
Unordered Unreliable:
Simply do nothing. We have 1, 2, 4.
Ordered Unreliable:
Now, I'm not sure this exists. However, if it did, it would look like Unordered Unreliable, in all cases but one. Let's say we sent 1, 2, 3, 4, 5. however packets 3 and 5 are lost, and 2 is delayed. We would then have 1, 4, 2. No resend requests are sent, and the packets are out of order.
Make any sense now?
--Chris
contingencyplan:
Okay, so for unordered, unreliable, we'd use straight UDP, and for ordered reliable, we'd use TCP?
Morgul:
yup.
whitelynx:
--- Quote from: contingencyplan on November 02, 2006, 02:19:57 am ---Here is my current understanding of Reliable vs. Unreliable and Ordered vs Unordered. I'm hoping whitelynx can correct any misunderstandings I have on the subject.
Reliable vs. Unreliable: This refers to whether the packet must arrive at the destination. If a packet marked as "reliable" fails to arrive at the destination, then we must request that the packet be resent.
--- End quote ---
Almost... It just means that we have to try to provide a guarantee that it will get there. (with reasonable limits) There are two ways of doing this: requesting resends of missing packets, (perfect for ordered reliable packets because you know that one's missing when a sequence number is skipped) or resending any packet after a given timeout, unless an ACK for that packet has been received. (which could be useful for unordered reliable sending, but which may need to be discussed first.)
--- Quote ---Ordered vs. Unordered: This refers to whether the packets must arrive (or at least be interpreted) in a specific order.
--- End quote ---
Exactly.
--- Quote ---TCP is an ordered, reliable protocol, to the point that it will outright block (i.e., stop receiving data and just keep sending resend requests) if it misses something. RUDP is ordered reliable as well (I think), but it won't block if it misses a packet. Rather, it collects the numbers that it didn't receive in the past N time units and send a resend request all at once (in the EAK segment).
--- End quote ---
Actually, from my understanding, they both work the way that you described RUDP. TCP will queue up out-of-order packets until the previous packets arrive, and then pass them all to the application once they do. The biggest difference between TCP and RUDP is that RUDP cuts out a lot of the unused "features" of TCP.
--- Quote ---So assuming the above info is right (I honestly expect it to be wrong, personally, but whatever), how would an ordered, unreliable or unordered, reliable packet behave? Can we have such a thing as an unordered, reliable packet, since we have to know which packets actually made it to the destination?
--- End quote ---
Yes, we can, using the second technique for making reliable packets that I described above. We could also rely on sequence numbers, but simply pass all packets up to the application when they come in instead of waiting for older packets when an out-of-order one arrives. I'm not sure which approach would be best for us.
--- Quote ---Okay, so for unordered, unreliable, we'd use straight UDP, and for ordered reliable, we'd use TCP?
--- End quote ---
Actually, no, on both counts. We wouldn't use straight UDP because we need some sort of header in there so we can figure out what type of packet it's supposed to be. (since we can have multiple packet types on each socket... take a look at the channel/socket thoughts in the IRC log on that page) For the same reason, we can't use TCP at all for this; we'd have to create a new Socket to be able to do that. Instead, I'd like all 4 of these sub-protocols to be usable on the same socket at the same time, by opening a channel for each.
Navigation
[0] Message Index
[#] Next page
Go to full version