Jump to content
  • Advertisement
Sign in to follow this  
guyaton

TCP vs UDP

This topic is 4628 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 found this off a site and was wondering if this was true.
Quote:
No games worth mentioning use TCP
The site discusses TCP vs UDP and suggests UDP even tho the packets aren't gaurenteed or are even gaurenteed the order in which they arrive. I'm not knowledgable about multiplayer networking or network programming and I was wondering if this was true. thanks in advance, ~guyaton

Share this post


Link to post
Share on other sites
Advertisement
Sounds like a rash statement without any real research or backing. The fact that the grammer is subpar doesn't add to the credability.

Share this post


Link to post
Share on other sites
I think it ultimately depends on the type of game you want to create.

For example, if you're creating a game which depends on quickly getting packets to and from your clients/server, you'll want to use UDP, due to the low overhead. Unfortuately, UDP does not guarantee delivery or the order in which you sent the packets. TCP requires more overhead, but it guarantees delivery and also guarantees the packets sent end up in the order in which you sent them. This is important for some types of games that don't necessarily depend on speed as the driving force behind the game.

Share this post


Link to post
Share on other sites
Most of the bigger games will use a combination of TCP and UDP - its the only real way to utilize network programming to its fullest extent. Without more info on the context of that statement its kind of hard to judge the statements credibility.

Share this post


Link to post
Share on other sites
While I'm no network expert, I think most real-time games (FPS, RTS) use UDP. This is because TCP guarantees delivery and proper ordering. To meet that guarantee, TCP has to do a lot of behind-the-scenes work which has the end-result of significantly delaying (in the scope of frame time) the arrival of network packets.

Of course, most UDP networking layers implement ordering and guaranteed delivery on top of UDP, so why reinvent the wheel? The advantage is that it gives more control to the application (or the networking layer of the application) in how it handles delayed or missing packets. TCP doesn't necessarily give you this flexibility. For example, with a custom UDP stacked like the one described above, your app could send "keyframe" packets every 30 updates so that the network layer could catch up without necessarily having to recover all of the in-between frames (whereas TCP doesn't know that some packets can be ignored once a different packet is sent/received).

I would expect that any non-real-time game, such as a turn-based game, would use TCP unless the network programmer was a masochist.

Of course, all of that above knowledge is based on the "state of the art" networking code circa 2000. Today, with wide availability of broadband, faster CPUs, higher quality NICs and better TCP/IP implementations, it all may be moot.

(Also, and this may be totally wrong, I think it may be easier sometimes to route UDP around NAT and firewalls, but that may be completely wrong!)

Share this post


Link to post
Share on other sites
thanks for all the great (and not to mention) spedious responses. This was from a site that has their own networking API that I was checking out. They use primarily UDP and I just wanted more info.

thanks again,
~guyaton

Share this post


Link to post
Share on other sites
Netstorm is an RTS that uses TCP. The idea of the programming there (according to the programmers) is: The network conditions that cause TCP to become ineffective (time delay) have the same effect on UDP. I'm not saying that UDP/TCP is a non-issue, just that it often seems that programmers go for UDP when TCP would do just fine.

Share this post


Link to post
Share on other sites
I prefer the ease-to-useiness of TCP, but there are plenty of UDP libraries which give you that ease plus the added benefit of using unreliable packets when reliability isn't important. Essentially they give you the best of both worlds.

TCP does offer some advantages with compatibility, as it's easier to work around the limitations of NAT using TCP.

Enet is a pretty good UDP networking library.

Share this post


Link to post
Share on other sites
Contrary to popular belief, an RTS isn't actually "real-time" in the sense that an FPS or virtual world is. Networked RTS-es always have a command delay, where you first give the command, and the unit says "yes, sir!" and starts packing up -- but it doesn't actually start moving until half a second later. This time is used to shuffle the packets to the other players. There are links in the Forum FAQ about this structure of a game, if you're interested.

TCP is perfectly fine for a game with these requirements, as long as you turn off Nagle (i e, turn on TCP_NODELAY).

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!