Path: utzoo!attcan!uunet!husc6!mailrus!cornell!uw-beaver!microsoft!waynec
From: waynec@microsoft.UUCP (Wayne Chapeskie)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: NetBIOS over TCP/UDP
Keywords: RFC 1001, RFC 1002
Message-ID: <1037@microsoft.UUCP>
Date: 15 Oct 88 01:22:02 GMT
References: <185@hsi86.hsi.UUCP> <957@asylum.UUCP> <187@hsi86.hsi.UUCP>
Reply-To: waynec@microsoft.UUCP (Wayne Chapeskie)
Organization: Microsoft Corp., Redmond WA
Lines: 97

[This is a bit long, but I hope it clarifies things a bit.]

In article <187@hsi86.hsi.UUCP> stevens@hsi.UUCP (Richard Stevens) writes:
>In article <957@asylum.UUCP>, romkey@asylum.UUCP (John Romkey) writes:
>> 
>> Sorry, but that IS Netbios. The programming interface defines the
>> semantics of the network operations and how you call them, and that's
>> it. Netbios is the programming interface, not what's under it.
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>OK, my next question is "what is the purpose of NetBIOS over TCP" ?
>I see two answers:  (1) To take the existing horde of NetBIOS
>applications and run them on other systems;  (2) To provide another
>communication interface for a programmer.

Not exactly.  "Netbios" tends to be a rather slippery term.
There are really two aspects to "Netbios":

1.  An msdos programming interface  (the "NCB", or "Int5c" interface).
    This interface is what was promulgated by IBM in their original
    PCNET product, picked up by Microsoft in MSNET.

2.  A set of networking functionality, which is implied by the
    interface.  This functionality includes a reliable, virtual
    circuit transport facility with the ability to preserve message
    boundaries, an unreliable datagram facility, and a naming
    convention.

    The precise nature of the underlying network transport was not
    defined:  you could put any
    combination of hardware and software transport you wanted there,
    as long as it provided the kind of circuit, datagram, and naming
    facilities implied by the upper level interface.
    Msdos network vendors did exactly that:  each had their own combinations
    of network hardware and protocols (often completely nonstandard).
    Even if they did use standard protocols (ISO, TCP/IP, XNS) down in the
    transport level, they still had to do something on top of them to
    provide the session level naming facilities required by the interface.
    You even have  cases where two vendors have both used
    the same transport level protocols (XNS, TCP/IP), but since they
    use different methods to implement the Netbios naming support, their
    Netbios implementations cannot communicate.

While the NCB interface was rigidly defined, and msdos programmers
have written "Netbios applications" which use it,
the NCB interface itself is strictly an msdos convention, and a pretty
sleazy one at that...  [There have been attempts to provide
exactly such an interface on Unix systems, in order to somehow make it
easier to port msdos Netbios programs to Unix.  I consider such
attempts misguided, and quite inappropriate to a Unix environment].
There is no requirement that the NCB interface be used to "speak
Netbios"; any interface which makes sense to the local
operating system can be used.

As a concrete example:  we have hordes
of Ungermann-Bass boards around here which implement all of Netbios
in slushware.  An msdos machine has a driver which takes "int 5c" NCB
commands and tells the board to do the appropriate thing.
On my Unix machines, I did a unix device driver which knows how to
talk to the board.  I have done versions of the driver which used
a device ioctl interface, and versions which use Sys
5.3 streams/TLI interfaces to talk to the driver.  I have never provided
an NCB interface.  Yet programs on the Unix machine can speak to
programs on the msdos machine, and so are in a sense "Netbios programs".

As you may gather from the earlier discussion, interoperability
among Netbios implementations is essentially non-existent.
Msdos programmers have this interface to write programs
to, but their programs can only talk to each other if the underlying
network transport services which implement the interface are
compatible.   RFC 1001/1002 attempt to ensure that this is the case
if the the underlying transport is TCP/IP.
They specify a protocol which lives on top of TCP/IP, implementing
Netbios name service, datagram delivery, circuit establishment,
and so on.  [A similar effort is also being made for Netbios over ISO TP4.]
The RFC's ensure that vendor A's "Netbios over TCP/IP" will
communicate with vendor B's "Netbios over TCP/IP". 

Since the RFC's do not specify a programming interface to the Netbios
facilities, the interface will be whatever is appropriate for the host
system.  Msdos implementations would no doubt be NCB, Unix
implementations may use the socket interface, TLI, generic cover
routines, or whatever, depending on how the RFC layer is implemented.
The point is to make sure that you know how to talk to the msdos machine.

So, I see two reasons for the "Netbios over TCP/IP" spec:
1.  Guarantee interoperability for those msdos Netbios implementations
which use TCP/IP as their underlying transport.
2.  Provide a mechanism for machines which already talk TCP/IP (your
average Internet host) to communicate with msdos Netbios programs, 
(i.e. msdos programs which do not talk TCP/IP directly).

[My apologies if you knew all this already.  However, this whole
"Netbios" silliness is often misunderstood...].

Wayne Chapeskie
(206)-882-8080			UUCP:  ...{uw-beaver,uunet}!microsoft!waynec