smb://

[Christopher R. Hertel]

> 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.

I think it depends on the presentation.  I suggested that, at the function
level (in Richard's library, if he is agreeable) you could query for both
the #20 and @1D names and return an error if both respond.  It is then up
to the application developer to decide which list to present (or both). 

Remember that this would only happen if the network were very misconfigured.

> 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?

Right, *if* they are both servers.  If you query for both the #20 and the 
#1D then you could see both, given a misconfigured network as we've 
described.  For the #1D, an H node would get a negative response from the 
WINS server and would then try broadcast.

> 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).  

Yes, this only happens in a broken network, where B nodes and H (or M) 
nodes are mixed on the same network *and* someone chose the same names.

> 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.

That's why I suggest that the library detect this.  The application can then

- report a network misconfiguration *and* list the file server services
  (it was correctly pointed out that dumping the browse list might 
  prevent people from actually accessing shares).

- list both the browse list and the file server services.  This option 
  depends a great deal on the list is presented.

The question was raised, regarding the second option, as to how one would
differentiate between the browser listing and the server listing.  That
is, given a badly configured network and the rare chance that the name 
GOOB represents both a workgroup and a server, what does:

  smb://GOOB/

mean?

Again, assuming that we have an application (like a web browser) that has 
decided to present *both* the browse list for workgroup GOOB and the 
service list for server GOOB, it might look something like this

  GOOB servers:
    FOO
    BOZO
    GOOB

  GOOB services:
    C
    D
    CDROM

If you select service CDROM, the resultant URL would be
  smb://GOOB/CDROM/

Since a service is specified, we *know* (based on the proposed syntax) 
that we are talking about *server* GOOB.

If you select server BOZO, then your next listing might look like this:

  BOZO services:
    C
    GAMES

So it is quite workable (though rare).

Chris -)-----

--
Christopher R. Hertel -)-----                   University of Minnesota
crh at nts.umn.edu              Networking and Telecommunications Services

    Ideals are like stars; you will not succeed in touching them
    with your hands...you choose them as your guides, and following
    them you will reach your destiny.  --Carl Schultz