W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

Re: [Server-Sent Events] Network connection clarification

From: Chaals McCathieNevile <w3b@chaals.com>
Date: Thu, 12 Jul 2012 12:53:42 +0200
To: "Ian Hickson" <ian@hixie.ch>
Cc: "Neil Jenkins" <neilj@opera.com>, public-webapps@w3.org
Message-ID: <op.whbxvsmr22x22q@widsith-3.local>
On Wed, 11 Jul 2012 00:52:06 +0200, Ian Hickson <ian@hixie.ch> wrote:

> On Tue, 10 Jul 2012, Kornel Lesi´┐Ż~Dski wrote:
>> However, I'm afraid that the most common implementation (aside from
>> complete lack of error recovery) will be a simple as 30-second retry
>> interval and that won't be very DoS-safe. UAs can do better than that.
> That's not entirely clear.

It would seem below that you are providing reasons why UAs can do better  
than that, and better than individual authors (apart from the question of  
whether it is better to have a couple of dozen UAs write the code, or  
every app developer do so)...

>> For example the spec could require UAs to have randomized retry interval
>> and exponential backoff on failure. Is there anything more that authors
>> could do client-side to avoid DoSing?
> Exponential back-off isn't at all necessarily the right solution. In
> particular, consider mobile devices, where network connectivity goes in
> and out as the user moves. Most of the time, you want to be trying to
> connect as soon as you have connectivity. Similarly with laptops on wifi
> where the connection is only briefly hurt by an obstacle -- you want to
> keep trying every few seconds until the obstacle is gone. Exponential
> backoff if a terrible thing in those kinds of situations.
> You can distinguish local network difficulties from server load
> difficulties in a variety of ways, e.g. having a dedicated ping server on
> the same network as the "real" server, which doesn't suffer from the same
> load concerns, and which you try to contact and only switch to  
> exponential backoff if it responds but the main server isn't. And so on.
> UAs can do that kind of thing.
>> SSE is mostly a convenience API (advanced authors can use streaming XHR
>> or WebSockets to achieve the same result the hard way), so lack of
>> convenience in error recovery feels like an omission in this API.
> If it's something we do want to eventually support, I think it's be
> something to consider for v2.

I think it is something to consider as a bug in v1 - UAs can decide to  
fail eventually, but a single dropped connection seems like a poor reason  
to do so given the still somewhat flaky network we have around the world  
today. Living in Western European capitals with relatively good  
infrastructure, I find simple network dropout on fixed "broadband"  
networks far more common that something like entering a tunnel.



Chaals - standards declaimer
Received on Thursday, 12 July 2012 10:54:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:37 UTC