dhcpcd-discuss

On Fri, 17 Feb 2017 17:19:24 +0000
Roy Marples <roy@xxxxxxxxxxxx> wrote:

> On 14/02/17 23:51, Neal P. Murphy wrote:
> >> Making dhcpcd react to a more preferred server right away would be
> >> quite easy. Storing the adverts for a period of time and then
> >> choosing the more preferred one to bind to would be trickier. Right
> >> now, I'm not sure which is the better solution.
> > 
> > Or maybe something in the middle. Save the first advert received.
> > Then for 2-5 seconds, receive an advert, compare it with the saved
> > advert, and save the 'better' one. At timeout, use the saved advert.
> > Of course, determining 'better' may be the real challenge.
> 
> You just described the latter of the two options, so it's not really in
> the middle :)

I understood the latter to mean 'store all of the received adverts for some time, then go through all of them and choose one.' My alternative is sort-of akin to keeping a running average: when an advert arrives, compare it with the *single* advert you have saved, and keep the better one. When the timeout happens, immediately use the *single* advert you saved because it is the best of all adverts you received. My idea uses less temporary storage ('1' vs. 'n' adverts stored).
 
> > Does it make sense to choose a route now, then later change if a
> > better offer comes along?
> 
> I have no problem with choosing a route now and changing it later as
> this is kind of a grey area and dhcpcd has a history of changing parts
> of how it works if something proves better.

Come to think of it, a multihomed system potentially must change its route(s) as its upstream providers come and go, so changing a route isn't unthinkable.

N