uh@zti1.UUCP (Michael Uhlenberg) (06/23/83)
Currently I am thinking about running uucp over X25. There are surely
many possible approaches, but I am looking specifically at uucp over
so called protocol converters, i.e. a black box with an X25 port and 1
or more V24 ports. These boxes are also sometimes called PADs for
Packet Assembler and Disassembler. Having such a box offers the following
advantages:
- Baud rate of up to 9600 instead of 300 or 1200
- No dialler necessary
- In my country (Germany) and other countries no legal problems with the PTT
(we may not buy our own modems, diallers are not available except some
very funny ones, and the computer(!) must have a PTT approval if connected
to a PTT modem).
Meanwhile we have two PADs which I operated back to back, i.e.
Computer <-> V24<->X25 <------> X25<->V24 <-> Computer
This did work with 4800 baud on the V24 links and 9600 on the X25 link,
but not with 9600 baud everywhere. But the connection is not totally
transparent, as the PAD goes from data-mode to command-mode when seeing
the character Ctrl-E.
The communication with the PAD will be like this:
send over the V24 line to the PAD the command "Call Connect":
Ctrl-e C C ID:xx
where xx is a two letter mnemonic. The PAD searches in an internal table
for this mnemonic, finds the corresponding station number, and issues
a Call Connect Request. When the connection is done, the PAD replies with
CONNECTED
This simple protocol could even be handled with the uucp login protocol.
After the connection is done, data can flow transparently in both directions,
with the exception of Ctrl-e.
Now I suggest the following: remove all control characters from the
uucp packets by catching them deep inside pk1.c, and transform them
to two non-control characters. Specifically, on write:
if (ch <= ' ') {
emit(' ');
emit(ch | 0100);
}
else emit(ch);
and the reverse on read.
Having all control characters eliminated from the packets (which now may
be longer than 64 bytes)
a) makes the PAD truly transparent
b) allows you XON/XOFF handshake (Tandem mode) between CPU and PAD
c) allows a special "End of packet" character, which indicates to the PAD
that the packet is complete and can be sent off.
I did not yet try b) and c); this will need some experimentation.
What are your feelings on the above? Someone doing similar stuff?
I know that a direct X25 connection on the computer could do much better
than that, but first of all, X25 cards are not yet readily available,
or very expensive, or rumored to be immature, and second, in my country,
installing such a card into my system would necessitate a complicated
process of approval by the PTT. A PAD however is not too expensive,
has all the licensing, and would offer many older or smaller systems
rapid access to X25.
Michael Uhlenberg
{decvax|philabs}!mcvax!zti1dave@edcaad.UUCP (07/16/83)
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