[ENet-discuss] Channels and ordering

[Lee Salzman]

All packets within a given channel are ordered by sequence number. It 
also happens that a packets is delivered only if all preceding reliable 
packets in the sequence have been delivered, with missing preceding 
unreliable packets in the sequence simply being ignored, if this 
particular packet is ready to be delivered. If some packet later in a 
sequence has already been delivered, and the packet being considered for 
delivery is earlier in the sequence, it will be discarded; this rule 
only really effects unreliable packets, or packets that somehow 
duplicated in transit.

The way this works is that a sequence number has, in effect, two 
portions X.Y. The X portion being a reliable sequence number, that gets 
incremented when a reliable packet is sent, and the Y portion being the 
unreliable sequence number, which is reset back to 0. Now, when an 
unreliable packet is sent, X does not get incremented, but Y does. This 
is how ENet knows if there were any undelivered reliable packets 
preceding an unreliable packet in the stream, since the unreliable 
packet will have a higher reliable sequence number. So reliable packets 
serve as synchronization points in a channel, even across unreliable 
packets.

Lee

M. Rijks wrote:
> Hi everyone,
>
> A question concerning channels and ordering of guaranteed and 
> non-guaranteed packets. If I understand Enet well enough, channels can 
> be considered different queues of incoming packets. Now consider this 
> scenario: let's assume I'm sending both guaranteed and non-guaranteed 
> packets on the same channel, and that Enet spends some time receiving 
> a guaranteed packet (it won't 'give' the packet to me until it is 
> fully received). What happens for any non-guaranteed packet sent on 
> the same channel? I suppose the sending end could already have started 
> to send the non-guaranteed packet, then realizing one of the 
> guaranteed packets might not have arrived, and trigger a resend. Or 
> does it stall subsequent packets and wait for confirmation of the 
> previous message? If it doesn't stall, then on the receiving end will 
> Enet keep waiting for full delivery of all parts (when the packet is 
> large) before giving me subsequent packets that may have arrived in 
> between?
>
> All reactions appreciated!
>