stevens@hsi.UUCP (Richard Stevens) (10/11/88)
Is anyone aware of any implementations of NetBIOS over TCP/UDP,
as specified in RFCs 1001 and 1002 ?? (I posted this to the
comp.protocols.ibm newsgroup last week and got zero response.)
Also, if such a beast exists, does it have a *reasonable*
user interface, as opposed to the PC NetBIOS interface,
where everything is done through a single function call with
a single argument (a pointer to an Ncb) ?
Richard Stevens
Health Systems International, New Haven, CT
stevens@hsi.uu.net
... { uunet | yale } ! hsi ! stevensromkey@asylum.UUCP (John Romkey) (10/11/88)
In article <185@hsi86.hsi.UUCP> stevens@hsi.UUCP (Richard Stevens) writes: >Is anyone aware of any implementations of NetBIOS over TCP/UDP, >as specified in RFCs 1001 and 1002 ?? (I posted this to the >comp.protocols.ibm newsgroup last week and got zero response.) I believe that Excelan, FTP Software and Ungermann-Bass do. That list could be wrong and it's probably not all-inclusive. >Also, if such a beast exists, does it have a *reasonable* >user interface, as opposed to the PC NetBIOS interface, >where everything is done through a single function call with >a single argument (a pointer to an Ncb) ? 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. RFCs 1001 and 1002 define some protocols that allow the programming interface to be implemented on top of TCP/IP. These protocols are necessary because the semantics of NETBIOS do not map well to the semantics of TCP and UDP, particularly in the area of names. -- - john romkey UUCP: romkey@asylum.uucp ARPA: romkey@xx.lcs.mit.edu ...!ames!acornrc!asylum!romkey Telephone: (415) 594-9268
stevens@hsi.UUCP (Richard Stevens) (10/12/88)
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. The problem with (1) is that I'd guess 99.9% of all existing NetBIOS applications are written *specifically* for the IBM PC and that a vast majority of them contain a lot of assembler code. That means to take the source for, say, a file server, and port it to a UNIX VAX that supports "NetBIOS over TCP" is non-trivial. If there are existing applications in C, for example, then does there exist a standard C interface to NetBIOS that can be used in different environments (i.e., both on a PC with "real" NetBIOS and on a systems with NetBIOS over TCP) ? The problem with (2) is who needs it ? Wanting to preserve the NetBIOS "user interface" seems like emulating the old OS/360 IO Control Blocks using the Unix i/o interface. Yes, it can be done, but why ? IBM has nicely given us a similar interface to TCP/UDP/IP under VM, where everything happens through a single function. That's an interface that's not worth preserving, and it is non-trivial to port any of our TCP applications from a BSD VAX using sockets to this beast. As I understand the interface for NetBIOS, you get a single function that takes a single argument (ptr to an NCB struct) and everything happens from there. It would seem simple to add a better user interface on top of that, but it would also be nice if that interface were standard across different vendor's implementations. It seems I'm missing something in the reasoning behind wanting NetBIOS over TCP, but given that vendors exist that sell this as a product there must be a need for it. Can someone shed some light on just what people are doing with it ? Thanks. Richard Stevens Health Systems International, New Haven, CT stevens@hsi.uu.net ... { uunet | yale } ! hsi ! stevens
romkey@asylum.UUCP (John Romkey) (10/13/88)
In article <187@hsi86.hsi.UUCP> stevens@hsi.UUCP (Richard Stevens) writes: >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. > >The problem with (1) is that I'd guess 99.9% of all existing NetBIOS >applications are written *specifically* for the IBM PC and that a >vast majority of them contain a lot of assembler code. Very correct. Some vendors have talked about "porting NetBIOS" to UNIX or other such systems. What they mean is bringing up the RFC 1001/1002 protocols under these systems, and some kind of who knows what programming interface that probably can't have anything to do with the standard NetBIOS interface unless you're running on an 80x86 system. There's a worse problem, even in the PC domain. Many NetBIOS applications, especially IBM-written ones, make use of undocumented NetBIOS features, or timing or other bizarre details of the oldest NetBIOS implementations, and it's pretty difficult to get these things running correctly over NetBIOSes that are substantially different from the IBM ones. >The problem with (2) is who needs it ? Wanting to preserve the I don't know. >It seems I'm missing something in the reasoning behind wanting >NetBIOS over TCP, but given that vendors exist that sell this as a >product there must be a need for it. Can someone shed some light on >just what people are doing with it ? Thanks. I think the whole purpose of NetBIOS over TCP is a political/marketing one. A couple of years ago a lot of people thought that NetBIOS was going to be THE way to go, THE way to talk to networks, because IBM had blessed it. Right. So you saw NetBIOS over Netware, over 3+, over ISO, over DECNet (I think), and then over TCP, by Excelan and Ungermann-Bass. At the Air Force's behest (because of ULANA and all), RFC 1001 and 1002 were written after much beating up of all parties involved so that different vendors' NetBIOS over TCP's could actually interoperate. Why do the vendors care? As near as I can tell, it's so that they can say they're IBM-compatible (never mind that a TCP NetBIOS wouldn't talk to a NetBIOS over IBM protocols), and so because their customers really told them they wanted NetBIOS. When I was at FTP Software, I saw that a lot of the market place didn't have the foggiest idea what NetBIOS was. "It lets you share printers!" they cried. "We can use fileservers!" they said. "It does record locking." Right. So now probably thousands of users have their NetBIOSes, like they asked for. I think some of them run Microsoft Networks or the PC LAN program in some version or another over it (seems a bit gratuitous on Novell Netware or 3COM 3+), and there are a few database products that let you query a central database through protocols that run over NetBIOS. Other than that, I don't have the faintest idea what people are using it for. -- - john romkey UUCP: romkey@asylum.uucp ARPA: romkey@xx.lcs.mit.edu ...!ames!acornrc!asylum!romkey Telephone: (415) 594-9268
larry@tapa.UUCP (Larry Pajakowski) (10/14/88)
Well we do run Netbios over UDP and are very pleased with it. Here are some reasons. 1. Our primary reason is that we dos software developement for both DOS and Unix/Xenix. Our server is a Compaq-386/20 running Xenix. 2. We have 1 set of source on the server for both Xenix and DOS in 1 place. 3. We use SCCS on the Xenix side for all source. 4. Our implimentation comes with ftp and telnet which allows us to test the Xenix version from a DOS box. 5. Dates and time stamps are preserved between the Xenix and Dos files. 6. We had our choice of servers: Xenix, Vaxen under VMS, NCR towers etc. 7. Dos developers can share the LASER printer on the Xenix system. 8. Dos developers use uucp heavily to move files between remote sites. 9. Other non technical personel are also on the LAN makeing for moving documents and mail easy. All in all we are very pleased with the development environment. Larry larry@tapa
waynec@microsoft.UUCP (Wayne Chapeskie) (10/15/88)
[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
snorthc@RELAY-NSWC.NAVY.MIL (10/19/88)
What is NetBIOS used for? A couple years ago we managed to get our first versions of PCIP running (CMU and FTP SW). I was sure management would be happy. The PCs could speak the native tongue of the internet, exchange files with various hosts running TCP/IP, even send mail. I figured a massive bonus would surely come my way. No, instead it was a swift kick. We want TRANSPARENT file access, mail, and print services for our PCs, said management. So we studied PC NFS, NetBIOS/TCP, and Locus. None of these solutions satisfy file, mail, print services 100%. That however is the answer [ I think] to the question what is NetBIOS for. Even just as a file service, it had potential. What choked it for us was the memory required to make it work. Why would anyone want transparent file access? Sigh. To this day, I wouldn't want to be held to this, but supposedly users do not want to be bothered to log in via FTP to xfer a file. They want the file to be referenced as drive "F:". These are a different breed of users than those who subscribe to info TCP I suspect. Anyway, that is all in the past. The future is my question. I read in the OS/2 SDK for the Lan manager that it is very MS-NET and NetBIOSy. Assuming for a minute (big assumption) OS/2 has some success in the marketplace, is this a boost for NetBIOS? Will we have to take NetBIOS/ISO (NetBIOS/GOSIP in my case) seriously? Stephen Northcutt Caveat: there are questions that have no right answer. Discussions of NetBIOS tend to lead to such questions.
renglish@hpisod1.HP.COM (Robert English) (10/26/88)
> / snorthc@RELAY-NSWC.NAVY.MIL / 4:49 am Oct 19, 1988 / > That however is the answer [ I think] to the question what is NetBIOS > for. Even just as a file service, it had potential. What choked it > for us was the memory required to make it work. Why would anyone > want transparent file access? Sigh. To this day, I wouldn't want > to be held to this, but supposedly users do not want to be bothered > to log in via FTP to xfer a file. They want the file to be referenced > as drive "F:". Saying "users don't want to be bothered" trivializes the issue somewhat. There are many DOS applications in which users never see the actual files involved. The application presents them with menus to perform tasks, and manages the files itself. A user who had to transfer all of the necessary files over via FTP would have to be much more sophisticated than one who merely used the application. Furthermore, there is the issue of file-sharing. If users access the files on the remote machine directly, they can share effectively share data with other users. If they must copy the data back and forth, they are likely to get inconsistent versions, forget to do the copies, etc. (I know, you've never walked away from a terminal without writing out a file). Working in a non-transparent environment is significantly more complicated than working in a transparent one. --bob--
todd@SEAS.UCLA.EDU (Todd Booth) (11/01/88)
In article <187@hsi86.hsi.UUCP> stevens@hsi.UUCP (Richard Stevens) writes: >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. There's a more important reason. > (1) A NetBIOS over TCP interface isn't required to run NetBIOS on other systems. Any NetBIOS interface can do that. > (2) NetBIOS over TCP doesn't provide a new communication interface to the programmer. If implemented correctly, the NetBIOS interface should look the same if it runs on top of ISO Network, TCP, IP, LLC, IPX, XNS, ... The whole point of a standard interface (NetBIOS) is to shield the programmer from the details of the lower layers. I see the advantage of NetBIOS over TCP/IP as the ability to provide NetBIOS with an reliable data stream over an IP based network. >It seems I'm missing something in the reasoning behind wanting >NetBIOS over TCP, but given that vendors exist that sell this as a >product there must be a need for it. Can someone shed some light on >just what people are doing with it ? Thanks. Don't know what's being done, but here's one example of what can be done: Simtel is a real pain for new users to access files via FTP. Simtel could run one of the PC DOS based network operating systems that require NetBIOS, for example IBM's PC LAN Program. They could use a NetBIOS over TCP/IP interface and develop a custom DOS application which provides uses a menu front end to retrieving their existing files. This would allow other NetBIOS over TCP/IP users throughout the internet to have a menu front end to the Simtel directories, in full color, with optional help keys, file definitions, automatic file downloading (note that FTP would no longer be required). In other words the ease of use of typical PC applications with the communications capabilities of TCP/IP. Disclaimer: I know very little about the NetBIOS over TCP/IP standard, jsut a few things about layered network architechure. --todd booth / ucla data communications ArpaNet todd@seas.ucla.EDU UUCP {ihnp4,ucbvax}!ucla-cs!todd Voice +1 (213) 825-1933 BitNet csdctgb@uclamvs.bitnet --todd