Hacker News Reader

Comment by jodrellblank | Hacker News Reader

> Websockets let you use RHTTP. The client connects, sends a request to switch to RHTTP, then becomes an HTTP server.

This isn't going to be another SIP, is it? 'Yes we've all agreed on this protocol, off you go and use it. NAT? What's NAT? Is it important?'

View on HN

I believe the key is in the part that says The client connects. The client initiates the TCP connection (thus traversing NAT), which stays alive like any other HTTP 1.1 connection (which has a Content-length header). The server produces the requests, however. I suspect that in order to traverse proxies, the client establishes the original connection via the quasi-standard HTTP CONNECT method which is otherwise used for proxying HTTPS.

This is conjecture, however, as I've yet to research RHTTP.

EDIT: it seems my instinct on proxying was incorrect, other posts imply that the 'Upgrade' header is used. I'm a little surprised that this is widely supported by proxies. I suppose the proxy just keeps the connection open if there's no specified Content-length. Timeouts spring to mind as a potential issue.

I think the RHTTP bit is someone confusing WebSockets with Opera's builtin webserver thing.

(No mention of reverse HTTP in http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-...)

Edit: Disregard that I need coffee. (Aka, I'm the one confused about Opera's builtin webserver thing.)

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.

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