Subject: [hybi] limits on number of connections

From: Joe Mason <[email-masked]>
Date: Mon, 1 Nov 2010 13:08:00 -0400

If I'm implementing a WebSocket client which has a fixed number connections allowed at a time, what is the best way to handle an attempt to create a connection beyond this limit?

The API only defines two exceptions that can be thrown from the constructor: SYNTAX_ERROR and SECURITY_ERROR.  Neither of these seem appropriate.

onerror is only called for errors that happen after connection is finished, so that's not usable.

So the only option I can see is to queue the connection and just not call "onopen" until another WebSocket connection is closed and frees its resources.

However, this is opaque to the caller and it's pretty likely that users will write scripts that don't behave well under these conditions, for example opening several long-running connections, leaving them all open until all work is done, and then closing them all at once.  I don't see any recommendations in the spec about how many websocket connections a user should consider reasonable to open at once.  I think this situation should be reported to the user somehow with an "out of resources" error, so that either a script can handle it (by using fewer connections than expected, retrying the connection after another connection is closed, or just aborting cleanly) or the error becomes clear in the debugger, rather than just deadlocking waiting for a connection which is never going to open.

More generally, if a request fails due to the underlying transport being unavailable, how should that be reported?  It's neither a SYNTAX_ERROR nor SECURITY_ERROR.  ("Out of resources" is a subset of this because it's guaranteed transient and it can be assumed that closing some other connections will clear up the problem, while a general network error is probably out of the script's hands.)

I understand the API is considered stable at this point, unlike the protocol.  Is there any scope for adding a new exception type?  (Also, it seems SECURITY_ERR and SYNTAX_ERR are not defined in the API spec at http://dev.w3.org/html5/websockets/, either directly or by reference - AFAICT the first is in http://www.w3.org/TR/XMLHttpRequest/#exceptions and the second is in http://www.w3.org/TR/DOM-Level-3-Core/idl-definitions.html.  Is that correct?  NETWORK_ERR from XMLHttpRequest might be appropriate for connections that fail for reasons other than invalid parameters.)

Joe

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 02 Nov 2010 03:27:00 +0100

* Joe Mason wrote:
>If I'm implementing a WebSocket client which has a fixed number
>connections allowed at a time, what is the best way to handle an attempt
>to create a connection beyond this limit?

This seems to be a question about the client-side API proposal by the
W3C. Comments on that should be sent to <[email-masked]>; the
IETF hybi working group is mostly concerned with the bytes that go over
the wire.

Per my cursory reading of the API proposal, it would seem this would
trigger the "fail the WebSocket connection algorithm"; I could not find
a definition of that, but apparently you would get a `close` event with
no `open` event. That of course does not let you distinguish between
various error cases, so it'd be like a "connection refused" condition.

I recommend you re-send your feedback to <[email-masked]>.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Joe Mason <[email-masked]>
Date: Tue, 2 Nov 2010 13:14:03 -0400

Thanks, I was under the impression both API and protocol were in scope for this list for some reason.  (I figured I just hadn't seen any API discussion because it was stable.)

I believe the "fail the WebSocket connection algorithm" implicitly references the algorithm in the protocol spec.

You're right, I had missed that it sends "close" in this case - I thought that it didn't send that until connection was complete, like error.  Since that seems to answer my question, I won't bother bringing this up on the other list.

Thanks!
Joe

---

From: "Simon Pieters" <[email-masked]>
Date: Tue, 02 Nov 2010 19:35:00 +0100

On Tue, 02 Nov 2010 18:14:03 +0100, Joe Mason <[email-masked]> wrote:

> Thanks, I was under the impression both API and protocol were in scope  
> for this list for some reason.  (I figured I just hadn't seen any API  
> discussion because it was stable.)
>
> I believe the "fail the WebSocket connection algorithm" implicitly  
> references the algorithm in the protocol spec.
>
> You're right, I had missed that it sends "close" in this case - I  
> thought that it didn't send that until connection was complete, like  
> error.  Since that seems to answer my question, I won't bother bringing  
> this up on the other list.

This has been discussed on whatwg before but no conclusion was reached...

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-May/026307.html

If you have any ideas on what is the best behavior then I suggest you post  
that to webapps or whatwg.

-- 
Simon Pieters
Opera Software