Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: SLIP documents
Message-ID: <1991Feb11.233102.24222@Think.COM>
Date: 11 Feb 91 23:31:02 GMT
References: <1991Feb8.203703.25654@zoo.toronto.edu> <1991Feb9.051623.29415@Think.COM> <84878@sgi.sgi.com>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 35

In article <84878@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>In article <1991Feb9.051623.29415@Think.COM>, barmar@think.com (Barry Margolin) writes:
>> Even worse, this one
>> parameter controls both whether checksums are generated during sending and
>> whether they are checked when receiving.
>Isn't this the right way to do it?  With a "single, system-wide parameter"
>controlling whether UDP is checksummed or not?

From p.78 of RFC1122:

   An application MAY optionally be able to control whether a UDP checksum
   will be generated, but it MUST default to checksumming on.

   If a UDP datagram is received with a checksum that is non-zero and
   invalid, UDP MUST silently discard the datagram.

4.2BSD-based UDP implementations violate both these requirements.  First,
it is supposed to be the application that decides whether it wants
checksumming; in BSD, either all applications get it or none do.  Second,
it is not permitted to disable checking of received packets.

>  We argued among ourselves
>years ago whether the NFS switch should be the same as the global UDP
>switch.

I wasn't only complaining about the fact that it affects all applications.
I was complaining about the fact that you can't disable generation of
checksums but still enable checking of checksums.  Thus, even though my
client does checksumming correctly, errors will still get through if the
server has them disabled.
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar