3 ms·

The part about the WebSocket connection close handshake is pretty valid. The spec should clarify the expected behavior when the underlying TCP connection is ter

by mustpax 15y ago

The part about the WebSocket connection close handshake is pretty valid. The spec should clarify the expected behavior when the underlying TCP connection is terminated prematurely. You probably want to restart the connection automatically since the WebSocket is still expected to be open. There are some failure modes to consider here for in flight data as well. Good stuff. But he starts going off the rails when he starts talking about port exhaustion and port randomization. A server can listen to a single port and service many requests, so long running requests definitely will NOT require listening to more one port. As for routers becoming clogged with alive TCP connections, the solution to this already exists. Router will drop any connection above capacity and let each party now. As long as the protocol can handle TCP termination gracefully it'll be fine.

saurik 15y ago
He in fact understands that the server is using a single port, and even uses the correct terminology for it in the document (which isn't normally important per se, but indicates that he really does understand it). In fact, the issue that he brings up seems quite insightful: most use cases of sockets in the past have involved one or two per high-level protocol, such as a chat client, or a VoIP connection. WebSockets promises an era where every document that I have open thinks it is a cool idea to have an "always up" connection to their home server, just in case I want to click on a new article (which I likely won't). In this situation, we are talking about each computer having many tens of outgoing long-lived connections as an "expected case", with some users (me, with my "too many tabs open") possibly having a couple hundred. The way that we have our router infrastructure setup--little NATs and DMZs all over the place, and with the poor implementation of the notion of "ephemeral ports"--is simply not setup to handle this kind of load at scale. I mean, if you have just a hundred users at a conference, you are in "danger territory" with regards to using many thousands of ephemeral ports on your out-bound facing firewall: this system wasn't really designed for that. That said, there are ways to rectify this, such as dropping existing connections, but do most routers actually do that, or do they instead deny new ones? Even if they /do/ drop existing ones, what is the behavior of the client? Example: you just stated, and this even seems reasonable, that if the underlying TCP connection "is terminated prematurely you probably want to restart the connection automatically": but as that will cause other peoples' connections to fail, that will just lead to a connection storm. In fact, this is a serious issue that I'm really glad this person has brought up, as I really hadn't seen this be highlighted in any previous conversations on this subject (although, I will happily admit that I don't read all of them, so it may be discussed every Tuesday on the WebSockets mailing list for all I know ;P).

by mustpax 15y ago

saurik 15y ago

He in fact understands that the server is using a single port, and even uses the correct terminology for it in the document (which isn't normally important per se, but indicates that he really does understand it). In fact, the issue that he brings up seems quite insightful: most use cases of sockets in the past have involved one or two per high-level protocol, such as a chat client, or a VoIP connection. WebSockets promises an era where every document that I have open thinks it is a cool idea to have an "always up" connection to their home server, just in case I want to click on a new article (which I likely won't). In this situation, we are talking about each computer having many tens of outgoing long-lived connections as an "expected case", with some users (me, with my "too many tabs open") possibly having a couple hundred. The way that we have our router infrastructure setup--little NATs and DMZs all over the place, and with the poor implementation of the notion of "ephemeral ports"--is simply not setup to handle this kind of load at scale. I mean, if you have just a hundred users at a conference, you are in "danger territory" with regards to using many thousands of ephemeral ports on your out-bound facing firewall: this system wasn't really designed for that. That said, there are ways to rectify this, such as dropping existing connections, but do most routers actually do that, or do they instead deny new ones? Even if they /do/ drop existing ones, what is the behavior of the client? Example: you just stated, and this even seems reasonable, that if the underlying TCP connection "is terminated prematurely you probably want to restart the connection automatically": but as that will cause other peoples' connections to fail, that will just lead to a connection storm. In fact, this is a serious issue that I'm really glad this person has brought up, as I really hadn't seen this be highlighted in any previous conversations on this subject (although, I will happily admit that I don't read all of them, so it may be discussed every Tuesday on the WebSockets mailing list for all I know ;P).