Beta release of new UUCP package available

70 views
Skip to first unread message

Ian Lance Taylor

unread,
Sep 10, 1991, 11:58:50 PM9/10/91
to
My new UUCP package is now available for beta test. I am calling it
Taylor UUCP (modest? me?) at least until I can think of a better name.
The package includes uucico, uuxqt, uucp and uux as well as a program
to dump configuration files (uuchk) and a testing program (tstuu). It
only supports the 'g' protocol for now. It will probably not work
with existing uulog or uustat programs, and the log files are not in
any standard form. It does not support TCP/IP or any other network
access, although it should work with uucpd. We have been using it to
call uunet for several weeks with no trouble.

The code is covered by the GNU Public License. It should run on most
Unix systems (and, currently, only Unix systems).

What distinguishes this package from other UUCP packages? You get
source code. It's also fairly complete, except as described above,
and when talking to another instance of itself supports restrictions
on transfer file size at specified times.

After discussion of some length in comp.mail.uucp, the program reads
standard V2 and BNU (HDB) configuration files, as well as a new set of
configuration files of mostly my own design. It does not, however,
read modemcap or acucap files; you can augment existing V2 files with
a BNU style Dialers file or a dialers file using my new configuration
scheme.

I am looking for information on functionality, portability and
efficiency. My goal is a complete, efficient, portable and highly
flexible implementation; any help will be gratefully appreciated.

I have put the code in the /tmp directory on uunet, where it is
available for anonymous UUCP or FTP (ftp.uu.net:/tmp). Because our
uunet link is via UUCP from an old VAX with no modem control lines, we
use XON/XOFF handshaking with the modem; since I haven't yet
implemented the 'f' protocol, I was forced to transfer a uuencoded
file. It is called taylor.uu and is a uuencoded compressed tar file.
If someone with FTP access would care to replace it with taylor.tar.Z,
I would be grateful; you may want to check both names when retrieving
it. I am told that it will remain in the /tmp directory so long as it
has been accessed within the last four days, which should suffice for
the beta test.
--
Ian Taylor | i...@airs.com | First to identify quote wins free e-mail message:
``Learning is not like a coin, which remains physically whole even through
the most infamous transactions; it is, rather, like a very handsome dress,
which is worn out through use and ostentation.''

Chris Lewis

unread,
Sep 12, 1991, 11:32:30 AM9/12/91
to
In article <25...@airs.com> i...@airs.com (Ian Lance Taylor) writes:
>Because our
>uunet link is via UUCP from an old VAX with no modem control lines, we
>use XON/XOFF handshaking with the modem; since I haven't yet
>implemented the 'f' protocol, I was forced to transfer a uuencoded
>file.

Huh? Now why would you want to run UUCP g protocol with XON/XOFF
handshaking? Or any flow-control handshaking whatsoever? The
handshaking you care about is the existance of carrier (eg: line
drop). Not flow control. g protocol does flow control for you.

Yes, hardware flow control is useful when you're talking to a modem
with g spoofing (like a trailblazer), but if you don't have hardware
handshaking, the occasional packet retransmit is bound to cost a lot
less (and be less error prone) than having to uuencode the durn thing.

Besides, the packet headers and trailers *can* have XON or XOFF's in them,
regardless of whether the data is pure printable data or not. I've seen many
occasions where large uuencoded (or otherwise ascii) transfers will
stall out or break UUCP transfers where XON/XOFF has been accidentally
enabled. (or, for that matter, when the modem you're using has other
special attention characters, eg: ^p in X.25 pads, VAX console ports etc.)
--
Chris Lewis; UUCP: ...!{cunews,uunet,latour}!ecicrl!clewis;
DOMAIN: cle...@ferret.ocunix.on.ca; Phone: Canada 613 832-0541
Psroff info: psroff-...@ferret.ocunix.on.ca
Ferret mailing list: ferret-...@ferret.ocunix.on.ca

Ian Lance Taylor

unread,
Sep 15, 1991, 8:44:47 PM9/15/91
to
cle...@ferret.ocunix.on.ca (Chris Lewis) writes:

>Huh? Now why would you want to run UUCP g protocol with XON/XOFF
>handshaking? Or any flow-control handshaking whatsoever? The
>handshaking you care about is the existance of carrier (eg: line
>drop). Not flow control. g protocol does flow control for you.

>Yes, hardware flow control is useful when you're talking to a modem
>with g spoofing (like a trailblazer), but if you don't have hardware
>handshaking, the occasional packet retransmit is bound to cost a lot
>less (and be less error prone) than having to uuencode the durn thing.

We do have a Trailblazer, and it is fully capable of overwhelming our
VAX's serial port; it does so within a line or so of conversation
mode, so I assumed that two packet downloads would also wipe out the
port, and that XON/XOFF was better than requiring retransmission; I
will check those assumptions.

Moreover, the package I just sent out is the first binary file I have
wanted to transmit to uunet since we started our UUCP connection last
November, so the additional cost of uuencoding data is utterly
negligible.

>Besides, the packet headers and trailers *can* have XON or XOFF's in them,
>regardless of whether the data is pure printable data or not. I've seen many
>occasions where large uuencoded (or otherwise ascii) transfers will
>stall out or break UUCP transfers where XON/XOFF has been accidentally
>enabled. (or, for that matter, when the modem you're using has other
>special attention characters, eg: ^p in X.25 pads, VAX console ports etc.)

Fortunately, we don't transmit much data out, and we haven't run into
any problems. I wasn't trying to suggest a way to run things; I was
just explaining why I chose to send a uuencoded file.

j...@cmkrnl.uucp

unread,
Sep 16, 1991, 12:46:25 PM9/16/91
to
In article <25...@airs.com>, i...@airs.com (Ian Lance Taylor) writes:
> We do have a Trailblazer, and it is fully capable of overwhelming our
> VAX's serial port; it does so within a line or so of conversation
> mode, so I assumed that two packet downloads would also wipe out the
> port, and that XON/XOFF was better than requiring retransmission; I
> will check those assumptions.

No. In fact, hell no.

Firstly, if you're running uucp, there is handshaking within the protocol.
Doesn't matter whether you're using the Telebit spoofing mode or not. Either
way, the modem is not going to send you more than 3 uucp packets (210 bytes
total) until your system sends out an ACK ("RR" in some uucp proto documents)
to tell it that the first packet came in correctly. (If your VAX's serial
port gets overrun with 3 uucp packets, maybe you should be running some
different software on the VAX. Uucp under VMS doesn't have such problems,
for example. :-)

Secondly, Telebit modems IGNORE xon/xoff when operating in spoofing mode.
Even if you configure them to use it.

Thirdly, if you still persist (and succeed) in configuring your computer's
serial port for XON/XOFF, the following bad things WILL happen: Eventually you
will get an incoming data packet that happens to have an xon or xoff in the
header. In fact, you will either send or receive such a packet relatively
early, on nearly *every* uucp connection! A longdata packet that is packet
number 2, with an "imbedded ACK" for packet 1, has a control byte that looks
just like an XOFF with the high bit set.

If your computer happens to be on the receiving end of this packet, and you
have configured the port for xon/xoff, your computer will interpret this as a
flow control character and elide it from the stream of data passed to the uucp
protocol handler. Guess what -- you have now corrupted what was a perfectly
valid packet. Moreover, NO amount of retransmissions will correct the
situation, since the contents of the control byte will not change.

Fortunately, most uucps turn off xon/xoff flow control on the serial port,
even if a misguided system manager has enabled them. In fact, the fact that
you can run uucp at all proves that you DON'T have xon/xoff flow control
enabled, at least not while uucp has command of the port.

Repeat after me: Uucp "g" protocol requires a completely transparent, eight-
bit-wide data path. No xon/xoff, no enq/ack, no godawful "parity" bits, etc.

> Fortunately, we don't transmit much data out, and we haven't run into
> any problems. I wasn't trying to suggest a way to run things; I was
> just explaining why I chose to send a uuencoded file.

No... Uucp also *provides* a completely transparent, eight-bit-wide data path.
Hence, you don't need to uuencode a file to send it via uucp. (How else do you
think we send megabytes of compressed news batches via uucp? You didn't think
we compressed them and then uuencoded them, did you?) uuencode is needed only
when sending binary files via mail.

--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
uucp "g" protocol guru, VMSnet [DECUS uucp] Working Group, and
Chair, VMS Internals Working Group, U.S. DECUS VAX Systems SIG
Internet: j...@dcs.simpact.com, hanr...@eisner.decus.org, or j...@crash.cts.com
Uucp: ...{crash,eisner,uunet}!cmkrnl!jeh

Ian Lance Taylor

unread,
Sep 17, 1991, 1:36:07 AM9/17/91
to
j...@cmkrnl.uucp writes:

>Firstly, if you're running uucp, there is handshaking within the protocol.
>Doesn't matter whether you're using the Telebit spoofing mode or not. Either
>way, the modem is not going to send you more than 3 uucp packets (210 bytes
>total) until your system sends out an ACK ("RR" in some uucp proto documents)
>to tell it that the first packet came in correctly. (If your VAX's serial
>port gets overrun with 3 uucp packets, maybe you should be running some
>different software on the VAX. Uucp under VMS doesn't have such problems,
>for example. :-)

I was under the impression that 210 bytes WAS enough to overrun the
serial port, from my experience with the modem in conversation mode.
Changing software is not an option. However, ...

>Secondly, Telebit modems IGNORE xon/xoff when operating in spoofing mode.
>Even if you configure them to use it.

presumably, I was wrong.

>Thirdly, if you still persist (and succeed) in configuring your computer's
>serial port for XON/XOFF, the following bad things WILL happen: Eventually you
>will get an incoming data packet that happens to have an xon or xoff in the
>header. In fact, you will either send or receive such a packet relatively
>early, on nearly *every* uucp connection! A longdata packet that is packet
>number 2, with an "imbedded ACK" for packet 1, has a control byte that looks
>just like an XOFF with the high bit set.

I think it will look like XON (10010001 == 0x91 == ^Q) with the high
bit set, not that it matters. Since the high bit is set, I would
expect the modem to ignore it.

>If your computer happens to be on the receiving end of this packet, and you
>have configured the port for xon/xoff, your computer will interpret this as a
>flow control character and elide it from the stream of data passed to the uucp
>protocol handler. Guess what -- you have now corrupted what was a perfectly
>valid packet. Moreover, NO amount of retransmissions will correct the
>situation, since the contents of the control byte will not change.

It appears to be possible to configure the port to generate XON/XOFF,
but not to pay attention to them, by setting TANDEM but resetting
AUTOFLOW.

>Fortunately, most uucps turn off xon/xoff flow control on the serial port,
>even if a misguided system manager has enabled them. In fact, the fact that
>you can run uucp at all proves that you DON'T have xon/xoff flow control
>enabled, at least not while uucp has command of the port.

No, it does not prove it. It is possible to run an eight bit
connection in one direction and an eight bit minus XON/XOFF in the
other, although certain file transfers will fail, if you only send
binary data in one direction. That is what I thought I was doing
(accepting binary data but sending non-binary data without embedded
XON/XOFF characters), but I was wrong because the Telebit was ignoring
the XON/XOFF anyhow.

>No... Uucp also *provides* a completely transparent, eight-bit-wide data path.
> Hence, you don't need to uuencode a file to send it via uucp. (How else do you
>think we send megabytes of compressed news batches via uucp? You didn't think
>we compressed them and then uuencoded them, did you?) uuencode is needed only
>when sending binary files via mail.

We don't compress outgoing news, so all our outgoing data is only
seven bits. Obviously I understand how news is transferred.

Again, it seems that I was wrong in what I thought was going on. I
made the posting primarily to show that I am not an idiot, and that my
perception of reality was reasonable even if it was incorrect.
--
Ian Taylor i...@airs.com uunet!airs!ian
First person to identify this quote wins a free e-mail message:
``This may be my one appearance in print. I may never occur in another
novel. You appear all the time; you can afford to be relaxed.''

Richard Lamb

unread,
Sep 24, 1991, 8:58:27 AM9/24/91
to
Jammie is absolutely right !! The g proto is a complete link level proto.
If you think youll be dealing with smart modems (TB,V.42,MNP) maybe adding
the "e" proto would be nice. Or for a X.25 (7-bit error-free) link the
"f" proto works real well (I run it on VMS between Cambridge and Dublin,IRE).

--
############################################################################
# _ /| | XtcN Ltd #
# \'o.O' | 11 Roxbury Ave. 4425 Butterworth Pl. N.W. #
# =(___)= | Natick MA 01760 Washington D.C. 20016 #
# U | Tel:508-655-2960 Tel:202-363-3661 #
# Ack! Phht! | E-mail: Internet: la...@xtcn.com Telex: 6504829720 #
# | X.400: C=US; A=MCI; S=Lamb; D.ID=4829720 #
############################################################################

Dave Platt

unread,
Sep 25, 1991, 1:24:31 PM9/25/91
to
In article <1991Sep24.1...@xtcn.com> la...@xtcn.com (Richard Lamb) writes:
>Jammie is absolutely right !! The g proto is a complete link level proto.
>If you think youll be dealing with smart modems (TB,V.42,MNP) maybe adding
>the "e" proto would be nice. Or for a X.25 (7-bit error-free) link the
>"f" proto works real well (I run it on VMS between Cambridge and Dublin,IRE).

I would avoid using the 'e' or 't' protocols over error-controlling
modems. These protocols _require_ a completely 100% error-free
transmission path... one which will either guarantee complete and
correct transmission of the data, or sever the link and report a
failure (e.g. as TCP will do).

Error-controlling modems aren't really sufficient. They'll detect and
correct most errors which occur between the modems... but they have no
ability whatsoever to correct errors in the modem-to-host links at
either end of the transmission. Since it's not unknown for serial
cables to come loose a bit and mangle a character, or for hosts to drop
a byte of incoming data if their serial port buffers get full, you're
taking serious chances with your data if you use 'e' or 't' over a link
of this sort.

I've found that 'f' works very nicely over MNP and V.42 modems. It's
safer than 'e' or 't', because it calculates a checksum of the file
being transmitted. The receiver validates the checksum and requests
retransmission of the file if there's a mismatch.

The biggest disadvantage of 'f' is that it's strictly a 7-bit
protocol... it can transmit 8-bit-binary data, but it "escapes out" all
hibit characters as well as all control characters. If you send
8-bit-binary data via 'f', it will grow by about 60% in the process (and
will be shrunk back to its original form by the receiver). If you must
send large amounts of 8-bit-binary data via 'f', you can c7encode it
first.

'f' does require that the modems (or whatever) support flow control.

--
Dave Platt VOICE: (415) 813-8917
Domain: dpl...@ntg.com UUCP: ...apple!ntg!dplatt
USNAIL: New Technologies Group Inc. 2468 Embarcardero Way, Palo Alto CA 94303

Matthias Urlichs

unread,
Sep 26, 1991, 6:04:07 AM9/26/91
to
In comp.mail.uucp, article <22...@ntg.ntg.com>,

dpl...@ntg.com (Dave Platt) writes:
<
< 'f' does require that the modems (or whatever) support flow control.
<
Most 'f' implementations force software flow control (i.e. XON/XOFF).
Configure your modem accordingly. (If the modem doesn't understand flow
control, you better use 'g'.)

'e' and 't', if somebody is reckless enough to use them on a modem link,
require hardware flow control which may or may not be enabled by the time the
protocol starts up; they've been designed for transmission over self-flow-
-controlling links like TCP/IP or or X.25ish packet switching networks.
--
Matthias Urlichs -- url...@smurf.sub.org -- url...@smurf.ira.uka.de /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany -- +49-721-9612521 \o)/

Reply all
Reply to author
Forward
0 new messages