Hacker News Reader

Comment by javascriptlol | Hacker News Reader

Unfortunately, during our circle back to the 1970's we lost UDP, which is essential for real time protocols.

Exactly. Flash sockets are TCP only (proprietary Adobe protocols aside), and it seems WebSockets ended up without any UDP support either.

The overhead of TCP is just ridiculous when you're trying to implement real-time game movements with dead reckoning, etc.

Unity has UDP sockets and yes all good games that require fast real-time action need UDP. Adobe had it partially in their latest Flash Media Server RTMFP protocol but it was very limited.

RUDP or Reliable UDP is the best of both.

Here's some great info on UDP vs TCP and only using one or the other:

UDP vs TCP http://gafferongames.com/networking-for-game-programmers/udp...

Characteristics of UDP Packet Loss: Effect of TCP Traffic http://www.isoc.org/INET97/proceedings/F3/F3_1.HTM

RUDP sounds very weird... why would you use it instead of TCP? At a glance, it looks like the only difference is RUDP doesn't enforce packets being received in-order (being a message-based protocol), while TCP does (being a stream-based protocol).

The great thing about UDP with a reliable layer on top is you can choose if you want an ACK back for any 'critical' data. Otherwise you can just ignore order or whether the endpoint receives it or not. It is a broadcast rather than a hard line essentially.

For instance let's say you have some physics update and for some reason you needed it networked, with many objects, receiving only 70% of those for many different elements may be just fine (discarding any you receive after that are older maybe for this example)...you may not need reliable acknowledgement that they received for most of them if any. But you definitely need to know when an enemy is killed so you make that a critical message to the server RPC'd to the clients and use a reliable flag which then will expect validation. Same with ordering... use when needed with RUDP or custom layer on UDP for reliability.

TCP does all this for you and works great for files/http etc. but doing this for all messages is great overkill in real-time games lower than turn based. And mixing TCP/UDP arguably causes some slowdown to UDP due to TCP queuing. RUDP solves all these issues and is flexible to reliable messages and just firehose broadcast.

http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol Designed by none other than Bell Labs...

Also SCTP was created to solve RUDP like issues as an official standard (RUDP is a draft) but standards take time: http://en.wikipedia.org/wiki/Stream_Control_Transmission_Pro...

Enforcing order is hugely important. With TCP, if you lose a packet, all incoming data to the app stops until it's recovered. This is disastrous for an app which can withstand some data being late but needs most of it to show up fast.

I think people would probably build their own communication protocol on top of UDP but not at the level of TCP, if they were given UDP support.

I'm not saying that's good or bad.

Back in college on a distributed systems course, one of the projects was exactly to build that because the professor wanted to produce somewhere between UDP (more than) to TCP (less than).

On the one hand there are tons off applications that don't need UDP and will do just fine with WebSockets. Lots of AJAX based sites can be made much more responsive through WebSockets. Email sites, sites like Google Docs, etc. Chat sites like Meebo or Google Talk. Even many types of games will do just fine with WebSockets. A WoW style game, a Diablo style game, etc.

On the other hand they, the w3c and the browser vendors, are working on unreliable (ie, UDP) peer to peer standard based off the WebRTC stuff so for those applications that can tolerate the unreliableness (ie, voip, video and real time games) it's not far off.

Thanks! I didn't know about WebRTC, so this seems like good news. Is it tailored to video/audio or are we talking about something you can design a protocol on top of?

Reply on news.ycombinator.com