[jcifs] BFS vs DFS

Michael B. Allen mballen at erols.com
Sat Jul 28 11:17:39 EST 2001


On Fri, Jul 27, 2001 at 10:28:55AM -0500, Christopher R. Hertel wrote:
> On Fri, Jul 27, 2001 at 07:47:45AM +0200, Torgny Johansson wrote:
> :
> > What's taking time is sometimes when there are no shares on a pc or if the
> > pc can't be found.
> 
> Hmmm...  I can imagine that there would be a timeout problem when a server
> cannot be found, but I'm surprised that no shares would cause a delay.

Yes, this is strange. The name is coming from the browse list but
querying WINS should immediately return false in which case the thread
should immediatly move on. But if hosts are going up and down like yoyos
then WINS and the browse list may not be up to date. Actually, if WINS
returns false the I believe the client will try to broadcast which I
think takes about 6 seconds to time out but of course the name must have
come from somewhere in the first place. SMB and WINS systems are highly
dynamic so you really have to start looking at traces to see what's
happening. Querying for a list of shares should return immediately though.

> > Also, the LAN I'm crawling is on many different subnets. I've set the wins,
> > but I have to set the baddr to the same adress as the wins to be able to
> > list all online pcs.
> 
> That's odd.

I think the reason you must set the broadcast address is because you
(I know I'm respondin to Chris but I'm addressing Torgny) have many
machines that do not register with WINS. You will natrually not see these
machines unless you broadcast for them and they happen to be on your
local network segment. This would confirm suspicious timeouts mentioned
above and might screw up jCIFS. Having some clients that register with
WINS and others that just broadcast is a bad idea -- unfortunately this
is all to common on University networks.

> 
> > Otherwise my crawler can't list any workgroups.
> 
> Huh?  That doesn't make sense.  You need to use broadcast name resolution
> to find the workgroups.
> 
> Mike, what do you think is happening here?

The default value for baddr is 255.255.255.255. This should be fine
unless you have multiple interfaces in which cast I think you will the
exception described in the FAQ. I beleieve there are other ways to screw
up the broadcast address. It might be the local machine, the network,
or elsewhere. It may be necessary to set baddr just to communicate via
broadcast at all. If you don't you may not be able to find local master
browsers in which case you wouldn't be able to list any workgroups.

> > I suppose it was this you guys talked about in an earlier discussion and this
> > was being dealt with in the 0.6 ver, right?
> 
> I'm not sure what's happening here.  It doesn't sync with my understanding
> of the workings of this stuff.  By setting the baddr to the same address
> as the NBNS you are, essentially, forcing P mode.  I don't know how you

Mmm, well I suppose if you set baddr to the WINS IP then the code that
was meant for broadcasting will go to the WINS server and might actually
get an answer. But if WINS is like 192.168.1.23 then baddr might very
well be 192.168.1.255. Are you using the *exact same* IP for baddr and
wins Torgny?

About what we were talking about before Torgny, jCIFS cannot get a server
list for workgroups that are entirely on a different subnets than the
client. It's as simple as that.

Mike




More information about the jcifs mailing list