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?

3 probably would never happen.

Guarenteed packets with DPlay (or TCP/IP with Winsock) removes all issues for you. It''s just slower.

Ben


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

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.)

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

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]

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]

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]

UDP and TCP implement their own checksums to check packet integrity.

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

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.