KERMIT - Error Free File Transfers with Non-Alpha Computers
by Bob Rubendunst, Soft Machines
If you have ever needed to transfer files between your Alpha
Micro and some other brand of computer, you know that file
transfers between unlike brands of computers are NOT easy.
Most communications packages, like my DYALOG product, provide a
way to send and receive information with other brands of
computers. However, because the non-Alpha equipment probably
does not support the same file transfer protocol, the file
transfer can be spoiled by telephone line noise, particularly
on longer distance link-ups.
A file transfer protocol is a process with its only goal
being the sure communication of information from one point to
another. Just as different programmers can write different
programs to solve the same problem, different protocols can
both communicate the same information, but in entirely
different formats.
There are many reasons why file transfer protocols are
different between brands of computers and even for products
that run on the same machine. Standards in the computer
industry have been slow to develop because of the speed at
which the computer market moves. Telecommunications is
exploding as people find new, slick solutions to old and new
problems. Both software and hardware vendors frequently exhibit
the "NOT INVENTED HERE" philosophy of "Well, if we didn't
do it, it must not be any good". It takes much more time
and many more resources to develop a file transfer protocol
than to just market the program that uses it. Also, writing a
proprietary product locks in a vendor's customer base. All of
these things have stifled the development of a standard.
One standard that did develop was the XMODEM protocol in the
CP/M computer field. It was developed by Ward Christensen of
the famous Chicago area Computer Bulletin Board System. While
XMODEM worked fine for CP/M systems, it was not well suited to
other kinds of computers, and it was not defined well enough to
guarantee compatibility between different implementations of
XMODEM.
This summer, I discovered KERMIT through a conversation with a
client. KERMIT is a universal protocol that was developed at
Columbia University to allow the various micro computers at
Columbia to trade files with their big mainframe computers.
Bill Catchings and Frank da Cruz of Columbia developed this
protocol in 1981, with the help of other colleagues at Columbia
and other research facilities. Columbia has been nurturing it
since that time.
KERMIT is named after the famous reporter, Kermit the
Frog, on the MUPPET SHOW. The name Kermit is used by permission
of Henson Associates., Inc.
At the beginning of a file transfer, the local and remote
KERMITs tell each other what they expect and can handle in the
way of communications. This enables KERMITs to communicate with
a wide variety of computers.
KERMIT is a great protocol because it is very flexible and well
structured. Even the manner in which improvements are added to
the protocol has been done in such a way that future versions of
KERMIT will be fully compatible with older versions. KERMIT is
a good concept beautifully executed.
KERMIT sends files from one computer to another by breaking
down the procedures and the data in the file into packets.
KERMIT sends packets one at a time, and then waits for the
remote KERMIT to acknowledge that it has correctly received a
procedure or data packet. The acknowledgement will only be sent
if a check field contained inside each packet is correct. In
this way, errors can be detected and packets can be re-sent
until the packets are transported without error from system to
system.
To make sure that as many people as possible should enjoy the
benefits of KERMIT, Columbia's policy on distributing KERMIT is
that KERMIT must not, and should never, become a commercial
product, sold for profit. Its goal is to promote communication
and sharing, and KERMIT itself should be freely shared, and not
sold.
I am donating KERMIT to AMUS. The donation will consist
of source code and documentation for Alpha-Kermit, which I have
developed from a C language version of KERMIT that I obtained
from Columbia this fall. I am giving all members of AMUS
permission to use KERMIT for free, provided that they follow
the non-profit guidelines that Columbia has established.
I will also give AMUS versions of KERMIT for IBM, DEC, Radio
Shack, CP/M and Apple computers that I obtained from Columbia.
I also invite YOU to add additional features to Alpha-KERMIT. I
would suggest that motivated individuals leave some
announcement of their plans on the AMUS bulletin board to
prevent unnecessary duplication of effort.
The reasons for donation are simple. There is a real need for a
universal file transfer method, so that information can be
shared. Being the lazy sort (aren't all programmers lazy?),
I'd rather write one program everybody in the AMUS community
could use instead of fifty. Also, it's a good way to say thank
you to all of the people in the AMUS community.
If you are puzzled as to why I am giving away KERMIT when I
sell DYALOG, I think that KERMIT will enhance the market by
generating more interest in telecommunications.
Here then, is a description of how to use all of the commands
that Alpha-KERMIT has.
How to Use Alpha-KERMIT
To use KERMIT, you must have a copy of KERMIT.LIT on your
DSK0:[1,4] account. (You may have to create this program file
by running the M68 program on KERMIT.M68.)
You must also be running AMOSL version 1.2 or later.
Currently, there is no version of Alpha-KERMIT
for the older WD-16 version of AMOS.
You must know the name of the TRMDEF you wish to use with
KERMIT. For example, the TRMDEF for your modem may be called
MODEM1.
Enter the KERMIT command, followed by the name of the TRMDEF
you wish to communicate with. For example:
KERMIT MODEM1
is the command line you would enter to communicate using the
MODEM1 TRMDEF on your system. If the TRMDEF you have chosen is
currently in use by another job, you will see this error
message:
?TRMDEF is assigned to another job.
If the TRMDEF is available for use, you will see the prompt:
Alpha-KERMIT >
which means that KERMIT is awaiting your next command.
Currently, the commands are:
AMOS - drop back to AMOS temporarily.
CONNECT - converse with the modem or remote computer.
EXIT - finish your Alpha-KERMIT session.
HELP - display helpful information.
RECEIVE - receive a file from the remote KERMIT.
SEND - send a file to the remote KERMIT.
SET - change a KERMIT parameter.
SHOW - display the parameters in use now.
Here is brief description of what each command does:
AMOS is used to temporarily leave KERMIT so that you can TYPE a
file, or get a directory listing. You must re-enter KERMIT to
end the communications session and free the communications
channel for other users. AMOS takes no arguments.
CONNECT is executed when you want to send and receive
characters between your CRT and the modem or the remote
computer. If you are using a "smart" modem, you can send the
modem the commands to dial the remote computer. When CONNECT is
executed, it shows you the key you need to press to end the
CONNECT session. When the CONNECT session ends, you may enter
another KERMIT command. CONNECT takes no arguments.
EXIT is the command you execute to end your KERMIT session.
This frees the communications TRMDEF so that others can use it.
EXIT takes no arguments.
RECEIVE is used to receive a file from a remote computer.
Before using the receive command, you must make sure that the
remote computer has executed the TRANSMIT command. If you are
operating KERMIT at the remote site, you must enter the
TRANSMIT command during a CONNECT session, then press the
ESCAPE key to enter the KERMIT command mode. You may then enter
the RECEIVE command. You may enter the name of the file as it
is to appear on your system. If you just enter RECEIVE, the
filename specified by the remote KERMIT will be used as the
filename.
SEND is used to send a file to a remote KERMIT. Before issuing
the SEND command, you must make sure that the remote KERMIT has
been given the RECEIVE command. (You do this by using the
CONNECT command, and then "escaping" back to the Kermit prompt.
SEND requires the name of the local file you wish to send to
the remote system.
SET is used to change options concerning the communications.
SET requires an argument, which consists of the name of the
option you want to change, followed by a logical operator. The
argument may be YES or NO, TRUE or FALSE, or 1 or 2, depending
on the option you are changing. If you are not sure of the
required logical operator for an option, enter SET, and the
option you wish to change, and the valid logical operators will
be displayed for you to choose from.
SET BELL ON dings the bell every time the KERMIT prompt is
displayed.
SET BINQUOTE allows you to change the binary quote character.
The binary quote character allows binary file transfers over
seven bit data lines. You must specify the new binary quote
character. Normally, KERMIT uses & as the binary quote
character.
SET BLOCKCHECK 1 sets KERMIT for 1 byte checksums, the default.
SET BLOCKCHECK 2 sets KERMIT for 2 byte checksums.
SET DEBUG ON
Turns on display of packet operation.
SET DEBUG OFF Suppresses packet operation display.
SET DUPLEX ON Allows full duplex operation.
SET DUPLEX OFF Allows half-duplex operation.
SET ENDLINE lets you change the default end of packet character
from carriage return to something else.
SET ESCAPE lets you change the character that you must press to
leave the CONNECT command. For example, SET ESCAPE ^G would
change the ESCAPE character to a control-G. This defaults to a
caret symbol.
SET RETRIES lets you change the number of packet retries
attempted before KERMIT aborts a file transfer. The default is
ten tries.
SET TIMEOUT changes the number of seconds that elapse before a
packet is re-transmitted.
SHOW displays all of the options that can be adjusted in
KERMIT, plus some additional parameters about the current
communications session.
For a more complete description of Alpha KERMIT, see the file
KERMIT.DOC on the AMUS computer. It has been adapted from
other KERMIT manuals from Columbia University.
So far, I have used Alpha KERMIT to communicate with IBM-PC
and Alpha Workstations. Thousands of medical records have been
moved to a new computer using KERMIT.
Here is a benchmark for comparing how quickly Alpha-KERMIT
can send files from one location to another. The file sent is
AMOSL.MON version 1.2(96), if you want to compare it to another
communications package. I have compared it to DYALOG here.
File: DSK0:AMOSL.MON[1,4] version 1.2(96)
Size: 27222 bytes, binary file
Baud rate: 2400 baud
Transfer times for AMOSL.MON[1,4]
DYALOG 2.0
: 126 seconds, effective baud rate of 2160
Alpha-KERMIT
: 263 seconds, effective baud rate of 1135
As you can see, KERMIT is not very fast. Nor can it send random
files. But KERMIT is fantastic for sending files to machines
previously untouchable.
I wish to thank Columbia University and the other people who
have donated KERMIT programs to Columbia. Thanks to Barry
Hamilton for reading the mag tape from Columbia.
Enjoy!
Glossary
JCB - Job Control Block. Used to access & control job related resources
TCB - Terminal control block. Used to access & control terminal resources
Kermit Packet Types
Type Name
Function
---- --------------------------------------------------------------S
Send-Init Sends local Kermit Parameters to remote Kermit
Y
Acknowledge Receiver verifies reception of packet
Y
(Acknowledge)
Returns Kermit parameters to instigating Kermit
F
File Header Contains name of file to be transferred
D
File Data Contains a portion of the data file contents
Z
End of File Signals receiver that all data file contents sent
B
Break
Signals receiver to conclude file transfer (batch)
N
Negative Ack.
Signal that receiver didn't get or like last
packet
E
Fatal Error Signal that other Kermit cannot proceed normally
ALPHA MICRO KERMIT
Program:
Language:
Documentation:
Version:
Date:
Bob Rubendunst (Soft Machines)
M68 (Alpha Micro 68000 assembler)
Karen Bojda (Soft Machines)
2.0(24)
March 16, 1994
Alpha-Kermit capabilities at a glance:
Local operation:
Yes
Remote operation:
Yes
Login scripts:
No
Transfer text files:
Yes
Transfer binary files:
Yes
Wildcard send:
Yes
File transfer interruption: No
Filename collision avoidance:
No
Can time out:
Yes
8th bit prefixing:
Yes
Repeat count prefixing:
No
Alternate block checks:
Yes
Terminal emulation:
Yes (Dumb or native terminal)
Communications settings:
Duplex
XON/XOFF:
No
Transmit BREAK:
No
IBM mainframe communications:
No
Transaction logging:
No
Session logging:
No
Debug Logging:
No
Packet logging:
No
Act as server:
No
Talk to server:
No
Advanced server functions:
No
Local file management:
Command/Init files:
Key redifinition/macros:
File attributes packets:
Command macros:
Raw file transmit:
Long packets:
Sliding windows:
No
No
No
No
No
No
No
No