Comment by rdw | Hacker News Reader

Comment by rdw | Hacker News Reader

Parent Full thread

It's still true that UDP is necessary for realtime communication. I recently worked on an MMO project in which a sub-team attempted to use TCP as the main layer, but ran into huge issues, all of which were cured by switching to UDP. TCP is good at what it's good at, but nearly every realtime audio and video protocol is gonna keep using UDP. You have to be able to ignore dropped packets instead of blocking the entire channel waiting for a full RTT, it very quickly spirals out of control.

Of course, TCP is a much better protocol for infrequent and request/response type interactions, so while I was at Linden we converted as much traffic as possible to TCP/XML. But a lot of the "realtime" stuff like object updates had to remain UDP, for empirical reasons.

Second Life didn't reimplement fragmentation -- messages just got truncated if they went over the MTU, lol.

UDP is not required for real-time communication. I have 5k+ concurrent channels of RTP over TLS (not DTLS) going most of the day. If you solved a throughput problem by switching from TCP to UDP, it means you had a middle-box doing bad things.

TCP is not slow unless you encounter congestion or packet loss. But you have to deal with those problems if you're sending data over UDP.

When I was at Linden, we activated fast start and bic on ADITI when testing OGP and Assets over HTTP and things worked MUCH BETTER.

OTOH, limited congestion and packet loss do not affect things much if you have UDP-based event/object updates. With TCP there there is no way to avoid latency due to head-of-line congestion, but with UDP you just drop a message and move on.

I think TCP works reasonably well today because the network is better and there is often very little packet loss, but as soon as you get some, TCP will optimise for throughput, like designed and at the expense of latency.

You should read about BIC.

actually... we DID do fragmentation in one of the messages. but i think that one didn't do windowing or something. this is the problem of using UDP, everyone thinks they're Van Jacobson and re-invents TCP poorly. In the case of the viewer, we had at least three implementations of "random transport over UDP," each talking with a different part of the back-end. Each used the same algorithm to deal with packet loss, however: dump core and wait five minutes. (I jest. I think we mostly fixed that, but it did happen occasionally.)

Reply on news.ycombinator.com