On Tue, 10 Jul 2012 20:57:23 +0100, Ian Hickson <[email protected]> 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
