Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!strath-cs!baird!jim From: jim@cs.strath.ac.uk (Jim Reid) Newsgroups: comp.protocols.nfs Subject: Re: Symlink locking considered useless over NFS Message-ID: Date: 23 Apr 91 12:57:05 GMT References: <3064@cirrusl.UUCP> <280EE8A1.30D@tct.com> <98765@sgi.sgi.com> Sender: jim@cs.strath.ac.uk Organization: Computer Science Dept., Strathclyde Univ., Glasgow, Scotland. Lines: 54 In-reply-to: vjs@rhyolite.wpd.sgi.com's message of 22 Apr 91 20:48:30 GMT In article <98765@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: Why would anyone want NFS/TCP? There are a number of reasons. Firstly, NFS over UDP is fine when the client and server are on the same bit of ethernet. The bursty nature on NFS traffic - typically a handful of packets back to back on the wire - is not so well suited to other types of networks. For instance, when the client and server are separated by routers and/or bridges that may drop packets now and again. [For NFS/UDP this is bad news as it causes the whole NFS request - perhaps an 8 Kbyte read or write to be retransmitted.] With TCP, only the dropped packet need be retransmitted. Another benefit of TCP is the use of round-trip times to assess how much data can be shifted across the network. In other words, it is more network-friendly than UDP if there is congestion or if the throughput rates of all the network interfaces between the client and server are not comparable. TCP's flow control algorithms could also be used to enable NFS clients and servers exert flow control on each other: "don't send me too many requests because I'm almost out of network buffers". All of these things become more important when NFS gets used over long-haul links like T1 lines where the overheads and costs of sending packets are more significant than on an ethernet or token ring. Aside from the networking considerations, there are two other areas where NFS/TCP will win over NFS/UDP. One is improved integrity of the NFS protocol. With TCP, either end of the connection will know if the other end goes away, which can make life less painful when a server dies. Since TCP guarantees delivery of data, there is no possibility of NFS requests and replies going astray as can happen with NFS/UDP at present. [Consider this scenario: a NFS client makes a link request. The server does this but the reply gets lost. The client repeats the request after it times out, only to get an error returned because this time the server fails the request because the link already existed! Although more recent NFS implementations cache the last few NFS requests and use transaction id's to detect duplicates, it's not foolproof.] 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. With UDP, it could be anything on the net that sends out the right-looking packet that is having the NFS dialogue with you. The only reasons why NFS over TCP is not attractive are performance and interworking. The former is not really a problem these days, given a decent implementation. The latter is more of a problem. Since NFS over TCP will only talk to other NFS/TCP platforms, you lose when you want to use NFS/TCP with a "standard" implementation that only speaks UDP. Jim