Summary

  • Kermit began at Columbia in 1981 as a practical answer to file exchange between mainframes and the growing number of microcomputers used by students and staff.
  • Its small acknowledged packet core operated over serial lines, while conventions for character sets, records, terminal behavior and optional features bridged differences that a raw connection could not resolve.

In the first Kermit file-transfer demonstration, two Kermit-20 programs exchanged a file over a null-modem cable between serial ports on the same DECSYSTEM-20. The Kermit Project later called it a proof of concept: copying a file on one computer was easier. The consequential test came a few weeks afterward. One end was a DEC-20 running TOPS-20; the other was an Intertec Superbrain running CP/M-80. The machines differed in processor, operating system and how they represented files. Sending bytes was only the visible part of the problem.

Columbia’s computing group was facing a change in who used its systems. Microcomputers were appearing in laboratories, departments, homes and dormitory rooms, while central time-sharing systems still held the files and services people needed. In a paper prepared in 1983, Frank da Cruz and Bill Catchings described students whose course or term IDs did not guarantee long-lived disk storage. A microcomputer with a floppy drive offered a way to keep work locally, if users could reliably move it between the small machine and a mainframe.

This account explains one institution’s design problem; it does not establish a universal pattern across universities.

The communication line made the mismatch worse. Ordinary asynchronous serial links offered little protection against noise, lost characters, full buffers or intermittent carrier loss. Kermit therefore divided a transfer into packets and made each packet part of a conversation. The sender began with a Send-Init packet that advertised parameters. The receiver answered with its own. A file header named the file, data packets carried successive pieces, and separate packets marked end of file and end of transmission. Acknowledgements let the sender advance; a negative acknowledgement or timeout caused a packet to be resent.

That sequence was deliberately modest. The packet number advanced modulo 64, so both programs could recognize which unit had been acknowledged and detect a missing or repeated step within the current exchange. A required one-character arithmetic check helped detect a changed packet. It was not a modern cryptographic checksum, and it did not identify the person at either terminal. It was enough to let the two programs notice many transmission errors and try again. Reliability came from the sender and receiver cooperating, not from the serial wire becoming trustworthy.

Kermit’s larger interoperability problem sat above that wire. The machines could share ASCII characters during communication and still disagree about file contents. A DEC-20 and a CP/M computer used different operating environments; IBM mainframes introduced further constraints. Files could contain records rather than a simple stream of bytes, text encodings could differ, and a host terminal might echo, wrap lines, translate case or consume control characters. If a program treated every connection as a transparent pipe, file content could be altered before it reached the receiving disk.

Kermit answered with a common transfer representation and explicit conversions at the ends. Its basic packet syntax used printable characters, and control bytes in data could be encoded as printable sequences. Kermit programs translated between that exchange format and their own local file conventions. The protocol manual describes the serial link’s shared assumption narrowly: ASCII over an ordinary asynchronous line. It did not make all computers alike; it gave their Kermit programs a limited language for exchanging a file despite differences in storage, encoding and terminal behavior.

The design also had to scale across implementations that did not share the same feature set. The November 1983 manual says the project could not impose one fixed protocol version on its distributed implementers. It described basic functions and optional features, using fields in the initial exchange to communicate capabilities. The manual’s design aim was that a primitive implementation should still be able to work with a more advanced one. That was an ambition expressed by the designers, not proof that every pair of Kermit programs interoperated.

Keeping the core small did not freeze the protocol. Later versions added such options as longer packets, stronger block checks and full-duplex sliding windows. The manual dates the sliding-window work to 1985–86 and credits a group at The Source Telecomputing. That extension addressed a different performance condition: waiting for an acknowledgement after every packet could waste time on a path with significant delay. It was negotiated rather than silently assumed. A receiver that lacked the option could remain with the basic exchange.

The later manual thus shows a growing family of implementations, not a feature that should be projected backward onto the first 1981 transfer.

By 1984, the Kermit Project timeline records an FTP site and an Info-Kermit mailing list on ARPANET. The protocol had become easier to distribute and discuss over a network, while its original reason for existing remained concrete: a user at one kind of computer needed to move a file to another. Kermit was not an Internet standard and did not replace network protocols. It filled a different layer of the work, making file transfer usable across systems that could reach one another through a serial connection or, later, a network service.

The history is a reminder that connectivity and interoperability are not synonyms. A carrier signal can join two terminals while their files remain incompatible; a packet check can catch some damage without proving who sent the data; a shared specification can make exchange possible without guaranteeing that every implementation adopted every option. Kermit’s contribution was to turn those seams into an explicit, implementable conversation.

Sources