Subject: Re: [hybi] Additional WebSocket Close Error Codes

From: Jason Duell <[email-masked]>
Date: Fri, 01 Jun 2012 12:19:53 -0700

On 05/29/2012 04:15 AM, Alexey Melnikov wrote:
>
>> I never got much of an answer about adding a new code for "client has 
>> too many websockets open", but let me ask it again.   We could 
>> conceivably have your proposed 1013 code  ("try again later") cover 
>> this case.   But one downside of this is that it doesn't distinguish 
>> between the case where the application could open a connection to 
>> another server (a particular server is overloaded),
>
> I think having a new code for "try another server" would be better, as 
> it is more explicit that an immediate action can be attempted (where 
> "server overload" or "try again later" imply that an action in a 
> future can be attempted). Would such split work for you?

There may not be another server, so "try another server" isn't always 
applicable.   So my vote would go to "server overload".   But I don't 
have strong feelings about it, so long as it's differentiated from 
client websocket limit reached.

cheers,

Jason
Mozilla

>> and the case where no websockets are going to work unless/until some 
>> existing ones go away (Client websocket limit reached).  So I suggest 
>> we want different codes for these.
>>
>> This could look like
>>
>>    1013    "Server busy"
>>    1014     "Too many websockets open in client"
>>

---

From: Jamie Lokier <[email-masked]>
Date: Thu, 7 Jun 2012 03:39:18 +0100

Alexey Melnikov wrote:
> Hi WG,
> I am sorry I didn't followup on this when the following 2 codes were
> suggested (See
> <http://www.ietf.org/mail-archive/web/hybi/current/msg09284.html>):
> 
> 1012/Service Restart
> 1012 indicates that the service is restarted. a client may
> reconnect, and if it choses to do, should reconnect using a
> randomized delay of 5 - 30s.
> 
> Use case:
> restart a service with 100k clients connected
> clients present an informative user notification ("service
> restarting .. reconnecting in N secs)
> clients should not reconnect all at exactly the same time .. thus
> the randomized delay

On the other hand, if you have almost real-time requirements and you
simply restarted a service, sometimes 5-30s is uncomfortable long.
For some applications it means the client is effectively frozen for
5-30s.  Sometimes, you want restarting the service to be as invisible
to the user as reasonably possible.

Your server knows the current load, so has an idea if it could handle
immediate or faster reconnection attempts.  On an intranet, you might
want it randomised as 0-1s for 10k clients.

Any reason you chose this length of time?  Could a suggested delay be
included with the error, with 5-30s being the default?

> 1013/Service Overload
> 1013 indicates that the service is experiencing overload. a client
> should only connect to a different IP (when there are multiple for
> the target) or reconnect to the same IP upon user action.

Maybe it could suggest which different IP(s) (and/or URL(s))?

-- Jamie

---

From: Tobias Oberstein <[email-masked]>
Date: Thu, 7 Jun 2012 04:50:02 -0700

> > 1012/Service Restart
> > 1012 indicates that the service is restarted. a client may reconnect,
> > and if it choses to do, should reconnect using a randomized delay of 5
> > - 30s.
> >
> > Use case:
> > restart a service with 100k clients connected clients present an
> > informative user notification ("service restarting .. reconnecting in
> > N secs) clients should not reconnect all at exactly the same time ..
> > thus the randomized delay
> 
> On the other hand, if you have almost real-time requirements and you simply
> restarted a service, sometimes 5-30s is uncomfortable long.
> For some applications it means the client is effectively frozen for 5-30s.
> Sometimes, you want restarting the service to be as invisible to the user as
> reasonably possible.
> 
> Your server knows the current load, so has an idea if it could handle immediate
> or faster reconnection attempts.  On an intranet, you might want it randomised
> as 0-1s for 10k clients.
> 
> Any reason you chose this length of time?  Could a suggested delay be included
> with the error, with 5-30s being the default?

When I suggested that use case, the 5-30s where merely a rough, unscientific guess what
range could make sense in a public WAN server scenario .. the 5s for allowing the server
to restart at all, and the upper bound of 30s leaving 25s for 100k clients to reconnect
within that interval:

100k/25s = 4k/s opening WebSocket handshakes sustained

But yes, ultimately the interval should be decided by the server based on (at least)

* exptected server restart time
* LAN vs WAN
* # of connected clients
* opening handshake rate the server can do

The server could for 1012 provide a close reason (string):

[5,30]

that is comma separated randomized reconnect interval .. JSON.

> > should only connect to a different IP (when there are multiple for the
> > target) or reconnect to the same IP upon user action.
> 

Close reason could be again JSON list like i.e.:

["ws://2nd.example.com", "ws://3rd.example.com:9000", "wss://4th.example.com", "ws://62.146.25.34"]

That could be interpreted by the client as a priority sorted list of servers to connect.

The priorities could also be given explicitly

[["ws://2nd.example.com", 2], ["ws://3rd.example.com:9000", 5], ["wss://4th.example.com", 12], ["ws://62.146.25.34", 9]]

where the client then connects to a server from the list with a probability proportional to the priority value, i.e. to

ws://3rd.example.com:9000

with probability

5 / (2+5+12+9)

and so on.

> 
> -- Jamie
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi