remove dependency on the backoff library

[marten-seemann]

This has bitten us before (see #13).
Really, there's no need for an external library to do a simple (jittered and capped) exponential backoff.

[betamos]

Note that backoff still jitters with randomness, even when it reached its max. I'm not worrying about it much though, just FYI.

[betamos]

Since I have some recent context debugging this (and this popped up in my feed), I'll share my thoughts and facts I found.

• Removing external dependencies is good.
• The backoff module is responsibly maintained. The maintainer is very strict about API changes (e.g. here).
• It can be difficult to write unit tests for business logic which sources time and randomness in business logic. The backoff module may be easier to mock.
• It's probably easier to tune the params or algorithm of the backoff module if necessary in the future.
• Apple uses exponential back-off for bonjour, capped at an hour. They worry a lot about multicast traffic. Also, they seem to be using it for both server and browser, whereas afaik we only use it for the browser..

[marten-seemann]

The backoff module is responsibly maintained. The maintainer is very strict about API changes (e.g. here).

My motivation for getting rid of this package is not based on the maintenance style of this repo. I just don't like pulling in a lot of code for something I can myself in 3 LOC.

It can be difficult to write unit tests for business logic which sources time and randomness in business logic. The backoff module may be easier to mock.

True, but that only applies if you dependency-inject your backoff dependency (which we didn't), so there's no change here.

Apple uses exponential back-off for bonjour, capped at an hour. They worry a lot about multicast traffic. Also, they seem to be using it for both server and browser, whereas afaik we only use it for the browser..

Are you suggesting that the maximum of one minute that we've been using here is too low?

[petar]

lgtm

[betamos]

Are you suggesting that the maximum of one minute that we've been using here is too low?

Unfortunately there's a conflict between recency and traffic amount - the longer TTL and browse intervals the more likely your data is stale and the longer it takes to recover when laptops connect and disconnect from Wifi and so on. As excessive mDNS traffic is not a common problem today, I keep these timeouts shorter in my application, so the current number is good for me.

If traffic amount becomes a problem, we could research more prior art (e.g. Chromecast, Dropbox) for "industry standard parameters" or even look at integrating with OS services like Avahi and Bonjour (which manages a single browser for all clients), should they be available on the system.

Thanks for the merge!