Jump to content
  • Advertisement
Sign in to follow this  
ronkfist

Thoughts about UDP

This topic is 4543 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 am thinking about implementing UDP into my engine but there are some things im not sure of. I've come to the conclusion that you can only get the maximum out of UDP when you only send packets that do not need to arrive at the other end. Once you start sending packets that must arrive, then you have to start resending packets (also the ones that dont need to arrive) and then you can aswell use TCP right? But in reality you will always have to send packets that need to arrive, so I was wondering if it would be a better idea to use 2 connections per client, 1 UDP and 1 TCP?

Share this post


Link to post
Share on other sites
Advertisement
The netowrking engine I made does this.. I create packets with reliability and ordering tags, this allows you to make sure the packet arrives and/or is in the correct order. There are lots of articles on how to make reliable UDP. There is no reason to have both TCP and UDP.

theTroll

Share this post


Link to post
Share on other sites
ronkfist,

That is pretty much the most common question on this forum. Check the FAQ HERE for common answers.

To briefly answer your question, UDP is useful even when packets need to arrive on the other end, you just need to add a layer on top of UDP which duplicates *some* of what TCP does in the way of making sure packets arrive and resending if not.

The benefit of UDP over TCP is that you can still send other packets while waiting for a re-transmit of a previous packet. As well, whenever you send a packet with TCP and it fails to reach its destination, its re-sent automatically, but the state information is usually out of date (irrelevant) by the time it reaches its destinations.

To look at it another way: A character is moving in a forward direction. You send a packet saying tha character C is at postion X at time T. When you send that packet the information is correct. But if the packet fails to reach its target, TCP will keep sending the same information over and over until its received and acknowledged.

But if you use UDP, you can detect that a packet failed to reach its destination and instead of re-sending the exact SAME packet, you can instead send a "new" packets which is more up to date. ie, the character C is now at position X+2 at time T+2.

Cheers!

Share this post


Link to post
Share on other sites
The idea about sending the updated information if sending of the previous fails is very good.

The idea of having both TCP and UDP, on the other hand, is very bad. It is possible, it's been done, but you'll end up in problems with syncing the stuff from the tcp socket and the udp socket. I suggest that you don't do this.

My approach to this is to classify packets to reliable (stuff that needs to be delievered in time) and unreliable.

For example, player join and similar packets are classified as reliable, and they are delievered in a TCP-ish fashion with ACK packets.

The unreliable packets, such as player status are stuff that is sended over and over again. So if one packet fails to reach it's destination, it really doesn't matter. There will be updated information available soon (or the connection has failed). What has to be taken care of is that packets have to be recieved in order. So, if a previously lost packet arrives late and a newer packet has already been recieved, the old packet is ignored.

Using this method, there needs to be an occasional (reliable) TCP syn-like packet to make sure the connection is still alive. There may be moments when there is no reliable transmission for quite a while or even a few seconds where no packets are transmitted, and the client/server cannot know whether or not there is a working connection anymore.

Hope this gives you an idea which way to go....

-Riku

Share this post


Link to post
Share on other sites
thx for the ideas, there were indeed some things I didnt think of.

I'll probably go with a solution like richard describes, because I really dont want to resend packets that don't need to be resend.

To do this I'll use 2 different kinds of packets like you said, ones that need resend when not arrived and ones that don't need to be resend. So I'll probably need 2 different 32bit sequence numbers which can never overlap eachother.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
ie, the character C is now at position X+2 at time T+2.


I'm not sure what you actually mean by this, but I will just give my opinion.
Don't send info which depends on other packerts (ie increment movements), instead send the actually location and time. Thus any packets(of this type) that are lost are not needed as there will be an new packet arriving shortly with the correct information.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!