Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

UDP vs TCP

gafferongames.com

Post reply on HN
Print view View original

121–130 of 198 posts

Re: UDP vs TCP

#121

Post by theWatcher37 »

jerf wrote: post #45
lobster_johnson wrote: post #40

Earlier quoted context omitted.

Picking a smallish, fixed chunk size should work, and it could even be made to self-regulate. Reassembly is trivial -- allocate the file first, write chunks to their right location. And for the control stuff (i.e. requesting chunks) you just use a TCP connection. UDP for the data only.

If you do the obvious work to convert UDP to a reliable streaming mechanism, you will generally more-or-less reinvent TCP, only probably more poorly, and would probably be better off just using TCP. UDP is a good choice when you have options or requirements that TCP can't accommodate. For instance, the classic case of streaming audio has both; it both requires timely delivery and has some very sophisticated technique…

Why are so many comments here ignoring the purpose of the article?

The purpose of this is for games, not web traffic or torrent2.0.

In real time games where you're syncing physics states or player locations data >200ms isn't just useless it's actually negative.

This article is 2+ years old, and is the foundation I suspect for libyojimbo which hybridizes UDP low latency communication for large player real time games and reliable messaging (basically custom TCP?) for less time critical things.

Re: UDP vs TCP

#122

Post by taneq »

z3t4 wrote: post #70

I think tcp have an unfair reputation. Our networks are better now then 30 years ago ... Worst case latency for tcp is like 3 seconds, compared to the packet never arriving. The trick is to hide the lag with animations. I think google, facebook, and world of warcraft use tcp for their real time apps !?

Sad to see you being downvoted when you're absolutely right. Yes, UDP is better for a twitch game, at the expense of a lot more work. No, unless you're building a AAA mouse-and-keyboard shooter, you probably don't need more than a TCP connection sending data packets back and forth using a somewhat well-thought-out protocol.

Re: UDP vs TCP

#123

Post by theWatcher37 »

user5994461 wrote: post #112
rstuart4133 wrote: post #102

The entire article makes me shudder in disbelief. It's aimed at people who don't know the difference between UDP and TCP (and possibly wet string). Yet he recommends they implement their own reliably protocol over UDP, and they avoid TCP because it's better to implement your own QoS? Why not add obtaining PhD in quantum mechanics just to round it out? It wouldn't alter the odds of pulling it off overly.

Agree. For people who are not familiar with TCP and UDP, the answer should be to ALWAYS use TCP. The only exception is some subset of games (FPS, RTS), that this article is exclusively intended for. Even there, for the average user who just wanna make a test game project, TCP may be easier to use and program around. For simple games (e.g. Connect 4), TCP is a better option either way.

In the article he clearly states this is for things like syncing physics in BF4 or halo.

Re: UDP vs TCP

#124

Post by snupples »

ajross wrote: post #68
kevhito wrote: post #50

Earlier quoted context omitted.

> ship all the chunks over with a sequential number Except that if you ship them too fast, they will at best simply build up in a buffer somewhere (e.g. near a bottleneck link), or more likely they will overflow causing many of your packets to be lost. So not only did the recipient not get them (and you have to figure this out and resend them later), but you also wasted a bunch of resources sending packets only to ha…

Exactly. The core feature provided by TCP is not reliability, that is trivially easy. What TCP gives us is robust flow control that can detect and adapt to current network capacity.

CNN has a video transfer tool for b2b subscribers that uses multiple UDP streams to increase transfer speeds. Instead it saturated and brought down our company firewalls, which were older and our main bottleneck. All for just a potentially few more megs of speed on TB sized videos. Gotta be careful with UDP.

Re: UDP vs TCP

#125

Post by user5994461 »

lobster_johnson wrote: post #23
mjevans wrote: post #6

The main difference between TCP and UDP, as this programmer discovered, relates to quality of realtime service. Times to use UDP over TCP * When you need the lowest latency * When LATE data is worse than GAPS (loss of) in data. * When you want to implement your own form of error correction to handle late/missing/mangled data. TCP is best when * You need all of the data to arrive, period. * You want to automatically m…

I always wondered why nobody used UDP for bulk data transfer: Ship all the chunks over with a sequential number identifying each, then when you've reached the end, have the client request any lost packets, then repeat the cycle until all are transferred. After all, the client doesn't need everything in sequential order if it knows the size, and it can deal with holes as long as they're eventually repaired. This gives…

> I always wondered why nobody used UDP for bulk data transfer

1) Bulk data transfer doesn't work over UDP.

There is no flow control whatsoever with UDP and no guarantee, it sends stuff without distinction between a 56k uplink and a 10Gigabit LAN. The packet loss and lack of reliability are atrocious when you send non negligible amount of data.

2) You'd need to create a protocol on top of UDP to handle the basics (controlflow/error/retransmission), that's equivalent to re-inventing TCP. Don't re-invent your own TCP, just use TCP ;)

Re: UDP vs TCP

#126

Post by user5994461 »

vvanders wrote: post #25
lobster_johnson wrote: post #23

Earlier quoted context omitted.

I always wondered why nobody used UDP for bulk data transfer: Ship all the chunks over with a sequential number identifying each, then when you've reached the end, have the client request any lost packets, then repeat the cycle until all are transferred. After all, the client doesn't need everything in sequential order if it knows the size, and it can deal with holes as long as they're eventually repaired. This gives…

You've kinda answered your own question there, congestion control becomes a big issue(also MTU discovery to a lesser degree). Games sit in this happy space where the data rate is ~10-20kb at most so they don't need to worry about congestion control as much.

Additional information: The source engine (valve) has been limited to 30 kb/s for more than a decade.

Re: UDP vs TCP

#127

Post by user5994461 »

Dylan16807 wrote: post #116
user5994461 wrote: post #111

Earlier quoted context omitted.

UDP is connectionless, it just sends data to . Doesn't care if that somewhere is online, or available, or exists at all.

If you don't check for returns, TCP isn't going to help either. The requirements you listed don't make sense as written. Nobody would ever use UDP.

TCP establishes a connection when it starts and it has build-in timeouts (and various mechanisms) to detect dead connections. TCP will signal to the application if the destination is unavailable or lost.

The requirements make sense and the common usages for UDP fit these requirements.

It's correct that [almost] nobody ever uses UDP. It's a niche protocol for a very few specific use cases, one of which is real-time FPS/RTS/MOBA games (which fits all the criteria I listed).

Re: UDP vs TCP

#129

Post by Dylan16807 »

snupples wrote: post #124
ajross wrote: post #68

Earlier quoted context omitted.

Exactly. The core feature provided by TCP is not reliability, that is trivially easy. What TCP gives us is robust flow control that can detect and adapt to current network capacity.

CNN has a video transfer tool for b2b subscribers that uses multiple UDP streams to increase transfer speeds. Instead it saturated and brought down our company firewalls, which were older and our main bottleneck. All for just a potentially few more megs of speed on TB sized videos. Gotta be careful with UDP.

That just sounds like your firewalls are made of pentium pros and duct tape. TCP can oversaturate a connection too, and a firewall should be able to handle large packets at line rate.

Re: UDP vs TCP

#130

Post by greyskull »

3131s wrote: post #92
_qbjt wrote: post #85

Earlier quoted context omitted.

It's a bit dogmatic to state "never use TCP". In the context of games, one example that comes to mind is turn-based multiplayer games (Hearthstone, for example). In this case, I would at least consider TCP over UDP as the overall amount of packets transmitted within a session is relatively low and packet loss is more consequential than latency. As far as negative interactions between TCP and UDP on the same interface…

It's a bit dogmatic to state "never use TCP". I was wondering about this too. Yesterday in the "WebRTC: the future of web games" post we had Matheus28, the creator of Agar.io, saying that his games are built on WebSockets, a TCP-based protocol. Agar.io is real-time and massively multiplayer, and seems to run smoothly enough. So is it completely critical to use UDP? I am curious as someone who has recently gotten into…

Props that you're branching out and having fun. That's what makes software special.

Agar.io is slow and simple. There isn't much state to encode and state doesn't change drastically that a few re-sent packets here and there are going to ruin the gameplay. Granted, if you're on a terrible connection with high packet loss, even a great algorithm on top of UDP won't save you.

There are better explanations than I can provide on why TCP isn't great for (parts of) fast, complex games, but it's enough to say that there's a huge difference in the complexity of state and state updates between say Battlefield and Agar.io or the game you described. Modern TCP on modern network connections will get you very far, but there's only so much you can deal with when a split second can mean the difference between "A was under the crosshair of B" and "A actually went around a corner, sorry B".

What you described is likely not going to be so sensitive. I don't think you'll personally have to worry about implementing a custom networking protocol over UDP any time soon - maybe unless you think your game is going to be played by people on terrible connections (possible!), or you end up with some abysmally inefficient state sharing over the network.

And, from a different perspective, getting caught up in those details tends to risk getting burned out. Better to see your game through to MVP then go back and make it great.

Post reply on HN