Introduction
Kermit is the name of a file-transfer protocol and a suite of computer programs for many types of computers that implement that protocol as well as other communication functions ranging from terminal emulation to automation of communications tasks through a high-level cross-platform scripting language.
The software is transport-independent, operating over TCP/IP connections in traditional clear-text mode or secured by SSH, SSL/TLS, or Kerberos, as well as over serial-port connections, modems, and other communication methods.
Literature Review
History
At the height of the timesharing era at Columbia University, about 1980, our central computers began to suffer from a glut of files. Disk storage space was running out, and increasing numbers of students wanted to keep the computer files they accumulated over their academic careers. The problem could not be solved simply by buying more disks because, as somebody’s law states, ‘‘Usage will expand to consume all available resources2.’’ A more decentralized approach was called for. Given the means, those who cared about saving their files from term to term would take the trouble to do it themselves. The newly popular floppy-disk-based microcomputers fit the bill nicely. The diskettes were cheap, capacious, and easily carried and stored. But how could files be transferred reliably from the university’s central computers to the microcomputer floppies, and back? The problem took on a new dimension with the introduction of the IBM PC in 1981, which struck a powerful blow to centralized computing. As the new generation of personal computers began to rival the large central computers in several key application areas, PCs (not only IBM) began to appear in offices all over campus, and soon spread to the homes and dormitory rooms of faculty and students. The users of these PCs needed to communicate and share their work — professors and students, This is a corollary to Parkinson’s Law, which says that ‘‘Work expands so as to fill the time available for its completion.
The Kermit File Transfer Protocol researchers or authors in collaboration, administrators up and down the ‘‘chain of command.’’ Communication was required between PCs and the central systems, between PCs and other (possibly incompatible) PCs, and between our central systems and minicomputers in the academic departments. In short, everything had to ‘‘talk’’ to everything else. But how? Computer networks were not a practical alternative in 1981, and today they remain a costly one, even when you can find a network that provides the required connections. The only medium that all our computers had in common was the ‘‘communication port,’’ the place where a terminal or a ‘‘modem’’ is attached. The operation of the communication port is relatively well defined and standardized, but it is not an ideal medium for bulk transfers of data (for reasons that will be covered later). On the other hand, it is usually standard equipment; with appropriate software it can do the job for little or no additional hardware expense. Several communication software packages were on the market in 1980-81, but they were not available for all our systems. Even if they had been, the total cost would have been enormous when multiplied by the number of microcomputers, minicomputers, and mainframes we expected to arrive in the ensuing years. And even if the cost were bearable, it would not have been wise to depend upon a single commercial vendor for such an important function — the company could fail, or raise its prices suddenly, or decline to add support for some new system. Had we been aware of public domain communication protocols and programs, particularly MODEM3 and its derivatives, we might have been tempted to adapt them to our needs. But it turns out that MODEM would not have fulfilled one of our most basic requirements: IBM mainframe communication. Finally, for better or worse, we took the do-it-yourself approach. We invented a new protocol and called it Kermit, after Kermit the Frog, star of THE MUPPET SHOW .
As luck would have it, the few types of systems that our protocol initially had to support — DECSYSTEM-20 and IBM 370-Series mainframes, CP/M and MS-DOS microcomputers — exhibit among them nearly every imaginable quirk and idiosyncrasy of communication style and file organization, and our protocol was designed to encompass all of them. The result has turned out to be adaptable to almost every new situation; its flexibility accounts in large measure for its popularity. It must be said, however, that had we known Kermit would eventually spread all over the globe (and 3MODEM is more properly referred to as the Christensen protocol; MODEM, XMODEM, and so on, are names of programs that implement this protocol. The Kermit and Christensen protocols are compared in detail on page 314. 4Why? Mostly because there was a Muppets calendar on the wall when we were trying to think of a name, and Kermit is a pleasant, unassuming sort of character. But since we weren’t sure whether it was OK to name our protocol after this popular television and movie star, we pretended that KERMIT was an acronym; unfortunately, we could never find a good set of words to go with the letters, as readers of some of our early source code can attest. Later, Bill Catchings noticed while looking through a name book for his forthcoming baby that Kermit was a Celtic word for free, which is what all Kermit programs should be, and words to this effect replaced the strained acronyms in our source code (Bill’s baby turned out to be a girl, so he had to name her Becky
Kermit is one example of why it’s good to share software of general utility (two others are EMACS [28] and TEX [20]). If we had elected to keep it to ourselves, or to license and sell it, or to keep the source code or protocol specification secret, it would never have reached its current level of popularity. It would never have been written for so many different computers. It would not have improved and evolved through the continuous contribution of bug fixes and new versions, complaints and suggestions. It would never have threatened to become a ‘‘de facto standard.’’ If the spirit of the ’80s is ‘‘Don’t give away anything you can sell,’’ then Kermit must be a child of the ’60s. Contrary to what you might expect from the foregoing polemic, Kermit programs are not necessarily in the public domain. On the contrary, many of them bear copyright notices to protect their authors or sponsoring institutions against having their work turned into commercial products. However, these copyright notices generally grant permission to any individual or organization to use, copy, modify, or redistribute the program, source code, or documentation as long as this is not done for profit, and the copyright notice and author credits are retained. Commercial hardware and software vendors are allowed to add Kermit protocol to their products provided they do not charge their customers extra for it (at least not beyond the incremental cost of reproduction and distribution), and they agree to certain other easy terms. Kermit distribution began at Columbia in 1981. Our original policy was ‘‘send us a tape and a return mailer and we’ll send you the Kermit distribution.’’ Since we were not able to make floppy disks in a wide variety of formats, we preferred to send tapes to institutional computing centers, which could take the responsibility for ‘‘bootstrapping’’ the desired microcomputer implementations to floppy disk and distributing them in appropriate formats to their users. By early 1983 the demand for Kermit tapes had grown far beyond our capacity to produce them and still do our ‘‘real jobs.’’ To get our system programmers out of the shipping room, we began to charge a distribution fee. This fee is not a software license fee. It allows us to keep up with demand by hiring production workers, and it compensates us for media, packaging, postage, computer utilization, and printing. It does not reflect the amount of software on the tape, the quality of the software, nor the amount of effort that went into producing the software — only the ‘‘parts and labor’’ required for reproduction and shipping.
The Kermit File Transfer Protocol For the benefit of those who have trouble with the fee, every effort is made to funnel Kermit programs into alternative distribution channels. Kermit programs are submitted regularly to user group libraries, and they are available on many computer networks and dialup bulletin board systems. All who have received Kermit programs from Columbia or elsewhere are encouraged to share them with their friends and neighbors. Kermit has been an encouraging example of international cooperation on a personal and institutional level.
Kermit runs happily in both Irelands, both Chinas, both Germanys. It can be found in the USA and the USSR, in Israel and Iraq; in New Zealand and New Caledonia, Chile and Czechoslovakia; in Malaysia and Mexico, Sweden and Switzerland, Norway and the Netherlands, and practically anywhere else you can think of. If a country has computers, many of them are probably running Kermit programs — people’s basic needs are pretty much the same everywhere, and people who use computers have begun to view the ability to transmit computer data as a basic need, even a right. Kermit fosters the free exchange of information and ideas, and it works against the trend towards information as commodity (or controlled substance). Our attitudes about sharing spring from a spirit of respect for fellow humans and other creatures. I trust and urge that Kermit be used only for peaceful and humane purposes. It was not created and shared to further causes of nationalism, war, oppression, or discrimination. Please use it in the spirit in which it is offered. Kermit Versus Networks You have probably read about computer networks. Networks are based upon dedicated physical connections between computers; they are the best way to put computers into communication with each other. They’re reliable, they’re fast, they support a variety of functions, and they’re easy to use. They overcome all the same problems that Kermit must cope with, and they do it better. So why bother with Kermit? If you have a network, and it includes all the computers you care about, then you don’t have to bother with Kermit. But networks are expensive, hard to install, and often designed to work only with a particular vendor’s equipment. Many microcomputers have no network option available; even when there is one, the expense can be prohibitive. And when the expense is tolerable, the logistics get in the way — cables must be laid, holes drilled, satellites launched. So chances are that your microcomputer is not on a network, or if it is, that some day you will need it to communicate with some other computer that is not on your network. Network connections must be installed by ‘‘management.’’ They require special ‘‘interface hardware,’’ operating system software, and so forth. Kermit programs, on the other hand, run (with very few exceptions) in the computer’s ‘‘user mode,’’ with no special privileges or changes to the system software required. Once you have a copy of Kermit on your computer, you can establish your own connection to any other computer that you can dial on the telephone or reach with a cable. Unlike proprietary Introduction networks, Kermit always comes with source code and documentation, so even if there is no Kermit program for your computer, a programmer can create one in a short time based on the Kermit programs that have already been written or the examples in this book. Networks are becoming increasingly widespread and interconnected, but they will never encompass every computer in the world. Communication programs like Kermit will always be needed to make the connections that aren’t already there: from home to work, from business trip to home base, from space to earth
Over the years, the Kermit Project grew into a worldwide cooperative nonprofit software development and distribution effort, headquartered at and coordinated from Columbia University. The Kermit Project is dedicated to production of cross-platform, long-lasting, standards-conformant, interoperable communications software, and is actively engaged in the standards process. Kermit software is used all over the world in every sector of the economy.
Although terminal emulation has been largely supplanted by the Web for online access, Kermit software continues to play a role in other applications such as remote sensing and data collection, remote management and troubleshooting of networking and telecommunications equipment, cargo management, medical insurance claim submission, electronic funds transfer, and online filing of income tax returns. Kermit software is embedded in cash registers, network routers, cell-phone towers, medical diagnostic and monitoring equipment, die-cutting and stamping presses, even cardiac pacemakers.
The Kermit protocol and software are named after Kermit the Frog, star of the television series, The Muppet Show; the name Kermit is used by permission of Henson Associates, Inc.
Significance of the Study
ATARI KERMITS
The eight-bit Atari version of Kermit, by John Palevich, was written in ACTION! and then compiled. (You don’t need the ACTION! cartridge to use the program.) This Kermit is available through the Antic Arcade Catalog. Kermit is also a part of Palevich’s Chameleon Terminal Emulator. Also available through the Antic Arcade Catalog ($19.95, AP113).
A 520ST version of Kermit came with our ST development package. Its one-letter command format is very similar to UNIX Kermit.
We got both Kermits running in matching configuration on both our ST and an Atari 800 (it could have been any other 8-bit Atari). Then we ported Listing 1 over to the ST. The listing is a simple Atari Logo program that draws a star against a randomly selected background color.
HARDWARE
We used a printer cable, a null modem connector, a gender changer (female-female) and a modem cable (RS-232 to D9) to attach our ST to Port R1 of an 850 interface. See Figure 1.
SOFTWARE
We booted Kermit on the 800 and set the following parameters:
A – Back S sends (Cursor left (ASCII))
B – Baud.Rate (9600)
C – Carriage return includes line feed is (off)
D – Default disk drive (D1:)
F – File type (text)
I – I/O Port (1)
T – Dialing method (tone)
L – Local Echo (off)
P – Parity (none)
Meanwhile, we loaded the ST Kermit program from GEMDOS and typed KERMIT R which put the ST into the Kermit Receive mode.
Back at the 800, we typed S [RETURN], entered the filename of our logo program and pressed [RETURN] again to begin the transfer.
An instant later, the transfer was over. At 9600 baud, our logo file and its filename, had been “Kermited” from the 800 to our ST and automatically written to the ST’s disk. At 9600 baud, Kermit ports files very rapidly. In fact, you’d have to type for more than four hours at 40 words per minute to match the amount of information ported during a 60-second file transfer.
OPERATIONS
Most Kermits support three commands: Send, Receive and Serve. Kermit Send and Kermit Receive are used when there is a human operator present at each computer. One operator will Send while the other Receives. Most Kermits also support wildcards in filenames. For example, to port all files with a .TXT extender, you’d type *.TXT as the filename to transfer.
The Kermit Server puts one computer on “remote control,” allowing both computers to be controlled by a single operator.
Type KERMIT V to place the St into the Kermit Server mode. While in this mode, the ST will automatically receive any files (and filenames) sent to it, and save each file to disk.
MODIFYING FILES
Our sample Logo file needed only one modification before it could run on the ST. The ST Logo didn’t permit multiple drawing pens. We removed the pen number from the second line of the STAR procedure, changing that line from SETPC 1 :COLR into SETPC :COLR and the program ran correctly.
Since then, we’ve Kermited many more Logo files, LISTed BASIC programs and numerous text files to and from the Antic 52OST.
Listing 1
TO STAR :LN :COLR
SETPC 1 :COLR
REPEAT 36 [RT 170 FD :LN]
END
TO MAIN :COLR
HOME
SETBG RANDOM 16
CLEAN
FS HT PU FD 90 PD
MAKE “LN :COLR
STAR :LN :COLR
MAKE “COLR :COLR + 1
IF :COLR = 16 [MAKE “COLR 1]
MAIN :COLR
END
Chapter 1
- Background
The Kermit file transfer protocol is intended for use in an environment where there may be a diverse mixture of computers — micros, personal computers, workstations, laboratory computers, timesharing systems — from a variety of manufacturers. All these systems need have in common is the ability to communicate in ASCII over ordinary serial telecommunication lines. Kermit was originally designed at Columbia University to meet the need for file transfer between our DECSYSTEM-20 and IBM 370-series mainframes and various microcomputers. It turned out that the diverse characteristics of these three kinds of systems resulted in a design that was general enough to fit almost any system. The IBM mainframe, in particular, strains most common assumptions about how computers communicate.
- Overview
The Kermit protocol is specifically designed for character-oriented transmission over serial telecommunication lines. The design allows for the restrictions and peculiarities of the medium and the requirements of diverse operating environments — buffering, duplex, parity, character set, file organization, etc. The protocol is carried out by Kermit programs on each end of the serial connection sending “packets” back and forth; the sender sends file names, file contents, and control information; the receiver acknowledges (positively or negatively) each packet. The packets have a layered design, more or less in keeping with the ANSI and ISO philosophies, with the outermost fields used by the data link layer to verify data integrity, the next by the session layer to verify continuity, and the data itself at the application level. Connections between systems are established by the ordinary user. In a typical case, the user runs Kermit on a microcomputer, enters terminal emulation, connects to a remote host computer (perhaps by dialing up), logs in, runs Kermit on the remote host, and then issues commands to that Kermit to start a file transfer, “escapes” back to the micro, and issues commands to that Kermit to start its side of the file transfer. Files may be transferred singly or in groups. Basic Kermit provides only file transfer, and that is provided for sequential files only, though the protocol attempts to allow for various types of sequential files. Microcomputer implementations of Kermit are also expected to provide terminal emulation, to facilitate the initial connection. More advanced implementations simplify the “user interface” somewhat by allowing the Kermit on the remote host to run as a “server”, which can transfer files in either direction upon command from the local “user” Kermit. The server can also provide additional functionality, such as file management, messages, mail, and so forth. Other optional features also exist, including a variety of block check types, a mechanism for passing 8-bit data through a 7-bit communication link, a way to compressing a repeated sequence of characters, and so forth. As local area networks become more popular, inexpensive, and standardized, the demand for Kermit and similar protocols may dwindle, but will never wither away entirely. Unlike hardwired networks, Kermit gives the ordinary user the power to establish reliable error-free connections between any two computers; this may always be necessary for one-shot or long-haul connections
Kermit is a public domain telecommunications program that lets different types of computers and operating systems swap text files with each other. Thus, software developers may write their applications on one machine and transfer the completed source code to another. Because GEM offers compatibility between different co-processors, there are many companies developing software on the IBM PC who will use Kermit to transfer their C language source code files to the Atari ST.
MUPPET SOFTWARE
Named aftcr Kermit the frog, this file transfer protocol monitors the flow of information between computers. Kermit can best be compared to XMODEM protocol. Files transferred through either of these protocols are broken into pieces, or “packets,” and sent individually. A checksum, similar to a TYPO II code, accompanies each packet.
Each time the computer receives a packet, it recomputes the checksum, and compares it against the sending computer’s original. If the two checksums match, Kermit assumes the packet was received correctly.
If the checksums don’t match, Kermit will send the packet again and again, until a rnatch is achieved. Kermit continues sending and checking packets until an entire file is successfully transfered.
Kermit was developed by Bill Catchings and Frank da Cruz at Columbia University in 1981. The first Kermit implementation linked a DEC-20 mainframe to a CP/M-80 microcomputer. Today, more than fifty types of mainframe and micro-computers have Kermit programs