[ENet-discuss] enet_peer_queue_acknowledgement and big packets

[Lee Salzman]

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
>
>