By the time it gets there, reliableSequenceNumber < channel ->
incomingReliableSequenceNumber indicates a roll-over in the sequence number space,
not an old packet. So, essentially, the sequence number rolled over and became small
again, but that represents still a 'higher' sequence number in the overall scheme.
The actual dropping happens earlier in the code here:
if ((command -> header.command & ENET_PROTOCOL_COMMAND_MASK) !=
ENET_PROTOCOL_COMMAND_SEND_UNSEQUENCED)
{
reliableSequenceNumber = command -> header.reliableSequenceNumber;
reliableWindow = reliableSequenceNumber /
ENET_PEER_RELIABLE_WINDOW_SIZE;
currentWindow = channel -> incomingReliableSequenceNumber /
ENET_PEER_RELIABLE_WINDOW_SIZE;
if (reliableSequenceNumber < channel -> incomingReliableSequenceNumber)
reliableWindow += ENET_PEER_RELIABLE_WINDOWS;
if (reliableWindow < currentWindow || reliableWindow >= currentWindow +
ENET_PEER_FREE_RELIABLE_WINDOWS - 1)
goto freePacket;
}
The reason the above code works, if the packet was old or if it is actually a roll-over, its reliable window gets bumped into the space of rolled-over windows. If a roll-over happened, the current window of the channel would be near the top of the sequence number space, and the reliable window of the packet would be near the bottom, so bumping it should not put it outside of the current window + a margin of reliable windows that are "guaranteed" to be empty (or rather free of old packets, by virtue of it taking a rather long time for the sequence number to wrap, and verifying all packets within that bubble have been acknowledged) at the end of the sequence number space for the purpose of disambiguating this case, as new packets will never advance beyond this bubble of free sequence number space. If it was, however, just an old packet, reliable window and current window would be close enough to each other that bumping it puts it outside of that range of free windows instead,
thus hitting the free packet goto there.
This is totally code you should not try to understand while sober, it is harder
to understand that way, I think. Or at least make sure you are in a
sufficiently abnormal state of consciousness to understand wrapping sequence
number spaces...
On 06/15/2012 05:54 AM, kaka chen wrote:
Hi All:
I am reading the source code of enet-1.3.4, but have some questions now.
Can someone explain when enet_peer_queue_incoming_
commands() process reliable command, if the reliableSequenceNumber < channel ->
incomingReliableSequenceNumber, it will be added at the end of the channel ->
incomingReliableCommands? Then how it worked? Why not drop it? Thanks!
790 case ENET_PROTOCOL_COMMAND_SEND_RELIABLE:
791 if (reliableSequenceNumber == channel ->
incomingReliableSequenceNumber)
792 goto freePacket;
793
794 for (currentCommand = enet_list_previous (enet_list_end (& channel
-> incomingReliableCommands));
795 currentCommand != enet_list_end (& channel ->
incomingReliableCommands);
796 currentCommand = enet_list_previous (currentCommand))
797 {
798 incomingCommand = (ENetIncomingCommand *) currentCommand;
799
800 if (reliableSequenceNumber >= channel ->
incomingReliableSequenceNumber)
801 {
802 if (incomingCommand -> reliableSequenceNumber < channel ->
incomingReliableSequenceNumber)
803 continue;
804 }
805 else
806 if (incomingCommand -> reliableSequenceNumber >= channel ->
incomingReliableSequenceNumber)
807 break;
808
809 if (incomingCommand -> reliableSequenceNumber <=
reliableSequenceNumber)
810 {
811 if (incomingCommand -> reliableSequenceNumber <
reliableSequenceNumber)
812 break;
813
814 goto freePacket;
815 }
816 }
817 break;
Kaka Chen
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
