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