Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!swrinde!mips!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: <98765@sgi.sgi.com> Date: 22 Apr 91 20:48:30 GMT References: <3064@cirrusl.UUCP> <280EE8A1.30D@tct.com> Sender: guest@sgi.sgi.com Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 32 In article , thurlow@convex.com (Robert Thurlow) writes: > > ... NFS over TCP isn't > far away ... This is the second recent reference I've seen to NFS/TCP/IP. (I'm probably not allowed to say where I saw the other reference.) Why would anyone want NFS/TCP? NFS over TCP seems good if you're trying to get over a very slow or very lossy link. NFS/TCP can't scale a fraction as far as NFS/UCP, despite statements to the contrary in that other, unnamed reference. NFS/TCP seems a generally unlikely choice. I write this as someone who argued hard in the old NCF-NCS-NCA battles for optional connection oriented transport for remote procedures (i.e. NCS over TCP). At Silicon Graphics, we care about remote procedures over TCP, because our graphics look like function calls, and we need performance several orders of magnitude faster than common remote procedure calls. (by cheating, we get enough of what we need). It seems straight forward to modify the Sun VAX reference code to use TCP handles, should anyone want to do it. I intend this as a serious question, not as the flame it may seem. There must be something I'm missing. Vernon Schyrver, vjs@sgi.com