smb://

[Steve Langasek]

On Thu, 28 Dec 2000, Christopher R. Hertel wrote:

> Right.  You can have this situation:
> A local LAN which contains a workgroup named BLEE.
> A remote subnet with an H or M mode server named BLEE.
> Since the two do no see each other, they are in separate name spaces and 
> immune to each other.

> Enter an H-mode node in workgroup SPOO on the same IP subnet as workgroup
> BLEE.  It calls for "smb://", and will get "BLEE" in the list.  If it now 
> calls for "smb://BLEE/" will it get the workgroup or the server?

> Note first that this is *still* considered an improperly configured 
> network by RFC standards.  Also, a WINS proxy would fix the problem.  
> However, the other solution is to try both BLEE#1D and BLEE#20.  If you 
> get replies from both then list both.

Ok.  It strikes me that the user may think it odd to see servers listed
together with shares in the same window, but if there's consensus that this is
acceptable, then I'd say it's the least-bad option. :)  I still think it's
preferable to have a URL syntax that clearly differentiates between server and
workgroup, but if no consensus can be reached on how to do that, then this is
also usable.

>> Question is, does this configuration work with existing clients, and if
>> so, what do we do about it?

> Basically, it's a messed-up namespace.  The client node can see both the
> local B nodes and remote nodes that use the WINS server, but the remote
> nodes cannot see the local B nodes and vice versa, which is bad all
> around.  It's not just workgroup and server names.  In this situation, our
> client might be able to see two servers with the same name.  Once
> registered locally via B mode, and one from a remote subnet via the WINS
> server. 

Unless I'm mistaken, an H-node client would never see two servers with the
same netbios name.  Doesn't one lookup method always take precedence over the
other?  So either the local B-node server will be accessible (by name), or the
remote P-node will be accessible, but not both?

The reason I distinguish is that, in the case where two servers are trying to
use the same name, things are already broken and someone will fix them (or
everyone will ignore them).  In the case where a server uses the same name as
a workgroup, even though this is Bad, we run the risk of breaking something
that isn't broken with other clients.

Steve Langasek
postmodern programmer