Xref: utzoo comp.protocols.nfs:623 comp.protocols.tcp-ip:9656
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!uwm.edu!zaphod.mps.ohio-state.edu!wuarchive!decwrl!crltrx!decvax!ima!esegue!johnl
From: johnl@esegue.segue.boston.ma.us (John R. Levine)
Newsgroups: comp.protocols.nfs,comp.protocols.tcp-ip
Subject: Re: Which gives best data integrity:  NFS, UUCP, or FTP?
Message-ID: <1989Dec21.025229.2837@esegue.segue.boston.ma.us>
Date: 21 Dec 89 02:52:29 GMT
References: <1972@dover.sps.mot.com>
Reply-To: johnl@esegue.segue.boston.ma.us (John R. Levine)
Distribution: na
Organization: Segue Software, Cambridge MA
Lines: 24

In article <1972@dover.sps.mot.com> cowan@spanky.sps.mot.com () writes:
>For UUCP, FTP, and NFS, in what way (if any) do each of these programs
>perform data integrity checks and data correction?

Uucp passes 128 byte packets each protected by a CRC of, I believe, 8 bits.
If a packet is bad the receiver ignores it and the sender times out and
retransmits it.  The most common place I've seen uucp lose data is that older
versions didn't notice if the disk filled up.

FTP and NFS both depend on the underlying network to do the error correction.
Ethernets and dedicated lines with the usual synchronous protocols both do
CRCs and again the strategy is to ignore the bad block and wait until it's
retransmitted.  The ignoring happens at the IP level; retransmission happens
at the virtual circuit level for TCP and is up to the application for UDP.
There are optional checksums in TCP (used by ftp) and UDP (used by nfs)
headers, but they are often turned off on the assumption that link level error
correction will be adequate.

SLIP (IP over RS-232 async) does no error detection at all, so except for
the aforementioned checksums, you're naked.
-- 
John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650
johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl
"Now, we are all jelly doughnuts."