Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!jgreco
From: jgreco@csd4.milw.wisc.edu (Joe Greco)
Newsgroups: comp.sys.cbm
Subject: Re: Punter Info Needed
Message-ID: <1759@csd4.milw.wisc.edu>
Date: 30 Mar 89 23:02:37 GMT
References: <1855.2423BBFD@isishq.FIDONET.ORG>
Sender: news@csd4.milw.wisc.edu
Reply-To: jgreco@csd4.milw.wisc.edu (Joe Greco)
Organization: Interstellar Telephone, Telegraph, and Telepath, Inc.
Lines: 89

In comp.sys.cbm article <1855.2423BBFD@isishq.FIDONET.ORG>, izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) wrote:
]
] > 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!

Sometimes wrong, more often downright funny.  It DOES give a basic
understanding, however, and that is the only reason I keep it.  (No
others available...)

]   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 

That makes sense, although I suspect that such a complex checksum
would probably allow the block size for the current block to be
encoded within the block.... which would allow for some "neat" things,
such as intelligent block-sizing on the fly.  Coding the NEXT block
means that that block MUST go through at the current size, which may
simply not happen on noisy lines.

]buffer space large enough to hold TWO blocks. Now, the sensible thing to do at 
RAM is cheap, they said that years ago.  I have no argument against
even 1K for buffer space.

]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 

Sensible, of course.

]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 
I thought it was just highest bit (^15) set, but I could be wrong.

Considering all the "pain" Steve put into making sure that blue-moon
events would not cause problems elsewhere, that was dumb.  I can make
a 65000 block archive easily... (grins)

]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 never accepted any of my ideas, solutions, suggestions, or
ANYTHING regarding BBS64, and I know you have more experience with him
than I.  Is this news to you, Geoff?  Come on.  There might be some
obscure merit to using "patterns," but I can't think of it....  but
I'm sure he did, just so that he would be able to ignore your
suggestion.  (Steve at his finest).  ;-)

]   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.

Steve is getting senile.

]   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).

Steve is unrealistic.  I stated over a year ago that C2 will not catch
on.  Stated it.  Also stated that BBS-PC (PC-PunterNet, or whatever he
calls it now) will never catch on, and certainly never have more nodes
than PunterNet on the 64....  there are too many GOOD BBS programs out
for the PC that are so much less limiting, and that can work with
FidoNet.  How Steve expects to be able to compete with FN is beyond me.
--
jgreco@csd4.milw.wisc.edu		Joe Greco at FidoNet 1:154/200
USnail: 9905 W Montana Ave			     PunterNet Node 30 or 31
	West Allis, WI  53227-3329	"These aren't anybody's opinions."
Voice:	414/321-6184			Data: 414/321-9287 (Happy Hacker's BBS)