

The WebSocket Protocol - Past Travails Are To Be Avoided - jashkenas
http://www.rlgsc.com/blog/ruminations/websocket-rediscovered-travails.html

======
mustpax
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
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).

------
brohee
[https://www.ietf.org/mail-
archive/web/hybi/current/msg07070....](https://www.ietf.org/mail-
archive/web/hybi/current/msg07070.html) is a discussion about the essay on the
HyBi WG mailing list.

Why he choses to publish an essay and not to join the discussion and actually
participate to the drafting process eludes me, it's not like he doesn't
obviously have the background to usefully contribute.

