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

91–100 of 198 posts

Re: UDP vs TCP

#91

Post by fulafel »

mullen wrote: post #51
scurvy wrote: post #44

Earlier quoted context omitted.

NFS on Linux defaulted to UDP for what seems like a really long time. There were perf issues with TCP (can't remember what they were).

NFS used to default to UDP for the same reasons that games still would use UDP, it just needed the data as quickly as possible since it was blocking IO. Now a days, we don't need UDP for NFS because networks are a lot faster and the advantages of TCP start to over rule UDP.

The original reason was that using UDP was much faster CPU-wise back in the 80's. There was a requirement to go fast because it was used for transferring data in bulk, not events like games.

When Linux came around it just followed suit. TCP support came to NFS only later with other bells and whistles in later NFS versions, and Linux stuck with basic NFSv2 for a good while.

NFS was designed for local-area networks, so it didn't need to worry about working over the Internet.

In addition to the network being much faster relative to CPUs back then, the TCP stacks hadn't seen the tuning they have now. Making TCP fast came later.

Re: UDP vs TCP

#92

Post by 3131s »

_qbjt wrote: post #85
mikepurvis wrote: post #7

The recommendation to avoid TCP altogether is surprising to me. Having encountered a number of video-conferencing systems which are in a similar space, it seems pretty standard to have separate real-time and control sockets on UDP and TCP respectively. I skimmed the linked paper and didn't find it conclusive; can someone summarize how it is that having a TCP socket can affect UDP traffic on the same interface? All th…

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 making simple Javascript games. One of the games is a multiplayer / head-to-head Minesweeper clone that I got working with Django Channels, but did not even consider the networking aspect of TCP vs. UDP. The more recent one is inspired by the real-life game "capture the flag" -- teams of Asteroids-style space ships have to defend their own territory and flag, and capture the opposing team's flag while going around shooting at each other. It features a large game board very much like Agar.io (with the game camera following your ship around). I am using Phaser.io and Node.js, and while the game is operational and pretty fun just playing with the AIs, it's not multiplayer yet. I am approaching the multiplayer aspect carefully because minimizing lag will be crucial to making the game enjoyable.

Any general advice from anyone is appreciated, I am new to both networking and game design but it's a lot of fun.

Re: UDP vs TCP

#93

Post by fulafel »

wtallis wrote: post #72
josephg wrote: post #69

Does anyone know if SCTP is suitable / in use by any games? It supports streams to work around the head-of-the-line blocking problem TCP runs into and it also supports opt-in unreliable delivery for game data. On the surface seems ideal for games, though I don't know if its getting much actual use.

Nobody who's in it for the money wants to be the first one to prove that SCTP can be deployed at scale. Application developers don't want to have to sort out getting a working SCTP implementation installed and configured on the proprietary operating systems they target, and past the firewalls of all the bottom of the barrel consumer routers.

You wouldn't use SCTP on top of IP, you would use on top of UDP and implemented in userspace. Browsers do it this way (in WebRTC data channels).

Re: UDP vs TCP

#94

Post by banachtarski »

nrjdhsbsid wrote: post #86
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…

This isn't really true, or at least not the main reasons to choose UDP or TCP . In modern days UDP is really only used in situations where you can afford packet loss and CPU is expensive, or when you need to bypass the built-in behavior of TCP on your OS. It's not as much about latency or data loss, usually UDP is used in places where processing power is expensive or load is too extreme to justify TCP. Sometimes, lik…

I'm not sure I follow your argument. Say I want to communicate from player A the position of player A to player B. The position is really only relevant for a 200 ms time frame or so (the game might support teleports, jumping, dashing, etc). In a TCP setting, even if a packet is old (>200ms), I have no choice but to send it regardless, and all new packets must queue behind it. The whole point behind using UDP for games is that I can control what the resend policy is, which determines what ends up in the buffers you are referring to in your post. TCP gives me not only little to no choice in the matter, but often does the worst thing in a critical situation, especially in a game where input latency is 6 ms and the tolerance for network latency is <50 ms.

Re: UDP vs TCP

#95

Post by lend000 »

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…

That sounds like a TCP congestion control mechanism, except worse! TCP leaves much to be desired in terms of performance, largely because their congestion control fails miserably on lossy links (TCP RENO). There are better backoff mechanisms that can be added on many distros, like Westwood. And then there are altogether more efficient protocols like QUIC. But designing one for general purposes from UDP is easier said than done.

Re: UDP vs TCP

#96

Post by orasis »

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…

Back in the day of hard drives, the random access I/O would be nasty and you'd have to be careful about creating sparse files, so you'd end up double writing the missing packets. you'd also still need congestion control so might as well just use TCP to retransmit.

Re: UDP vs TCP

#98

Post by yaur »

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…

IMO the rule is actually really simple. If the correct thing to do when you lose a packet is to retransmit it use TCP, if it's not use UDP.

Re: UDP vs TCP

#99

Post by nrjdhsbsid »

banachtarski wrote: post #94
nrjdhsbsid wrote: post #86

Earlier quoted context omitted.

This isn't really true, or at least not the main reasons to choose UDP or TCP . In modern days UDP is really only used in situations where you can afford packet loss and CPU is expensive, or when you need to bypass the built-in behavior of TCP on your OS. It's not as much about latency or data loss, usually UDP is used in places where processing power is expensive or load is too extreme to justify TCP. Sometimes, lik…

I'm not sure I follow your argument. Say I want to communicate from player A the position of player A to player B. The position is really only relevant for a 200 ms time frame or so (the game might support teleports, jumping, dashing, etc). In a TCP setting, even if a packet is old (>200ms), I have no choice but to send it regardless, and all new packets must queue behind it. The whole point behind using UDP for game…

You're right in that UDP will let you send the most updated data without requiring everything to be sent. My main issue was that UDP does not give you lower latency. TCP algorithms are extremely aggressive to the point I doubt you could get more recent packets on the wire with UDP.

The problem is, the OS throws everything into the same buffer, and unless you're clairvoyant you won't be able to skip sending old packets into the buffer until it's too late. Basically by the time you know the data is outdated it's already on the way to the NIC buffer and you can't stop it, making TCP and UDP equal in this regard

Re: UDP vs TCP

#100

Post by fulafel »

wtallis wrote: post #15
exDM69 wrote: post #8

Earlier quoted context omitted.

Another article on this site addresses TCP plus UDP mix. The tl;dr is that they should not be used at the same time because TCP retransmission will interfere with UDP (and routers give TCP priority). As long as TCP happens outside of the "hot" loop, it's fine.

> (and routers give TCP priority). What routers? Is this something that stupid routers did in the '90s and people are still worried about, or are modern routers actually behaving this way? (And if so, why?) TCP retransmission interfering with UDP sounds like something that shouldn't be a problem on any sane network, especially if the application authors are smart and use something like LEDBAT for their TCP traffic wh…

The internet is generally built on the implicit contract of "TCP-friendly flow control". If your homegrown protocol backs off slower than TCP, some router configurations will drop your packets first.

There is no general policy against non-TCP packets of course, as lots of important internet services are non-TCP. Just flows that don't respond to congestion.

It's not a vendor specific thing, all the major router vendors provide ways of doing this.

(Note: router != your home NAT box)

Post reply on HN