Archived

This topic is now archived and is closed to further replies.

Packet reliability

This topic is 5671 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I''m curious - I haven''t seen this discussion as I''ve traversed the posts... I know that there are a number of possibilities of packet unreliability in network programming, but I just want to make sure I''m on the right track with my thinking... When programming a network game, you have to be prepared for: 1) Lost packets (the packet is just gone, next packet will need to update the state fully) 2) Packets that arrive out of order (packets sent as A B, and arrive as B A) 3) Packets arrive more than once (sent once from source, but arrive more than once because of inaccurate system self-checking) Are these all reasonable to watch out for? (I know packet loss is a given). And am I missing anything? Also, does guaranteed delivery avoid ALL the troubles above?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
3 is more likely to happen if you are using some sort of reliable transfer, with unreliable transfer it doesn''t happen so much, as it just gets sent once and doesn''t (normally) get duplicated while being routed, although it can happen. It''s more likely to happen with reliable transfer as a packet might be slow arriving and be resent and then both packets get there, but reliable transfer takes care of this for you anyway so it doesn''t matter.
Once a connection is initialised, TCP isn''t actually slower at transferring data, it is the mechanisms that make it reliable that can cause data to be sent less quickly, and DPlay actually uses these same mechanisms for it''s reliable data delivery (sliding window, etc.)

Share this post


Link to post
Share on other sites
3 happens all the time if you have a broadcast protocol and multiple NIC''s or if the broadcast goes across multiple protocols (i.e. IP and IPX).

Another thing to watch out for is late packets. e.g. packet 1 gets dropped, packets 2 - 2000 arrive over the next couple minutes, then packet 1 finally shows up.

-Mike

Share this post


Link to post
Share on other sites
Thanks for the input. I think I'll just play it safe and watch for all three. It might do me some good to set up a packet send analysis program, which shouldn't take too long to write. Someday

[edited by - Waverider on June 6, 2002 2:02:38 PM]

Share this post


Link to post
Share on other sites

  
int a_winsock_server::CheckSum(a_message data)
{
int temp=0;
char * str = data.message;
char * ar = (char*)&temp;
for (int j=0; j<data.length; j++)
ar[j%4] = ar[j%4] ^ *str++;
return temp;
}


for your message I use a struct

int ID
int CheckSum
int Length
char * Message

packet.CheckSum=CheckSum(packet.Message)

when you recieve a message compare it''s stored CheckSum to the checksum of the recieved message. That''s pretty much all you need for checking packet integrity.

Ben


IcarusIndie.com [ The Rabbit Hole | The Labyrinth | Programming | Gang Wars | The Wall | Hosting]

Share this post


Link to post
Share on other sites
Are you saying it's also possible for a packet to be garbled internally?

Your checksum suggestion WOULD help against hackers, somewhat, mind you...

[edited by - Waverider on June 6, 2002 6:00:00 PM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
UDP and TCP implement their own checksums to check packet integrity.

Share this post


Link to post
Share on other sites
The IP checksum is not always reliable. Routers need to fiddle with the packet as it goes through and they rechecksum it. If it corrupted the message after receiving it and before rechecksuming the error won''t be detected when the message finally hits your machine.

And yes, this has been known to happen in the real world.

-Mike

Share this post


Link to post
Share on other sites
plus the checksum algo used for ip is pretty simplistic to other methods (like md5). this is because of bandwidth vs cpu usage. you as a game designed can afford to use more cpu handle packets then a router since its important that packets are not corrupt. also you wont need anywhere near the bandwidth that routers perform, so md5 should be plenty fast, though it WILL be slower then some of the other "simple" checksum algos. put it this way, linux users trust using md5 checksums (well ussually mulitple checksums using different algos are used for things) for patches and such to ensure the file is not tampered with (this includes security software).

ip checksums only let the dirver/os know if the packet was corrupt (then the os/driver can just drop it depending on how it is designed to handle things). ipv6 is not going to use the current system of checksumming (its still unclear witch method will be used), which says something about its reliability vs other more cpu intensive methods.

Share this post


Link to post
Share on other sites
I was also going to say that 3 tends to happen when you broadcast, particularily with multiple protocols in use.

TCP''s guaranteed delivery doesn''t exactly avoid those problems, it handles them - and it''s method of handling them may not be optimal for your game.

I believe the guys at FunCom managed to make a mmorpg work over tcp (though how well it works is an issue of debate) for Anarchy Online.

Share this post


Link to post
Share on other sites