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

[Perry Smith]

On May 13, 2010, at 10:05 AM, Simon Pieters wrote:

> On Wed, 12 May 2010 20:51:59 +0200, Michael Nordman <michaeln at google.com> wrote:
> 
>> 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.

Hosts have limits on open file descriptors but they are usually in the ten's of thousands (per process) on today's OSs.

I don't think this is an area for the spec.  The open must be allowed to fail if something goes wrong.  The OS might reject it and the browser might reject it too.  Aside from that, I don't think the spec should dictate what to do here.

A nice UA, I think, would monitor a particular tab or browsing context for being out of control.  This might be opening an infinite number of sockets or running infinite threads to bog the user's system down (or it might be because I forgot a semicolon :-).  There are countless ways for nasty javascript to upset the user.  A nice UA from a nice group would learn these new ways and adapt to them over time.  When detected, the UA could ask the user if they want this mayhem to continue or not.  I think rampant socket abuse is just one of countless places nasty javascript is going to exploit the user.  I don't see how the spec can foresee all of them nor should a "complaint UA" be required to detect all of them.

Perry
Ease Software, Inc. ( http://www.easesoftware.com )

Low cost SATA Disk Systems for IBMs p5, pSeries, and RS/6000 AIX systems