Re: Late to the party - multiple search domains on the network.

[Peter Jones <pjones redhat com>]

On Tue, 2005-04-12 at 16:35 +0100, Simon Kelley wrote:
> Peter Jones wrote:
> > On Mon, 2005-04-11 at 13:53 +0100, Simon Kelley wrote:
> > 
> > 
> >>. Query a configuration setting from the DHCP server. (using DHCPINFORM, 
> >>and cached.)
> > 
> > 
> > I think NM (or, rather, any program in the position of asking for a new
> > lease to be requested by the dhcp client, etc) should be the part doing
> > the caching here.
> > 
> > Only it can know which configuration settings should be queried, and
> > only it knows the semantics of how those config settings are used.  So
> > your dbus-aware dhcp client needs to either have a bunch of cache
> > manipulation functions, which aren't really important to dhcp but matter
> > to NM, or it can simply let the program with the logic do the caching.
> > 
> > 
> 
> Think of the configuration settings in the DHCP server as a read-only 
> database,

That's simply wrong, AFAICS.  This is a network; by definition things
are volatile, and there's nothing to prevent a DHCP server from
implementing settings as writable or as being fairly volatile -- the
DHCP protocol itself just isn't the mechanism for changing them.  For
vanilla "please give me an IP" usage you can ignore that fairly safely,
but there's no way the code implementing the dhcp protocol itself can
know the semantics of vendor-class options.  It _must_ have higher level
knowledge for that.

> and the DHCP client doing queries on that database on behalf 
> of NM and others. All I plan to do is for the DHCP client to keep a 
> record that "I already asked the server for the value of <foo>, so I 
> don't need to ask it again, I'll just return the same answer." This is a 
> bit of protection for the DHCP server (a network shared resource) 
> against abusive clients which ask for the same thing repeatedly. It's 
> completely transparent to the users of the DHCP client.

That's an argument for caching -- not for where the caching should
happen.

> A little optimisation.

A little premature optimization is the root of a little evil? ;)

> The cache would be flushed when DHCP leases are renewed, to avoid stale 
> data, since the configuration might not be _completely_ imutable.

The application can still know that it needs to look something up again;
it has to be able to flush at _least_ the vendor-class options.  You
_cannot_ know the semantics of when they change, and they're not
necessarily read only.

[...]
> I think later in the thread, we came to the conclusion that interface 
> manipulation could be left to NM, with the exception of a fail-safe to 
> ensure that an address is removed by the DHCP client when a lease 
> expires and is not renewed.

Yep, I just hadn't gotten there yet.  Thanks!
-- 
        Peter