26-Jan-84 10:30:55 Brian Nelson See K11INS.DOC For edit history, see K11CMD.MAC If you really have a problem with RMS, please read K11INS.DOC first. You DO NOT need RMSRES on your system to use Kermit. You don not even need ANY RMS-11 files on your system to run. To reach me Brian Nelson Computer Services University of Toledo 2801 West Bancroft Toledo, Oh 43606 (419) 537-2841 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 com- municate 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. The KERMIT protocol is specifically designed for character-oriented transmis- sion over serial telecommunication lines. The design allows for the restric- tions 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, 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, con- nects 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 sequen- tial 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 allow- ing 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 serv- er can also provide additional functionality, such as file management, mes- sages, 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 charac- ters, 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.