Sign in to follow this  
pasman

ACK dilema

Recommended Posts

hi, i've implemented a basic ACK system on UDP for my game and while testing it over the net something strange happend:)...when i send a text to the server, as the client I wait for an ACK from the server and resend if needed...but sometimes the message got to the server...but the ACK didn't get back to the client so it sent it again..and again:). I guess i could prevent this if i order the packets, but what if i don't need that for that specific case? Any ideeas? thanks [Edited by - pasman on August 5, 2004 7:37:07 AM]

Share this post


Link to post
Share on other sites
Sounds like it's doing exactly what it's supposed to.

If you want guaranteed delivery, use TCP.

Since everyone on this forum wants to use UDP... you'll need to add some sort of duplicate packet checking code to the server side. If it gets a dupe packet, send another ack [assume the first was lost]

Share this post


Link to post
Share on other sites
You need to put a sequence number in your packets to detect dups. i.e. when you send a packet stick a number in it that says it's packet #14 (or whatever). The other side keeps track of what packets is received and if it's already received it goes ahead and ACK's it and then throws it out.

Google for "sliding window protocol" for more info on this kind of stuff.

Share this post


Link to post
Share on other sites
first of all thank you for your responses and i'll look into SWP.
now...all the packets have ID sticked to them, this is how i handle ACKs, but would it work if i'd keep a list of most recently received packets (that were ACKed)? but when having 10000 users on a server wouldn't that be a little too much? And also shouldn't i use the same dup check on client side? thanks

Share this post


Link to post
Share on other sites
Yes, you usually keep a list, and yes, you need to do it on both ends, and yes, there's a reason why 10,000 users per server isn't all that common to see.

Of course, just keeping a list of spans of acked and unacked packets won't take much memory. I'd be surprised if it's bigger than 100 bytes per user! The bigger memory hog might be keeping copies of all sent packets until they are acked.

Anyway, you can stop accepting new packets if the list grows too big, and send some kind of NAK to force the client to catch up.

Share this post


Link to post
Share on other sites
Client or server doesn't really mean anything. What matters is what you're doing. If you're trying to send or recieve reliable UDP then you need to worry about acks, duping, dropped packets, reordering, etc, etc.

Typically what you do is to keep track of the minimum sequence number you'll accept and then which packets in your window that you've already recieved. When you get the packet at the bottom of the range then you can bump up the minimum.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this