info-kermit@ucbvax.ARPA (02/12/85)
From: Frank da Cruz <SY.FDC%CU20B@COLUMBIA.ARPA>
Info-Kermit Digest Mon, 11 Feb 1984 Volume 1 : Number 4
Departments:
ANNOUNCEMENTS -
Kermit for Alpha Micro 68000 Systems
New Release of Harris 800 Kermit
UNIX KERMIT -
Data compression for C-Kermit fans
System III Unix Kermit
Bugs in C-Kermit 4.0
MISCELLANY -
Kermit-MS in Color
Sacred Characters, Cont'd
----------------------------------------------------------------------
Date: Mon 11 Feb 85 16:43:17-EST
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Subject: Kermit for Alpha Micro 68000 Systems
To: Info-Kermit@CU20B.ARPA
This is to announce Kermit for Alpha Microsystems AM-1000, AM-100L, and
ELS super-micro computer systems, running AMOSL 1.2 or later, written
in Alpha Micro 68000 assembler, contributed by Bob Rubendunst of Soft
Machines, Champaign IL, and also contributed to the Alpha Micro User's
Society and to the on-line AMUS network in Boulder CO. The files are in
KER:AM*.* on CU20B, available via anonymous FTP.
------------------------------
Date: Mon 11 Feb 85 17:05:52-EST
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Subject: New Release of Harris 800 Kermit
To: Info-Kermit@CU20B.ARPA
This is to announce a new release of Harris 800 Kermit from Dave Wilson
at the University of Wisconsin Academic Computing Center. It's written in
Harris Pascal. For those Harris sites that do not have Pascal, a ready-
to-execute load module is available from the Harris User Exchange. Thanks
to Paul Stevens of MACC for sending it in. No mention was made of what
the differences are between this version and the first one (September 84).
The files are in KER:H800*.* on CU20B.
------------------------------
Date: Fri, 8 Feb 85 16:59:10 pst
From: James Woods <jaw@AMES-NAS.ARPA>
To: info-kermit@Berkeley
Subject: Data compression for C-Kermit fans
# "Shrivel up!" -- DEVO, from their American debut
Taking advantage of the Lempel-Ziv data compressor now making
the rounds on USENET/ARPANET, C-Kermit users may easily invoke the pair
compress file | kermit -is -
kermit -ik | uncompress
for faster file transfer. How much faster? Well, the code, which
runs wherever C compilers are sold, typically yields 50-60% reduction
for text, 65-80% for formatted ASCII numerical data, and good rates for
bitmaps. So, coupled with the fact that compress runs much faster
than typical modem rates (> 60K baud on a VAX 11/750), we have a tidy
savings, even after the 26.6% expansion induced by Kermit's "quoting"
of control characters. The rates are somewhat less (5-10%) for machines
limited to a 16-bit address space.
The Kermit designers should be commended for not designing
fancy data compression into the protocol itself. (This is tough to
do with short packets in any case.) Of course, the Tinkertoy nature
of UNIX pipelines is also indispensible for this clean separation
of function. Advise for non-UNIX Kermit users -- weep!
For a copy of the public domain compress code, contact Joe Orost at
vax135!petsd!joe@berkeley.
-- James A. Woods {ihnp4,hplabs}!ames!jaw (or jaw@amelia)
[Ed. - I agree, pipes are neat. The 26.6% figure is not a fixed overhead
of Kermit, by the way. Since 33/128 of the ASCII characters are
non-printable, the 26.6% control-character prefixing overhead will occur
only in files where all ASCII characters occur with equal frequency. In
fact, most text files have only about 5% control characters. Kermit's own
dumb data compression also pays off quite well sometimes -- most
dramatically in short binary program files, where lots of contiguous memory
is intialized to 0's.]
------------------------------
Date: Sun 10 Feb 85 23:46:41-PST
From: Herm Fischer <HFISCHER@USC-ECLB.ARPA>
Subject: System III Unix Kermit
To: SY.FDC@CU20B.ARPA
Frank,
ckmain: String length problems (134 & 1541). (512 max on Xenix)
[Ed. - I've received reports of various maximum string constant
or fprint argument sizes; the smallest so far is 128.]
ckwart(178): index used in OR (arithmetic) expression... uncool.
can only compare pointers to "NULL" for equality or lack thereof.
index is called strchr in System III versions.
[Ed. - Index will have to be defined inside wart, perhaps
renamed to avoid lawsuits...]
ckwart/main() lacks exit(0) which prevents System III make from
going onto next make step automatically. Add exit(0) call at end
of main().
[Ed. - Fixed.]
ckuser: obesely oversized... break apart... many strings too long...
[Ed. - Sigh... Let's only do this once.]
ckxbsd and ckzbsd now outfitted with conditional compilations for: system
III, bsd, Xenix, and PC/IX. I strongly support having only ONE set of
"unix" modules. Anyway, that is how I did the System III (and PC/IX and
Xenix 3.0 ) port. Am in final cleanup stages on it.
re uucp Line Locking, I have already found two different System III
versions which do it two different ways. Will compare your furnished
example code to mine.
Main problems are with ckuser right now: too large to handle with some
compilers! several strings too long too!
Herm
ps - am getting messages from Xenix users with OLD version 7 based
Tandy-distributed versions. It is highly doubtful that the C-Kermit for
Xenix 3.0/Sys III will be retrofittable to V.7 based Xenixes. That early
one was highly deficient in "unix-like" features...
------------------------------
Date: 9 February 1985 15:27-EST
From: Ed Schwalenberg <ED @ MIT-MC>
Subject: Bugs in C-Kermit 4.0
To: sy.fdc @ CU20B
I am attempting to bring up C-Kermit 4.0 under 68000 Xenix. So far, I've
encountered the following bugs:
1. ckxbsd.c function ttxin does a read(foo,bar,&count) instead of
read(foo,bar,count).
I don't see how this could ever have worked.
[Ed. - Me neither... It's fixed now.]
2. ckxbsd.c functions ttinl and ttinc declare int c; and int ch; respectively,
then do read(foo,&c,1), followed by c &= 0377. This doesn't work on
machines like the 68000 that have bytes in the opposite order from VAXen.
Declaring c (or ch) unsigned char fixes it, and obviates the need for the
masking instruction which follows (assuming 8-bit chars). The function
coninc does it right, though.
[Ed. - Thanks for pointing this out; it's fixed now.]
3. ckxbsd.c function ttflui has the comment "What's this???" which agrees
with the code, anyway. I see that you use one file descriptor for read
and write; this code seems to think that by specifying FREAD as the
argument to ioctl(TIOCFLUSH) you'll only flush input. I think it would
be lots more clear and portable to have separate read and write channels.
In any case, the Xenix documentation claims that the arg is ignored for
TIOCFLUSH.
[Ed. - 4.2BSD allows you to specify which queue's buffer to flush, read or
write. For now, I just changed to comment.]
4. "C-Kermit> dir /usr/ed" results in ?File not readable, which seems to be
deliberate. Is it? Why?
[Ed. - Not deliberate; cmifi() checks to see if the specified file is
readable, /usr/ed is a directory file, hence not readable. This will have
to be fixed. Meanwhile, use "dir /usr/ed/*" or replace cmifi() with cmfld().]
Other than that, it has gone very smoothly and well. Congratulations on
a fine piece of work, especially the TENEX-style command completion. (I
don't care for it as a user interface myself, but I'd much rather have ONE
user interface than 2 (or 3, or 4...).
[Ed. - Everybody wanted an interactive command parser, so I put in the one
I liked best. I tried to make it easy for others to substitute other parsers
to suit their tastes.]
So now it works for 68000 Xenix, though I want to attack it with prof(1) and
see if I can improve the performance (it loses packets over 2400 baud).
[Ed. - C-Kermit works fine on a VAX with 4.2BSD at 9600 baud, using
xon/xoff. It'll work even better when someone does a DMF32 driver that
will support DMA. If you don't have xon/xoff, then tweaking performance is
desirable so long as it doesn't interfere with portability.]
------------------------------
Date: Sun 10 Feb 85 00:53:26-PST
From: Jim Celoni S.J. <Celoni@SU-SCORE.ARPA>
Subject: Kermit-MS in color
To: Info-Kermit-Request@CU20B.ARPA
Minor glitch in MS-DOS Kermit 2.27: When on a color display with
foreground/background colors set, Kermit seems to ignore them and
always write to the screen white on black, and the grey + key
replaces the mode line with a black hole instead of writing
background-colored spaces. +j
[Ed. - Noted.]
------------------------------
Date: 8-Feb-85 20:26:40-PST
From: wunder@FORD-WDL1.ARPA
Subject: Sacred Characters
To: info-kermit@CU20B.ARPA
The "MMDF Dial-up Link Protocol" had a fairly complete mechanism for
handling sacred characters. I use past tense because I think that CSNET
is using MMDF II these days, and I have no information about that
protocol. Anyway, here is a quick description of the MMDF sacred
character (and packet length, and escape character) negotiation.
This description is based on an April 1980 document called "MMDF Dial Up
Link Protocol" by Ed Szurkowski. It is U. of Delaware report
ud-nsf-csnet-81-002. Parts of this message are taken almost straight
from that report, particularly the big diagram. This was the second
version of a carefully designed protocol, and I think that Kermit could
get some goodies here ("If you are going to steal, steal good.").
MMDF uses a limited character set for the negotiotiation: 0-9, A-F.
16-bit packet checksums are always sent as four hex digits. The packet
type is one hex digit, and the flags (Origin, EOF, and a two-bit sequence
number) are in one hex digit. MMDF can actually work over a link that
allows only hex digits, one escape character, and a way to send a delimited
record (like following the packet with a CR).
These are the packet types for the sacred characters (SC) negotiation:
XPATH SC's in my transmit path (and my xmit packet size)
XPATHACK acknowledge XPATH
RPATH SC's in my receive path (and my rcv packet size)
RPATHACK (guess)
ESCAPE I will use this escape character
ESCAPEACK (guess again)
An XPATH packet looks like this:
+-----+-----+-----+-----+-----+-----+-----+-----+-----+----//----+-----+
| Checksum | 2 |Flags|Max. Packet| Illegal Input Chars. |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+----//----+-----+
1 2 3 4 5 6 7 8 9 40
Max. Packet is two hex digits which are the longest packet that this
host can send.
Bytes 9 through 40 are 32 hex digits which are an encoding of the illegal
output characters for the host. The hex number is interpreted as a 128
bit vector (one bit for each ASCII character). If the bit is on (1) in
the vector, that charcter cannot be transmitted by the host.
An XPATHACK packet carries no data. It just acknowledges an XPATH packet.
The RPACK packet looks exactly like an XPATH. It describes the limitations
of a hosts receive path.
After a host has successfully sent an XPACK and an RPACK, and received
one of each from the other host, it chooses an escape character based on
all this great information. The ESCAPE packet contains the normal
header (checksum, type, and flags) and also has the chosen escape
character encoded as (you guessed it!) two hex digits. This is the
escape character that this host will use to transmit data. The other
host chooses its own escape character.
All illegal characters are sent escaped, either with special control
character forms (like <ESCCHAR>M for carriage return) or with the general
<ESCCHAR>## form, where ## is two hex digits corresponding to the ASCII
value of the character which has been escaped.
The protocol is used like this:
Host A Host B
---- - ---- -
<--- XPATH [Host B's xmit limitations]
XPATHACK --->
<--- RPATH [Host B's rcv limitations]
RPATHACK --->
XPATH ---> [Host A's xmit limitations]
<--- XPATHACK
RPATH ---> [Host A's rcv limitations]
<--- RPATHACK
<--- ESCAPE [Escape character that Host B will use]
ESCAPEACK--->
ESCAPE ---> [Escape character that Host A will use]
<--- ESCAPEACK
DATA --->
<--- DATAACK [repeat as necessary]
<--- DATA
DATAACK ---> [repeat as necessary]
QUIT --->
<--- QUITACK
I threw the DATA and QUIT stuff in there so that all this wouldn't
seem so pointless. DATA and QUIT are legal MMDF, of course.
This shouldn't be that hard to add as an attribute (or maybe a
capability bit) with some restructuring of the packet exchanges to keep
the strict packet-ack rhythm of Kermit. Since Kermit philosophy forbids
negotiations, the ESCAPE/ESCAPEACK might not fit in too well. The
ESCAPE/ESCAPEACK must be done somehow, though, because the normal Kermit
escape characters cannot escape arbitrary printing characters.
In my opinion, the MMDF escaping is much much cleaner than the Kermit
foobar-quoting approach, but compatability overrides elegance. Perhaps
the Hex-quoting would be a separate mode. Sort of a "low gear" for
weird communication paths.
walter underwood
[Ed. - This is undoubtedly a good approach. Too bad we didn't think of it
when we designed Kermit. Again, the problems are: (1) getting the code
into a significant subset of the Kermit implementations, and (2) educating
users about it. The second problem is the worst -- how does a "naive" user
know that if you are connected to Datex-P via a satellite link from Tymnet
gatewayed via X.25 from an Internet host accessed through a TAC dialed
through a (vendor-name-omitted) "smart" modem, ..., what the sacred
characters are? It's hard to tell whether the effort to handle bizarre
situations like this would be worth it. Maybe a good first step would be
to learn exactly what roadblocks people are actually running into where
an approach like this might help.]
------------------------------
End of Info-Kermit Digest
*************************
-------