Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bbn!oberon!aero!trwind!msd
From: msd@trwind.UUCP (Marc S. Dye )
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: NetBIOS v/s NFS
Keywords: NetBIOS NFS
Message-ID: <467@trwind.UUCP>
Date: 30 Mar 89 18:53:39 GMT
References: <15732@admin.mips.COM> <8903231542.AA05216@vax.ftp.com>
Reply-To: msd@TRW.Com (Marc S. Dye (ayuda))
Organization: ayuda Company
Lines: 64

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.                          |
+---------------------------------------------------+