W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: [Server-Sent Events] Infinite reconnection clarification

From: Pablo Flouret <pablof@motorola.com>
Date: Tue, 12 Jun 2012 16:30:18 -0700
To: Odin Hørthe Omdal <odinho@opera.com>, "Ian Hickson" <ian@hixie.ch>
Cc: "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <op.wftcwsdnblozfe@berserk.local>
On Mon, 11 Jun 2012 17:56:00 -0700, Ian Hickson <ian@hixie.ch> wrote:

> On Tue, 17 Apr 2012, Odin Hørthe Omdal wrote:
>>
>
>> I tried yanking the network for 10+ minutes, and when I put the cable in
>> again, both Firefox and Chromium used 25 seconds to reconnect. When only
>> yanking it for one minute, the reconnection was much faster (2-5
>> seconds). This with *reconnection time* set to 500ms.
>
> As far as I can tell, none of that is conforming. If you yank the cable,
> they should retry once, then give up, per the spec.
>

FWIW, this was one of the complaints from the opera mail team when they  
put server-sent events to some nice real-world use [1]. In particular:

"We’ve also found a potential related issue with the spec itself: "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". This  
means that if you lose internet connection (for example pass through a  
tunnel on the train), the eventsource will try to reconnect, find there’s  
no network and fail permanently. It will not make any further attempts to  
connect to the server once a network connection is found again. This same  
problem can cause a race condition when waking a computer from sleep as it  
often takes a few seconds to re-establish the internet connection. If the  
browser tries to re-establish the eventsource connection before the  
network is up, it will therefore permanently fail.

This spec problem can be worked around by observing the error event. If  
the readyState property is now CLOSED (in readyState 2), we set a 30  
second timeout. When this fires, we create a new eventsource object to  
replace the old one (you can’t reuse them) which will then try connecting  
again; essentially this is manually recreating the reconnect behaviour."


[1]  
http://blog.fastmail.fm/2012/01/09/building-the-new-ajax-mail-ui-part-1-instant-notifications-of-new-emails-via-eventsourceserver-sent-events/

-- 
pablo flouret
motorola | webkit / browser team
Received on Wednesday, 13 June 2012 12:08:28 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:52 GMT