well, i guess the topic is pretty self-explainatory... and how am i supposed to implement a decent way of controlling the packets?

Reliability depends on many factors. Main ones i can think of are the physical hardware that the packet travels through. How busy those lines of travel are. And many other random factors. I have read of people losing 1 in 10 packets. I''ve heard of people losing 1 in literally 100,000 or more packets. It really depends on so many factors that a specific number will never be placed on it.

A decent way that I know of for controling this is that if you are sending data that is critical that it arrives then you implement a function on the other end to send a confirmation packet saying "Hey, I got packet xxx from you". If you get packet 1 and 3 then you can send back "Hey, I''m missing packet 2"

From what I know, there really isn''t much more you need to do in order to make UDP reliable. The trouble come when you try to implement the reliability. Which data structure you use as a buffer to store incoming packets to make sure you have them all. How many packets do you consider a "safe" number to store. How to handle events that fall outside of the bounds of your buffer. Like if your buffer can hold 5 packets and you recieve 1,2,4,5,6 but not 3 and then packet 3 comes in last but your buffer is full so you will miss it.

Personally, I think I''d set up a buffer to hold 3 packets of each packet type you need to send. Most games/programs have multiple types of packets that are sent. I say store 3 because this allows you a case of receiving 1,3 and requesting 2 and if you then request packet 2 and recieve something else then you can discard them all and send a request askin for packet 1 all over again. I think this would be better than a dynamic structure when it comes to attacks. if it''s dynamic then I could easily send you packet 1 then skip 2 and send you face ones ad infinitum quickly eating up your resources. 3 is the minimum that you can get by with but you can choose 4,5, or whatever you think you need.

Of course this is coming from someone who is still in the process of designing his first network code so don''t take my word as law unless enough others here concur.

Hope this helps,
Webby

yes, i''m totally with you with the buffer and the ack-reply, but what if my ack-packet from the client won''t reach the server?

If the very odd case happens and your ACK packet doesn''t arrive then the machines just pretend like it failed and resend the packet as normal. If you get the ACk later on another day or something then you just disregard it as old data. Keep a counter of what packet you are dealing with. If you get one that''s lower than the one''s you''ve already seen then it''s just duplicate.

One quastion I have on the keeping a counter bit though. I''m assuming you use a short of an integer but what when your packets reach maxshort or maxint in number. Do you restart from 0? Seems logical except for cases like checking if X comes before Y in which case packet 0 comes before 64,000 but it also comes after it.

Any ideas there aside from the general check of
if thisPacket.num == 0 && lastPacket.num == 64,xxx then OK.packet

I guess the above would work but it adds an extra if statement into the logic.

Webby

Adding 1 to 65535 makes it roll over to 0. No special case needed.

if ((lastPacket.num + 1) == thisPacket.num){  // correct order}else{  // incorrect order} 

The general case is: (maximum_int + 1) == minimum_int , and works for all integers, signed and unsigned.

[edited by - foofightr on May 14, 2003 6:41:04 AM]

Very cool.

Amazing the little things you learn even after 4 years experience with C++

Webby

quote:

---

Original post by foofightr
Adding 1 to 65535 makes it roll over to 0. No special case needed.

if ((lastPacket.num + 1) == thisPacket.num){  // correct order}else{  // incorrect order}  

The general case is: (maximum_int + 1) == minimum_int , and works for all integers, signed and unsigned.

[edited by - foofightr on May 14, 2003 6:41:04 AM]

---

I think he was talking more about.. what if you have code in place to buffer 3-4 packets, and you CAN work with slightly out of order packets. You''d have to test packet-1, packet-2, packet-3, etc to see if it is within your range. Then if it is, handle the packet, and clear out the buffer of packets that arrived after it (if they are dependant on it arriving).