Jump to content
  • Advertisement
Sign in to follow this  
SymLinked

TCP / UDP advice

This topic is 4413 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

Hello, We develop a game where we use UDP for our communication (TNL) and it's wonderfull. I am now toying with the idea of creating another server that the client connects to as well, like a auth server of some kind. So I ran into the TCP vs UDP dilemma, and quite honestly (after 3 days of research) I still can't decide which one to use. The auth server obviously will not send packets to clients in quick succession, just occasional CRC/login checks. TCP looks sexy in that I don't have to spend time implementing guaranteed transfer, which I need. UDP looks sexy in that I can chose whether I want the packet to be guaranteed or not, and that I might save a few bits. I saw comments in a few places where it was mentioned that TCP/IP is limited in that it opens a socket to each connection and that it would be a huge resource problem for the server when many are open at the same time. What's so heavy about opening a socket? I have also heard that mixing TCP and UDP is a bad idea.

Share this post


Link to post
Share on other sites
Advertisement
Hi,

My experience is that it is better to use right tools for the right job. If you need to handle packet fragmentation, reordering and packet loss. Why not use TCP? I don't think that TCP overhead is a problem nowadays.

Share this post


Link to post
Share on other sites
Hi Murtzi. Thanks for your post!

Quote:
Original post by murtzi
Hi,

My experience is that it is better to use right tools for the right job. If you need to handle packet fragmentation, reordering and packet loss. Why not use TCP? I don't think that TCP overhead is a problem nowadays.


This is my impression as well! Though these things can be implemented ontop of UDP, TCP already has them implemented.

So then my only remaining question is: How about mixing these two protocols? The connection to the gameserver uses UDP, while the connection to the masterserver uses TCP.

Will I run into priorization issues between the two, or any other problems?

Share this post


Link to post
Share on other sites

From previous posts in this forum, a lot of people have mixed the two protocols, but in an ideal world, it would be best to just stick with one or the other for everything. Realistically, I don't see there being much of an issue for a client. The problem does become a "problem" on a server when you're using udp and tcp. For TCP you need a socket per connection (usually).

GCS584

Share this post


Link to post
Share on other sites
Granted I'm no expert, but I think that if we go back 10 years when modems were prevailent that using TCP for a multiplayer game would be disasterous. Modems tend to lose a lot of packets.

Now everything is moving to digital connections where the QoS is much much higher that modems. The connections drop only a fraction of the packets they used to and even when packets do get dropped, the connection is able to recover more quickly.

I think it might still be a stretch to using TCP for a FPS game, but I dont think it would be as bad as one would think.

Just my random thoughts.

-=[ Megahertz ]=-

Share this post


Link to post
Share on other sites
The thing that can kill TCP is that if even a single segment is lost the stream of segments is held up, even if other segments have arrived. In a fast paced system like a game this is usually unacceptable.

With some kind of reliable UDP layer, you can choose whether to deal with unordered packets immediately even if you are waiting on delivery of others. This gives you a lot of flexibility.

You could have some sort of mixture of UDP/TCP if you wanted, a UDP socket for unreliable and/or unordered data and TCP for guarenteed/ordered data.

But you can get UDP wrappers that can simulate TCP-like connections while retaining other UDP options.

Share this post


Link to post
Share on other sites
Why not re-use your existing TNL code for the other client/server connection?

If you don't want to do that, then TCP could work fine, as there is no critical latency-dependent data in that stream.

Share this post


Link to post
Share on other sites
Quote:
Original post by SymLinkedHello,

We develop a game where we use UDP for our communication (TNL) and it's wonderfull. I am now toying with the idea of creating another server that the client connects to as well, like a auth server of some kind.

So I ran into the TCP vs UDP dilemma, and quite honestly (after 3 days of research) I still can't decide which one to use.

The auth server obviously will not send packets to clients in quick succession, just occasional CRC/login checks.

TCP looks sexy in that I don't have to spend time implementing guaranteed transfer, which I need. UDP looks sexy in that I can chose whether I want the packet to be guaranteed or not, and that I might save a few bits.

I saw comments in a few places where it was mentioned that TCP/IP is limited in that it opens a socket to each connection and that it would be a huge resource problem for the server when many are open at the same time.

What's so heavy about opening a socket?

I have also heard that mixing TCP and UDP is a bad idea.


You might consider an alternative which offers the benefits of both.

Share this post


Link to post
Share on other sites


How complex are the interactions done by your proposed Authentication server??

If its simple Request & Reply then it should be easy to do in UDP (without the TCP connection overhead). That server might also have a connection to the main server (that does something with that authentication ??) That connection would be of long duration and likely a TCP connection would be warranted there (or do your own 'reliable' with UDP as youve already done elsewhere.)

Share this post


Link to post
Share on other sites
Thanks everyone for your comments.

Quote:
Original post by MatrixCubed

You might consider an alternative which offers the benefits of both.


Thanks for your suggestion. However, TNL works just fine and switching in the middle of a game sounds painful, which is why I didn't ask for alternatives :)

Quote:
Original post by hplus0603
Why not re-use your existing TNL code for the other client/server connection?

If you don't want to do that, then TCP could work fine, as there is no critical latency-dependent data in that stream.


That's something I have been toying with, but I have not figured out how to use the ACK/gauranteed functions after 3 days of research :) NetEvents are useful in TNL when both client/server have the same classes. But if they don't then class ID's will not match both sides.

But yeah, the loginserver is standalone and if I went with TCP/IP it would be the only protocol used on that very server. The client would have to mix, of course.

You went with only UDP for your projects, correct?

Quote:
Original post by wodinoneeye


How complex are the interactions done by your proposed Authentication server??

If its simple Request & Reply then it should be easy to do in UDP (without the TCP connection overhead). That server might also have a connection to the main server (that does something with that authentication ??) That connection would be of long duration and likely a TCP connection would be warranted there (or do your own 'reliable' with UDP as youve already done elsewhere.)


Aye, mostly request and reply. Thanks man.

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!