larry@nstar.UUCP (Larry Snyder) (02/13/90)
ISC is planning on releasing Slip for 386/ix next month. I am under
the idea that Slip with TCP/IP and RFS will allow me to run RFS (or NFS)
over serial lines so that I may use FTP. Is this true? Can someone
fill me in with the details?
--
Larry Snyder, Northern Star Communications, Notre Dame, IN USA
uucp: larry@nstar -or- ...!iuvax!ndmath!nstar!larry
4 inbound dialup high speed line public access systemdyer@spdcc.COM (Steve Dyer) (02/13/90)
In article <511187@nstar.UUCP> larry@nstar.UUCP (Larry Snyder) writes: >ISC is planning on releasing Slip for 386/ix next month. I am under >the idea that Slip with TCP/IP and RFS will allow me to run RFS (or NFS) >over serial lines so that I may use FTP. Is this true? Can someone >fill me in with the details? Er, you seem to be a little mixed up. FTP is a protocol which runs over TCP/IP which allows you to send or retrieve files between two machines. You copy the file over, which is then part of the local file system, and you operate on the file like any other file. Both RFS and NFS are remote file systems, meaning that they provide an access method beneath the UNIX system call layer (i.e., open, close, read and write operate on remote files in much the same way as they do on local files.) NFS runs over RPC which usually runs over IP, and RFS can run over IP, so it should be at least theoretically possible to run them over SLIP, provided your vendor gives you all the right "glue". A couple of points: SLIP provides framing, but no checksum or retransmission. It's very easy to drop a byte or two when a machine like a 386 is heavily loaded. For a protocol which ordinarily expects a low error link layer like ethernet, SLIP can cause some nasty surprises. In most Sun-derived implementations of NFS, NFS checksumming is turned off by default. Combine this with SLIP, and it's only a matter of time before some of your data gets corrupted. You should see whether ISC provides some way of turning on NFS checksums if you're going to use NFS over SLIP. Finally, NFS over a 9600 baud line is mainly useful (if that) for occasional archival access to files. I wouldn't try to beat on the filesystem at all. -- Steve Dyer dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer dyer@arktouros.mit.edu, dyer@hstbme.mit.edu
vjs@calcite.UUCP (Vernon Schryver) (02/14/90)
In article <511187@nstar.UUCP>, larry@nstar.UUCP (Larry Snyder) writes: > ISC is planning on releasing Slip for 386/ix next month. I am under > the idea that Slip with TCP/IP and RFS will allow me to run RFS (or NFS) > over serial lines so that I may use FTP. Is this true? Can someone > fill me in with the details? > Larry Snyder, Northern Star Communications, Notre Dame, IN USA > uucp: larry@nstar -or- ...!iuvax!ndmath!nstar!larry Vanilla SLIP, as opposed to various "header compression" or "checksumming" or "error correcting" varients or the new PPP (RFC-1xxx, I don't remember), should not be used with NFS. The reason is that classic SLIP uses a simple 1-byte framing without error detection. Most varieties of NFS (anything based religously on the Sun 4.xBSD reference tapes as well as Sun at least until recently) run with UDP checksumming turned off. This means that corrupted bits will not be noticed. The result is file corruption for either the client or on the server's disk. NFS was originally implemented on media with link-level error detection, and the designers felt that saving the extra checksum computation was worthwhile. Today checksumming is the most expensive part of network transfers at high speed. (That statement comes from my day job at a workstation mfgr where we are sloshing TCP at 6MByte/sec over some media.) Application protocols such as FTP which run over TCP/IP do not suffer this problem, because the TCP checksum cannot legally be turned off. For interactive use, such as telnet or rsh, over vanilla SLIP you need a 9600 or better <<full-duplex>> modem. Because of the 40 byte TCP/IP header, 9600 or 19200 half-duplex made to look like full is not useable for interactive applications. With "TCP/IP header compression/prediction", SLIP can be used with Telebit Trailblazer+ modems for interactive use. Without header compression, the 19.2 half-duplex TB+ is not statisfactory I do not know but doubt that the ISC SLIP does header compression yet. One might expect them to port Drew Perkin's PPP reference implementation soon. Any V.32 modem is a good choice. A Telebit T2500, switched between PEP for file transfers and v.32 for interactive use can give >1KByte/sec FTP and good interactive performance. Notice I wrote 1KB, not the familiar 1.4KB we all get from TB+'s and UUCP. I know people doing NFS, YP, X, and rlogin with T2500's and even TB+'s with a SLIP with header compression as good as or better than VJ (if I do say so). I think they're crazy--NFS likes lots of network bandwidth. The big win with SLIP is that you can do lots of stuff at once with the same line. If your SLIP driver does reasonable TOS queueing, you'll hardly notice file transfers going on while you are doing interactive stuff. Vernon Schryver vjs@calcite.uucp P.S. I said nothing about RFS.
vjs@calcite.UUCP (Vernon Schryver) (02/14/90)
In article <1658@ursa-major.SPDCC.COM>, dyer@spdcc.COM (Steve Dyer) writes: > ... You should see whether ISC provides some way of turning > on NFS checksums if you're going to use NFS over SLIP.... This will not help in a heterogeneous network. Imagine that you use SLIP to connect your 386-clone to a second PC, and that one talks to an ethernet. What if you NFS-mount the file system of a Sun 3 running 3.0 on your machine? Or vis versa? Yes, you can get corruption because the distant Sun will not be doing UDP checksumming. It will not help that your PC's are checksumming, because RFC-(I forget) tells your machine to not worry, be happy if a UDP packet with a 0 checksum arrives. Remember that the TCP and UDP checksums are end-to-end. Vernon Schryver vjs@calcite.uucp
dyer@spdcc.COM (Steve Dyer) (02/15/90)
In article <83@calcite.UUCP> vjs@calcite.UUCP (Vernon Schryver) writes: >In article <1658@ursa-major.SPDCC.COM>, dyer@spdcc.COM (Steve Dyer) writes: >> ... You should see whether ISC provides some way of turning >> on NFS checksums if you're going to use NFS over SLIP.... > >This will not help in a heterogeneous network. Clearly both ends have to have UDP checksumming turned on. I had that implicit assumption, but I didn't make it obvious. -- Steve Dyer dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer dyer@arktouros.mit.edu, dyer@hstbme.mit.edu
hwajin@wrs.wrs.com (Hwa Jin Bae) (02/20/90)
In article <82@calcite.UUCP> vjs@calcite.UUCP (Vernon Schryver) writes: >Vanilla SLIP, as opposed to various "header compression" or "checksumming" >or "error correcting" varients or the new PPP (RFC-1xxx, I don't remember), >should not be used with NFS. The reason is that classic SLIP uses a >simple 1-byte framing without error detection. Most varieties of NFS >(anything based religously on the Sun 4.xBSD reference tapes as well as Sun >at least until recently) run with UDP checksumming turned off. This means >that corrupted bits will not be noticed. The result is file corruption for >either the client or on the server's disk. This problem can be overcome by patching the SunOS or any other relevant Unix kernel. My vanilla SLIP code for our realtime OS (called VxWorks) provides okay service for NFS when both sides turn the UDP checksum on. So I know NFS works fine once you turn the UDP checksum on. It's kinda amusing to use NFS over 9600 baud line but sometimes it's useful. Do this on SunOS: % su % cp /vmunix /vmunix.save % adb -w -k /vmunix /dev/mem udpcksum?w 1 ^D And "do the right thing" on your relevant OS to accomplish the equivalent effect. hwajin -- hwajin@wrs.com (uunet!wrs!hwajin) "Omnibus ex nihil ducendis sufficit unum." Hwa Jin Bae, Wind River Systems, 1351 Ocean Avenue, Emeryville, CA 94606, USA