Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site edcaad.UUCP
Path: utzoo!linus!philabs!cmcl2!floyd!vax135!edcaad!dave
From: dave@edcaad.UUCP
Newsgroups: net.dcom
Subject: Re: Anything done for uucp over X25?
Message-ID: <537@edcaad.UUCP>
Date: Sat, 16-Jul-83 09:10:38 EDT
Article-I.D.: edcaad.537
Posted: Sat Jul 16 09:10:38 1983
Date-Received: Sun, 10-Jul-83 05:08:32 EDT
References: <174@zti1.UUCP>
Organization: Architecture, Edinburgh U., Scotland
Lines: 31

We use UUCP over two different packet-switch nets,  viz:

1.	Edinburgh's RCONET - a pre-X25 net which IS capable of
	providing a transparent 8-bit path from a host to a
	terminal.  This uses uucp with only one modification,
	a flag to halve the packet size so that a window of
	3 packets fits in a PAD buffer. Performance is
	CATASTROPHIC (i.e. < 100 baud from a 1200 baud line).

2.	BT's PSS (via a gateway from the RCONET).  This,  unlike
	1,  uses a uucp modified to use printing characters only
	(i.e. only 4 bits).  We have tried various ways to
	get uucp through a less-than-8-bits path,  and this
	is the only attempt that has even looked like it might
	work.  It is still unusable.  Performance is
	UNBELEIVABLY CATASTROPHIC (no figures yet).

Basically,  all attempts to add another layer under the packet
driver are a waste of time.  They almost always start from the
availability of a reliable,  flow-controlled path with less
than 8 bits,  and are trying to get to a reliable,  flow-
controlled path with 8 bits.  If your path is already
reliable and flow-controlled,  you don't need the packet
driver at all.  The BERKNET encoding will do what you really
want.

If you must use a PAD,  try to get one where the call setup
is done via a different port from the data transfer (cf. using
the DN11 ACU).  I don't know of any that work this way,  but
talk to your supplier.  It's just blowing a new PROM.
	David Rosenthal	{mcvax|vax135}!edcaad!dave