🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.protocols.misc
Article #709

Re: not packet-switching, packet-linking; fidonet specs??

#709
From: steve emmerson
Date: Fri, 04 Sep 1987 13:58
49 lines
2974 bytes
In comparing packet-switching and packet-linking in article
<8709040503.AA13106@RUTGERS.EDU>, REM%IMSSS@SAIL.STANFORD.EDU (Robert
Elton Maas) writes:
+----
|... (Packet-linking is
|error-protected blocks of data sent just on a single hop, and
|immediately dis-assembled before incorporation into error-protected
|block for next hop, which means a single block can contain data from
|more than one logical stream that will go different ways at the next
|hop, which means it's efficient to have single characters of data
|passed at a time on a stream because only a fraction of a block is
|used, thus the overhead of error-protection and framing is distributed
|over multiple streams instead of applied to each stream. Each hop has
|flow control, which includes buffering limits in the receiving node,
|and local i.e. hop acknowledgements. LOST PACKETS CAUSE RESEND ON ONE
|HOP RATHER THAN ACROSS AN ENTIRE NET [my emphasis -- sre], and are 
|therefore much more prompt. ...
+----
    

Please excuse my confusion, but wouldn't it still be necessary to have 
end-to-end resend capabilty?

If I understand your explanation correctly, wouldn't it still be
possible for a block to be irretrievably lost due to a node crash?  If
node A notifies node B of correct reception of a block from node B, and
then crashes (loosing that block) it couldn't get a retransmission from
node B if node B reused that particular block buffer (as it should upon
reciept of the acknowledgment).  If, on the other hand, node A notifies
node B only *after* forwarding the packets of the block and *then*
crashes, then isn't there the possibility that one of the packets will be
incorrectly received at one of the other nodes causing the same result
(i.e. no locally available valid copy)?

Am I missing something?

-----
Steve Emmerson
RSMAS Remote Sensing Laboratory
Rosenstiel School of Marine and Atmospheric Science

USPS:  U. of Miami/RSMAS/MPO; 4600 Rickenbacker Cswy.; Miami, FL 33149-1098
USAN:  steve@umigw
AT&T:  (305) 361-4065
SPAN:  miami::emmerson (DECnet address 3.2)
uucp:  ...!{decvax,akgua}!ucf-cs!miami!emmerson
DDN:   emmerson@miami.miami.edu (192.31.89.4) or
       emmerson%miami.span@su-star.arpa or 
       emmerson%miami.span@vlsi.jpl.nasa.gov
Technical Details
Message-ID: <107@umigw.MIAMI.EDU>
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!seismo!ut-sally!husc6!hao!umigw!steve
References: <8709040503.AA13106@RUTGERS.EDU>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!seismo!ut-sally!husc6!hao!umigw!steve
From: steve@umigw.MIAMI.EDU (steve emmerson)
Newsgroups: comp.protocols.misc
Subject: Re: not packet-switching, packet-linking; fidonet specs??
Message-ID: <107@umigw.MIAMI.EDU>
Date: Fri, 4-Sep-87 09:58:06 EDT
Article-I.D.: umigw.107
Posted: Fri Sep  4 09:58:06 1987
Date-Received: Sat, 5-Sep-87 17:29:48 EDT
References: <8709040503.AA13106@RUTGERS.EDU>
Reply-To: steve@umigw.UUCP (steve emmerson)
Distribution: na
Organization: University of Miami
Lines: 49
Keywords: packet-linking, packet-switching
Summary: end-to-end buffering still needed?