Packet delay

You didn''t say why you are counting packets, but whatever the reason there is going to be a prolem. What if a packet is sent at 00:59, you reset the counter at 1:00, and the packet arrives at 1:01? It seems you are going to have overlap of the time boundries regardless of packet timing.

With regards to how late a UDP packet can arrive, RFC 768 defines what UDP is, but I didn''t see anything about timeout values. Maybe there aren''t any???

If I/we knew why you were doing this, we might be able to offer alternate suggestions.

Well, I use it for higher layer to ensure reliability/ordering/sequencing the packets. That''s why I need to count packets. I need to say ''this packet has num xxx, so it''s old, discard it''.

Packets don''t have set timeouts based on time, but they have a TTL (Time-To-Live) value. As the packet is routed across the ''net, routers decrement the TTL. If the TTL is decremented to 0 the packet is dropped and an ICMP TIME_EXCEEDED message is sent to the source of the packet to let it know what happened. (As a sidenote, this is how traceroute works... increase the TTL from 1 until we finally reach our destination)

Now you can estimate how long this is, but it can vary wildly depending on the route the packet takes... Maybe you''ll bounce off a few satellites and get routed back and forth across the country!

Anyway, a better way to handle this without ''counting packets'' or reseting the packet counter after a fixed amount of time would be to add a 32-bit sequence number in the header you wrap around the data you send - just like TCP uses. The speed at which this number wraps around depends on the amount of bandwidth you have. For TCP saturating a T1 (1.5Mbps) it takes about 6.4 hours to wrap around. For saturated 10Mb ethernet it takes about an hour to wrap.

There is a value called the MSL (Maximum Segment Lifetime) that gives a guesstimate as to the maximum time a packet could bounce around the ''net before delivery and it''s generally accepted as 120 seconds last I heard. But unless you plan on your wrapper being used to constantly send data faster than 300Mbps, a 32-bit sequence number is more than enough to avoid getting 2 values with the same sequence number. And if you don''t know, just make it a 40 48 56 or 64-bit number. Every 8 bits means 256 times more potential (though its another byte to send per packet, so only do it if you need to)

Anyway, the sequence number that you just let roll over will work fine.. and I imagine you''d run into some synchronization issues using anything that''s based on a timer. Keep in mind you only have to use a sequence number for packets that have to be presented in order, too. For data where order recieved doesn''t matter you can leave the sequence number out - shrinking that packet by a few bytes, and keeping your sequence number from rolling over as fast.

Good luck!
-nohbdy