On Mar 2,  9:11pm, Ted Lemon wrote:
} Subject: Re: rdist vs. sup
} 
} > I thought TCP was designed to guarantee error-free delivery of a
} > packet.  Shouldn't TCP cause the packet to be resent if the IP
} > checksum is wrong?
} 
} There's really no way to *guarantee* correct delivery of a message,
} although in_cksum makes a really good try of it.  It all comes down to
} probabilities.  In_cksum does a pretty good job of making sure that
} one or two one-bit changes in a packet will be detected, but if you're
} getting many bits changes in a packet from time to time, there's a
} decent chance that a mutated packet will slip through occasionally.

Over a serial link using error correcting modems (V.42, etc.) I'd say
the most likely packet corruption would be dropped bytes at either end
of the connection.  This should be pretty detectable by the IP checksum.
In V.42 mode, there is a CRC on each hdlc packet sent between the modems
(generally it's a 16 bit CRC and a 256 byte maximum packet size).  This
CRC is pretty darned good about detecting the types of burst errors caused
by noise on the line.  If you use PPP instead of SLIP, then I believe you
are also protected by the PPP CRC which should be pretty good about tossing
corrupt IP packets.  I'd say it would be rare indeed for a corrupt packet
to pass the PPP CRC and the IP checksum, since these use different algorithms.