Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.8 $; site uiucuxc
Path: utzoo!watmath!clyde!cbosgd!ihnp4!inuxc!pur-ee!uiucdcs!uiucuxc!hamilton
From: hamilton@uiucuxc.CSO.UIUC.EDU
Newsgroups: net.dcom
Subject: Re: uucp and Tymnet
Message-ID: <11200002@uiucuxc>
Date: Tue, 1-Oct-85 22:29:00 EDT
Article-I.D.: uiucuxc.11200002
Posted: Tue Oct  1 22:29:00 1985
Date-Received: Fri, 4-Oct-85 03:27:42 EDT
References: <11886@rochester.UUCP>
Lines: 49
Nf-ID: #R:rochester.UUCP:-1188600:uiucuxc:11200002:000:2699
Nf-From: uiucuxc.CSO.UIUC.EDU!hamilton    Oct  1 21:29:00 1985


>In article <11886@rochester.UUCP> lee@rochester.UUCP (Lee Moore) writes:
>>I am considering running UUCP over Tymnet in async mode.  I know
>>that I have to put the line into "transparent" mode (8-bits...) but
>>is there anything else to know?  Has anybody else tried this?
>
>You also have to turn off all control characters and make the timer
>(timeout before sending incomplete packets) as short as possible
>(I believe it's 50 Msec.).  Unfortunately, that still has things very
>slow....  If you can try using
>an X.25 Pad and the 4.3 UUCP.  4.3 UUCP supports pads (protocol "f")
>directly.  We are getting 5600 baud effective thru-put with it.
>The major problems with 4.3 is twofold:
>	1) Uses 7 bit mode, so binary files go up in size.
>	2) Assumes "error free" transmission, and only ships a checksum
>	   at the end of the file.  In our case, one of the ends cannot
>	   guarantee reception of characters even at 2400 baud with
>	   flow control, so we die a lot.
>Chris Lewis,

    i had a similar problem trying to run uucp thru a mux that stole the
parity bit and did it's own flow control.  some colleagues here also
needed to run uucp thru a sytek localnet.  i also had chris's problem
#2 -- even tho my muxes guaranteed error-free transmission 6 miles
across town, i couldn't count on the 6 FEET from the mux to my 68000 box
(it occasionally got overrun at speeds over ~2400 baud).
    so i cooked up a variation on the "f" protocol.  i substituted a
couple of routines for the "read" and "write" used by the code in pk1.c.
these new routines do byte stuffing/unstuffing like the "f" protocol
before/after calling the "real" read and write.  in my case, i modified
the stuffing to leave "benign" control chars (newline, tab, etc) alone;
my problem was with ^S/^Q and anything >= 0200.  the actual protocol is
still "g" (renamed "h"), so you still get per-packet acks and checksums.
thruput isn't too bad; the people using the sytek lan get 450 bytes/sec
over 9600 baud for large, mostly text, files.  if the pk1.c code does
reads and writes of whole packets (i never really deciphered it), you could
add an end-of-message character to each packet to avoid waiting for timeout
(i'm pretty sure sytek has such a feature; maybe tymnet does also?).
    the biggest hassle with my solution is keeping 2 versions of uucico
around, and arranging for the right one to be invoked when needed.  one
of these days i'll go back and make it use the "brand" field in L-devices
or something like that.

	wayne hamilton
UUCP:	{ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!hamilton
ARPA:	hamilton@uiucuxc.cso.uiuc.edu
CSNET:	hamilton%uiucuxc@uiuc.csnet
USMail:	Box 476, Urbana, IL 61801
Phone:	(217)333-8703


Brought to you by Super Global Mega Corp .com