Hacker News Reader

Comment by mikepurvis | Hacker News Reader

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 that said, I certainly see the argument for an all-UDP protocol in terms of defining your own retransmission approach, or attempting to avoid it altogether with forward error correction or whatever.

View on HN

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.

That's not an explanation. That's just pointing in the general direction of where to look for an explanation.

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 long, and TCP traffic is more often relatively short-lived HTTP connections, not long-running FTP.

The paper is just another piece of evidence that TCP synchronization sucks. You are very unlikely to encounter such perfect TCP synchronization on today's Internet, and even if you did, the dynamics of introducing some UDP flows to that situation would be different.

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 to work- (authentication/joining room/leaving/adjusting quality), the UDP is used for audio/video (some pieces may be lost during congestion, it's okay).

If you use UDP for everything, you'll randomly loose control AND audio/video. It's the worst of both worlds.

Not to be dismissive but I think the guy who gave you the advise doesn't really understand networking (or doesn't explain very well or was talking about some weird usage we don't know about).

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!

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

But it's the driver of the NIC that manages its network packet queue! Then it uses a an interrupt to signal the OS that data is available or that the window is open for transmit. I'm totally aware there's a lot more to it, I do socket programming everyday.

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, I'm not aware of any but I'd love to be corrected if wrong. As you pointed out, it's not uncommon to use both. The BIND 9 DNS server, for example, allows the use of TCP for DNS queries over 512 bytes [1].

[1] https://ftp.isc.org/isc/bind9/cur/9.10/doc/arm/Bv9ARM.ch06.h...

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.

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.

I'd argue that Agar would run smoother on UDP. The decision was not really a decision here. WebSockets provide TCP only. One can use WebRTC data channels now but there are still issues woth compatibility.

And it's all tradeoffs. For example, Ultima Online used TCP and worked relatively fine on decent networks. In case of a packet drop, you'd observe a complete pause on the world but most animations / movement had a 100ms or more buffer area. If you wanted to move some direction, your character would start moving, if there was no ack after a single step (100ms if running) then it would stop. The world was being streamed as diffs from previous state so it depended on tcp's reliability.

Anarchy online used udp for game and tcp for chat. While the OP argues against this, I think it is a good seperation. I remember playing it on a congested network and the game state fucked up really bad. Tunneling over a tcp stream to a vps server close to game servers made it playable for my case. Maybe they should have gone with tcp. Or their networking code did not compensate for UDP's issues better.

On the other hand, anything more action packed like a fps would probably be better off with UDP as the author suggests.

the post also recommends that some http traffic is OK, but doesn't that directly contradict the advice to not mix tcp with udp (assuming that the http traffic sits on top of tcp)?

It's clarified in the next line. > "The point is, don’t split your game protocol across UDP and TCP."

There is always going to be data transmitted other than the game protocol. Most likely that is going to be limited and not at the same time as real time data is being transmitted.

Reply on news.ycombinator.com