Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!rochester!udel!princeton!njsmu!klg
From: klg@njsmu.UUCP (Kenneth Goodwin)
Newsgroups: comp.dcom.modems
Subject: Re: TrailBlazer and UUCP
Summary: CRC not needed with TB+
Message-ID: <467@njsmu.UUCP>
Date: 31 Aug 88 15:47:08 GMT
References: <12793@mimsy.UUCP> <27022@oliveb.olivetti.com> <28073@oliveb.olivetti.com>
Organization: NJ State Medical Underwriters, Lawrenceville
Lines: 90

> In article <7708@cit-vax.Caltech.Edu> mangler@cit-vax.Caltech.Edu (Don Speck) writes:
> >too has the bug fixes), then negotiate a 128-byte or 256-byte packet
> >size.  This should be simple enough to implement that it could actually
> 
> could spoof the packet size negotiation and repackage the packets for
> the remote end.  That way I could take advantage of larger packet sizes
> even if the remote system hasn't upgraded his software.
> 
> 
> So, I'll make the tty buffers bigger.  There is a problem with
> reliability though.  A one byte CRC(?) per packet isn't really enough
> when you get much larger packets.


This is getting to be really interesting. I had in fact made several
suggestions to Telebit along these lines a while back when they posted
a request for suggestions to the net. The basic idea was to use
some of the apparently  unused S registers in the modem to program
the attributes of the protocol. You would set for UUCP, Kermit or Xmodem
styles with one register, and with the others, select packet sizes,
CRC or NO CRC checksumming, ACK or NO ACK's and what have you.
Remember that IT DOES NOT MATTER what the TB+ at the other end of your
connection is doing. The TB+ does protocol spoofing between your computer
and your TB+ and transmit's PEP protocols to the other TB+. My understanding
is that PEP does not contain any UUCP header information. ((Telebit?))

Ideally for TB+'s on a reliable comm port on your
computer you could set the TB+ for:

	1) 19.2 KB computer to modem transmission rates
	2) UUCP Protocols
	3) 256 byte input packet size
	(if you change the tty drivers to allow larger raw input limits
	then this number can be as big as needed....)
	4) 16KB (or larger) output packet size (on the fly if necessary)
		(set to filesize if less than the largerst desirable
		packet size)
	5) NO CRC checksum bytes, you probably don't need them because
	PEP takes care of the transmission, and CRC is only cuurently
	being used between the computer and the local TB+.

	the basic idea is that you can configure the TB+ AS YOU LIKE IT
	to maximize throughput between your computer and your TB+.

	If you CU (tip) out, you should be able to TURN off UUCP spoofing
	altogether and eliminate the PEP overhead....

	NOT that all these will greatly increase uucico throughput
	unless the other end likewise configures it's TB+.
	Throughput will still be restricted to the weakest link in the chain..

One possibility of all this is that it may be possible for a UUCP site
to talk to a Kermit site without "knowing" it, if both have the NEW
TB+'s since it may be possible for the TB+'s to act as protocol converters.
It would sort of follow this scenario:
	1) System A open's it TB+ and configures baud rate (via autobaud)
	and desired protocol and protocol attributes. Say UUCP with 256 INPUT
	and 4 KB output packet sizes, NO CRC bytes in packet.
	(UUCP G+ protocol :-) )

	2) SYSTEM A calls SYSTEM B's TB+ and logs into an account that is
	attached to a kermit remote server program (the  kermit uucico
	equivalent) System B configures it's TB+ for Kermit protocols
	with desired kermit packet attributes.

	3) TB+ system A handshakes with TB_ System B  and exchanges
	protocol information UUCP <-> KERMIT (NOTE PEP protocol must
	have protocol update control packets so when either system
	changes it's  computer<->modem protocol the other end is immediately
	informed of the changes in protocol and changes it's behavior
	accordingly. If the protocols are the same, then nothing needs
	to be done. If the protocols are different, then the TB+
	must reformat the packets from one format to another.
	ie. (turn a uucp  S command packet into the kermit equivalent
	before (after) PEP transmission)

	actually it should be
		uucp <-translation to-> generic PEP <- translation to -> kermit

	in other words, take all the abilities of all known transmission
	protocols, (uucp, kermit, ?modem) and roll them into a superset
	PEP protocol structure. Have the TB+ translated from the spoofed
	protocol (ie UUCP) into PEP at the local end, transmit the
	PEP protocol to the other end, and have the remote TB+
	translate from the PEP protocol to the remote spoofed protocol
	(ie, kermit).
	The TB+ may be doing something along these lines anyway (Telebit?)

Ken Goodwin
NJSMU.