[ENet-discuss] enet_peer_queue_acknowledgement and big packets

[Lee Salzman]

Ugh, the top part of my reply got cut off the e-mail when I pasted it 
in. To paraphrase
what the missing part said:

Sequence numbers are only 16 bit and are expected to 
overflow/wrap-around. The
sequence number space is divided up into fixed-sized windows, so that it 
ultimately
behaves like a ring-buffer of sorts.

Lee

Lee Salzman wrote:
> So if peer A  sends a packet  in sequence number window W to peer B, 
> and B receives
> this, this is a  guarantee that all packets  older than window W-N all 
> got from A to B
> and got  acknowledged - otherwise A would simply stall sending until 
> that did happen
> before  sending the packet in window W. Below W-N is a buffer zone of 
> unused windows
> - keeping in mind that below W-N it eventually wraps around again - 
> where unused means
> all packets previously sent from that window before have been 
> acknowledged.
>
> The window W can only advance to send a packet in the next window 
> (W+1), if at
> least one packet in window W was acknowledged, AND if a certain number 
> of free
> windows F ahead of W are all completely unused, i.e. W+1...W+F-1 are 
> unused. Or to
> tie it to the above paragraph: W+F = W-N in the weird wrap-around logic.
>
> On the peer B, packets with sequence numbers less than the last consumed
> sequence number (old packets) need to be dropped. However, due to 
> wrap-around,
> a packet with lesser sequence number can represent either a genuinely 
> old packet,
> or one that is a new packet and has wrapped around via overflow of the 
> sequence
> number.  So it uses the heuristic  that so long as the packet is 
> within a certain
> range of the last consumed packet, it will accept it. But if the 
> packet is so far
> away that it is ahead of the W-N...W range a packet might span, the 
> packet will
> just be dropped by the receiver  assuming it was an old packet from a 
> prior
> wrap-around. The packet is not acknowledged so that if it was actually 
> a new packet
> that just got way ahead, the resend will act to disambiguate it, 
> provided the
> peer B continues to consume packets. That encompasses the first part of
> that "if()".
>
> However, it is feasible that some older packet was consumed, but never 
> properly
> acknowledged. So the second part of the "if()" is there to limit the 
> scope of the
> test, to allow for this acknowledgement, while still making sure that 
> any packets
> ending up dropped by the above heuristic never get an acknowledgement 
> at all,
> to force a resend to occur. It's also there to prevent peer A from 
> labeling
> windows as free while B is still processing them.
>
> Lee
>
>
> Ale wrote:
>> Hi,
>>
>> trying to send very big packets in RELIABLE mode led me to a point in 
>> which
>> the receiver of the packet doesn't send the acknowlegde to the fragment
>> just received anymore.
>> Being more specific, I find enet_peer_queue_acknowledgement
>> is not queueing the ack in the acknowledgement list,
>> because it returns at the following lines:
>>
>> if (reliableWindow >= currentWindow + ENET_PEER_FREE_RELIABLE_WINDOWS -
>> 1 && reliableWindow <= currentWindow + ENET_PEER_FREE_RELIABLE_WINDOWS)
>>           return NULL;
>>
>> Then the sender receives no more acks, tries to resend the fragment and
>> ultimately disconnects
>> (also, enet_peer_queue_acknowledgement returns ENetAcknowledgement *,
>> but the return value is never tested by the callers...)
>>     It seems like there is a possibility for a fragment (part of a 
>> RELIABLE
>> packet)
>> to be received without sending the acknowledgement, while the sender
>> really waits for it...
>> is that on purpose?
>>     I was wondering what is the purpose of the if(...) condition, so 
>> I am
>> asking the meaning of reliableWindow, currentWindow
>> and the whole concept of window in enet.
>>
>> thanks
>> Ale
>> _______________________________________________
>> ENet-discuss mailing list
>> ENet-discuss at cubik.org
>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>
>>   
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>