For video games:
I would use sequence numbers. Unless it''s absolutely necessary, you can discard old packets or packets that were never received because the next one coming in or future dated one is more important. Ideally, the client starts his sequence off at 0, and increments it by one each message sent to the server. When the server receives the datagram, it compares the sequence # in the packet to the last received sequence # from that client. If it’s <= the current #, discard the packet as it is old or a duplicate, if it’s > current #, accept it and update the current # = sequence #. If you want to receive all packets, you could end up with worse performance than TCP due to packet loss in trying to get the client to send you every update. In conjunction with this you would have a prediction algorithm to update clients and yourself accordingly, so that movement and sensitive things like this are not jerky.

If you need to ensure safe delivery of important information (like item pickups), you can use a token-bucket algorithm. Essentially the client fills up one of his buckets (maximum buckets allowed = X) with the information he wants to send to the server. He’ll fire it off and wait for a response on that particular bucket (server filled information about anything, like what other clients are doing). By using certain latency guessing or averaging algorithms, if the bucket hasn’t returned, the client can fire it off again. On the server side, it would keep track of the bucket number so it can discard duplicates. This way you can separate weapon, item, or whatever information into their own buckets and send them in pieces for the server to process. This will have guaranteed delivery without relying on another protocol, TCP, to be enabled in parallel with UDP.

For application purposes:
Use TCP? Heh, what more is there to say =)

davedx, i'm doing the same thing, available here.

[Edited by - fenghus on December 22, 2004 2:20:08 AM]

look at crc32 in gamedev articles & Resources