Kermit — simple PC communications

Kermit - Simple PC C o m m u n i c a t i o n s

341

Alan PHILLIPS and Doug S H E P H E R D

Department of Computing, University of Lancaster, Bailrigg, Lancaster, LA1 4YR, U.K.

The paper presents a high-level overview of the popular Kermit file transfer protocol, available on almost all micros and mainframe systems. It describes what Kermit can offer users; the conditions under which it can be used; and briefly ex- amines the protocol itself. Finally details of how to obtain Kermit are given.

Keywor&.: Kermit, File transfer, Micro communications.

I. Introduction

Kermit is a protocol that permits the transfer of files between computer systems - whether micros, mainf rames or minis - along asynchronous con- nections. For the case of micro- to-mainf rame

transfers, this would normal ly mean along terminal lines.

The system was devised by F r a nk da Cruz and

Bill Catchings at Columbia Univers i ty in New York in 1981, and from its early days as an IBM

PC- to -DEC 20 link, it has grown so that now there are over 200 different m a c h i n e / o p e r a t i n g

system combina t ions that can use it. In the

academic sector it is already the de facto s tandard, and commercial use of it is rapidly growing.

In this paper we shall present an overview of Kermit , looking at the assumpt ions it makes, the na ture of the protocol and the sort of facilities it offers users.

The most frequent quest ion on Kermi t is " W h y is it called Kermit?" . Some main ta in that it is an ac ronym for " K L 1 0 Error-free Reciprocal Micro Interchange over Tl?Y-lines", and there are those who say it is an old Celtic word meaning "free". Just possibly, it 's a frog.

Alan Phillips is a communications pro- grammer in the Department of Com- puting at Lancaster University. For the past two years he has been running Lancaster University's Kermit distribution service, which makes the software available to the academic and commercial communities in the UK. He is the author of the Kermit implementation for the Acorn BBC micro- computer.

Doug Shepherd has been Professor and Head of the Department of Comput- ing at Lancaster University since 1983. His main research interests are in the areas of Distributed Computer Sys- tems and Communications. He has published over thirty papers in these areas and is co-editor of Local Area Networks: An Advanced Course, which is published in the Springer Verlag Notes on Computer Science service.

North-Holland Computer Standards & Interfaces 6 (1987) 341-346

2. What Kermit offers users

To begin with, we can summarise what Kermi t can actually do for users. It lets them move files f rom any machine which has a Kermi t implementa t ion runn ing on it, to any other machine of any type with its own Kermi t implementa t ion , provided that the machines are jo ined by an asynchronous l ink of some sort.

The protocol has been designed so that any Kermi t implementa t ion can work with any other - if the two have differing degrees of sophist icat ion they will use the lowest c o m m o n denomina to r of facilities available. Only a minu te n u m b e r of Kermi t implementa t ions (most no tab ly the ICL 2900 V M E / B version) have unusua l requirements that the other Kermits cannot always meet.

Once the machines are hnked, file transfer is extremely simple to accomplish. Kermi t can han-

0920-5489/87/$3.50 © 1987, Elsevier Science Publishers B.V. (North-Holland)

342 A. Phillips, D. Shepherd / Kermit - Simple PC Communications

die text files or binary files, and the protocol does not care what the data actually is. It will encode bytes where necessary, and do this automatically.

If text files are being transferred (meaning here files that have some sort of record structure that the user wants to keep) the Kermit protocol will handle any disparity in the way end-of-record is indicated between the systems. The common situation with dumb transfer of having extra line- feeds scattered through the file, for example, will not arise using Kermit. The rule the protocol uses is that if the file can be handled with normal utilities on one system, it can be handled by normal utilities when it gets to the other one too.

Kermit also moves the exact amount of data in the file, rather than rounding up to block boundaries as some other protocols are apt to do. This can be helpful when moving binary files - but, of course, the operating systems at each end may have their own ideas about how the data actually is stored.

The other very useful user feature is the ability to move files by wildcard groups - in its simplest form, a user can move all the files on a disc in one Kermit command.

3. The main advantages of choosing Kermit

For those choosing a file transfer system, the three main advantages of Kermit could well be that - It is already implemented on almost every mac-

hine that is in common use (and on several that are quite esoteric).

- The software is completely free. - It is the most widely used protocol and becom-

ing a standard.

characters will not be interfered with in transit from one Kermit program to the other. About the only time this will not be true is when the terminal controller in use decides to usurp a character (" @" for example) for its own use, so requiring it to be doubled to get it through. This will defeat most Kermits, although a few have the ability to tell the sending system what the controversial character is for it to do the doubling.

(Incidentally, Kermit is an ASCII-based protocol - EBCDIC machines must translate data to ASCII for transmission and from ASCII on recep- tion)

The second assumption is that one control character - usually CONTROL-A - can be made to pass unchanged from one Kermit to the other. Again this is almost always true, the most common exception being the V M E / B implementation, where CONTROL-A is about the only character that cannot be passed from one end to the other. The protocol defines how the control character used can be selected, but only a few Kermits implement this feature (one that does not is the CP/M-80 family, which means that currently CP/M-80 Kermits cannot talk to V M E / B Ker- mit). The IBM PC and BBC Kermit implementations, though, do allow the control character to be selected by the user.

The final assumption is that the communications system is not going to introduce characters of its own in the middle of Kermit data. The structure of the packets does allow characters to be interposed between packets (for example, the protocol is happy to have a CR at the end of a line from the micro side arrive as LF-CR at the mainframe), but this must not happen within the packets. If it does happen, the packet error check will fail.

4. The conditions Kermit expects

Kermit makes very few assumptions about the environment in which it is running - specifically, about the nature of the communications line it must use. These have been quite carefully chosen on the basis of the restrictions that mainframe communications links usually impose, and very few systems either do not comply with them or cannot be made to comply by suitable co-ercion.

Firstly, Kermit assumes that all printable ASCII

5. How Kermit appears to a user

Having looked at the environment needed to run Kermit, we can move on to see how it appears to the actual user of the system. Typically the user will be sitting at a micro linked somehow to a mainframe, and will want to move a file from micro to mainframe.

The initial phase is to actually log the micro in as a terminal. All Kermit implementations offer some sort of terminal emulation - this varies,

A. Phillips, D. Shepherd / Kermit - Simple PC Communications 343

obviously, from a simple dumb-teletype at one end right up to an almost totally-complete VT102 emulation in the latest IBM PC Kermit and a Tektronix 4010 emulation in the Sirius MS-DOS 2 implementation.

Whatever terminal emulation is provided, it will be enough to let the user log in and start the host Kermit program running, and issue the command to tell it a file is on the way. All he needs to type, typically is

RECEIVE

Now the user escapes from terminal mode on the micro, usually with the character sequence CONTROL-] and C, to Kermit command mode. To transfer a file, all he needs do is type the " S E N D " command and specify the file he wants to move - if he wants, he can specify a wildcarded name to move more than one file. The two Kermits will then talk Kermit protocol to each other until it's done.

For example, the command

SEND RESULTS.DAT

would transmit one file, and

SEND * .DAT

would move all files with type " .DAT". The sending Kermit program actually transmits

the name of the file it is sending in a "file header" packet. This name is usually sent in a "Kermi t normal form" as

name.type

with the actual name being manipulated if necessary. The receiving side will translate the normal form to whatever it wishes, so that in most cases the user can let the protocol work out any changes needed in the syntax of filenames between systems. Most implementations allow the user to over-ride the translations if he wishes, and most Kermits take avoiding action if the receiver gen- erates a name that matches that of an existing file.

Once the file is sent, the user can re-enter terminal mode, tell the mainframe Kermit to receive another file, and so on. He can go on doing this for as long as he wishes.

All Kermit implementations will allow this mode of operation. The more sophisticated ones (mostly on mainframes) offer a facility termed "Server Mode" which makes things even easier for the user, which we shall consider later.

6. Technical aspects of the protocol

We can look now at the more detailed aspects of the protocol to see how Kermit actually organises its data transfer.

Kermit is a packet oriented protocol, and each packet is organised to look like a normal sort of line typed at a terminal or output by a host. Every packet is preceded by a "start here" marker (usually CONTROL-A) and terminated by an end-of- line character, usually Carriage-Return.

The structure of each packet is quite simple: the data portion is preceded by a small packet header and followed by a checksum field. The header of each packet contains basic control information. It indicates the packet type (data of various types, ACK, NAK, file-header and so on), the packet sequence number, and the packet size. Each of these occupies one byte. The checksum field will be one or two bytes, depending on what technique is being used.

All Kermit packets follow this basic structure. A Kermit dialogue is a very simple interchange of packets: the sender transmits a packet of the type it wants, then waits to read a reply from the other end. The receiver looks at the transmitted packet, validates its header information, and replies with either a short ACK packet or a short N A K packet.

If the reply is ACK, the dialogue continues; if it's NAK, the sender will retransmit, up to a suitable retry limit. If at any stage the receiver wishes to abort the transfer (for example, the disc it is using might be full, or the sender has violated the protocol in some way) it can send an E R R O R packet instead of an ACK or N A K - this aborts the transfer, and also contains a text diagnostic message that the other side can show to the user.

That basic structure allows Kermit to move any sort of data. It has a set of rules for handling characters within that data, which are quite simple to implement.

Kermit tries to minimise the amount of data sent, so, following the assumptions we saw it make earlier, it sends all printable ASCII characters unchanged. Other characters are transformed by one of a small set of rules - - Binary fields in the packet header and check-

sum are made printable by adding 32 to them. (This, incidentally, gives the maximum size a packet can have as 94 bytes, as the highest printable ASCII character has code 126 = 94 + 32.)


- Control characters in file data are encoded into a two-byte sequence. The character itself is made printable by adding 64, and it is preceded by a "quote" character. Typically, a Carriage- Return character - which is C O N T R O L - M - in a file will transmit in a packet as the two bytes " # " and "M" .

- Any byte that has bit 7 set is also encoded into a two byte sequence. The byte itself is modified to lose bit 7, and is then preceded by a (different) quote character.

This technique is optional, and will be selected only if both Kermits implement it and the environment is such as to need it.

- Repeated characters can be encoded as 3-byte sequences - using a third quoting character - to save transmission time. Not all Kermits implement this, though.

7 . E r r o r c h e c k i n g

The Kermit protocol allows extensive error checking and recovery to be done, through the mechanism of the ACK and N A K replies. The various facilities the receiver has to detect errors are: - Each packet is preceded by a CONTROL-A

byte, allowing the receiver to ignore extraneous inter-packet bytes injected by the communications system.

- Packets contain a sequence number, in the range 0..63, which increments for each packet sent. The protocol rules are such that each side can detect lost packets, ignore repeated ones, or decide that the whole transfer has gone irre- coverably wrong.

- Each packet contains a byte indicating what its length ought to be, and this can be checked against the amount of data that actually arrives.

- Each packet is checksummed. The checksum can be one of three types, depending on the particular implementations in use. All implement the default, which is a straight 8-bit sum. Some allow this to be extended to a 16-bit sum, and a few implementations support a 16-bit CRC polynomial. In practice, the 8-bit sum is adequate for almost all types of link, and works well even on noisy phone lines.

8 . T h e s t a g e s o f a K e r m i t t r a n s f e r

The various optional features of the Kermit protocol are all selected automatically in the first, or negotiation, phase of a transfer.

The transfer begins with the sending system transmitting a setup packet, containing details of either its full capabilities or the subset of them the user has selected. Many facilities - such as " the quote character I 'm going to send you" are selected simply by one end declaring to the other what it will do. Others, such as the encoding of data with B7 set, are done on the basis of " I will if you will" - the sender requests use of the facility, and the o the r end either agrees or disagrees in its reply.

This phase of the protocol can be a little limit- ing - there is only one pass of negotiation, so the initiating side cannot make another suggestion if it does not like what the receiver sends back. In practice, though, it works very well.

Once the two sides have negotiated, the data transfer begins. This involves the sending of one file, possibly followed by others, and goes on until the side sending the data sends a "break transmission" packet to end the transfer. Any further transfers the user may wish to do then begin again at the negotiation phase.

9 . K e r m i t s e r v e r s

As we saw earlier, many mainframe and mini Kermits, and a few on the larger micro systems such as the IBM PC, now implement what is termed "server mode". This gives the user much easier control of a Kermit session.

The use of a non-server Kermit involves the user in escaping in and out of terminal mode on his micro, to give commands both to the mainframe Kermit and to the micro Kermit. Kermit server mode lets him control everything from the command mode of his micro Kermit, once the mainframe side has been started up.

The basic idea of the server is that the mainframe program sits waiting for input on the terminal line as usual: now, though, it is expecting to see Kermit protocol packets containing various commands.

The obvious commands are those for " I ' m sending you a file" and " I want to pull a file from you". All micro Kermits can issue the first of

A. Phillips, D. Shepherd / Kermit - Simple PC Communications 345

these, as the protocol uses the same packet type as in the non-server case, and almost all can issue the second packet type with their " G E T " command.

Server mode, though, gives much more. Many micro Kermits now implement the " R E M O T E " command, which allows server commands to be passed to the mainframe system. There are server commands to list directories to the micro screen; change directory, delete files, type them on the screen; issue host operating system commands - a Kermit server makes life extremely simple for even an inexperienced user.

As an example, the user on a micro Kermit might type the command

R E M O T E TYPE RESULTS.DAT

to display a file from the mainframe to his screen (the output uses the full Kermit protocol, so is error-free). He might then fetch it to his micro disc with

G E T RESULTS.DAT

then delete it from the mainframe filestore with

R E M O T E DELETE RESULTS.DAT

10. Recent protocol extens ions

Recently, the protocol has undergone some revision and extension (the latest definition is now edition 6) to cope with performance aspects. Kermit makes low utilisation of lines due to the need to wait for A C K packets, and where the link is a complex set of network hops performance can be bad.

The first extension is for " long packets". As we have seen, each packet carries a length byte in its header: due to the need to encode the value as a printable character this limits the packet size to 94 bytes. The " long packet" extension defines a packet header enhancement, in which lengths of up to 9000 bytes can be indicated. On very good lines, where there are no transmission problems (and where the receiving system can put up enough buffer space) this lets data travel in long, fast bursts.

The second extension is termed "sliding windows". This operates much like windows in the X25 sense - the sending system can continue sending packets without waiting for an ACK, and can have up to 31 ACKs outstanding. This reduces

the idle period between packets and improves performance over network hops.

At the moment, though, only a tiny number of Kermits implement these extensions - specifically the latest Prime Kermit and PDP-11 Kermit.

11. A summary of the good things about Kermit

To summarise the good things about Kermit on the more technical side - - It is implemented on about any machine availa-

ble, and is appearing in more and more commercial packages.

- It is being actively developed, with new implementations coming almost every week, and there is a vast base of experience in its use.

- All versions are available as source and can be customised to the user's exact needs or tailored to meet any special circumstances.

- The protocol is strictly defined, is administered centrally at Columbia, and is fully published.

On the user's side, the main good points are that: - It transfers files usably, resolving end-of-record

handling differences - It can transfer files by wildcard group - Mainframe and some micro systems implement

server mode - The amount of data sent down the line is

minimised. What is often the best point of all about Kermit

is that it is centrally distributed by Columbia and Lancaster, so that there is no need to spend weeks trying to find a source of supply for any specific version that might be required.

12. Getting hold of Kermit

There are several sources for getting hold of Kermit. The world centre for Kermit is Columbia University in New York. They can supply tapes in several formats, and files can be pulled from there by anonymous FTP on Arpanet.

In the UK, and for anyone who can access JANET, it is easier to get files from the Lancaster distribution machine. Lancaster has a complete set of files which is kept up-to-date with Columbia and can supply these on tape, or (for a few micro systems) on disc. Alternatively the files can be pulled from the Lancaster machine with Blue Book


FTP, or can be picked up by logging in and using Kermit. These facilities are available 24 hours a day, 7 days a week, and no prior arrangement is needed.

Lancaster and Columbia both publish news- letters on electronic mail. The Columbia news-

letter is held online at Lancaster; to get regular copies of the Lancaster one mail a request to

[email protected]

on JANET. We are able to send it to any machine registered in the NRS or accessible over PSS/IPSS.

Documents

Kermit — simple PC communications