namecache redesign

[tridge at samba.org]

> Ahh.  I didn't realize that you wanted a persistent cache,

It's not just the persistance, it's the sharing between
processes. Imagine what happens when hundreds of PCs power up in the
morning and they all want to talk to a Samba server, and that server
needs to resolve some netbios name (eg. DC) or DNS name (eg. SRV
records).

If we share the cache between all the smbd processes then that will
make things scale a lot better, particularly as lookups happen with
UDP packets, so trying several hundred at once can lead to lookup
failures.

> though I'm a bit concerned with the idea of caching NBT name
> resolution long-term.

NBT names come with an attached timeout value, we should probably use
it :)

>  I'm thinking about things like the LMB name.  
> At startup, if the LMB name is in the cache will smbd use that mapping or
> call for an election?

If its in cache and not expired then we should probably use it,
although I wouldn't mind a way of forcing a cache clear on startup.

> What happens if the mapping is no longer valid?
> What happens if there were changes in smb.conf that, for example, cause 
> Samba's status as a master browser to be [up|down]-graded?

we used to cope with this in nmbd by checksumming smb.conf and if
these was a change then dump the cache. Maybe a similar solution could
be used. We just store the checksum in the cache, and make loadparm.c
calculate it during the load.

> I'd want to put the NBT name cache into nmbd and have smbd talk to
> nmbd for all local name resolution.

I don't think that will scale very well. A shared cache via tdb will
scale much better than everyone talking to one process.

Cheers, Tridge