ACK dilema
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]
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]
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]
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.
Google for "sliding window protocol" for more info on this kind of stuff.
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
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
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.
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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement