[jcifs] Re: SMB URL

[Steve Langasek]

On Fri, 14 Sep 2001, Christopher R. Hertel wrote:

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

..and where transport matters, most (power) users expect this to be specified
as the protocol.

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

Sure.  Supposing you have a URL of smb://dns.name/share, and dns.name has
SMB/NBT running on port 445, and nothing on port 139...  Is it reasonable to
expect an application to extract the correct answer from such a tangle?  The
'try every combination until you find one that works' approach will certainly
violate principle of least surprises for server administrators, who risk
getting calls about broken URLs if they install an unrelated SMB service on
a different port.

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

A very amusing and useful analogy.  HTTPS and SMB/TCP even have in common that
they break virtual server functionality...

Steve Langasek
postmodern programmer