? Kermit - A Protocol for Painless Micro... Transfer ' ...

?   Kermit - A Protocol for Painless Micro... Transfer         ' ...
Kermit - A Protocol for Painless Micro and Mini File
Brian Nelson )
Computer Services +
University of Toledo *
2801 West Bancroft*
Toledo, Ohio
Abstract B This article will describe the Kermit file
transfer protocol.B This protocol allows many (if not most) types of
computer systemsB to effect, at minimum, error free file transfer with
other systems+ and microcomputers over asynchronous lines.
Introduction B With the widespread use of personal computers the need
for fileB exchange between systems has become of foremost concern
amongB users and managers alike.
There are many commercial
productsB available which meet this need, some of which may offer
moreB advanced functions such as transparent record oriented
fileB access.
Networks that do this, such as DECnet, can be
expensive,B and if your computer or microcomputer is not on the network
yourB needs won't be met. Transfer of files with removable disks
canB work, but generally only when the computers are of the same
type,B it's not very useful when the systems are removed in
location.B Rarely will a larger mini or supermini be able to
read a microcomputer's disk.
B A more realistic approach, from both
cost and convenience, is toB find a way to use ordinary
telecommunications and/or in-house PBXB systems to connect computers and
microcomputers together.
If aB local connection using a PBX or front
end switch is not available,B there is always dialup access with standard
103/212 modems.
DataB can be transferred with very simple methods, such
as TYPING a fileB on one system and capturing it on the other system, but
this givesB no protection from noise and overrun of data. It is not very
userB friendly either.
What is really needed is a protocol
to2 accomplish file transfer reliably and efficiently. B The first
obvious use of any program or protocol designed toB accomplish
file transfer is to be able to provide the ability toB support file
uploads and downloads from minis and superminis suchB as the VAX and
PDP-11 to remote personal computers, such as the PCB and Rainbow.
should also be widely available for manyB different micros and
File transfer from micro toB micro, as well as from a
larger central host, should be possible.B The command interface
should be easy to learn, and require noB intervention from a central
site operator or other user. The many
B implementations of Kermit follow these lines, and all
versionsB allow some form of transfer in either direction.
advancedB versions, such as those found on the PDP-11, DEC10/20 and
VAX,B offer what is known as server operation, which allow the
remoteB (connected) Kermit system to completely control the file
exchangesB from their system. Since as of this writing (October 9,
1985)B there are available over 160 versions of Kermit available
forB numerous micro, mini and
Kermitaddresses this need quite well.
B While the primary use of Kermit will
likely be to support fileB transfer
from microcomputer to
mini/supermini and mainframeB connections, there are many uses for
Kermit for connections fromB mini to mini and so on.
The author
routinely use Kermit forB transfering software developed for the PRO/350
on a RSTS/E 11/23+B and a VAX 11/785, as well as using the PDP and VAX
for dialing outB to other systems around the country (not to mention
VAX to PDP+ directly though a front end port selector).
The Kermit
B The Kermit protocol is designed
normalB asynchronous
data and commands
areB transferred with a packet oriented protocol, basically
consistingB of a start of packet character (normally SOH), followed by
length,B control, data and checksum fields. Communication is half
duplex,B in that for every packet sent, the sender must wait for either
anB acknowledgement packet (ACK) or a negative acknowledgement
packetB (NAK).
Transmission is in ascii, with no requirements for
theB transmission of eight bit characters or control characters
otherB than control-A for marking the start of a packet. All
'control'B characters imbedded in the data are prefixed to convert them
toB printable characters, the same applying to eight bit characters
ifB required by the characteristics of the line. Since there are
manyB different implementations of Kermit, the protocol provides
aB mechanism by which the capabilities of two connected Kermits canB be
negotiated to allow for differences in the level of protocolB support.
Examples of protocol features that not all KermitsB understand
compression and transfer of file
The packet format is
[email protected]
| MARK | char(LEN) | char(SEQ) |
| CHECK |@
B where all fields consist of ASCII
characters, and the charB function converts a number in the range 094 (10) to a printableB ASCII character by adding 32 (10). The MARK,
LEN, SEQ and TYPEB fields are one byte, the DATA field is variable
in size, and the* CHECK field is one to three bytes in size.B The MARK
(normally control A) signifies the start of a packet.
B The length field tells how long the rest of the packet is.
TheB SEQ field is used to insure synchronization used to detect lost
orB duplicate packets.
The SEQ number wraps around every 64
packetsB due to the need to encode it as a printable ascii character in
theB range 32 (10) to 126 (10). The TYPE field specifies whether
theB packet is a DATA or CONTROL packet. The DATA section is used
forB the actual transfer of data or informative messages from a
KermitB server, this field can be up to 90 characters in length.
AnyB character whose low seven bits fall in the range of 0 to 37
(8),B ie, char and 177 (8) is less than 40 (8), will have the value
100B (8) exclusive or'ed (xor'ed) with itself and be prefixed by
aB shift character, '#'. Other shift characters may be use for
eightB bit characters if the line characteristics require such.
DataB compression may also occur in the data field, this is done
withB yet another shift code and byte count sequence. The CHECK
fieldB is a checksum, either a one character, two character or
threeB character CRC check; the sender computes it and the receiver
mustB compute it and compare. A checksum mismatch will result in
theB receiver sending a NAK packet (negative acknowledgment)
whichB directs the sender to resend the NAK'ed packet. The packet may
beB following by a terminator (likely an ascii 13). This
terminatorB is NOT part of the protocol and is sent only to tell the
receiverB that a 'line' is present. Not all Kermit implementations
requireB this; all Kermits will discard data outside of a packet in
any event. B Error detection and recovery is by checksum, as noted,
and byB packet read timeouts.
If the packet should be corrupted
theB checksum will be incorrect, the receiver will NAK the packet.
IfB an expected packet never arrives within the timeout period, or
ifB the received packet is not the expected one (as determined by
theB SEQ field) the packet will also be NAK'ed. There are limits as
toB how many times an expected packet will be NAK'ed without
aborting the current operation.
Packet types
[email protected]
(ACK), text may be in DATA field.
Acknowledgement (NAK))
Send initiate (Send-Init)
Receive Initiate0
Break (EOT, end of
File name header6
End of
file (EOF, end of current file)?
Error packet, text may
be present in DATA field
Generic SERVER command. The
first character in the C
data field will be a command to
a server, arguments *
may follow that character. =
Login, user and password follow in data field 9
change working or default directory. "
Bye, Logout
Finish, Exit server, but do not log out
Erase, delete files on server system
Directory query &
Disk space usage queryT
Type a file onto local kermit /
Rename file(s) on server
system K
Copy file(s) on server system <
Who's logged in, as in sho sys, sy/s, dev tt1
Send a
terminal message to a user A
Help, the server responds
with commands it can do #
Server status query &
Program, run a program
Journal 0
Variable, alter a Kermit setting A
Execute host command.
The host command follows in
the data field.
B Note
that some of the generic server commands, as well as the CB packet,
may not be feasible for a given environment.
ForB instance, the
REMOTE LOGIN command, which sends the generic IB command to the
server, can only be done under RSTS/E; the genericB U command (disk
space) is meaningless under RSX unless one wantsB the free space on
the entire volume. No Kermit server will abortB on receiving a packet it
can't execute, it will simply send anB error packet with an
informative message saying it can't process the requested
A typical transaction
B An example of a Kermit-11
kermit telling a VMS Kermit-32 server to? expect a file follows. The
Kermit-11 command was SEND JUNK.TST
(0)PDP sends:
^A. S~*
@-#Y3~( , '
(0)VAX sends:
^A, Yp/ @-#Y3~! (
(1)VAX sends:
^A%!Y,\[email protected]
(2)PDP sends:
^A`"D$ set ter/vt100#M#J$ xcc :== ccl cc3
#M#J$ xas :== ccl as#M#J!4S
(2)VAX sends:
(3)PDP sends:
(3)VAX sends:
(4)PDP sends:
(4)VAX sends:
^A%$Y+&1 B In packet
zero, the Kermit's exchanged information regarding theirB capabilities.
The PDP-11 sent an 'S' packet with the data for itsB maximum packet
length, default time out, number of pad charactersB to follow a
packet (none, hence the space), use a null forB padding, end of line
terminator (a CR + 32), the prefix characterB for control characters, a
'YES' to say the it can prefix eight bitB characters with the default,
that it would like to use CRC blockB checks, that it will use a
tilde for data compression, and theB 'CAPAS' mask, which here says
that it can process attributeB packets (discussed later). Since the
VAX also sends a '3' for the
B checksum type, they will both switch to CRC checks on
theB following packets. In packet 1, the PDP11 sends the filename
theB VAX should use for the file it creates. The VAX then sends
theB acknowledgement.
In packet three, the PDP sends the first
(andB only for this file) packet of data. Note that the sequence
#M#JB is a carriage return/line feed sequence with 100 (8) xored
intoB each character. The '#' character informs the other Kermit
thatB it must xor the next character with 100 (8). In packet three
theB PDP11 sends an EOF packet, the VAX acks it. In packet four,
theB PDP sends a break packet which tell the VAX that no more files
(ofB a possibly wildcard group) are coming and the VAX Kermit acks
theB break packet.
Both Kermits now switch to the single
character9 checksum and the VMS kermit enters the server idle
B More specific information regarding Kermit packets and
stateB transitions can be found in the references listed at the end of
the article.
Transmission of file attributes
B One of the
optional features of the Kermit protocol is theB ATTRIBUTE packet.
The attribute packets allow a Kermit program toB send to a receiving
Kermit information regarding the
fileB organization, size,
cluster/retrieval size, protection and soB forth. There is even a
system dependant attribute packet typeB that can be used to
transfer things like the RMS11 IFAB (theB RMS/FCS attributes). Since
to date only the author's KermitB implementation, Kermit-11, can
process attribute packets, the$ discussion is limited to the PDP11. B One of the things that two Kermits exchange before any
fileB transfer is an information packet, this packet tells the
receivingB Kermit about itself. The last field in this packet, the
CAPASB mask, tells Kermit if the other one can process attribute
packets.B If two Kermit-11's are communicating, they will find that each
canB do so, and the sender of a file will then send over
attributeB packets indicating the need (or lack of) for binary
transmission,B based on the file organization, filetype and protection
code (forB RSTS/E). If the sending Kermit-11 is running on RSTS/E,
RSX11M/M+B or P/OS it will also send a copy of the RMS/FCS attributes so
theB received file will be identical (to FCS and/or RMS) to the copy
onB the sender's system.
Since other implementations of Kermit
mayB use this special system attribute packet, Kermit-11 always
sendsB an attribute packet telling the receiver what hardware
andB operating system it is running on, and thus will only use
suchB data if they are compatible. Of course, there will be times
whenB a file may be binary and Kermit-11 can't tell so, many
Kermit'sB have a SET FILE BINARY and SET FILE ASCII to allow the user
toB override defaults. Kermit-11 also has a SET FILE AUTO/NOAUTO
to; disable it from trying to determine a file's binary status.
# The
PDP-11 Kermit-11 implementation
B The author's version of Kermit-11 is
written in Macro-11 and can
B run on RSTS/E, RSX11M, RSX11M Plus, P/OS, RT11 and TSX+.
ThisB version of Kermit is distinct from the other three PDP-11
KermitsB available; the Stevens P/OS menu driven Kermit; the University
ofB Toronto RT11 pascal Kermit and Bob Denny's P/OS Kermit.
InB Kermit-11, the RSTS and RSX file system interface is via
RMS11B version 2, while the RT11 interface attempts to emulate the
RMS11B subsystem. The choice of Macro-11 for the implementation
languageB was made for several reasons, one being the availability of
theB assembler on all systems and another being speed and compactness
of the code.B RMS11 was used for RSTS/E and the RSX11M based systems to
provideB a common i/o interface to the host file system. Additionally,
BobB Denny of Alisa Systems further extended the RMS interface
toB support remote file access over DECNET with Kermit,
allowingB commands such as SEND NODENAME::[BRIAN.FUBAR]FILE.TYPE and
otherB remote file accesses over DECNET. RMS11 version 2 also provides
aB very simple and powerful means of doing wildcard searching,
fileB renames and file deletion via the $PARSE, $SEARCH, $RENAME
andB $DELETE macros; it also allows the same RMS interface code to
beB used on all systems without change. Points against RMS
basicallyB amount to it's size, RMS is quite large even if overlayed.
ThisB is helped by using the segmented RMSRES available on RSTS/E
andB RSX11M Plus. The one over negative point is that RMS11 version
2B does not function well, if at all, on the older versions of PDP11B operating systems, specifically, one should be using RSTS/E v8
orB later, RSX11M v4.1 or later, and RSX11M Plus version 2.1 or
later. B All versions of Kermit-11 receive eight bit data assuming
noB parity is used.
Where parity is a must, Kermit-11 has to use
aB prefixing scheme for eight bit binary data.
Binary files
areB created as FIXED no carriage control files such as used for
taskB images. Note that parity generation is done by software
inB Kermit-11.
The P/OS version of Kermit-11 runs under control
ofB DCL. The next release of Kermit-11, which will be 2.37,
willB include support for the PRO TMS (Telephone Management
System)B option. Each version of Kermit-11 has it's own source file
toB deal with the operating system, for RSX it is K11M41.MAC,
forB RSTS/E they are K11E80.MAC and K1180S.MAC, and for RT11 they
areB called K11RT*.MAC.
Apart from these specific files, all
otherB source files are shared. The RT11 Kermit-11 can use either
theB version 5.x XL and XC handler for high throughput, or it can
useB multiple terminal service to do all its terminal i/o. This
secondB option allows the use of any interface supported, including
theB PDT150 modem port, DL/DLV11's and DZ/DZV11's.
TSX+ users
canB connect to CL: for dialing out, the exact means is documented
in the Kermit-11 users guide.
Future directions
B With the advent
of packet switched networks and
satelliteB communications the
Kermit protocol will likely be extended toB increase efficiency over
such links. The main problem is the halfB duplex nature of Kermit, the
packet acknowledgements can take upB to several seconds in transit
thus drastically reducing theB throughput.
There are several
possibilities under discussion and
' a standard should be appearing shortly.o
Summaryn B With the
knowledge that there are Kermit implementations for mostB personal
computers in use it becomes apparent that the KermitB standard is
well worth looking in to. A list of versions running( on Digital
hardware follows the article.
2 Kermit: A File-transfer Protocol for
Frank da Cruz and Bill Catchings BYTE Magazine, June/July
1984u % The Kermit Protocol Manual, version 5n Frank da Cruz
19843 Columbia University Center for Computing Activitiesa
on obtaining Kermit:
KERMIT Distribution 4 Columbia University Center
for Computing Activities
7th Floor, Watson Laboratory 612 West 115th
Streetn New York, N.Y. 10025s = Kermit is also usually found on the
Decus symposia SIG tapes.a2 Kermit-11 is available from DECUS as number
11-731 8 Digital hardware that Kermit is currently available for: &
Operating Program
4 Machine
2 DEC PDP-11
U of Toledo4 DEC PDP-11
U of Toledo4 DEC PDP-11
RSX-11/M+ Macro-11
U of Toledo4 DEC PDP-11
U of Toledo5 DEC
OMSI Pascal U of Toronto 4 DEC PDP-11
U of Toledo3 DEC PDP-11
Unix 2xBSD C
Columbia Ue3 DEC PDP-11, ... Unix V7
Columbia Ur1 DEC
R. Hippei5 DEC Pro-3xx
Bliss, Macro Stevens I.T. 4 DEC Pro-3xx
U of
Toledo4 DEC Pro-3xx
U of Toledo3 DEC Pro-3xx
Venix V1
Columbia Un3 DEC Pro-3xx
Venix V2
Columbia U23 DEC Rainbow
Columbia UX3 DEC
Columbia U 4 DEC Rainbow
Merrell-Dow3 DEC VAX
Ultrix-32 C
Columbia U 5 DEC VAX
Bliss,Macro Stevens I.T.
C (VAX-11 C) Columbia Uo5 DEC VAX
U of Toronto,3 DEC VAX, ...
Unix 4xBSD C
Columbia Ud4 DEC VT-180 Robin CPM80
Turbo Pascal Jeff Duncan, DEC
VT-180 Robin CPM80 2.2 M80,LASM
CPM80 2.2
ACC5 DECsystem-10
Bliss, Macro Stevens I.T.
Columbia U
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF