1299981 - Determine and implement a backoff policy for clients

Status: NEW

(Core :: DOM: Push Subscriptions, task, P3)

Description

[Lina Butler (ex-Mozilla)]

This has come up before, but we decided it wasn't worth the extra complexity then. We currently only do exponential backoff for reconnects; let's spend some time thinking about other ways to reduce the strain on an overloaded connection node.

Some ideas from today's meetup:

* We could wait a random amount of time before connecting at startup (between 0 and 5 minutes, for example), to avoid thundering herds when machines restart or wake up from sleep at the same time.

* For `register` and `unregister` responses, the server could send a 500-class status code with a "retry-after" field. This would indicate that the client should keep its connection open (reconnecting would make the problem worse!), and queue or reject requests until the server is less busy. H2 would give this to us for free.