ForceDDPCheckSum
Jeff Imig
extension which forces 'on' DDPCheckSum.
I'm wondering if anyone here has experience with the extension? Are there
major flaws in using it? Specifically, does it have to be turned on on
both ends of the transaction, or if it works transparently. Also does it
work through routers over TCP/IP.
I have had definite problems with files downloaded from ftp sites which had
internal corruption detected by Stuffit but which transferred nonetheless.
The article suggests to me that ForceDDPCheckSum may help reduce the
incidence of those errors; is that the case?
*-------- Jeff Imig --- jeff...@rs6000.cmp.ilstu.edu *
*--------- Psychology Department -------------------------*
*---------- Illinois State University --------------------*
*----------- Normal, IL 61790-4620 -----------------------*
Jim Hayes
>There is an article in the November 94 MacUSER (p.147) discussing an
>extension which forces 'on' DDPCheckSum.
>I'm wondering if anyone here has experience with the extension? Are there
>major flaws in using it? Specifically, does it have to be turned on on
>both ends of the transaction, or if it works transparently. Also does it
>work through routers over TCP/IP.
It would be good if both ends used properly checksummed packets, but
this isn't always possible, or in the case of DDP, usable. When I
experimented with forcing DDP checksumming a few years ago, I found a
number of "network" applications like QuickMail and Public Folder
stopped working. I left it alone after that.
TCP/IP packets have built protocol-level checksums, so you're
generally safe. Even if your TCP/IP frame is being carried through
DDP to your mac, MacTCP will catch the corruption even if AppleTalk
doesn't. :-(
>I have had definite problems with files downloaded from ftp sites which had
>internal corruption detected by Stuffit but which transferred nonetheless.
>The article suggests to me that ForceDDPCheckSum may help reduce the
>incidence of those errors; is that the case?
Probably not. If you're using TCP streams (which FTP uses) you're
generally safe, unless the data gets corrupted before it enters, or
after it leaves the network.
History:
DDP Checksums have a long and checkered past. (And are a particular
hot button of mine.)
DDP Checksums are turned off by default on the Macintosh. Apple's
official claim was that it adversely impacted performace because it
took too much precious CPU time to compute. (I have private reasons
to believe that there was another reason behind this decision.)
Turns out that not including a DDP checksum in Ethernet/Token Ring/FDDI
packets wasn't too much of a problem because those media have built in
CRC mechanisms that blow the pants off of a simple bit-rotated-checksum.
BUT, as network complexity increased, and your packets were more and
more likely to travel through a bridge or a router to some other net
using some unknown media (maybe without good integrity checking,) the
need for a protocol level checksum became obvious. (As did the need to
check packet sequence numbers, a lession which Apple only recently
learned with AppleShare.)
For example, I once managed a very large network with lots of WAN
interfaces (64Kbit/1.5MBit) and when AppleTalk packets would be bridged
onto the WAN media (using a very dumb bridge) they were subject to
a range of errors because the data could not be guaranteed to arrive
intact, or necessarily, in order.
For a second example: I once caught an Apple NuBus Ethernet card (the
old one made by 3Com, Rev H) SWAPPING two bytes of data in the packet
as it went out on the wire. It also computed the CRC taking the
swapped bytes into account, so it was indeed a "correctly formed"
packet, though the data was now invalid. If the packet had a DDP
checksum, this would have been caught on the receiving end, instead the
packet was accepted and the result (a file transfer) was corrupted.
Protocol level checksums are a good thing, as long as everybody uses
them, and the installed base of software doesn't break.
My $0.02.
--
Jim Hayes, Engineering Email: jha...@cisco.com
cisco Systems Inc, Voice: (408) 526-5268
San Jose, CA 94025 Fax: (408) 526-8282
Wesley Craig
>I'm wondering if anyone here has experience with the extension?
Sure, we use it extensively, here.
>Are there
>major flaws in using it?
The only problem is that some machines don't correctly compute ddp
checksums. The solution I recommend is to not purchase equipment that
can't perform this simple operation correctly.
:wes
Richard E. Brown
>There is an article in the November 94 MacUSER (p.147) discussing an
>extension which forces 'on' DDPCheckSum.
>
>I'm wondering if anyone here has experience with the extension? Are there
>major flaws in using it?
A couple minutes with ResEdit convinces me that ForceDDPChecksum is safe
and efficacious. It simply installs a patch to the _Control trap which sets
the "checksumFlag" bit in the .MPP driver's PWriteDDP call. This causes the
DDP code to compute a checksum for the outgoing packet (which the application
could have done in the first place).
I second the comments that others have made here, notably:
1) DDP Checksums are a Good Thing. We were transferring large (6-10 Mbytes)
files using AppleShare. Without ForceDDPChecksum, we could repeatably
transfer the file without incident, although the result was corrupted.
Making the same transfer with ForceDDPChecksum installed on the Mac
fixed the problem.
2) Routers, bridges, and other networking stuff *will* corrupt packets
sooner or later. A DDP checksum will protect your data.
3) The argument about slowing performance may once have had some shred
of credibility. In these days of 25 MHz and up processors, it's
completely ludicrous. Listen, folks: this is your *data* we're talking
about. Saving a couple dozen microseconds per packet ain't worth it.
4) For maximum protection, both end nodes of the session must compute
the checksums. But it'll help even if you install it only on one end.
5) Some devices don't work when DDP Checksums are present. Don't buy
equipment from vendors who don't know how to read a spec. Alternatively,
ask the vendor to fix the bug, and use their response time as a
measure of their credibility.
Rich Brown E-Mail: richard...@dartmouth.edu
Manager of Special Projects AppleLink address: Rich.Brown
Dartmouth College
Kiewit Computer Center Telephone: 603/646-3648
Hanover, NH 03755 USA Fax: 603/646-2810
Dan Lanciani
| 5) Some devices don't work when DDP Checksums are present. Don't buy
| equipment from vendors who don't know how to read a spec. Alternatively,
| ask the vendor to fix the bug, and use their response time as a
| measure of their credibility.
It's been quite a while since I looked at this, but wasn't the prime
example Apple's old ImageWriter itself? I remember not being able to
access these through a gateway for that reason. But I think there
was a firmware patch. :)
Dan Lanciani
ddl@harvard.*
A.Buteau 62 17
Is somebody running lwsrv.beta under Solaris 2.3 ?
And if yes with wich modifications ??
Thanks a lot because it'a impossible to run CAP on my network without lwsrv.beta
Jean-Luc MOUNIER
| equipment from vendors who don't know how to read a spec.
Also don't use a Personal LaserWriter NTR later from .... Apple !
| Alternatively,
| ask the vendor to fix the bug, and use their response time as a
| measure of their credibility.
We are still waiting for ROM upgrades.
They change the ROM for LaserWriter IIg more than one year after we have so
many problems.
Scott Winders
(Jean-Luc MOUNIER) wrote:
There was a repair extension program available from 8/93 to 8/15/94
that provided new ROMs for the Personal LaserWriter NTR that fixed
the DDP checksumming problem.
Please check with your local dealer to see how you might get the new
ROMs now...
--
Scott Winders
win...@aux.support.apple.com
"My opinions are my own, not my employer's"