> > 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.
>
> What happens if a single server has processes listening on both port 139 and
> port 445, but the services provided on each port are different? This is
> entirely possible with a solution built on Samba. Do you include the port
> number in the URL in order to disambiguate?

You would need to have some mechanism for specifying which port you
wanted. If the name is a NetBIOS name and no port is specified, then port
139 is a good guess. If the name is a DNS name or IP, the I suppose you
could guess at 445 first and try 139 if 445 doesn't work. Another way is
to do as Luke suggests and use the CIFS: vs. SMB: names as "hints" rather
than absolutes.

Of course, you can use the :port field of the URL string (not covered in
the current draft) but that only specifies a port number, not a transport.
Also, that only helps if the URL string was actually typed in with the
:port field included.

This is all part of the problem. Even sticking with SMB: == SMB/NBT and
CIFS: == CIFS/TCP we have ambiguities, though they can be "figured out".
The current draft gives a "best effort" description of how to figure out
what "smb://name/" means. What we need to provide in order to offer a
"unified" scheme is a "best effort" description of how to figure out what
"smb://name/" means in a "unified" context.

> > 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.
>
> In the above case, will this work if the crazy admin is running SMB/NBT on
> port 445?

No, not unless the application tries both ports (for some crazy reason).

My assumption is that if :port is not specified then SMB/NBT should be
running on port 139. That's just like saying that httpd should be
expected to be running on port 80 unless otherwise speciied.

By the way: *BINGO*! That's the counter example I needed.

For anyone still willing to consider the "non-overlapping" model,
consider this: Http and https are both the same protocols, but they run
on different ports on different transports. Https runs over an encrypted
tunnel (SSL) while http runs "native". Users don't have a lot of trouble
with that.

More LiOX on the fire.

Chris -)-----

--
Christopher R. Hertel -)-----                   University of Minnesota
crhnts.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
----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info including how to unsubscribe.  Save time, search
the archives at http://discuss.microsoft.com/archives/index.html

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]