Re: [Server-Sent Events] Network connection clarification

On Sun, 29 Apr 2012, Neil Jenkins wrote:
>
> In response to the request for comments on server-sent events, I believe 
> the definition of when to fail a connection needs clarification and/or 
> adjustment.
> 
> Specifically, in Section 5 Processing Model, the line:
> 
> "Any other HTTP response code not listed here, and any network error 
> that prevents the HTTP connection from being established in the first 
> place (e.g. DNS errors), must cause the user agent to fail the 
> connection."
> 
> Combined with the definition of "fail the connection"...
> 
> "When a user agent is to fail the connection, the user agent must queue 
> a task which, if the readyState attribute is set to a value other than 
> CLOSED, sets the readyState attribute to CLOSED and fires a simple event 
> named error at the EventSource object. Once the user agent has failed 
> the connection, it does not attempt to reconnect!"
> 
> ....this seems to imply that if there is no internet connection 
> currently present, the EventSource connection will fail and not attempt 
> to reconnect.

Correct. EventSource is intended to not ever reconnect except in the case 
of the server being fine.


> This obviously reduces its usefulness. For example:
> 
> - A user is connected to the internet via 3G on a train and passes
>   through a tunnel. The connection is lost, so the EventSource
>   object tries to reconnect after x (say 30) seconds.

Right, though that's more of a side-effect of the design than intended. 
The reconnection logic is intended for the case of a server wanting the 
user agent to reconnect because it's shifting its load (e.g. when you have 
a cluster of machines behind a load balancer and one of the machines is 
being taken down so needs to offload its connections to others on the 
cluster) or because it knows no events will be coming any time soon. That 
it happens to also mean that a network break will result in a reconnection 
(once) is an unfortunate side-effect.


>   If, when this
>   first reconnection attempt happens, the user has still not
>   regained a network connection, it will fail permanently and never
>   reconnect again.

Right. The script is supposed to be the one doing the reconnecting.


> - When a computer wakes from sleep, there is often a delay before the
>   network connection is re-established; this creates a race condition -
>   if the EventSource attempts to reconnect before the network is
>   reestablished it again fails permanently.

Right. Again, it's only because it's hard to distinguish this case from 
the server closing the connection that there's any attempt to reconnect at 
all.


> In my opinion, the failure due to the absence of an internet connection 
> should be a temporary failure, and should ideally schedule a 
> reconnection attempt when the computer next finds a network. The current 
> spec seems to explicitly disallow this, although some browsers are 
> attempting to reconnect anyway.

The idea is to let the script handle network troubles, so that authors are 
in full control of how much load their servers get when they are having 
trouble. The alternative is that UAs will DOS networks without the 
networks having a way to gracefully reduce it.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 10 July 2012 19:57:46 UTC