Re: [Server-Sent Events] Infinite reconnection clarification

On Tue, Jun 12, 2012 at 3:48 AM, Odin Hørthe Omdal <odinho@opera.com> wrote:

> If you're on a page on your phone, on a Wifi connection, you go away from
> your home and take the bus. After one hour you get to work, there you get a
> new Wifi connection and the web page on your phone starts doing what it was
> up to before - even though the web page author never really thought about
> that.
>

What's the rationale behind the spec saying not to reconnect at all?  If
the API makes each app individually handle reconnects, then not only does
it push more work on web developers, it'll create two problems: apps that
attempt reconnects too rapidly, and ones that--as Odin points out--don't
reconnect at all because the developer didn't know he had to.

Too rapid reconnects will probably be a common problem.  A naive
implementation will just retry on a period, eg. every 30 seconds, which
will cause the usual problems: a server goes down, and every client begins
its 30-second delay at the same time, causing the server to be hammered
with requests every 30 seconds.  The usual solution to this is using a
random factor in the delay, plus an exponential (or at least increasing)
delay time.

It would also make sense for the web app to be able to tell that it's in a
retrying state.  That is, it's not connected and according to the current
spec would have received an error, but it's not in an error state either
(retries are still ongoing), so the app can display that it's offline.
This also lets the app know that some messages may have been missed (though
that can be done at the application level with a sequence number).

On the other hand, for rockstar web page authors, it's nicer to control
> that yourself. However, doing that, the browser doesn't know what you're
> doing in your setInterval calls, and thus it's a bit harder to be smart
> about it. If it is doing the reconnections itself, it can have different
> heuristics and algorithms to control the behaviour.


There are a lot of these.  For example, the browser knows when a connection
becomes available.  If you're on mobile it'll know when a wifi or cell data
connection becomes available, and can open a new connection right away
instead of waiting unnecessarily.  It knows if there's no connection at
all, so it can go to sleep and not waste battery with retries.  On desktop
browsers, it knows when a network cable is plugged in, and if the machine's
IP address changes.  This is all information that can be used to adjust the
reconnect timing.

-- 
Glenn Maynard