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

Peter Jones wrote:
On Tue, 2005-04-12 at 16:35 +0100, Simon Kelley wrote:

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

A little optimisation.

A little premature optimization is the root of a little evil? ;)
How did I know that you were going to day that?

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.

That's true, I'd allow that the caching could be done in NM (or
equivalent) It's worth pointing that AFAIK no current Unix DHCP
implementaions allow use of DHCPINFORM and therefore fetching of DHCP
configuration independent of getting a DHCP lease _at_all_. I guess I'm
also still reacting to my reception on the IETF DHCP mailing list when I
suggested changes to make it easier to use DHCPINFOM for on-the-fly



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]