brinkema@fjcnet.GOV (John R. Brinkema) (07/02/89)
Boy am I confused! Is NetBIOS an interface or a protocol? That is, is it simply a standard network interface for PCs that is independent of any underlying network or protocol; or does it 'evelope' the information sent accross it assuming that there is an equivalent NetBIOS interface on the other end that will remove the NetBIOS envelope. This question keeps coming back to me as I read books and articles, each document apparently giving a different answer! [Most recently, RFC's 1001 and 1002 which clearly define a protocol, but I think only for Names, which makes sense.] Consider the following hetrogeneous (inter-)network setup: a client netBIOS program running on a PC on an ARCnet Novell LAN, gatewayed to an ethernet TCP/IP LAN with a UNIX box connected to it, running a server of some kind, talking UNIX standard TLI. When the client does some basic NetBIOS calls (not Name Support, which I assume is NetBIOS's problem, unless there is a Name Server in the (inter-)network), what arrives at the server/TLI end? For example, if the client does a NetBIOS 'call', what arrives at the server/TLI end? How about NetBIOS 'Send No-Ack'? 'Send Datagrams'? 'Hangup'? etc. How about the other direction: server/TLI to client/NetBIOS? ==== What I am trying to do is write one server that doesn't care about where the client is in the network, how the client talks to the network (NetBIOS on a PC; TLI on a UNIX V box; Sockets on a UNIX BSD box); or what network(s) or protocol(s) is(are) between the client and server. I want to use the 'natural' network interface for the client box; I assume that NetBIOS is such for PC's. I *know* that TLI is the 'natural' interface for UNIX V boxes (whether is really is or not :-) ). tia: jb In real life: John R.Brinkema, Mgr. Advance Systems Group Federal Judicial Center 1520 H. St. NW Washington, DC 20005 (202) 633-6400
jbvb@ftp.COM (James Van Bokkelen) (07/07/89)
In article <193@fjcp60.GOV>, brinkema@fjcnet.GOV (John R. Brinkema) writes: > Boy am I confused! Is NetBIOS an interface or a protocol? That is, is > it simply a standard network interface for PCs that is independent of > any underlying network or protocol; or does it 'evelope' the information The answer to this depends on whose "NETBIOS" you're using. One aspect of the NETBIOS "standard" is a (relatively) standardized way that applications can call a network layer, using command blocks called NBCs and usually via INT 5C. All the application cares about is that some sort of name handling, datagram service and session service is provided, it doesn't care about the network-level details at all. Another aspect is the transport layer details themselves, which usually vary from network to network and vendor to vendor. Sytek defined a protocol long ago. IBM defines another protocol for use on 802.5 rings. RFC 1001/1002 define a way to use TCP/UDP/IP as the transport layer. 3Com, Banyan and Novell each have different ways of mapping the INT 5C calls to XNS variant transport layers. Thus, the NETBIOS that 3Com provides with 3+ uses 3Com's variant of XNS for its transport services, the NETBIOS provided by Novell with Netware uses Novell's XNS variant, the NETBIOS that IBM ships with the PC LAN program uses its own private transport protocol on top of 802.2 LLC2 services, the NETBIOS that Sytek first did uses a Sytek-private transport protocol, etc, etc. While implementations comforming to one standard (e.g. Sytek or RFC 1001/1002) can interoperate, there is no interoperability between these different families, you have to build a translating gateway. > .... [Most recently, RFC's 1001 and 1002 which clearly define a protocol, > but I think only for Names, which makes sense.] RFCs 1001/1002 define the way all NETBIOS operations map to TCP (RFC 793) and UDP (RFC 768) operations, not just names. Three special reserved port numbers are defined, name and datagram packet formats, session establishment and disconnect, message headers and the whole 9 yards, they're all there. > Consider the following hetrogeneous (inter-)network setup: a client > netBIOS program running on a PC on an ARCnet Novell LAN, gatewayed to an > ethernet TCP/IP LAN with a UNIX box connected to it, running a server of > some kind, talking UNIX standard TLI. > > When the client does some basic NetBIOS calls (not Name Support, which I > assume is NetBIOS's problem, unless there is a Name Server in the > (inter-)network), what arrives at the server/TLI end? For example, if > the client does a NetBIOS 'call', what arrives at the server/TLI end? > How about NetBIOS 'Send No-Ack'? 'Send Datagrams'? 'Hangup'? etc. If the gateway has been done right, "call" on the client is translated on the TCP/IP side into 1) a UDP broadcast packet to port 138, with an RFC 1001/1002 name query in it, 2) a directed UDP packet back to the gateway indicating that the name exists, 3) an attempt to open a TCP connection from the gateway to the server's port 139, and 4) an exchange of session headers on the TCP connection to determine if the called name is listening for the calling name. As I see it, you have two problems. First, you have to get a translating gateway of some sort, that supports RFC 1001/1002 and whatever other media you have in mind. Second, you have to buy/implement RFC 1001/1002 on top of TLI on your Unix box. If the package you buy is just billed as an SMB server for Unix boxes, make sure that there is some API through which you can make your application work; in some cases the RFC 1001/1002 code may be embedded inside the server, and not accessible to other applications. Of course, if I were you, I'd keep a sharp eye on NETBIOS's built-in limitations (badly documented, several conflicting "standards", many programs that abuse the "standards" horribly, flat name-space, broadcast protocols), and consider basing the whole application on something more powerful and/or better standardized, like RPC... -- James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901