Sign in to follow this  

How to add reliability?

This topic is 4852 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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…

Share this post


Link to post
Share on other sites

This topic is 4852 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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