How to add reliability?

Started by
6 comments, last by jacksaccountongamedev 19 years, 7 months ago
I got a working UDP system working and sending packets. But the problem is that there is a chace that some packets are dropped. In one sense this doesn't matter, not every packet is needed if they are all updates. But I would like to add reliability to packets when they contain information that must be recieved on the other end. This includes things like streamed datafiles, and server commands including "the map is changing" and "bob joined the game" I would also like to avoid the standard send1->ack1->send2->ack2... because the reliable information should be allowed to take some extra time to finish being collected and acked, while non-reliable packets are being sent. And so I would like to hear some of your ideas for implementing this...
Advertisement
use TCP for packet types that need to get there. TCP is a system built on top of UDP to make packets reliable.

-me
Well, you could send a packet and have a bit in the header that states whether the packet requires an acknowledgement, and if it does give the packet and ID. This way, the machine sending the packet will simply put the packet in a list until it receives a response, OR a certain time expires and resend. In the meantime any data can keep being sent/received, and every little while check the packets in the list. I would probably use a doubly linked list and put the packets in order of which requires an acknowledgement first, this way when you are comparing time passed to time till resend, you need only check the first packet in the list, all the others have more time :). Also, the chances of getting the earlier packet first are pretty good so when a packet comes in, you won't have to traverse the list as far on average. Once you receive an ack, you traverse the list and remove the packet that matches the ID sent in the ack. TCP is another alternative, but it requires a seperate port and requires using a connection state. The great thing about udp is that it's connectionless. One huge advantage, at least in online games, is you could have seperate servers with a list of IP's, and during gameplay switch servers without having to "close" a connection. This may not seem like a big deal, but imagine playing a MMORPG where each section had it's own server, one could simply have a list of locations with IP's and simply move around and switch servers without playing the connect/disconnect game :).

That said, a lot of games (mostly few player online games) will work perfectly well with TCP and it would even be easier to implement, as you could put it into another thread and let it just send the packet you tell it without interfering with the rest of your program.
Thanks...

I'm trying to avoid the TCP.
So looks like I'm just going to have to make lists for
the packets sent/revieved and check timeouts and such.
you could have a look at this:

http://enet.cubik.org/

Its a udp wrapper which includes sending reliable packets... The source code is included so you could read through it and see how they did it :)

I used it myself in one of my games and i've got to say its really great. I've had no problems with it at all.
Quote:Original post by Palidine
use TCP for packet types that need to get there. TCP is a system built on top of UDP to make packets reliable.

TCP is not built on top of UDP. TCP is a seperate protocol.
Thanks for the link SpaceDude, that is along the lines
of what I'm trying to make.
Uhhh… I don’t mean to hijack this thread but I have an Enet question for you Spacedude:
Basically, I’m unable to get my Enet programs to work on Windows 98 or Windows Me machines – on enet_host_connect() the thing crashes and spits out an error about kernel.dll whether a connection was available or not. These programs do, however, work perfectly on computers running Windows XP. Is this not odd? Did you have any troubles as such? If not I’d be grateful if you might send me an example of you’re connect code so as that I have a basis of comparison…

This topic is closed to new replies.

Advertisement