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

161–170 of 198 posts

Re: UDP vs TCP

#161

Post by astrobe_ »

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…

UDP is usable for this when used to transport a file transfer protocol. I've seen for instance Kermit over UDP. Basically, if you transport data using a protocol that already takes care of integrity, using TCP is more or less redundant and just adds annoyances (connection management).

Re: UDP vs TCP

#162

Post by cpncrunch »

ra1n85 wrote: post #42
cpncrunch wrote: post #37

The reality is that these days there generally isn't any packet loss, so UDP vs TCP isn't such an issue as it might have been in the past. In fact TCP has a number of advantages these days such as easier firewall traversal, WebSockets, etc.

>The reality is that these days there generally isn't any packet loss Do you have any sources/data on that? Genuinely interested where you drew that conclusion from. From my vantage point (anecdotal), ISPs and carriers routinely under-provision, congest peerings, and don't find a problem well until after a number of customers complain.

I measure packet loss on my cable connection every 5 mins of the day. Also Ive been developing realtime collaborative applications using tcp for over 20 years.

Re: UDP vs TCP

#163

Post by fivesigma »

A huge problem with TCP wrt gaming is the default ACK frequency on Windows which is set to 2. This effectively almost doubles the latency of game connections (sending/receiving a lot of time-sensitive small packets).

It can be changed with a registry setting (TcpAckFrequency) but you can't expect even a significant fraction of your users to do that. Why this isn't a per-connection option sort of like TCP_NODELAY is beyond me.

Re: UDP vs TCP

#164

Post by theandrewbailey »

the_mitsuhiko wrote: post #152
Negitivefrags wrote: post #137

Earlier quoted context omitted.

People talk like most games use UDP, but they don't. Pretty much the only genre that does is First Person Shooters. MMOs (like world or warcraft) MOBAs (like Dota) RTSs (like Starcraft) Action RPGs (like Diablo) All of these are action games and use TCP. In most genres people would rather have the simulation pause when there is packet loss, and then run fast to catch up rather than have unreliable data about player l…

> MMOs (like world or warcraft) MOBAs (like Dota) RTSs (like Starcraft) Action RPGs (like Diablo) Dota 2 definitely does not use TCP. The Starcraft games I assume can also work with TCP but I doubt that they use it as a primary choice of communication. I would love a source for this.

Most sites that I come across say that Brood War primarily uses UDP, along with most other similar vintage Blizzard games.

http://wiki.teamliquid.net/starcraft/Port_Forwarding

Re: UDP vs TCP

#165

Post by jwatte »

Negitivefrags wrote: post #137
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…

People talk like most games use UDP, but they don't. Pretty much the only genre that does is First Person Shooters. MMOs (like world or warcraft) MOBAs (like Dota) RTSs (like Starcraft) Action RPGs (like Diablo) All of these are action games and use TCP. In most genres people would rather have the simulation pause when there is packet loss, and then run fast to catch up rather than have unreliable data about player l…

It's easier and more robust to do NAT traversal with UDP than with TCP. The Xbox game network services implement TCP within the Microsoft domain on top of UDP!

Re: UDP vs TCP

#166

Post by [deleted] »

wtallis wrote: post #53
blackflame7000 wrote: post #39

Earlier quoted context omitted.

Do you have a better explanation to offer because I'd love to learn? Not sure why I deserve a downvote for offering a potential solution when you with 6000 karma offer nothing.

I think the claim was far too broad to actually be entirely true, and the evidence was both narrow and weak. The 1997 paper only shows that certain simulation parameters can produce bad packet loss for UDP traffic. But those parameters are almost all irrelevant to today's Internet: MTU is now 1500B not 512B, TCP congestion control is usually something like CUBIC rather than RENO, buffers are never a mere 16 packets l…

[deleted]

Re: UDP vs TCP

#167

Post by blackflame7000 »

user5994461 wrote: post #120
blackflame7000 wrote: post #22

Earlier quoted context omitted.

I too was wondering how TCP and UDP can affect one another on the same interface and the explanation I read is that at the lowest level both UDP and TCP segment data into packets and place them onto the same network adapter's queue which can affect they way they are transmitted under congestion depending on the device/drivers.

This makes no sense. UDP will drop data if there is congestion. Basically, if you care about congestion and data loss, you should not use UDP. --- If you do UDP and TCP. The UDP transfer will loose data during congestion, while the TCP transfer will slow down and try harder. This has some usage. For instance, videoconferences software will do TCP and UDP. The TCP is used for control data -low volume data that needs t…

Error checking can easily be added to udp for control data. Infact in IPv6 it's mandatory. At one moment you say udp will lose out, but we know tcp will back off on its reattempts exponentially based on the congestion window. Thus udp would win out. The argument wasn't that it was a significant impact, the argument is that they can cause interference.

Re: UDP vs TCP

#168

Post by blackflame7000 »

SomeStupidPoint wrote: post #63
blackflame7000 wrote: post #35

Earlier quoted context omitted.

What it really comes down to is file block size granularity. TCP is simply using a much finer block size (~1500 bytes) which means a higher likelihood of arriving than for a large UDP packet. Furthermore, you'd still have to implement your own checksumming algorithm to ensure data integrity as UDP doesn't require a packet checksum for IPv4. I suppose you could offload file-block integrity validation to another thread…

But bittorrent breaks the files in to chunks it can receive out of order and sends those over TCP, so TCP only preserves ordering within a chunk. It might even get chunks from several different people. The real answer is that chunking over TCP is efficient enough that little is gained by chunking over UDP.

Yes what I'm saying is that bit torrent uses TCP to segment fileblocks instead of using UDP to send the file block as one large datagram

Re: UDP vs TCP

#169

Post by ajross »

Dylan16807 wrote: post #118
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.

A robust flow control that's tuned for bulk downloads, and badly adapted for small real-time streams.

Sure. And not even the best known flow control mechanism. But nonetheless that is the important innovation of TCP, not reliability. The post by lobster_johnson upthread implied that you could use UDP for "bulk data transfer", which basically doesn't work without reinventing something akin to TCP.

Re: UDP vs TCP

#170

Post by kmm »

skarap wrote: post #149
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…

Nobody ever mentions that UDP has one additional feature that TCP doesn't: preserving of message boundaries.

A datagram-like protocol with the reliability of TCP might be nice.

I once implemented a communications protocol that worked with variable-length independent messages over TCP. It felt a little silly pushing distinct datagrams into a stream, that would be chopped up into a packets, sent to another PC, where the OS would then reassemble those packets back into a stream, only to be chopped up again in messages.

Implementing the system for chopping up the stream really felt like it should have been done by a lower level as well, not in an application

Post reply on HN