W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2010

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

From: John Tamplin <jat@google.com>
Date: Thu, 13 May 2010 13:35:03 -0400
Message-ID: <k2v3f94964f1005131035r2ab79a60m98320a6fde6f49cc@mail.gmail.com>
On Thu, May 13, 2010 at 1:19 PM, Perry Smith <pedzsan at gmail.com> wrote:

> >>> [[
> >>> 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.
> >>> ]]
> >>>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.

 I think simply saying that a user agent may restrict the number of
connections like the server might is sufficient.  As written, it implies the
number is actually unlimited.

John A. Tamplin
Software Engineer (GWT), Google
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100513/f0b29d18/attachment.htm>
Received on Thursday, 13 May 2010 10:35:03 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:23 UTC