Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpda!hpcuha!aspen!hpcc01!hpbbn!hpbbrd!hpfcmdd!hpfcso!hpldola!hpctdlb!hpctdlr!cac
From: cac@hpctdlr.HP.COM (Chris Clabaugh)
Newsgroups: comp.dcom.lans
Subject: Re: DECnet problem/protocol question
Message-ID: <3260006@hpctdlr.HP.COM>
Date: 1 Aug 90 19:38:45 GMT
References: <4084@dogie.macc.wisc.edu>
Organization: Hewlett-Packard CTD, Colo. Spgs.
Lines: 27

I can try and help.  Chances are that the packets that are doing the DAP file
transfer are made up of Ethernet, the Routing protocool, NSP, and finally DAP.
Ethernet does a checksum of the whole packet but has no knowledge of whether
the data from the file is really bad or not.  Therefore Ethernet won't
detect the problem.  DRP (the Routing protocol) will be using the Long Data
Message and it does not do a checksum at all.  Other DRP message types do
(like the Level 1 and Level 2 Routing messages).  NSP also does not do a
checksum.  Therefore both of these protocols won't detect the problem either.
Finally, that brings us to DAP which does calculate its own checksum of the
data.

DAP works by sending the whole file across the network and then finally the
the checksum in a separate packet.  If the checksum is bad, then this won't
be discovered until the whole file has already been transferred.

NSP was originally designed to work on early phases of DECnet.  There was no
LAN in these early phases and therefore you are right, it ran on DDCMP as well
as some others.  In Phase IV (the current phase for now, Phase V is soon),
LANS and X.25 were added along with other enhancements.  NSP is actually a
fairly robust protocol.  It has 'port' numbers and sequence numbers.  It also
segments packets and does flow control.  It does, however, lack a checksum.

I hope this helps...

Chris Clabaugh
Hewlett-Packard Colorado Telecommunications Division
cac@hpctdkg.hp.com