Hacker News Reader

Comment by iamaleksey | Hacker News Reader

Well, the NAT issue is almost solved with STUN [http://en.wikipedia.org/wiki/STUN] and TURN [http://en.wikipedia.org/wiki/Traversal_Using_Relay_NAT] (in those cases where STUN is not enough). Together they make ICE [http://en.wikipedia.org/wiki/Interactive_Connectivity_Establ...].

But none of these is needed for websockets to work.

View on HN

N.b. --- those solutions only work for UDP traffic, not TCP; if you want to use them and have a reliable stream protocol you'll end up reinventing TCP atop UDP.

"Reliable" and "stream" are different things. We often use (a variant of) RDP, reliable datagrams. We often want packets with guaranteed delivery, but not necessarily guaranteed order. We also use what we call USP (only partially intentionally to confuse everyone) which is an unreliable stream protocol. Packets aren't guaranteed to arrive, but if they do, they're in the right order.

Such variants have their places.

True indeed (and that's why I used both words), although for a general-purpose protocol intended for wide deployment, you probably want both properties.

There is STUNT for that, but I have no idea about its current status. [http://nutss.gforge.cis.cornell.edu/stunt.php] [http://tools.ietf.org/html/draft-ietf-mmusic-ice-tcp-08].

I don't think it has a very good success rate. I'm guessing that for a truly reliable TCP solution you would need to throw everything at the wall and hope something sticks: uPNP, NAT-PMP, and maybe this STUNT/ICE-TCP thing.

Reply on news.ycombinator.com