Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!sgi!vjs@rhyolite.wpd.sgi.com From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Newsgroups: comp.protocols.nfs Subject: Re: Symlink locking considered useless over NFS Message-ID: <99526@sgi.sgi.com> Date: 25 Apr 91 04:44:46 GMT References: <3064@cirrusl.UUCP> <280EE8A1.30D@tct.com> Sender: guest@sgi.sgi.com Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 59 > > I wrote: > Why would anyone want NFS/TCP? Well, after mail, postings, & time, I've thought about it some more... In article , jim@cs.strath.ac.uk (Jim Reid) writes: > > There are a number of reasons. Firstly, NFS over UDP is fine when the > client and server are on the same bit of ethernet.... > ..... All of these [bad] things become more > important when NFS gets used over long-haul links ... NFS/TCP sounds good for private data over the Internet or slower. > .... Since TCP guarantees delivery of data, there is no possibility > of NFS requests and replies going astray as can happen with NFS/UDP... NFS/TCP should suffer short network problems better than NFS/UDP. As you say, the need for the XID cache goes away in those cases. But what do you do when server or client crash and are restarted? In principle it is easy to re-establish the TCP circuit, but I bet the code will be buggy and unreliable for years. One would probably be building TCP connections in the client and server kernels. The fastpath and client handles get a lot messier. What happens when a bad network connection or circuit re-user breaks the TCP virtual circuit? Then the client is in the same stew as with a lost UDP packet. This problem cries out for the XID cache. > The final area where NFS over TCP beats NFS/UDP is security. Since UDP > is a datagram protocol, it is trivial to inject UDP data that looks > like NFS requests and replies into a network. This makes it > straightforward to impersonate an NFS client or server. With TCP, it > is theoretically possible but far from easy to inject data into an > existing TCP connection. Thus clients and servers can have more > confidence about who is at the other end of the NFS protocol if TCP is > used.... I use machines with many hundreds of NFS clients. Extrapolating to the Internet gets thousands of mostly idle NFS clients/server. Just to limit the number of TCP connections to at most hundreds, you'll be building up and tearing them down continually. Good times to for a bad guy to fake in. As is often said, you should not rely on TCP curcuits for security. > The only reasons why NFS over TCP is not attractive are performance > and interworking. ... NFS/TCP should be significantly faster than NFS/UDP, when the fast network and not the disk is the bottleneck. I think I know why in my measurements recent 4.3BSD TCP over FDDI is signifcantly faster than UDP. Even if not true for other fast hardware (tho I think it will be), consider the speed advantages of huge buffers. The big problem with NFS/TCP still seems to me that it won't scale as well as NFS/UDP. Vernon Schryver, vjs@sgi.com