You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
each packet carries a packet_id, and the current implementation requires it to be strictly the next one of the last received. now, in UDP packets may arrive out of order, and if this happens, we discarded all future packets (i.e. not sending back an ack, not storing them anywhere); and wait for the exact next packet (with packet_id being last_received_packet_id + 1). A more optimal strategy could be to accept future packets in a window, ack them, and carry some data structure (list?) with the holes of the packet_id space.
related is the handling of old packet_id: assume the peer send us 5, we acked, they send us 6, and 5 again (since the ACK was lost on the way). currently, we ignore/drop the re-sent 5; whereas a well-behaving implementation should likely re-send the ACK for 5.
The text was updated successfully, but these errors were encountered:
each packet carries a
packet_id
, and the current implementation requires it to be strictly the next one of the last received. now, in UDP packets may arrive out of order, and if this happens, we discarded all future packets (i.e. not sending back an ack, not storing them anywhere); and wait for the exact next packet (with packet_id being last_received_packet_id + 1). A more optimal strategy could be to accept future packets in a window, ack them, and carry some data structure (list?) with the holes of the packet_id space.related is the handling of old packet_id: assume the peer send us 5, we acked, they send us 6, and 5 again (since the ACK was lost on the way). currently, we ignore/drop the re-sent 5; whereas a well-behaving implementation should likely re-send the ACK for 5.
The text was updated successfully, but these errors were encountered: