REM%IMSSS@SAIL.STANFORD.EDU (Robert Elton Maas) (09/04/87)
<HS> Date: 31 Aug 87 19:09:50 GMT <HS> From: clyde!watmath!utgpu!utzoo!henry@rutgers.edu (Henry Spencer) <HS> To: protocols@RUTGERS.EDU > The entire globe needs yet anotehr new protocol like it needs 5 billion > new holes, one each in the heads of the earth's 5 billion people. <HS> Interesting that you should say this in the context of an article that <HS> basically says "run OSI". Ever heard of TCP/IP? :-) IP is packet switching, which is NOT the best way to run a network, it has a whole host of problems due to lack of flow control on per-hop basis, which apparently CANNOT be solved since Arpa-Internet is currently coming up with more and more wild ideas to try to circumvent the problems by hackery (source quench for example). I still believe packet-linking, not packet-switching, is the best way to go. Would anybody like me to write an essay describing the method and arguing on its behalf? Can anyone argue in favor of packet switching as opposed to packet linking? (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, and are therefore much more prompt. Constipation at any node causes backup along that route, but doesn't affect any other routes except insofar as buffer space is globally allocated in each node, and constipation never causes packets to actually get lost.) Does anybody know of any international standard protocol, proposed or actually in effect as a legal standard, which is packet-linking rather than packet-switching? If not, PCNET or other packet-linking protocol needs to be developed to the point where it can be proposed as an international standard which is an alternative to TCP/IP and current ISO protocols. <JAM> Date: Tue, 1 Sep 87 12:14:29 EDT <JAM> From: jcm@ORNL-MSR.ARPA (James A. Mullens) <JAM> To: pcnet@ai.ai.mit.edu <JAM> Subject: Why PCNet? > The entire globe needs yet anotehr new protocol like it needs 5 billion > new holes, one each in the heads of the earth's 5 billion people. <JAM> (In an attempt to be more specific and to learn somthing myself) <JAM> Why choose the unfinished PCNet over the existing Fido Net? Could somebody email me the protocol specs for Fido Net so I could study them and comment on their suitability?
steve@umigw.MIAMI.EDU (steve emmerson) (09/04/87)
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
randy@oresoft.UUCP (Randy Bush) (09/05/87)
The Fidonet protocol spec is available on many Fidonet compatible systems for Fidonet 'file request' or download. The document name is FSC001, and is usually in a file FSC001.ARC. The current version is FSC001-7. I will email a copy to you, but you won't be at all impressed. FSC001 documents a protocol which was being used, and does not represent a clean design to say the least. Interested parties can download or file request from Fidonet 1:105/6 at 1 (503) 297-9145. Then again, it's in use on a few thousand systems worldwide. -- Randy Bush, Compiler Group, Oregon Software, Portland Oregon (503) 245-2202 uucp: ..!tektronix!oresoft!randy Telemail: RBush Fidonet: 1:105/6
randy@oresoft.UUCP (Randy Bush) (09/06/87)
REM%IMSSS@SAIL.STANFORD.EDU (Robert Elton Maas) writes: >Could somebody email me the protocol specs for Fido Net so I could >study them and comment on their suitability? When I replied to your message, my neighbor's deamon bounced the mail. I will send the spec to you iff you supply a mailing address. Sorry. -- Randy Bush, Compiler Group, Oregon Software, Portland Oregon (503) 245-2202 uucp: ..!tektronix!oresoft!randy Telemail: RBush Fidonet: 1:105/6