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

Re: [Server-Sent Events] Network connection clarification

From: Kornel Lesiński <kornel@geekhood.net>
Date: Tue, 10 Jul 2012 22:27:48 +0100
To: "Neil Jenkins" <neilj@opera.com>, "Ian Hickson" <ian@hixie.ch>
Cc: public-webapps@w3.org
Message-ID: <op.wg81wmm8te2ec8@aimac.local>
On Tue, 10 Jul 2012 20:57:23 +0100, Ian Hickson <ian@hixie.ch> wrote:

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

I share the concern about DoSing.

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.

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?

It'll be easier to get handful of UAs to implement robust recovery by  
default than to expect each and every author to do that.

I'm not sure whether online/offline events are quick and reliable enough  
to speed up reconnection after network failure on client side, but most  
UAs could observe network on system level and avoid waiting too long time  
after temporary network signal loss. I doubt many authors will implement  
recovery as sophisticated as that.

There's "retry" directive in the SSE protocol, so authors have some  
control already (server under load can send retry: 99999 or site-specific  
control message and close the connection). If that's not enough, then I  
think it'd be better to give authors more control of UAs auto-reconnect  
features, rather than expect all authors to better than UAs with their  
implementation from scratch.

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.

regards, Kornel Lesiński
Received on Tuesday, 10 July 2012 21:28:18 UTC

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