[jcifs] Master Browsing Caching

[Christopher R. Hertel]

On Thu, Oct 24, 2002 at 11:31:15PM -0400, Allen, Michael B (RSCH) wrote:
:
> > I want to scan the network for all domains, in our network we have a 
> > number of 'interesting' master browsers.  Some won't let us connect to 
> > the IPC$ share
> > 
>       That is pretty interesting considering you have to connect to IPC$
>       to retrieve the browse list.

Some systems require a valid username/password in order to access any 
share, including IPC$.  I'm not sure that this is the problem, though.
I imagine that it would be hard to read the browse list from a system
that required encrypted auth...if you don't have the credentials.

> > , others are set up to use plain text passwords.
> > 
>       Also interesting considering retrieving the browse list usually 
>       uses null credentials but if not you can set
>       disablePlainTextPasswords = false.

Again, if you know the credentials.  :)

> 
> > So, the two areas that I am interested in 'enhancing' are as follows.
> > 
> > 	o The __MSBROWSE__ name should not be cached in NbtAddress
> > 
> 	Why?
> 
> >  :- a quick 
> > change to getCachedAddress stops the cached name ever getting used.
> > 
> > 	   	if (hostName.name.equals(NbtAddress.MASTER_BROWSER_NAME)) { return 
> > null;  }
> > 
> 	Set cachePolicy = -1.
> 
> 	All jcifs properties are described on the Overview page of the API
>       documentation.

I agree with the "Why?".  What does caching do that prevents you from 
getting all of the local __MSBROWSE__ IPs?

> > 	o Currently the NameServiceClient  waits on the first Name response 
> > before continuing, if there is more than one response (if there are 
> > multiple domains on the network), then we should probably wait for all 
> > responses within 500 ms of the first response, and then interrogate all 
> > the master browsers individually you should find yourself with an very 
> > complete idea of domains on the network.
> > 
>       We're not going to do this. We do what NT does. You should be able
>       to collect domain names fine listing "smb://". Sure it *might* 
>       create a more complete list if you have machines going up and down 
>       like yo-yos but it's not behavior that is observed in any other
>       clients I don't really see the benefit.

There are two perspecives here.  If you are looking for a local master
browser (*any* local master) then sending a query for __MSBROWSE__ and 
taking the first response is the right thing to do.  This is probably 
correct for 99% of what jCIFS will need to do on a LAN.

>From the pedantic point of view, however, if you query for a group name 
you expect a list of IPs (though the list may have 0, 1, 2... entries).
The problem with this point of view is that Microsoft broke it a long time 
ago when they failed to implement a working NBDD.  Getting a proper group 
list only works in B mode on a local LAN.  Still, that is the mode we're
talking about.

I also think Mike's right about "what NT does", which is that it keeps 
only the first IP in its cache when it does a broadcast name query on a 
group name.  You can't do point-to-point connections with a group, you can 
only make them individually.  It says so in the RFCs.  :)

If it sounds as if I'm waffling, I am.  Mike is right from the practical 
point of view.  I would say, though, that it would be worth-while to have 
a mechanism for doing a group name query and retrieving from that a list 
of IPs.  That is lower-level functionality that can be very useful for 
folks doing special-purpose work like this.

> >   From my understanding of CIFS 
> > each WORKGROUP/DOMAIN has it's own Master Browser, even though the 
> > master browsers should have all DOMAINS in their browselist.
> > 
> 	This is not quite right. Each subnet has at least one master browser.
>       I don't know if there is a master browser for each workgroup. I
>       don't think so. Chris?

I'm 'fraid it is as complicated as it sounds.  :)

If there is at least one member of a given workgroup on a given subnet 
that is capable of being an LMB, then there will be an LMB for that 
workgroup on that subnet.

So, if you have ten nodes on a subnet, and:

2 are members of workgroup FOO
3 are members of workgroup BAR
5 are members of workgroup ICK

... and all of them are capable of being LMBs... then you will have three 
LMBs, three backup browsers, and four potential browsers.

This is also how cross-workgroup browsing works.  The LMBs all find one 
another via the __MSBROWSE__ name.  That's what the name is used for.
The LMBs announce their browse lists to the __MSBROWSE__ name, so the LMB 
for workgroup FOO sends a message to __MSBROWSE__ and now BAR and ICK know 
about the FOO workgroup.

If the workgroup is an NTDomain (geez I hate the terminology) then the 
local LMBs pass the new information up to the DMB.

What I don't know (yet) is:
1) Do the DMBs do anything to coordinate cross-NTDomain browse lists?
2) What happens to a node on a subnet that doesn't have a member of 
   workgroup FOO when the user tries to look at the server list for
   FOO?

On that last question, I know that the easy thing to do is look for a
DMB for workgroup FOO (assuming one exists).  I don't know what Windows 
does, though.

Chris -)-----


-- 
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org