Advertisement

sequence for reliable udp protocol

Started by October 02, 2003 04:14 PM
4 comments, last by Maik Lathan 21 years, 4 months ago
hi, currently i implement a network-module for a project. it''s a game. i use winsock + UDP. what i want is to make my own protocol reliable based on udp. there''re different approaches for it. i decided to use sequence numbers. on both sides client/server i store last_send_sequence and last_received_sequence, now i can drop out packets which are out of order or duplicated by checking if the sequence_number is smaller or equal last_received_sequence. my sequence numbers are unsigned long. i faced into a problem. lets say one side sended already 2^32 packets so the sequence number is 0 after the next ++ but on the remote side the incoming_sequence is still 2^32. then if i use my check again if(sequence_number[0]<=last_received_sequence[2^32]) the point is that this condition always fails and so every packet gets dropped. this happens when one side sended 2^32 packets. where is the problem or missed i something. thanks in advance. ciao maik
ya know thats a LOT of packets .. i dont think you will aproch that number unless the clients are going to be connected for days...

but if your worried use a dubble :D
Advertisement
I think you are unlikely to exahust an unsigned 32 bit number as a packet id, assuming that those ids are exculisive on a per user basis. Do some numbers, lets say a 1 Kb/sec transfer rate, at an average of 40 udp packets/sec.

It would take a continous stream of data for over 3 years at that rate for a user to cycle through all the ids. Even at 10x the rate would still take you down to 4 months of continous connection.

If however for some reason you wanted each packet from all the sessions to have a unique ID you would exhaust it in a matter of hours depending upon the number of users. Say a conservative 100 users at the 40 packets/sec will exahust the IDs in 12 hours.

So switch to 64 bits if your going to need unique ids for the entire application. It will take over 10 billion years to exhaust at the 40 packets/sec rate.

Good Luck

-ddn
Your going about this sequencing the wrong way. You want to just loop around and reuse sequence numbers instead of sending an unsigned long. Try sending a byte instead and loop around 0 - 255.

Try looking up "Sliding Window Protocol". This is the best implementation of what your trying to do. I use it successfully in my Reliable UDP protocol.

Good luck,
Synth0id
There is no point in doing anything at all, you'll die pretty soon anyway.
What synthoid said. Don''t forget that (2^n == 0) for an integer n bits long. So if you''re at 2^32-1 (the max) and increment one, then it becomes 0. Your check, as you showed it, would work. You''d probably have found that out for yourself if you had actually sent 4 billion packets, but odds are you haven''t gotten around to it

I personally used a 16 bit sequencer, because it was likely enough to me (in theory) that there could be a >256 packet gap due to a lag spike. In that case you''d be hosed if those packets in la-la land eventually made their way to their target and had the same sequence numbers as the current packets. Note that I didn''t do much testing on this, because I never got around to testing on crappy connections (such as overworked dialup ISP), so it may well be that 256 is more than enough, in which case it would fit very nicely.
thanks for all the answers, i''ll try...

ciao maik

This topic is closed to new replies.

Advertisement