Hacker News new | ask | show | jobs
by jstewartmobile 3253 days ago
So many of these comments are like "UDP is not TCP!" or "Muh TCP guarantees!", then they go on to mention WebRTC?!!!

I mean, if you're streaming audio and video Real Time, is there really any point to TCP? If a few frames get dropped, then bursted back once the connection stabilizes, does that improve the user experience in any way?

WebRTC seems like a perfect candidate for UDP communications for the actual media streams.

2 comments

WebRTC is best option for media streams today for peer-to-peer cases.

The goal of the topic is to explore simple option for server-client communication using low-latency communication, without reliability and without ordered delivery.

WebRTC can be used for such case, although it is not designed for it. Due to that implementation is very complex and not much adopted. This is something we trying to explore, either new API or simplifications to WebRTC to make it simple choice for UDP in server-client scenarios.

Given the kind of feedback happening (and my initial reaction admittedly was similar), maybe a different name would help with perception (I'm already not a big fan of "WebSockets", but "WebTCP" would have been worse), promoting the goals over the implementation detail of UDP?
If there is alternative transport protocol to enable low-latency delivery as efficient as UDP, then it is worth exploring.

UDP - is something been used by many industries for long time and is well known protocol to make a foundation from.

It just seems like most real-life usages of WebRTC are either media-centric where TCP does more harm than good, or multiplayer scenarios where it's a wash since TCP's ordering is a pro while TCP's overhead is a con.
TCP congestion control can be very beneficial for streaming applications (when combined with adaptive rate codecs).

With UDP you have to create your own feedback mechanism to find the optimal bitrate to stream to the far side at.

This is where DCCP or alternative protocols come in play.