Path: utzoo!utgpu!watmath!isishq!f171.n221.z1.FIDONET.ORG!izot
From: izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh)
Newsgroups: comp.sys.cbm
Subject: Re: Punter Info Needed
Message-ID: <1855.2423BBFD@isishq.FIDONET.ORG>
Date: 13 Mar 89 23:19:18 GMT
Sender: ufgate@isishq.FIDONET.ORG (newsout1.25)
Organization: FidoNet node 1:221/171 - Izot's Swamp, Kitchener ON
Lines: 52


 > From: jgreco@csd4.milw.wisc.edu (Joe Greco)
 > Message-ID: <1531@csd4.milw.wisc.edu>
 
 > I have a sugar coated overview of the protocol, describing the basics.
 > Not at all technical.  If you want to know how to use it, look at the
 > BASIC program supplied with it.  If you want to understand how it
 > works, you're too advanced.... go get a real protocol.  :-)
 
   No kidding. Steve's own description of the protocol he designed and wrote 
is flat out wrong in one or two places!
 
   And there are various stupid things done. First of all, each block header 
contains the size, in bytes, of the NEXT block so that the receiver can be 
certain (via the checksums) that it knows exactly how long the next block 
should be. OK, let's accomodate Steve on that one, even though it requires 
buffer space large enough to hold TWO blocks. Now, the sensible thing to do at 
the end of the file is simply indicate that the next block contains 0 bytes, 
right, and the acknowledgement of the last block also indicates understanding 
that the transfer is over. Well, Steve decided in stead that putting a 255 in 
the high byte of the block number would in stead be the signal. Quite aside of 
the fact that C1 is physically incapable of transferring files requiring more 
than 64,000 blocks, it means that something completely out of pattern must be 
checked for each & every time a block arrives.
 
   Since the sender & receiver are both sending GOO, BAD, ACK, or S/B at each 
other, Steve found that sometimes they would send simultaneously and the C64's 
RS-232 routines would garble the data, meaning that neither ever got the 
other's message. To solve this, the sender and receiver use different delay 
patterns: long-long-short and short-short-long. "Why not", ask I, "just have 
the sender use long delays and the receiver short ones?"... the answer, it 
seems, is that Steve is incapable of accepting such simple solutions.
 
   Steve is now working on C2 (his third protocol). It's a streaming protocol 
that requires that either the OS be able to seek to a random byte # in a file 
and read/write at the middle, or that the entire file be buffered/written to a 
temporary file, because bad blocks are re-sent after the whole file has been 
run through once.
 
   However, unlike his other two protocols, this one works only on machines 
for which people like Chuck Forsberg have already spent years perfecting 
protocols. I'm willing to be that C2 will not catch on, simply because it has 
REAL competition (not to mention that it is a late entry into the race).
 
   Geoff ( watmath!isishq!izot )
 


--  
 Geoffrey Welsh - via FidoNet node 1:221/162
     UUCP: ...!watmath!isishq!171!izot
 Internet: izot@f171.n221.z1.FIDONET.ORG