Sign in to follow this  
Xeon06

TCP or UDP? Why not both!

Recommended Posts

Hey all, I am currently making a 2D fast-paced action-based network game. I have a working client and server and I can send messages between them. I don't have much experience making networked games but I have a Cisco CCNA 1 and 2 certification so I have some understanding on how networking works. Now I'm currently using TCP to transmit my messages, but I understand that TCP is slow and that I won't be able to use it when I start the real programming. So let's use UDP! But I also know that UDP isn't reliable. Some stuff needs reliability like shots, chat messages and the like. But player movement can be done with UDP. But here is what I don't get. Why are there debates about which one to use? Why not use both? UDP for speed critical stuff, and TCP for reliability critical stuff. I haven't tried using both yet (I can't try anything now, not on my good computer) but is it just undoable? Does it require opening two sockets? If so then I guess I can only use UDP, but how can I make reliable messages in UDP? Sorry for that wall of text, I hope you guys got what I meant. Thanks.

Share this post


Link to post
Share on other sites
Quote:
Original post by Xeon06
but I understand that TCP is slow and that I won't be able to use it when I start the real programming.


TCP isn't "slow". It uses same routers and same wires. But due to ordered, guaranteed delivery, if byte at time T fails to deliver, TCP will not deliver any bytes T+n until T arrives, via resend or after delay.

This is a direct consequence of such delivery. If one doesn't need guaranteed ordered delivery, or perhaps doesn't even want it, then TCP is the wrong choice in the first place.

Quote:
Why not use both? UDP for speed critical stuff, and TCP for reliability critical stuff.
A recent comment.

A common reason is likely practical. Since someone using UDP needs other types of messages between completely-unreliable and completely-reliable, some form of custom reliable UDP is implemented anyway, so adding reliable/ordered packets to that is trivial and simplifies having to manage two connections.

Another reason why TCP may be undesirable out-of-box is because it performs its own bandwidth management, behavior of which may not be optimal. It depends.

Quote:
Does it require opening two sockets?
Yes. Why would opening two sockets be a problem?

Quote:
If so then I guess I can only use UDP, but how can I make reliable messages in UDP?


Start here.

Share this post


Link to post
Share on other sites
You can do reliable communication with UDP, you would just need to do the sequencing, acknowledgement and retransmission yourself (essentially implement over UDP the things that TCP does for you). You could do these things for information that you need reliably and not do them for data where you don't.

That's how I'd do it anyway.

Share this post


Link to post
Share on other sites
Thanks for the answers guy.

Opening two sockets isn't a problem, it's just annoying to have to do that, and keep track of sending and receiving messages on both for each client, in my opinion. I found this neat library (I happen to be working in C#) that does reliable UDP. I'll try using that. Thanks for the answers guys.

Share this post


Link to post
Share on other sites
You can use both, if you want. However, it might be easier just to implement your own reliable control-packet layer on top of UDP and use that instead of a separate TCP connection. Like you said, if you have both, you need two sockets (on the client), and to do a little bit of extra work to synchronize them.

I'm personally using both in my current project, but it's mainly because of how I started and I wanted some practice using both. By now it's a fairly stable system that works really well, but if I had to do it from scratch again, I'd probably do UDP-only to save on the effort. I might remove the TCP connection later on if I feel it's no longer needed.

But yea, I just wanted to say it is possible and there's probably nothing extremely horrible about it. But it doesn't really offer that many advantages over UDP-only, at least nothing that can be replicated with your own custom reliable layer over UDP.

Oh, as a note, I'm using TCP to establish a connection to the server, and exchange control/info packets and stuff like chat. The UDP connection is used for all time-critical things like player movement and (in the near future) shooting.

Share this post


Link to post
Share on other sites
The main strike against TCP is that simultaneous-open TCP nat punch-through doesn't work as well as with UDP. Thus, for any peer-to-peer cases (such as user hosted games, or file transfer), you're better off with UDP from a compatibility point of view.

Btw: both the question of "UDP, TCP or both" and the Lidgren network library (as well as others) are mentioned in the Forum FAQ. Which is linked by the top stickied message on this board. I'm just saying you could have saved some time :-)

Share this post


Link to post
Share on other sites
I read that FAQ in it's entirety exactly before posting. That's where I got the link to lidgren. However, it seemed to me as UDP only by reading the description and I need reliability. It's not until this topic that I got that UDP could be reliable, too.

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
Btw: both the question of "UDP, TCP or both" and the Lidgren network library (as well as others) are mentioned in the Forum FAQ. Which is linked by the top stickied message on this board. I'm just saying you could have saved some time :-)


Please consider adding Ebenezer Enterprises to the Forum FAQ.


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

Share this post


Link to post
Share on other sites
Thanks for the suggestion. However, I don't add solutions based on provider requests, only based on happy user requests or significant market penetration (as seen in trade press).
So if you have some happy users, you can tell them to come here and post about it, or point me at some trade press coverage, and I'll be happy to add the link.

Share this post


Link to post
Share on other sites
Quote:
Original post by Xeon06
Why are there debates about which one to use? Why not use both?
Truth be known, I think the reason there is so much debate is because there are a lot of people on the Internet with an opinion, but far fewer people with actual real world experience. It's merely a ratio, for every real developer there are 1000 more who are more interested in being 'right' than getting it right.

There is no technical reason why you can't use a TCP and UDP socket at the same time (ie. No socket library which supports TCP is ever likely to come with an api restriction like that) but as rightly pointed out already, TCP isn't exactly as friendly as UDP when it comes to NAT punchthrough, which is potentially problematic depending on your network topology. There are other relationships between TCP and UDP, like for example what happens to your TCP connection when your UDP connection is using most of your bandwidth. Though I'm sure there are plenty of people with an opinion who will explain these much better than me ;-)

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
Thanks for the suggestion. However, I don't add solutions based on provider requests, only based on happy user requests or significant market penetration (as seen in trade press).
So if you have some happy users, you can tell them to come here and post about it, or point me at some trade press coverage, and I'll be happy to add the link.



There's a proverb about letting another man praise you so I won't argue too much with your decision. I will say though that every time someone uses the service, code generated by the service is being used. So we are both providers and users.

Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

"Let another man praise thee, and not thine own mouth; a stranger, and not thine own lips." Proverbs 27:2

Share this post


Link to post
Share on other sites
@TheGlib: is NAT-punchtrough needed for clients who try to connect trough TCP? Cause afaik it isn't. Or am i wrong?

@Topic: I think in general TCP is really easy as a beginner to handle but if you want to create "fast-paced" game as you say where ever millisecond of ping-improvemnt counts you have to somewhat use UDP i guess.
In my approach i just implent bigger server ticks but because of TCP they are sure to arrive and i think the result is kinda equal though my game is not a shooter or racing game.

Share this post


Link to post
Share on other sites
NAT punch through is not needed when only the client is behind a firewall, whether it's TCP or UDP. Punch-through is also not needed if the server is behind a firewall, if that firewall is doing proper port forwarding, DMZ handling, or reverse NAT.

Share this post


Link to post
Share on other sites

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