Goofy UUCP protocol
Robert Pinder
Ever since I set up my uucp site last month, I've been struck by how
inefficient the 'uucp-g' protocol seems. The receiver ACKs continually.
This is no problem I guess with full-duplex modems, but I can't understand
how it lasted so long with all those proprietary half-duplex 9600 bps modems
(Telebit and their spoofing notwithstanding).
I understand the inertia of backwards compatibility, but why isn't something
like Zmodem incorporated? It has large blocks and only NAKs when an error
is detected and handles multiple files! What could be better?
R.i.P. pin...@nyongwa.cam.org
Ian Lance Taylor
>Ever since I set up my uucp site last month, I've been struck by how
>inefficient the 'uucp-g' protocol seems. The receiver ACKs continually.
>This is no problem I guess with full-duplex modems, but I can't understand
>how it lasted so long with all those proprietary half-duplex 9600 bps modems
>(Telebit and their spoofing notwithstanding).
>I understand the inertia of backwards compatibility, but why isn't something
>like Zmodem incorporated? It has large blocks and only NAKs when an error
>is detected and handles multiple files! What could be better?
The 'g' protocol was designed for flaky communications lines, and it's
quite robust (although I think the checksum calculation could be both
more efficient and more powerful (i.e. able to catch more errors)).
It can handle dropped packets and duplicated packets, and it uses a
window to minimize the cost of continual ACKs. It's certainly not
very efficient, particularly, as you say, for a half-duplex modem
without spoofing (which is why Telebit invented spoofing in the first
place). Now that everybody has error free modems (you all do, don't
you?), 'g' is definitely out of date.
In any case, there are other protocols that are used with UUCP, namely
'e', 'f', and 't'. I don't know too much about the 'e' protocol. The
'f' protocol basically assumes an error free modem (it only checksums
an entire file at a time, so even a slightly flaky line will be
unusable), but unfortunately it assumes a seven bit communication
path, which makes transferring compressed files much less efficient.
The 't' protocol does no error checking at all, so it can only safely
be used with something like TCP.
The inertia of the 'g' protocol is stronger than just backward
compatability, since any protocol a UUCP package uses has to be
compatible with the package it's talking to. I just checked uunet,
for example, and it supports only the 'g' protocol and the 't'
protocol. I intend to add at least an eight bit protocol for error
free modems to my UUCP package, but we only call uunet and they're not
going to be running my package. Any new protocol that anybody designs
faces the same problem--in can catch on in small enclaves, but will
take a long time to spread.
--
Ian Taylor i...@airs.com uunet!airs!ian
First person to identify this quote wins a free e-mail message:
``It doesn't matter how obvious the truth is if the truth is that you'll
never escape.''
Kenneth Jamieson
>This group seems as apropos as any for this question:
>
>like Zmodem incorporated? It has large blocks and only NAKs when an error
>is detected and handles multiple files! What could be better?
>
>R.i.P. pin...@nyongwa.cam.org
Look at the "e" and "f" protocols.
--
========[ Xanadu Enterprises Inc. Amiga & Unix Software Development]=======
= Political Correctness - a stupid idea supported by tiny minds =
= who enjoy the power they get from making you feel guilty. =
=========== Ken Jamieson: uunet!tronsbox.xei.com!tron1 ===================
= NONE of the opinions represented here are endorsed by anybody. =
===========================================================================
Don Lewis
>In article <1991Nov13.0...@ccu.umanitoba.ca> pin...@nyongwa.cam.org (Robert Pinder) writes:
>>This group seems as apropos as any for this question:
>>
>>I understand the inertia of backwards compatibility, but why isn't something
>>like Zmodem incorporated? It has large blocks and only NAKs when an error
>>is detected and handles multiple files! What could be better?
>>
>>R.i.P. pin...@nyongwa.cam.org
>
> Look at the "e" and "f" protocols.
But you probably won't want to use them. There is no end to end error
check in the "e" protocol. If any characters get corrupted between the
computers and the modems, you lose. The "f" protocol has an overall
file checksum, but it is a 7 bit protocol, so if you send arbitrary
binary files (like compressed news), the number of bytes actually sent
gets greatly increased by the added escapes.
In article <21...@celit.fps.com> bi...@fps.com (Bill Davidson) writes:
>I've been thinking some more about Larry's claims about 'f' protocol and
>V.32bis+V.42bis.
>
>'f' protocol quotes all control characters and all 8 bit characters
>down to 7 bit ascii.
>
>This introduces a ton of redundancy to the file. I coded up a quick
>little 'f' coder and grabbed one of my outgoing compressed news batches
>to see how bad it was.
>
> 16-bit compressed file: 397803
> same sent through 'f' encode: 655966
--
Don "Truck" Lewis Phone: +1 916 265-3211 Silicon Systems
Internet: (under contruction) FAX: +1 916 265-2931 138 New Mohawk Road
UUCP: {uunet,tektronix!gvgpsa.gvg.tek.com}!ssigv!lewis Nevada City, CA 95959
j...@cmkrnl.com
(Robert Pinder) writes:
> The [uucp g] receiver ACKs continually.
> This is no problem I guess with full-duplex modems, but I can't understand
> how it lasted so long with all those proprietary half-duplex 9600 bps modems
> (Telebit and their spoofing notwithstanding).
There are several aspects to why it has "lasted so long" (present tense,
not past tense):
o Uucp got to be extremely popular when 1200 and 2400 bps full-duplex
modems were the norm.
o By the time there was a big demand for high-speed uucp links, the
Telebit uucp spoofing modems were available.
o I don't think there was a serious effort to design a uucp protocol
that would work well with half-duplex 9600 bps modems because it was
widely recognized that they were a passing fad, because full-duplex
9600 bps (and faster) modems were not that far off.
o If you need REALLY FAST throughput you don't want uucp anyway; you
want an Internet connection.
> I understand the inertia of backwards compatibility,
evidently not. Although there are now several uucp's for PCs, one or two
for Macs, and one [ahem] for VMS, and most of these are under current development,
the vast majority of uucp sites "out there" are Unix sites... and Unix uucp
is not being updated by anybody at the moment. A new protocol is not going to
gain widespread acceptance until it... well, until it gains widespread
acceptance. And that means, not until it's in a majority of intalled Unix
uucp's.
Also, we have to worry about back-compatibility with *modems*. Yes, it is true
that you can run uucp marginally faster through V.32bis with V.42bis
compression than you can through Telebit modems with PEP and spoofing. (Though
not as much faster as you might imagine.) However, this is a very recent
development. The vast majority of uucp sites who are moving large amounts of
data have invested in Telebit modems. Only the more recent Telebit modems will
do V.32 as well as with PEP, and *none* can do PEP as well as V.32bis. And
spoofing only works with 'g' protocol. So these sites must continue to use 'g'
until they have money (and reason) to replace their modem pool.
> but why isn't something
> like Zmodem incorporated? It has large blocks and only NAKs when an error
> is detected and handles multiple files! What could be better?
Zmodem is not the ultimate protocol. It has its problems. For example...
in the absence of ACKs, you really don't know if the receiving system is
getting any of your data. Oh, sure, it sends you a NAK if it gets a garbled
packet or notices a missing packet... but how do you know it's getting any
packets at all? You don't. You could burn up valuable long-distance time
sending a multi-megabyte file straight into the bit bucket, and you wouldn't
know until you reached the end of the file! Sorry, but I don't regard this as
characteristic of a wonderful design.
--- 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
(aren't you impressed? No??? Oh well.)
Internet: j...@cmkrnl.com, hanr...@eisner.decus.org, or j...@crash.cts.com
Uucp: ...{crash,eisner,uunet}!cmkrnl!jeh
Rich Salz
>place). Now that everybody has error free modems (you all do, don't
>you?), 'g' is definitely out of date.
Wrong.
Error-free modems aren't good enough; you must make sure that the path from
the modem into your CPU is error-free as well. There are very few true error-
free communications channels out there; TCP is perhaps the most common, hence
Rick's t protocol.
/r$
Ian Lance Taylor
>Wrong.
Nevertheless, I still think that 'g' is out of date. I didn't suggest
that the 't' protocol should replace it. There should be protocols
that work more like the 'f' protocol, with a checksum over entire
files and much less communication from the recipient to the sender.
The 'g' protocol is robust, but the packet size is too small (while
the protocol permits it to be larger, it seems that most
implementations limit it to 64 byte packets) and the per-packet
overhead is too large. I never claimed that error-free modems
eliminated all errors, but I think it's clear that they eliminate
most; the cost of the 'g' protocol is needlessly high.
Leslie Mikesell
>> I understand the inertia of backwards compatibility,
>the vast majority of uucp sites "out there" are Unix sites... and Unix uucp
>is not being updated by anybody at the moment. A new protocol is not going to
>gain widespread acceptance until it... well, until it gains widespread
>acceptance. And that means, not until it's in a majority of intalled Unix
>uucp's.
Ah, but it *has* been updated in the form of SysVr4's 'G' (note uppercase)
protocol that allows per-site (and maybe per-device) specification of
block and window size, pick-up-where-last attempt aborted and some
other stuff. What we need is for someone to publish the specifications
so it can be added to the other versions.
>Zmodem is not the ultimate protocol. It has its problems. For example...
>in the absence of ACKs, you really don't know if the receiving system is
>getting any of your data.
Zmodem does allow specifying a window size and forcing acks if you want.
>You could burn up valuable long-distance time
>sending a multi-megabyte file straight into the bit bucket, and you wouldn't
>know until you reached the end of the file! Sorry, but I don't regard this as
>characteristic of a wonderful design.
It's nice as long as you can turn it off when you want. There are many
situations where it is slow/and or expensive to turn the line around.
For example if a packet net with a per-packet charge is involved the
'g' protocol acks cost you as much as the data - if a satellite link
is involved, 'g' protocol spends about half its time waiting.
Les Mikesell
l...@chinet.chi.il.us
Aris Stathakis
>rs...@bbn.com (Rich Salz) writes:
>>In <28...@airs.com> i...@airs.com (Ian Lance Taylor) writes:
>>>place). Now that everybody has error free modems (you all do, don't
>>>you?), 'g' is definitely out of date.
>>Wrong.
>>Error-free modems aren't good enough; you must make sure that the path from
>>the modem into your CPU is error-free as well. There are very few true error-
>>free communications channels out there; TCP is perhaps the most common, hence
>>Rick's t protocol.
>Nevertheless, I still think that 'g' is out of date. I didn't suggest
>that the 't' protocol should replace it. There should be protocols
>that work more like the 'f' protocol, with a checksum over entire
>files and much less communication from the recipient to the sender.
>The 'g' protocol is robust, but the packet size is too small (while
>the protocol permits it to be larger, it seems that most
>implementations limit it to 64 byte packets) and the per-packet
>overhead is too large. I never claimed that error-free modems
>eliminated all errors, but I think it's clear that they eliminate
>most; the cost of the 'g' protocol is needlessly high.
What we need is a fully bi-directional full-streaming type UUCP protocol.
I.e. You can receive and send data at the same time - which is perfectly
possible on full-duplex modems. There are several MS-DOS transfer protocols
such as this - bimodem comes to mind. Also BinkleyTerm includes a protocol
called JANUS which I believe is in the Public Domain. I wish something like
this could be incorporated into uucico. Adding features like on-the-fly
compression/encryption and aborted file transfer resumption would also
be neat :-)
Aris
--
Aris Stathakis | Bang: ..!uunet!ddsw1!olsa99!tabbs!aris or ar...@tabbs.UUCP
- -
- What garlic is to food, insanity is to art. -
j...@cmkrnl.com
> What we need is a fully bi-directional full-streaming type UUCP protocol.
> I.e. You can receive and send data at the same time - which is perfectly
> this could be incorporated into uucico. Adding features like on-the-fly
> compression/encryption and aborted file transfer resumption would also
> be neat :-)
Yes, it would be neat.
Repeat earlier comments about getting a significant number of uucp sites to
run it, and about losing the advantages of uucp spoofing in the huge installed
base of Telebit modems.
Also, the "half-duplex" nature of uucp file transfers is not an attribute of
the 'g' protocol; it is more or less wired into the "middle layers" of uucico.
The "session layer", if you like (although uucico probably isn't written neatly
enough to see or easily change the layers in the code).
So adding full-duplex file transfers, so that you could be doing a "push mode"
file send from both ends at once, would not be a matter of implementing another
transport- and link-level protocol (which is what g, t, f, etc., are).
--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
Chair, VMS Internals Working Group, U.S. DECUS VAX Systems SIG
Ronald S H Khoo
> The 'g' protocol is robust, but the packet size is too small (while
> the protocol permits it to be larger, it seems that most
> implementations limit it to 64 byte packets)
64 bytes x window of 3 gives you the maximum that most UNIX
implementations will tolerate without flow control at a lower level.
People have enough difficulty setting up uucp as it is and you want to
make it harder ? Perhaps when the common-or-garden UNIX RS-232 interface
supports RS-232-E fullduplex flow control EXPLICITLY, not till then.
If you want Z-modem, I'm sure omen!caf will sell it to you. But please
don't break my *working* g-proto UUCP.
--
Ronald Khoo <ron...@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)
David Summers
>I.e. You can receive and send data at the same time - which is perfectly
>possible on full-duplex modems. There are several MS-DOS transfer protocols
>such as this - bimodem comes to mind. Also BinkleyTerm includes a protocol
>called JANUS which I believe is in the Public Domain. I wish something like
>this could be incorporated into uucico. Adding features like on-the-fly
>compression/encryption and aborted file transfer resumption would also
>be neat :-)
>Aris
>--
> Aris Stathakis | Bang: ..!uunet!ddsw1!olsa99!tabbs!aris or ar...@tabbs.UUCP
>- -
>- What garlic is to food, insanity is to art. -
I wrote a simple bi-directional protocol for UUCP (I called it 'b') a couple
of years ago. It works great on a perfect comm. channel, but it seems to
have some problems trying to recover (sometimes) when there is noise. It
streams and piggy-backs ACKS on the packets going the other direction (if
any). It was somewhat irksome trying to debug 8 processes at once. It
works by forking uucico into two processes on each side of the comm. link,
and then forking two more processes (for a total of 4 per side).
If anyone is interested, I'll look it up and send it to them. It requires
MINOR changes to the UUCICO programs (basically just the amount of code
necessary to add in another protocol, UUCICO is VERY modularized...I like
it). I can NOT send entire UUCP code to anyone as it is owned by AT&T.
What I CAN send is just the changes I made and my new code.
I will probably be looking into this again sometime within the next month,
as I will be learning a new lanugage (Promela (sp?)) which enables the
user to specify and test out a communications protocol. Right now, I'm
waiting for the book that describes Promela.
- David Summers
The Squire, Phish
>
>Also, the "half-duplex" nature of uucp file transfers is not an attribute of
>the 'g' protocol; it is more or less wired into the "middle layers" of uucico.
>The "session layer", if you like (although uucico probably isn't written neatly
>enough to see or easily change the layers in the code).
>
>So adding full-duplex file transfers, so that you could be doing a "push mode"
>file send from both ends at once, would not be a matter of implementing another
>transport- and link-level protocol (which is what g, t, f, etc., are).
Well, yes an no. The half-duplex nature of uucp, in a protocol such as 'g', is
due to the constant acking of packets. If you could, say, rewrite 'g' such that
you could be sending data while you were responding to the data BEING SENT,
you could implement bidirectional transfer. Of course this would entail
rewriting some of the middle layers, like you said, which is why I agree with
you to a point.
The ideal transfer protocol, IMHO, would be some sort of bidirectional Z-modem
with error recovery, and a periodical "yes, I'm still here and everything's
okay" depending on configuration and/or line conditions.
But to echo, we won't see new protocols until people start using them, and
people won't start using them until people start using them. (redundancy
intended). The solution, as I see it, would be to develop a protocol, and
just start including it in the distributions. If nobody else speaks it yet,
you have some extra code sitting around. But eventually, people will start
using it, if everyone agrees on it.
So who wants to start the draft for such a protocol?
--
If you insist upon living in a | ch...@zeus.calpoly.edu | Fubar Systems BBS
dream, you may be taken as mad. | | (805) 54-FUBAR
I like my dream. | Because all you of | 3/12/24, MNP5, 8N1
Then you *are* mad! | Earth are IDIOTS!! | FSBBS 2.0, FSUUCP 1.2
Ian Lance Taylor
>In article <29...@airs.com> i...@airs.com (Ian Lance Taylor) writes:
>> The 'g' protocol is robust, but the packet size is too small (while
>> the protocol permits it to be larger, it seems that most
>> implementations limit it to 64 byte packets)
>64 bytes x window of 3 gives you the maximum that most UNIX
>implementations will tolerate without flow control at a lower level.
>People have enough difficulty setting up uucp as it is and you want to
>make it harder ? Perhaps when the common-or-garden UNIX RS-232 interface
>supports RS-232-E fullduplex flow control EXPLICITLY, not till then.
Why is it that so many Unix serial ports do not support hardware
handshaking? Just about every terminal I've seen supports it
(probably VT100's don't or something). I'm used to running my
terminals at 38400 baud. Going back to 9600 is a real step down.
For that matter, our SCO box supports hardware handshaking fine.
Also, while our DECstation 3100 doesn't it can easily handle more
bytes than that without overloading.
>If you want Z-modem, I'm sure omen!caf will sell it to you. But please
>don't break my *working* g-proto UUCP.
Nobody said anything about breaking your UUCP. The packet and window
sizes are negotiated when the protocol starts up. My UUCP package
permits you to set the values (on a per-system, per-device or
per-dialer basis), but my package will always send the other system
whatever it requests. If you use my UUCP and try for a large packet
size and your port overflows, you can just lower your packet size.
Actually, it's not quite that simple because some other UUCP packages
will crash if you ask them to send a larger packet size (the Ultrix
4.0 UUCP will, for example). So you can really only raise the packet
size if you know for sure that the other system's software as well as
your local hardware can handle it.
Peter Busser
>The ideal transfer protocol, IMHO, would be some sort of bidirectional Z-modem
>with error recovery, and a periodical "yes, I'm still here and everything's
>okay" depending on configuration and/or line conditions.
available. It has Z-Modem performance in one direction. However, HST modems and
V32bis modems do not seem to work well with bi-directional programs. And I
think MNP/V42/V42bis will not work very well too.
Greetings,
Peter Busser
--
#include <std/disclaimer.h> /* These are MY words, not those of my employer! */
brain fault - core dumped
Ian Lance Taylor
>The half-duplex nature of uucp, in a protocol such as 'g', is due to
>the constant acking of packets. If you could, say, rewrite 'g' such
>that you could be sending data while you were responding to the data
>BEING SENT, you could implement bidirectional transfer. Of course
>this would entail rewriting some of the middle layers, like you said,
>which is why I agree with you to a point.
No, the 'g' protocol can already handle bidirectional transfer. Each
data packet contains an acknowledgement of what packets have already
been received. You don't need to send an unadorned ACK. Of course,
you want to be careful about when you send your ACK's, so that you do
in fact combine them with data.
The problem really is at the ``session'' layer. There's no way to
distinguish an incoming command from incoming data. After requesting
to receive a file, it is no longer possible to receive commands until
the file is completely finished. If you stick to the 'g' protocol,
you could distinguish commands by using the alternate channel (a type
2 packet), which is normally unused by UUCP (I still consider the
problem to be at the session layer; this is just taking advantage of
an unused protocol feature to solve a higher level problem). This
would just leave you with the problem of correlating commands,
responses, and file transfers. Not to mention being incompatible with
everybody else.
>But to echo, we won't see new protocols until people start using them, and
>people won't start using them until people start using them. (redundancy
>intended). The solution, as I see it, would be to develop a protocol, and
>just start including it in the distributions. If nobody else speaks it yet,
>you have some extra code sitting around. But eventually, people will start
>using it, if everyone agrees on it.
>So who wants to start the draft for such a protocol?
Oh, after I earn some money and get back to my UUCP package I'll churn
something out for people to scoff at. I sure wouldn't mind if
somebody else went first, though.
Gregory Gulik
>
>Nevertheless, I still think that 'g' is out of date. I didn't suggest
>that the 't' protocol should replace it. There should be protocols
>that work more like the 'f' protocol, with a checksum over entire
>files and much less communication from the recipient to the sender.
>The 'g' protocol is robust, but the packet size is too small (while
>the protocol permits it to be larger, it seems that most
>implementations limit it to 64 byte packets) and the per-packet
>overhead is too large. I never claimed that error-free modems
>eliminated all errors, but I think it's clear that they eliminate
>most; the cost of the 'g' protocol is needlessly high.
I agree completely.
I'd love to be able to change the packet size, and the sliding
window value, but it's compiled in and can't change it.
Does anyone have any idea when the GNU version of UUCP will
be available?
-greg
--
--
Gregory Gulik
gu...@ebony.rtsg.mot.com || gr...@gagme.chi.il.us
|| gu...@depaul.edu
The Squire, Phish
>ch...@zeus.calpoly.edu (The Squire, Phish) writes:
>
>>The half-duplex nature of uucp, in a protocol such as 'g', is due to
>>the constant acking of packets. If you could, say, rewrite 'g' such
>>that you could be sending data while you were responding to the data
>>BEING SENT, you could implement bidirectional transfer. Of course
>>this would entail rewriting some of the middle layers, like you said,
>>which is why I agree with you to a point.
>
>No, the 'g' protocol can already handle bidirectional transfer. Each
>data packet contains an acknowledgement of what packets have already
>been received. You don't need to send an unadorned ACK. Of course,
>you want to be careful about when you send your ACK's, so that you do
>in fact combine them with data.
Right. What I meant was to rewrite g so as to take advantage of this.
The alternate channel, for example. So let's do it. :-)
>The problem really is at the ``session'' layer. There's no way to
>distinguish an incoming command from incoming data. After requesting
>to receive a file, it is no longer possible to receive commands until
>the file is completely finished. If you stick to the 'g' protocol,
>you could distinguish commands by using the alternate channel (a type
>2 packet), which is normally unused by UUCP (I still consider the
>problem to be at the session layer; this is just taking advantage of
>an unused protocol feature to solve a higher level problem). This
>would just leave you with the problem of correlating commands,
>responses, and file transfers. Not to mention being incompatible with
>everybody else.
Unless everyone else does it.
>>So who wants to start the draft for such a protocol?
>
>Oh, after I earn some money and get back to my UUCP package I'll churn
>something out for people to scoff at. I sure wouldn't mind if
>somebody else went first, though.
I have a draft... whether or not I want to submit for scoffing is
another problem. I'd rather bang it against someone else's implementation
and see how it goes.
Matthias Urlichs
pe...@idca.tds.philips.nl (Peter Busser) writes:
< In article <1991Nov19.0...@zeus.calpoly.edu> ch...@zeus.calpoly.edu (The Squire, Phish) writes:
< >The ideal transfer protocol, IMHO, would be some sort of bidirectional Z-modem
< >with error recovery, and a periodical "yes, I'm still here and everything's
< >okay" depending on configuration and/or line conditions.
< >So who wants to start the draft for such a protocol?
< It already exists and is called Janus. BinkleyTerm uses it and source code is
< available. It has Z-Modem performance in one direction.
Where is the source code FTPable from?
< However, HST modems and
< V32bis modems do not seem to work well with bi-directional programs. And I
< think MNP/V42/V42bis will not work very well too.
HST doesn't work well because of their slow back channel.
But there are no technical reasons why the others shouldn't work; i.e.,
throughput in one direction shouldn't suffer just because you're sending data
in the second direction too. If it does, somebody's doing something wrong.
--
Matthias Urlichs -- url...@smurf.sub.org -- url...@smurf.ira.uka.de /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany -- +49-721-9612521 \o)/
j...@cmkrnl.com
> j...@cmkrnl.com recently informed us:
>>
>>Also, the "half-duplex" nature of uucp file transfers is not an attribute of
>>the 'g' protocol; it is more or less wired into the "middle layers" of uucico.
>>The "session layer", if you like (although uucico probably isn't written neatly
>>enough to see or easily change the layers in the code).
>>
>>So adding full-duplex file transfers, so that you could be doing a "push mode"
>>file send from both ends at once, would not be a matter of implementing another
>>transport- and link-level protocol (which is what g, t, f, etc., are).
>
> Well, yes an no. The half-duplex nature of uucp, in a protocol such as 'g', is
> due to the constant acking of packets.
Not at all. The acks live (or *should* live) at the data link level. There
are several VERY widely-used protocol stacks out there whose wide-area data
link layers ack every packet (barring imbedded acks and the like) but whose
upper layers have no problem supporting multiple sessions on the data link.
(I'm thinking of DDCMP under DECnet, and HDLC under OSI. I confess I've never
looked at SLIP.)
Half-duplex modems with long turnaround times were a passing fad, just a
stopover on the way to high-speed, full-duplex modems. Today there is no need
to consider an ack-less protocol like Zmodem. And there are good reasons not
to. With Zmodem you can send a whole bloody file without ever knowing if the
receiver is, or is not, paying attention. This may be fine for Zmodem's prime
use, downloading stuff from a BBS -- after all, you're sitting at the receiver;
you know whether you're receiving or not -- but it is not at all robust enough
to put into a hands-off communications package.
Someone has suggested that we design a new data link protocol. I know that
everybody likes to design things, but proving that a protocol is correct is no
easy matter. (I'm not talking about perfecting an implementation, but rather
about proving that the protocol *as specified* is correct. As a consultant I
have billed many hours getting people out of messes they got into by insisting
on developing their own protocol instead of using something known to be
correct.) I suggest *very* strongly that an existing data link protocol be
adopted instead.
For that matter, a proper implementation of 'g' will work just fine as a data
link layer under multiple sessions. Why reinvent anything? By using an
existing protocol, we maintain some possibility of compatibility with
existing and future modems that engage in protocol spoofing.
For the session layer, simply add a byte in the data field of data packets to
indicate "session 0" (caller is master) or "session 1" (answerer is master).
(Not original with me; someone else -- who grafted full-dup operation onto
uucico this way -- thought of it.) I don't see a need for session-level ACKs
since everything here is point-to-point; if the (single) data link is reliable
then the session level can be trusted too.
What about the application layer? What functionality is needed beyond
that provided by standard uucp? As long as we're recoding things we might as
well
One thing I can think of right away is that it would be nice to have a "SNn"
response code that explicitly means "disk full, try again later", and the
requesting system should *not* simply up and die upon receiving this code
(which is what at least one version of Sun uucp seems to do).
--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
uucp protocol guru, VMSnet (DECUS uucp) Working Group, and
Chair, VMS Internals Working Group, U.S. DECUS VAX Systems SIG
(aren't you impressed? No? oh well)
j...@cmkrnl.com
> In article <29...@airs.com> i...@airs.com (Ian Lance Taylor) writes:
>>
>>Nevertheless, I still think that 'g' is out of date. I didn't suggest
>>that the 't' protocol should replace it. There should be protocols
>>that work more like the 'f' protocol, with a checksum over entire
>>files and much less communication from the recipient to the sender.
Funny you should mention 'f' in that context. With 'f' you still have
acks for every packet. They're simply being generated by your X.25 network
and absorbed by your X.25 software; you never see them -- but they're still
there.
Sorry, but unless you have an absolutely reliable data link underneath uucp --
which is the case with 'f' over X.25, which is its intended use -- you really
need to ack more frequently than once per file. You really do not want to
have to send a whole file over again if it's wrong.
>>The 'g' protocol is robust, but the packet size is too small (while
>>the protocol permits it to be larger, it seems that most
>>implementations limit it to 64 byte packets) and the per-packet
>>overhead is too large. I never claimed that error-free modems
>>eliminated all errors, but I think it's clear that they eliminate
>>most; the cost of the 'g' protocol is needlessly high.
>
> I agree completely.
>
> I'd love to be able to change the packet size, and the sliding
> window value, but it's compiled in and can't change it.
Again, this is a problem with most implementations of 'g', not with 'g' as
specified.
Let's not throw out the baby (a proven protocol, supported by uucps everywhere,
and also supported by the vast installed base of Telebit modems) with the
bathwater (inability to extend the window and packet size beyond the typical
3/64, in most implementations).
--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
Chair, VMS Internals Working Group, U.S. DECUS VAX Systems SIG
Ian Lance Taylor
>One thing I can think of right away is that it would be nice to have a "SNn"
>response code that explicitly means "disk full, try again later", and the
>requesting system should *not* simply up and die upon receiving this code
>(which is what at least one version of Sun uucp seems to do).
My UUCP package handles this in a somewhat different way. It first
confirms that it is talking to another UUCP package which understands
the package sizing protocol (mine is the only one right now, of
course) by sending a -N switch with the Sfoo command sent by the
master. If the slave understands it, it responds with ROKN rather
than merely ROK.
When sending a file to a UUCP which understands sizes, a ninth field
is added to the send command to hold the size. If the notify string
is empty, it is sent as "". If the file is too large to send at the
moment, the slave will respond with RN6. If the file is too large to
ever send, the slave will respond with RN7 (my package does not
currently generate RN7).
When requesting a file from a UUCP which understands sizes, a sixth
field is added to the receive which is the maximum size file we are
prepared to receive. If the file is larger than that, or the file is
larger than the slave is prepared to send, the slave will respond with
RN6. The RN6 will be optionally followed by the actual size of the
file, which will allow the master to determine whether it will ever be
able to receive the file (my package does not currently send the file
size with the RN6). If the file is too large for the slave to ever
send, the slave will respond with RN7 (my package does not currently
generate RN7).
My configuration file allows you to specify the maximum file size that
may be transferred based on what time it is, which system placed the
call, and which system is making the request.
Ian Lance Taylor
>In article <56...@melon11.UUCP>, gu...@motcid.UUCP (Gregory Gulik) writes:
>> In article <29...@airs.com> i...@airs.com (Ian Lance Taylor) writes:
>>>
>>>Nevertheless, I still think that 'g' is out of date. I didn't suggest
>>>that the 't' protocol should replace it. There should be protocols
>>>that work more like the 'f' protocol, with a checksum over entire
>>>files and much less communication from the recipient to the sender.
>Funny you should mention 'f' in that context. With 'f' you still have
>acks for every packet. They're simply being generated by your X.25 network
>and absorbed by your X.25 software; you never see them -- but they're still
>there.
You don't have to run 'f' only over X.25. It works fine over modems.
Your point is still correct: when using the 'f' protocol over a
reliable modem connection, the acks are being generated by hardware in
the modems. This is more efficient than generating them in software.
>Sorry, but unless you have an absolutely reliable data link underneath uucp --
>which is the case with 'f' over X.25, which is its intended use -- you really
>need to ack more frequently than once per file. You really do not want to
>have to send a whole file over again if it's wrong.
No, you don't, but with a reliable modem connection the file will very
rarely be wrong. And with a modem that drops the line when the
carrier is lost and a system that recognizes a dropped line, you won't
wind up sending an entire file into empty space because if the modems
lost contact the port will be closed. I know that not all systems
will do this, but an increasing number will.
>Let's not throw out the baby (a proven protocol, supported by uucps everywhere,
>and also supported by the vast installed base of Telebit modems) with the
>bathwater (inability to extend the window and packet size beyond the typical
>3/64, in most implementations).
Note that 'g' is supported by uucps everywhere at a packet size of 64
bytes and a window of 3 packets. Similarly, it is supported by
Telebit at a packet size of 64 bytes and a window of 3 packets. I
will grant that it is a proven protocol.
I am still far from convinced that the 'g' protocol is the way to go
when using reliable modems.
In particular, the 'g' checksum is just too hard to compute for no
apparent gain. It does three unnecessary operations on each byte.
Does anybody know a theoretical reason for this? It still succumbs to
single bit errors.
Warren Burstein
ability to continue from where you left off if the link drops in the
middle of a file. Of course this would be more than just changing the
transport protocol...
--
/|/-\/-\ The entire world Jerusalem
|__/__/_/ is a very strange carrot
|warren@ But the farmer
/ itex.jct.ac.il is not worried at all.
j...@cmkrnl.com
> j...@cmkrnl.com writes:
> I am still far from convinced that the 'g' protocol is the way to go
> when using reliable modems.
If you are using reliable modems PLUS a reliable link between modem and
computer, then you can get away with things like 'f'. I know that the
modem-to-computer link is not going to corrupt data very often, but dropped
data (due to overruns) is a problem... and the faster your modems go, the more
of a problem it is. Hardware flow control (RTR/CTS) is only a partial answer,
and a lot of computers don't support it yet anyway.
> In particular, the 'g' checksum is just too hard to compute for no
> apparent gain. It does three unnecessary operations on each byte.
> Does anybody know a theoretical reason for this? It still succumbs to
> single bit errors.
On a piddly little MicroVAX II, chksum() takes 1.15 milliseconds for a
64-byte packet. That same packet will take about 50 milliseconds to move
out the door at 1400 char/sec, the maximum speed typically seen on PEP links.
From these figures, it is hard to say that the checksum calculation is a
significant burden on the host CPU... even if we were running full-duplex
and doing twice as many checksums. It will be some time before modem
technology advances to the point where the checksum calculation is much of
a burden... and that's with a uVAX II; most of us are running CPUs that are
at least several times faster. And the CPUs will continue to get faster as
well.
But if you insist, try recoding chksum() in your local assembly language.
I got it to run twice as fast that way, mostly because the C compiler didn't
recognize the end-around-rotate-word for what it was.
As for not detecting single-bit errors, that's fine. Obviously, any checksum
algorithm will fail for certain types of errors, unless it sends as many check
bits as there were data bits!
But we don't really care if we detect single-bit errors, because single-bit
errors are *extremely* rare in the serial data comm environment:
o In simple FSK modulation schemes, it's a rare burst of line noise
that only lasts as long as a single bit.
o In multibit modulation schemes (more than one bit per second per
baud), it's impossible for an error to affect only one bit! And it's
still rare for an error to last only as long as one set of bits.
Consider the 2400 bps scheme, wherein four bits are sent at once via a
combination of amplitude and phase modulation. (If I remember right,
there are twelve possible phases, and for four of them, two different
amplitudes; total, 16 possibilities.) Here, even if a burst
of line noise is so short that it affects only one of the four-bit
signals (1/600 sec. or less), it *must* affect four bits at once. Of
course it is possible that the effect will be to change it from, say,
0001 to 0000.... but it is far more likely that multiple bits will be
changed. And it is still more likely that line noise will affect
more than one set of four bits.
Of course we could go to CRC-16... but if you think that g's checksum is tough
to calculate... whew!