CIFS archives -- September 2001, week 2 (#14)
Christopher R. Hertel
crh at nts.umn.edu
Fri Sep 14 13:44:04 GMT 2001
Paul, you said:
> Why is it necessary to take this approach? It would be overly
> restrictive on implementers, and requires the spec to detail exactly how
> name resolution and directory service must be provided.
The specification will not dictate how service name resolution should be
done, but it should provide an example of how such resolution *might* be
done.
It *must* dictate which outcome will result from which strings in which
situations. There cannot be any ambiguity there. The meaning of the URL
string is inherent in the definition of the URL scheme, not in (possibly
differing) implementations.
That's why I need your input. If you implement the URL string one way and
we wind up specifying it another way then the URL strings become useless
because they don't mean the same thing from system to system.
In an updated draft, what we are trying to achieve is this:
CIFS: == SMB: - the two URL prefixes mean the same thing.
cifs:// - gives the list of local workgroups, the root of the
local W2K Domain service hierarchy. [No one has yet
shown me how to do this.]
cifs://name/ - gives the following:
+ If name is a NetBIOS workgroup name, the list of servers
in the workgroup. [I know how to find this out.]
+ If name is a NetBIOS server name, the list of shares
offered by the server. [I also know how to discover
this.]
+ If name is a DNS name or IP address, then:
= If the remote node is offering SMB services on port
139, then the list of shares. [We can simply try to
connect to the port.]
= If the remote node is offering CIFS services on port
445, then the list of shares. [Again, simply try to
connect.]
= If the remote node is a W2K Domain Controller, then
a list of servers in the W2K Domain (browse list).
[I don't know how this is done but I assume, once
again, that we would just try to connect.]
Worst case that's three NetBIOS queries (with possible
repetitions), one DNS lookup, and three TCP connection
attempts before we even know what service we're talking
to.
cifs://name:port/
- Under the assumption that browse services are not
redirected to alternate ports we can reduce the above
problem to one of simply figuring out which semantics
are used on the port. I think this can easily be done
by sending an NBT Session Setup request and ignoring
the reply if its an error.
On the other hand, what if someone does redirect service
listings (the browse list) to another port. Sigh. That
puts us back to the previous case (cifs://name/).
cifs://name/share/...
- Workgroups do not offer shares, as far as I know, so
this would only be a file service connection. If we
know that 'name' is an NBT name then we might try port
139 first. Otherwise, use Luke's suggestion and try 139
first if "smb" is the prefix, else try 445 first.
The problem with the above--and the one I am trying to solve--is that I
need to know that the 'cifs://name/' format can be made to work without
causing long delays and annoying the user.
My original suggestion was to separate old SMB and new CIFS semantics
using two different URL schemes. My thought was that by splitting the
two environments we could reduce the problems to managable ones. I am
not against creating a "unified" scheme. I just need to know that it
*can* be done in a reasonable way.
Most of all, I need to fill in the above outline with explanations of what
*might* happen on the wire to figure out which kind of service is
available.
Chris -)-----
More information about the samba-technical
mailing list