svn commit: samba r5118 - in branches/SAMBA_4_0/source: librpc/idl librpc/ndr nbt_server

[Christopher R. Hertel]

On Mon, Jan 31, 2005 at 05:11:30PM +1100, Andrew Tridgell wrote:
> Chris,
> 
>  > From my testing, Windows systems do not decode the half-ascii NBT names 
>  > received from the wire.  They compare encoded string against encoded 
>  > string.  That's probably quicker than what Samba1..3 do.
> 
> yes, that is how windows does things. The cpu cost is totally trivial
> (its almost certainly in the noise),

Yes, I mentioned that in my message.  I was just talking about the 
differences because I thought they were interesting.

> the question really is which is
> better from a user perspective and which makes for clearer code.

...that's why I like comments.  :)

> I used decoded strings in the nbt library as I thought that made for
> clearer code. Volker queried me on this, and thought that binary
> netbios names (such as names containing embedded NULLs) might be
> common.  I thought it wasn't common, and can't recall any complains
> about Samba3 not supporting them, so I thought that the clearer code
> was a good enough reason to use decoded names.

With my nbtquery tool I specifically added a '-c' option to handle the 
cases in which Windows allows for mixed case names.  Traditionally, the 
names are all upper case, but there are exceptions in the wild.  I don't 
recall, but it's possible that some of them match the machine name (only 
mixed case).  Another problem that I ran into here at the University was 
non-Server Service names with a <20> suffix.

As for embedded nuls in the decoded NetBIOS name: I have seen them.  The 
nbtquery tool uses length-delimited strings for this reason.

> If someone knows of applications that really won't work with a WINS
> server that doesn't support binary NBT names then please let me
> know. I could easily change Samba4 now to use and compare encoded
> names, at a loss of some readability and maintainability in the code.

I think you could make the code just as readable and maintainable.  Code 
itself can do a great job of expressing method, but it's not as good at 
expressing intent, so the readability of raw code is really a function of 
the user's understaning and expectations.  ...but that's a tangent.  :)

Point is, I have seen NetBIOS names with nul bytes in them and had to
modify my own tools to handle them.  I also wrote those tools because I
couldn't get nmblookup to handle things like mixed-case NetBIOS names
(without gutting and replacing much of the nmbd suite, which was on my
mind as an option...).  Both quirks are real and the more Microsoft moves
away from NetBIOS the more likely it is (empirically) that they'll
introduce non-STD19 behavior.

2cents...  :)

Chris -)-----

-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org