percy@mips.COM (Percy Irani) (03/23/89)
May be a dumb question, but here goes... Why would one choose NFS over NetBios (or vice-versa) when networking IBM-PC's and Unix machines? (Please note: no assumptions on the transport layer i.e. Ethernet or Token Ring - I really dont want to start that debate again). Im cognizant of the following: 1) In an existing PC network, use Netbios on Unix to network PC's 2) In an existing TCP/IP network, use NFS to network PC's Does one have an advantage over the other? Is one better than the other? Would DOS users be willing to live with a Unix based NetBios file server? Would Unix users be willing to live with NetBIOS for networking PC's? What does NetBIOS have that NFS does not? Please reply to me directely. Thanks for the responses. ---------------------------------------------------------------------- #include <disclaimer.h> I speak for myself! ----------------------------------------------------------------------
jbvb@VAX.FTP.COM (James Van Bokkelen) (03/23/89)
The most fundamental issue is one of naming: NFS naming is unloveable in a number of ways, but it doesn't require broadcast name defense like NETBIOS does. This means that a network of NFS users can easily extend across IP routers, and links of various different characteristcs, where NETBIOS usually requires that everyone be on the 'same' LAN cable (bridges allowed). RFC 1001 and 1002 specify mechanisms which give you a little extra flexibility, but not enough to compete with Domain Names. Also "NETBIOS on Unix" is not an easy concept to implement. People like Syntax will sell you something with a similar name, but what it really is is a Unix- based file server for SMB protocols (an even higher layer). As a programming interface, NETBIOS is amazingly specific to Intel and DOS. As such, it isn't going to replace sockets (or streams) as the way to talk to the network on Unix hosts. It is also session-layer protocol, so a PC DBMS vendor would have to emulate RFC1001 and 1002 on Unix in order to port their product to Unix. jbvb
msd@trwind.UUCP (Marc S. Dye ) (03/31/89)
JBVB has alluded to a basic misunderstanding with what most people call NetBIOS. NetBIOS per se is a protocol suite and API whereas NFS is (mostly) an application package which comes bundled with protocols (IP/UDP, and some TCP buried in there in various applications) (see note 1). When you get NetBIOS from one of the various vendors (e.g. Excelan-cum-Novell, FTP Inc., CMC, ...) you get the API and then must acquire the file-sharing applications (e.g. IBM PC Network, MS/NET, ...) to actually produce a distributed file system implementation. PC Network and it's godfather, MS/NET, implement the file and device sharing they do with a protocol known as SMB. SMB is highly DOS-specific. I agree w/ James' description of the scalability of NetBIOS vs. NFS. Though the NetBIOS-over-TCP/IP specs have given thought to extension over widely-dispursed implementations, I haven't seen much of this implemented. It's hard to imagine what the point would be really, since the heritage of the transport NetBIOS protocols themselves isn't rooted in an internetworking bloodline. I'm not in total agreement with James' notion that NetBIOS itself must be DOS/PC specific, though the NCBs themselves certainly are. I'm aware of at least one implementation that layers the NCB API atop a portable NetBIOS interface which isn't OS-specific. Beyond the above comments, it should be stated that NetBIOS-based file sharing (I'm aware of) relies on a connection-based approach whereas NFS uses a datagram-based approach. Because of Sun's conscious transactional design approach, NFS servers are inherently stateless (though they often do tricks such as cacheing locally to improve performance). It follows from this that servers don't ever care if client systems die, and clients simply retry queries and eventually succeed across server death situations (unless your file died in the fire ;>). Connection-base file sharing (NetBIOS) cannot claim this robustness -- TCP provides no mechanism for connection survival across host death. But, NetBIOS does implement a more robust file locking mechanism than does NFS. This no doubt has endeared it to many DOS-based application implementors. The ability to do this locking is largely due to extensions made in DOS itself circa version 3.1. NFS bears largely from the Unix heritage, where any OS-supported locking is the burden of the application. I'm not really sure NFS-based applications can participate in the Unix-style locking mechanisms -- I've never seen it done, nor tried to do it myself. If you're interested in remote file systems with commercial-type file access control, I'd be more inclined to look to someone like Novell to attempt to unify TCP/IP and these notions than to buy into NetBIOS-atop-TCP/IP or NFS at this point (my opinion). ++msd Marc Dye -- ayuda Company msd@TRW.Com Note 1: I'm speaking here of the implementation of PC/NFS from Sun. I haven't seen FTP Inc.'s up-close-and-personal yet, but it's likely to be normal PC/TCP (including IP/UDP/TCP, applications, and a BSD-socket API) plus an NFS client application, and perhaps RPC and XDR API facilities as well. +---------------------------------------------------+ | The opinions expressed are those of my employer | | -- I work for myself. | +---------------------------------------------------+
dab@ftp.COM (Dave Bridgham) (03/31/89)
In article <467@trwind.UUCP>, msd@trwind.UUCP (Marc S. Dye ) writes: > JBVB has alluded to a basic misunderstanding with what most people call > NetBIOS. NetBIOS per se is a protocol suite and API Here is precisely what James was talking about. NetBIOS is *not* a protocol suite, it is only an API. That API can be (and has been) implemented using any of a number of methods on any of a number of protocol stacks only one of which is on top of TCP/IP with the method specified in RFCs 1001 and 1002. > I'm not in total agreement with James' notion that NetBIOS itself must > be DOS/PC specific, though the NCBs themselves certainly are. I'm > aware of at least one implementation that layers the NCB API atop a > portable NetBIOS interface which isn't OS-specific. Not only are the NCBs rather MSDOS specific but using software interrupt 5C is *very* MSDOS specific. If NetBIOS is the interface specification (the API) then NetBIOS is exactly NCBs and INT 5C. > But, NetBIOS does implement a more robust file locking mechanism than > does NFS. But, NetBIOS doesn't implement any file locking at all. If it's done at all it's done by some application running on top of NetBIOS. > I'm not really sure NFS-based applications can > participate in the Unix-style locking mechanisms -- I've never seen > it done, nor tried to do it myself. If you're writing an application that uses filelocking you don't want to base the locking on NFS or NetBIOS; you want to base it on MSDOS. Then NFS should translate the MSDOS locking calls into the appropriate NFS (or rather lockd) operations. I believe Sun's PC/NFS does this. > If you're interested in remote > file systems with commercial-type file access control, I'd be more > inclined to look to someone like Novell to attempt to unify TCP/IP > and these notions than to buy into NetBIOS-atop-TCP/IP or NFS at this > point (my opinion). I agree. You should be able to implement MSDOS locking with NFS, but Novell is using a protocol specific to MSDOS so they can guarantee an exact match. David Bridgham FTP Software, Inc.
martillo@cpoint.UUCP (Joachim Carlo Santos Martillo) (04/04/89)
Actually, xenix net does provide an int5c interface to netbios under xenix. It is not well documented.