Hacker News Reader

Comment by ravxx | Hacker News Reader

[flagged]

> Whoever made this article is pretty clueless

This genre of HN comment irks me. Technical writing is an exercise in taking a lot of material and distilling it down to an audience. Writing that does a good job this will often look basic to someone with a deep understanding of the tech. It doesn't mean the author is clueless, it just means they decided they made different decisions on what to cut than you would have.

That the author didn't mention UDP "leaves out" the vs. objective, however. If it were a fair contest, the article would mention the use of WebRTC over UDP, which isn't just for streaming media (an assumption I had before doing a bit more research on it).

> This article aims to delve into these technologies, comparing their performance, highlighting their benefits and limitations, and offering recommendations for various use cases to help developers make informed decisions when building real-time web applications.

So, the article's intent was to help others. When we do things like this, we should ensure all technologies being evaluated will be covered exhaustively. Otherwise, you risk leaving out an important part of the puzzle and then assumptions kick in which ignore a possible better solution for a given use case.

It looks like UDP use is possible between a browser and a server, and that connection has to have components that deal with dropout, given it's UDP. There is a LOT to consider and deal with implementing UDP over WebRTC, so I put a dump of this up here: https://pastebin.com/xgA78dky

Author here. The article is mostly about web apps. How would your signaling server emit new connection updates to clients in the scenario you describe?

I think what they mean is that yes, the signalling needs to be done over "traditional" web APIs (websockets, etc), but that's just for discovering/negotiating the p2p connections. The actual data transfer between the peers then happens over UDP which can have a bunch of advantages over TCP for some scenarios.

The WebRTC section of the article seemed weird in general. The reason WebRTC doesn't specify signaling requirements is that clients can use any communications mechanism they'd like for signaling, and in the case where you are using WebRTC as sever-push mechanism, the "signaling" server and the server you want to receive pushes from could be the same server, allowing the use of "regular" HTTP as the transport for your "signaling" data.

With QUIC & HTTP/3, and things like RFC 8441 & 9220, you could well be using UDP with non-WebRTC protocols, and TCP stacks & routers tend to be pretty well tuned these days, so UDP doesn't necessarily have much of an advantage in this kind of use case.

If you check out the benchmark the article uses, it specifically breaks out using "unreliable WebRTC/WebTransport". The "unreliable" looks to be referring to UDP (I despise how people misleadingly associate UDP with "unreliable"). They also have "reliable WebRTC/WebTransport", which appears to be using TCP. In the latter case, they actually found in some cases WebTransport doing a tad better in the face of packet loss, which is interesting. I haven't looked at the details of the tests, but in my experience benchmarching WebRTC is not as straightforward as one might expect; it's entirely possible the nature of the benchmark itself is leading to WebRTC's better & worse performance.

Does WebRTC still ignore web proxies?

Reply on news.ycombinator.com