Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!philabs!mcvax!zti1!uh From: uh@zti1.UUCP (Michael Uhlenberg) Newsgroups: net.dcom Subject: Anything done for uucp over X25? Message-ID: <174@zti1.UUCP> Date: Wed, 22-Jun-83 20:35:24 EDT Article-I.D.: zti1.174 Posted: Wed Jun 22 20:35:24 1983 Date-Received: Thu, 23-Jun-83 21:41:20 EDT Lines: 57 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!zti1