Hacker News Reader

Clients should really be using something like exponential backoff ethernet-style.

Just imagine how annoying that would be. Your local resolver has a blip of connectivity and during the time it cannot contact an origin nameserver it burns all of the reasonable retry intervals. After a few seconds its link comes back up but the resolver is still waiting because of "backoff".

Exponential backoff is a really bad antipattern that harms users. There are other, better ways to shed load.

Also, there's no evidence that any DNS infrastructure was overloaded during this event, so what are we even discussing?

6 seconds of wait for a 3-second blip still sounds reasonable.

Not really; if I unplug a cable, connections break; but if I plug it back in they can and should resume much faster than 6 seconds.

And what about a five minute "blip"? Arguably it should resume proper operations as soon as the link goes back up, not some (unknown to user) time afterwards.

Yes but event driven is way different. That should be instant because the software can be told by the system that connectivity was restored and respond immediately since it’s aware of the hardware being plugged in.

What should people use instead of exponential backoff?

Capped Fibonacci backoff with random delay inserted at the cap?

Reply on news.ycombinator.com