5 ms·

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 tim

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.

pvg 9y ago
NATs are the reason REST won over CORBA et al. I don't think NAT had an awful lot to do with that.
- jamesblonde 9y ago
  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.
  - gluczywo 9y ago
    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/distributed_systems/a-note-on-distributed-computing.pdf https://github.com/papers-we-love/papers-we-love/blob/master...
  - pvg 9y ago
    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 https://i.imgur.com/iVDUypy.jpg
nbaksalyar 9y ago
> 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/ https://webrtchacks.com/ and https://www.html5rocks.com/en/tutorials/webrtc/infrastructure/ https://www.html5rocks.com/en/tutorials/webrtc/infrastructur....
- jbeda 9y ago
  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.
  - adamfisk 9y ago
    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.
topspin 9y ago
"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.

pvg 9y ago

NATs are the reason REST won over CORBA et al. I don't think NAT had an awful lot to do with that.

jamesblonde 9y ago
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.
- gluczywo 9y ago
  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/distributed_systems/a-note-on-distributed-computing.pdf https://github.com/papers-we-love/papers-we-love/blob/master...
- pvg 9y ago
  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 https://i.imgur.com/iVDUypy.jpg

nbaksalyar 9y ago

> 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/ https://webrtchacks.com/ and https://www.html5rocks.com/en/tutorials/webrtc/infrastructure/ https://www.html5rocks.com/en/tutorials/webrtc/infrastructur....

jbeda 9y ago
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.
- adamfisk 9y ago
  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.

topspin 9y ago

"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.