Re: [Server-Sent Events] Network connection clarification

On Tue, Jul 10, 2012 at 2:27 PM, Kornel Lesiński <kornel@geekhood.net> wrote:
> 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.

Yes, this has been said before.  It's unlikely that most authors will
even realize they need to handle reconnects - EventSource is just so
simple and easy to use, it seems crazy that we'd have to hold its hand
through that.  A lot of apps will break for no reason, just because
someone's network hiccuped for 30 seconds or so.

For those that do put in reconnects, doing it right isn't hard, but is
definitely non-trivial.  You want, as Kornel says, to do exponential
backoff with some random wiggle in intervals.  A naive 30s retry
interval, as you suggest, is actually *very likely* to accidentally
DoS the servers if the hiccup was somewhere on the server's side.  If
it's on the user's side, and they have multiple apps using EventSource
which are all set up on 30s reconnects, having all of them pound the
user's connection every 30s isn't great either.

This can be handled easily and competently by browsers.  There is no
strong reason for authors to want to customize their reconnection
behavior.  The only possibility I can see with a possibly use-case is
to deny reconnections entirely, but I can't come up with one off the
top of my head, and this should be the non-default behavior if we do
offer it.

In short, the current EventSource behavior is very likely to produce
wrong defaults in most cases, breaking apps for no good reason.
Correct reconnection behavior is easy but non-trivial.  Browsers can
very simply do it all themselves, and take into account multiple
EventSources spread across multiple apps with smart behavior.

~TJ

Received on Tuesday, 10 July 2012 21:45:08 UTC