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

181–190 of 198 posts

Re: UDP vs TCP

#181

Post by cpncrunch »

dbcurtis wrote: post #106
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.

On the loopback port, sure. I work on protocols that use sketchy wifi on mobile units that roam among access points. Sometimes they roam into RF black holes. TCP is all kinds b0rk3d for what I am doing.

>Sometimes they roam into RF black holes

I'm not sure how UDP is going to help if you have no connectivity.

These days TCP copes as well as UDP with temporary complete loss of connectivity, due to fast recovery. It is really just packet loss that kills TCP, but that isn't generally an issue these days if you're in the USA/Canada/Europe/Japan/Korea/Australia, and your wifi isn't crapping out.

Re: UDP vs TCP

#182

Post by lobster_johnson »

Franciscouzo wrote: post #174
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…

A lot of the internet's bulk data transfer uses UDP, torrents.

BitTorrent is mostly TCP these days, though, as pointed out elsewhere in this thread.

Re: UDP vs TCP

#183

Post by deburo »

ozy wrote: post #157

"TCP has an option you can set that fixes this behavior called TCP_NODELAY" That fixes nothing. Now you are sending too many small packets using too many syscalls. Just like UDP, buffer in user space, send in one go. If you do that, TCP_NODELAY makes no difference. (The exception is user input, if you want to send those as they happen, use TCP_NODELAY, but think about the why ... it has little to do with what this ar…

I will preface this with the fact that the author worked on at least one such FPS game (Titanfall 2) and probably know what he is talking about.

He offered one solution to fix one behavior of TCP, the behavior being that if the data written to the buffer is not big enough, TCP might hold it. Setting TCP_NODELAY forces the protocol to avoid holding data. But this is only written as a note to coders who might think TCP_NODELAY will fix TCP for action games, but it doesn't actually, because the protocol has other characteristics that are undesirable in that type of games.

Moreover, you write this: waiting on a dropped packet and the delay it causes is unnoticeable. Unless you have a FPS game with TCP as its network protocol to validate this claim, I call bull. Many network programmers recommend against TCP. This is probably not simple cargo-culting.

Re: UDP vs TCP

#184

Post by user5994461 »

blackflame7000 wrote: post #167
user5994461 wrote: post #120

Earlier quoted context omitted.

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.

> the argument is that they can cause interference.

UDP ignores everything else and always expect resources to be available for itself.

We could say that UDP interferes with everything, we could say that everything interferes with UDP, it's both ways.

Re: UDP vs TCP

#185

Post by blackflame7000 »

user5994461 wrote: post #184
blackflame7000 wrote: post #167

Earlier quoted context omitted.

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.

> the argument is that they can cause interference. UDP ignores everything else and always expect resources to be available for itself. We could say that UDP interferes with everything, we could say that everything interferes with UDP, it's both ways.

Who chooses when a UDP packet is dropped? The freaking network adapter device driver which is what I said in the first place!

Re: UDP vs TCP

#186

Post by epsylon »

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

I don't know which reality bubble you live in, but this is utterly false. I live in the country side and get routinely an average of 40% packet loss on many, many websites. There are plenty of occasions for packets to get lost somewhere between a client and a server.

Re: UDP vs TCP

#187

Post by user5994461 »

blackflame7000 wrote: post #185
user5994461 wrote: post #184

Earlier quoted context omitted.

> the argument is that they can cause interference. UDP ignores everything else and always expect resources to be available for itself. We could say that UDP interferes with everything, we could say that everything interferes with UDP, it's both ways.

Who chooses when a UDP packet is dropped? The freaking network adapter device driver which is what I said in the first place!

There is a lot more in the transmission chain than just that driver.

Re: UDP vs TCP

#188

Post by raarts »

user5994461 wrote: post #127
Dylan16807 wrote: post #116

Earlier quoted context omitted.

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 FP…

> it's correct that [almost] nobody ever uses UDP

Skype, Facetime, WhatsApp, Hangouts, Telco VoIP, Facebook Live, YouTube Live, Surveillance Cams, most VPNs.

Re: UDP vs TCP

#189

Post by ozy »

deburo wrote: post #183
ozy wrote: post #157

"TCP has an option you can set that fixes this behavior called TCP_NODELAY" That fixes nothing. Now you are sending too many small packets using too many syscalls. Just like UDP, buffer in user space, send in one go. If you do that, TCP_NODELAY makes no difference. (The exception is user input, if you want to send those as they happen, use TCP_NODELAY, but think about the why ... it has little to do with what this ar…

I will preface this with the fact that the author worked on at least one such FPS game (Titanfall 2) and probably know what he is talking about. He offered one solution to fix one behavior of TCP, the behavior being that if the data written to the buffer is not big enough, TCP might hold it. Setting TCP_NODELAY forces the protocol to avoid holding data. But this is only written as a note to coders who might think TCP…

"TCP_NODELAY forces the protocol to avoid holding data"

That is the misunderstanding. It will send one non full packet, and only then "hold on to data" until the next packet is a full packet. But that condition will reset when all data has been acknowledged. If you buffer in userspace and write data in one go, at 25 network fps, you basically never trigger the condition where TCP_NODELAY makes a difference.

It is not nagle's algorithm, but a variant of minshall-nagle, what modern systems use.

There is a reason why FPS games use UDP, but that discussion should not start with TCP_NODELAY. That one is misused enough ... often when it fixes anything, it is because it masks a real underlying problem, had you fixed that problem, your system would react much better under stress or bad networks.

Re: UDP vs TCP

#190

Post by paulddraper »

cthalupa wrote: post #141
user5994461 wrote: post #125

Earlier quoted context omitted.

> 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 (co…

>1) Bulk data transfer doesn't work over UDP. Tell that to all of the people that use TsunamiUDP to do bulk data transfer. It uses TCP as a control protocol, but the data transfer is all UDP.

It sounds like they would agree.

Bulk data transfer doesn't work over UDP, but it can work over UDP and TCP.

Post reply on HN