Feedback on WebSocket API, Editor's Draft 13 November 2009.

I have a few problems with the WebSocket API as it is described.


If the client is sending too much data to the server, I don't want it
to be disconnected just because some buffer is temporarily full, but
that is the required semantics of the API. If my application must send
out a lot of data, I don't want my applications to have to guess the
networking bandwidth, the browser's buffer quota and the server's
capacity and throttle my sending. Let me, the developer, be able to
say what I want to do if the server/network can't swallow my messages
fast enough. One way is to let Send return false without closing the
WebSocket, increase the ready state with an extra state
(SendBufferFull?) and an extra event handler. The send function should
in that case also send the message later (since it would otherwise be
hard to implement this functionality efficiently on most OSes). Throw
an exception if one tries to send a message when the ready state is
SendBufferFull.


There should be a described way of sending options to the protocol
implementation. Ie how to enable/disable something like Nagle's
algorithm for a TCP protocol implementation. Perhaps add an optional
third argument to the constructor instead of having to encode options
into the url or protocol strings.


The document does not describe what happens when a message is received
when no event handler has been associated with onmessage. There are at
least three choices for an implementation;
A) Throw away the message.
B) Enqueue the message until an event handler has been added.
C) Don't read from the socket until an event handler has been added.

Only the C option it acceptable to me and that allows the application
to implement A and B if that is needed. If my application can not
process received messages fast enough, I want my application to be
able to throttle the amount of messages sent and a common way to do
that is to simply stop receiving data (remove the handler in this
case) until one is ready to receive more. The client's and server's
buffers will fill up and the server application can take action on its
end. Since that can always happen, it doesn't burden the server with
any extra logic.


Although it is partly outside of the scope of the document, I still
would like to raise the question about why creating a new protocol and
not allowing plain TCP?

The internet is full of servers that speak various protocols over TCP.
The RFCs describe plenty of them. There are a lot of methods to limit
the access to them based on the client's IP number, they have methods
of logging the IP number, port and time of each connection to a
logfile. There are load balancing products that can base their
decisions on the clients' IP numbers. If you want to have a web front
end to them, you can write it with Java, Flash and Silverlight (each
with their own limits). I would love to be able to write frontends to
existing servers with the WebSocket API instead, but that's not
possible with the current proposed protocol since no existing servers
speak WebSocket. One can of course write a proxy server and tunnel the
clients' connections through it, but then the access limits would have
to be duplicated, the logging would have to be duplicated. The load
balancers would do a worse job. That's just some of the downsides of
proxies.

I understand the need to limit the amount of damage a browser can do
via malicious javascript, but why not simply use one of the existing
limits of the current networking capable web technologies?
With Java applets you can connect to TCP ports on the same hostname
that served the applet (or is it the same IP?).
With flash, you can connect to any server and any port as long as the
application can first download a policy file from the same IP number.
I'm not familiar with Silverlight, I only know it is possible to
connect to TCP ports with it.

The "origin" concept is a great way to limit malicious javascript, but
so is flash policy files. If a policy file must be downloaded from a
specific port/URL, before the application is allowed to connect and
the browser caches the result for a while that would limit DoS attacks
quite well while at the same time make the WebSocket API powerfull
enough to make use of old protocols.

Regards,
Sebastian Andersson

Received on Wednesday, 25 November 2009 17:10:56 UTC