[jcifs] Re: SMB URL
Christopher R. Hertel
crh at nts.umn.edu
Sat Sep 15 02:37:17 EST 2001
> please could someone expliain the definition of 'unified'?
> and also non-overlapping.
We are all coming at this problem from separate directions, so it is no
surprise that we are having terminology trouble. I think these terms
came from Conrad, but I'm not sure any more.
Okay, this pure taxonomy not a statement of intent. Terminologywise:
- By "unified" I mean that one URL format (either SMB: or CIFS: or both
as aliases for one another) would support browsing and filesharing
over either transport.
- By "non-overlapping" I mean the model in which SMB: speaks only
SMB/NBT and CIFS: speaks only CIFS/TCP.
- By "SMB/NBT" I mean "old-style" (pre-W2K) NBT transport.
- By "CIFS/TCP" I mean SMB over native TCP and all of the newer
supporting protocols and services that go along with that
(MS-Kerberos, Active Directory, MS-DNS, etc.)
Hope that helps.
The whole purpose of this discussion is to determine if it is reasonable
to create a "unified" specification as proposed by Thursby and Apple.
History: In earlier discussions, I had proposed the "non-overlapping"
approach. The current draft includes that proposal. My
reasoning, for historical reference, was as follows:
1) I felt that the "non-overlapping" approach had already
presented us with a large problem. The string "smb://name/"
is already difficult to resolve (is it a DNS name or IP, a
NetBIOS server name, or a NetBIOS workgroup?).
2) The different transports seemed sufficient to distinguish
the two systems (SMB/NBT vs. CIFS/TCP). In addition, the
two transports come with completely different support
protocols. Browsing, authentication, etc. are all different.
At the CIFS conference, I presented the SMB URL and opened a
number of discussions with different vendors. At that time, the
folks from Thursby and Apple proposed the "unified" model. They
were able to convince me that the problems of switching between
SMB/NBT and CIFS/TCP were managable (though, once again, these
take time to resolve on the wire).
Where we are:
Where *I* am right now is this: I need one or more documentable
mechanisms for reliably interpreting a string in the form
I also need to know that the user will not be sitting on his/her
hands for an annoying amount of time while packets are sent all
over the place trying to figure out what kind of name '<name>'
really is, and which kind of service it represents.
I think this is critical to providing a specification for a
"unified" URL scheme. Before we can provide such a scheme, we
need to *know* that it will work.
All that said, I *know* that the "non-overlapping" scheme will work. The
problem with the "non-overlapping" scheme is that it isn't percieved to
be "user-friendly". Okay, I can buy that. So let's come up with a
workable mechanism that would support a friendlier URL.
I outlined my best effort in another message. Luke, you replied with:
> > Note, by the way, that the decision to use port 139 or port 445 is made
> > based on whether or not we detect NBT. Now that I think of it,
> > there is no reason to try both ports *if* we go to the trouble of
> > discovering NBT by sending queries.
> yes there is.
> samba may be running on both ports, is resolved via a WINS
> server but not via DNS. going to 445 will save a round-trip.
> a dual-mode NT4/NT5-domain server may not be accessible /
> correctly configured to be reached via DNS but is accessible
> via Broadcast-mode NetBIOS, but again, it's still running
> both 139 and 445.
If these servers are running both SMB/NBT and CIFS/TCP then it doesn't
matter which transport we use, or to which port we connect.
The point I was trying to make, however, is that one possible mechanism
for figuring out how to resolve "smb://name/" or "cifs://name/" is to
determine whether the remote system is running NBT at all. If it is,
then use SMB/NBT semantics and defaults. If not, then use CIFS/TCP
semantics and defaults.
I'm not arguing that it is or isn't the best mechanism, just that it could
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
More information about the jcifs