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

Re: [Server-Sent Events] Infinite reconnection clarification

From: Glenn Maynard <glenn@zewt.org>
Date: Wed, 13 Jun 2012 08:35:57 -0500
Message-ID: <CABirCh_wECJ3KAJSRqrXu3aiBOmYVNaZp8A6th4__viw5N7pmg@mail.gmail.com>
To: Pablo Flouret <pablof@motorola.com>
Cc: Odin Hørthe Omdal <odinho@opera.com>, Ian Hickson <ian@hixie.ch>, "public-webapps@w3.org" <public-webapps@w3.org>
On Tue, Jun 12, 2012 at 6:30 PM, Pablo Flouret <pablof@motorola.com> wrote:

> 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."
>

This is exactly the sort of bad workaround that I was talking about.  It
causes at least two problems.  First, user annoyance at having to wait 30
seconds for it to reconnect (if it takes 2 seconds to reestablish the
connection, the browser can know this and reconnect promptly instead of
making the user twiddle his thumbs for half a minute).  Second, if the
server dumps every connection simultaneously (eg. the server process
crashed) then every client will be on the same 30-second timer, resulting
in every client periodically hammering the server simultaneously.  A smart
client implementation can avoid this, randomizing the delay so the
reconnects come in at different times, but you can't expect every web
developer to implement that.

-- 
Glenn Maynard
Received on Wednesday, 13 June 2012 13:36:31 GMT

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