[whatwg] WebSockets: what to do when there are too many open connections

[Michael Nordman]

On Wed, May 12, 2010 at 4:31 AM, Simon Pieters <simonp at opera.com> wrote:

> establishing a WebSocket connection:
>
> [[
> Note: There is no limit to the number of established WebSocket connections
> a user agent can have with a single remote host. Servers can refuse to
> connect users with an excessive number of connections, or disconnect
> resource-hogging users when suffering high load.
> ]]
>
> Still, it seems likely that user agents will want to have limits on the
> number of established WebSocket connections, whether to a single remote host
> or multiple remote hosts, in a single tab or overall. The question is what
> should be done when the user agent-defined limit of established connections
> has been reached and a page tries to open another WebSocket.
>
> I think just waiting for other WebSockets to close is not good. It just
> means that newly loaded pages don't work.
>
>
Agreed, not good. The intent of the api is to start opening a socket now,
not at some undefined point in the future after the user has taken some
undefined action (hey user... please close a tab that has a socket open...
not particularly user actionable).


> If there are any WebSockets in CLOSING state, then I think we should wait
> until they have closed. Otherwise, I think we should force close the oldest
> WebSocket.
>

Force closing the oldest is not good. A malicious site could cause all open
sockets to be closed. Also this would have nasty side effects. Consider a
memory allocator that just deleted the oldest allocation to make room for
new allocations, far removed things just start failing on odd ways... no
thank you.

An obvious way to handle this condition of "too many sockets are open" is to
fail to open the new socket with an exception/error which indicates that
condition.


>
> --
> Simon Pieters
> Opera Software
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100512/c4add750/attachment-0002.htm>