Hacker News Reader

Comment by jamesblonde | Hacker News Reader

Strange to see this relatively old article appear. NATs are still with us. The main progress has been WebRTC. Otherwise, researcher who looked at TCP at the time (e.g., stunt) for simiulataneous TCP Syn packets failed. It was too hard to synchronize timing. Most middleware still ignores NATs and hopes it will go away (it won't). NATs are the reason REST won over CORBA et al.

View on HN

"NATs are the reason REST won over CORBA et al."

CORBA "et al" lost because they are fragile, not because of network issues. SOAP, for instance, is no more difficult from a connectivity perspective than REST; it rides on the same TCP/HTTP rails as REST. Yet hardly anyone, given the choice, will choose SOAP today.

Not that REST (really just HTTP APIs, mostly) is all that robust; it just asks far less of everyone involved to specify, coordinate and troubleshoot. You can hit an endpoint with your browser, pop open the browser developer tools and figure out what is going on. That _easy of use_, which CORBA, SOAP, "et al" completely forego, lowers cost, speeds development and causes an order of magnitude less nausea for developers. The market has proven the value of these benefits, despite what holdouts wish to believe.

   > The main progress has been WebRTC

Yes, it is a kind of combination of the best approaches to NAT traversal from the SIP world, supporting both STUN & TURN and ICE with the Trickle addon.

Some very good references on the topic I found recently: https://webrtchacks.com/ and https://www.html5rocks.com/en/tutorials/webrtc/infrastructur....

The WebRTC stuff was based on libjingle originally. We built that as part of the Windows Google Talk client. It was all based on XMPP and not SIP.

The techniques were used in many contexts at the time.

Yeah exactly. This signaling protocol doesn't really matter, and both SIP and XMPP to me are way over engineered and super inefficient- silly that they're text based at all. Essentially like HTTP 1.0 and 1.1 vs HTTP/2 - we just don't have the latter in the signaling case yet, or at least not standardized that I know of.

NATs are the reason REST won over CORBA et al.

I don't think NAT had an awful lot to do with that.

CORBA just didn't work across organization's internal networks when NATs started appearing in the late 90s. I am convinced it would have had such a lead it would have dominated. Web services appeared to rectify NATs/CORBA, but it sucked as a standard. Then came REST to fix web services. The root cause was NATs, IMO.

While NATs might have contributed to its demise, there were more fundamental reasons why CORBA failed.

For anyone interested in thorough analysis instead of opinions I recommend this really good article from 1994:

https://github.com/papers-we-love/papers-we-love/blob/master...

The root cause was not NAT. Web Services were CORBA-inspired so that's a pretty solid data point that it wasn't NAT.

You might enjoy this for a laugh, though (Aug. '96 vintage).

https://i.imgur.com/iVDUypy.jpg

Reply on news.ycombinator.com