].rm 66 .c;The Kermit protocol and the PDP-11 .s 2 .c;Brian Nelson 12-APR-1986 06:54 .s 2 Abstract .s 1 #This article will describe the author's implementation of the Kermit file transfer protocol for the PDP-11 series under RSTS/E, RSX11M/M+, P/OS RT11 and TSX+. This protocol allows many (if not most) types of computer systems to effect, at minimum, error free file transfer with other systems and microcomputers over asynchronous lines. .s 1 The first obvious use of any program or protocol designed to accomplish file transfer is to be able to provide the ability to support file uploads and downloads from superminis such as the VAX and PDP-11 to remote personal computers, such as the PC and Rainbow. Additionally, there is a need to provide at least basic terminal emulation. This can be done several ways; a Kermit program can provide a simple 'glass' tty mode, or in the case of a PC, might provide an intelligent terminal emulation, most likely to be of a VT100 series terminal such as MacKermit provides. Some mode of terminal emulation is generally required since the file transfer operation of Kermit requires two Kermits to be running; one on the LOCAL system (your PC, Rainbow, ...), and one on the HOST (often called the REMOTE system) system. Obviously, the simplest method of achieving this is to use Kermit on the local system as a terminal to log into the remote system and then invoke the host's Kermit program. .s 1 The first step one usually takes in starting a Kermit session is to establish the connection between the two systems. When we are connecting two single user systems, such as a Rainbow to another Rainbow, we would simply connect the COM ports together with a NULL modem cable and then invoke Kermit on each system. One would most often set one of the PC's up as a Kermit 'server'; this allows the other system to control the server and initiate file transfer requests without the need to move between the two machines. .br If we are on our Rainbow and we wish to transfer files from a multiuser host, such as a VAX or PDP-11, we would first make a connection to the host with a modem or direct line. Once the physical link has been made, we would log into the remote system and invoke Kermit on that system and run it as a server. This is often done by typing 'KERMIT SERVER' on the host. .lit (slide CONNECT1 goes here) .eli Note that the micro-computer Kermits assume the use of the systems COM port for communications. When a larger system, such as a PDP-11 or VAX, is used to connect to a remote system, the Kermit program must usually be told which terminal line to use. For example, using a PDP-11 to dial out to a remote system would require the SET LINE command, where the line given is the name of a terminal device, such as TT27: or TXA0:. When this is done, there may be a need to control some of the modem signals, most likely DTR (Data Terminal Ready). .lit (slide CONNECT2 goes Here) .eli .s 1 Basic Kermit commands .s 1 Now that we have established the physical link, how do we get files transferred? Well, it's quite simple. Assuming that we gave the remote Kermit the SERVER command, we use: .lit Kermit-11>GET file.type Request a file from the remote Kermit-11>SEND file.type Send a file to the remote system Kermit-11>BYE Tell the remote Kermit to log out .eli These are the commands we need when talking to a Kermit server. There are, of course, many others which may support file manipulation on the host, as well as obtaining HELP. These commands are normally thought of as REMOTE commands. Indeed, they are prefixed by the REMOTE keyword, as in: .lit Kermit-11>REMOTE HELP Kermit-11>REMOTE COPY FILE1.TYP FILE2.TYP Kermit-11>REMOTE CWD [USERFILES] .eli Before continuing, note that not all Kermit programs implement the same level of support. In general, the large system Kermits, such as Kermit-32 (VMS), Kermit-20 (Tops-20) and Kermit-11 (PDP-11 and PRO) support a large command set. No single command is really required by Kermit; the protocol specifies the transportation of files, not the command interface. At a minimum, however, a Kermit program requires the SEND and RECEIVE commands to effect file transfer. Server support is optional, if we don't have server support available then we must use the SEND and RECEIVE commands and tell each Kermit such every time we want to move a file. .s 1 What do we use Kermit for? .s 1 I routinely use Kermit for transferring software developed for the PRO/350 on a RSTS/E 11/23+ host as well as using the PDP-11/44 and VAX 11/785 I run at the University of Toledo for dialing out to other systems, such as the LCG Tops 20 system and the LDP public domain library. Considering that there exists a Kermit for almost any DEC configuration one can even use Kermit as a poor man's Decnet. In my case, I have a DMF32 modem port from the 11/785 and a DZ11 port from the 11/44 connected to the Gandalf PACX front end switch, which allows me to connect either system to any of the other systems on the PACX, which includes an IBM 370 compatible system as well as connecting the VAX to the PDP-11. .s 1 With the knowledge that there are Kermit implementations for most personal computers in use it becomes apparent that the Kermit standard is well worth looking in to. A list of versions running on Digital hardware follows the article. .br .s 1 The Kermit protocol .s 1 The Kermit protocol is designed to operate over normal asynchronous terminal lines. All data and commands are transferred with a packet oriented protocol, basically consisting of a start of packet character (normally SOH), followed by length, control, data and checksum fields. Communications is half duplex, in that for every packet sent, the sender must wait for either an acknowledgement packet (ACK) or a negative acknowledgement packet (NAK). Transmission is in ascii, with no requirements needed for the transmission of eight bit characters or control characters other than the choice of control-A for marking the start of a packet. All 'control' characters imbedded in the data are prefixed to convert them to printable characters, the same applying to eight bit characters if required by the characteristics of the line. Since there are many different implementations of Kermit, the protocol provides a mechanism by which the capabilities of two connected Kermits can be negotiated to allow for differences in the level of protocol support. Examples of protocol features that not all Kermits understand include data compression and transfer of file attributes. .s 1 How Kermit transfers a file .s 1 The means by which Kermit transfers a file is quite simple; the protocol includes a START OF HEADER (normally a SOH, control A), after which follows a LENGTH field, then a SEQUENCE character and a TYPE field. After this, the DATA follows, with a checksum trailing the data segment. The checksum can be one of three types, the first being basically an additive sum wrapped into 6 bits, the second being the same but 12 bits in size, and the third type a CRC based checksum. The sequence number increments for each packet sent, module 64. .lit (example slide goes here) (checksum1 and Checksum2 files go here, if you feel its needed) .eli .br #Rather than to go into more detail about the the Kermit protocol, the reader should consult the references listed at the end of this article. .s 1 The PDP-11 Kermit-11 implementation .s 1 #The author's version of Kermit-11 is written in Macro-11 and can run on RSTS/E, RSX11M, RSX11M Plus, P/OS and RT11. The RSTS and RSX file system interface is via RMS11 version 2, while the RT11 interface attempts to emulate the RMS11 subsystem. The choice of Macro-11 for the implementation language was made for several reasons, one being the availability of the assembler on all systems and another being speed and compactness of the code. .br #RMS11 was used for RSTS/E and RSX to provide a common i/o interface to the host file system. Additionally, Bob Denny of Alisa Systems further extended the RMS interface to support remote file access over DECNET with Kermit, allowing commands such as SEND NODENAME::[BRIAN.FUBAR]FILE.TYPE and other remote file accesses over DECNET. RMS11 version 2 also provides a very simple and powerful means of doing wildcard searching, file renames and file deletion via the $PARSE, $SEARCH, $RENAME and $DELETE macros. Points against RMS basically amount to it's size, RMS is quite large even if overlayed. This is helped by using the segmented RMSRES available on RSTS/E and RSX11M Plus, though there is no remote file access for RMSRES in the current release of Kermit-11. The other objection to RMS will come from RSTS/E users, who are used to using files that normally lack file attributes. This is overcome by the ability of RMS v2 to create stream ascii files. .s 1 The RSTS/E Kermit, while it does 'run' under RSX emulation, does NOT use any RSX directives (apart from GTSK$S) to interface to the executive, as (one) the RSX directive emulation under RSTS/E is only a small subset of 'real' RSX and (two) there is no need to go though an additional layer of overhead to make RSTS/E map RSX calls to native calls. The 'multiple private delimiters' feature is used to avoid losing read pass all (binary) mode on read timeouts, as well as setting the link to '8-bit' mode to keep the terminal driver from stripping the high bit from data received. .s 1 The RSX11M/M+ and P/OS versions of Kermit-11, like the RSTS/E and RT versions, receive eight bit data assuming no parity is used. Where parity is a must, Kermit-11 has to use a prefixing scheme for eight bit binary data. Like the RSTS/E version, binary files are created as FIXED no carriage control files such as used for task images. Note that parity generation is done by software in Kermit-11. The P/OS version runs under control of DCL. The next release of Kermit-11, which will be 3.50, will include support for the PRO TMS (Telephone Management System) option. .s 1 #The RT11 and TSX+ version of Kermit-11 maintains source module compatability with the RSTS/E and RSX versions. Each version of Kermit-11 has it's own source file to deal with the operating system, for RSX it is K11M41.MAC, for RSTS/E they are K11E80.MAC and K1180S.MAC, and for RT11 they are called K11RT*.MAC. Apart from these specific files, all other source files are shared. The RT11 Kermit-11 can use either the version 5.x XL and XC handler for high throughput, or it can use multiple terminal service to do all its terminal i/o. This second option allows the use of any interface supported, including the PDT150 modem port, DL/DLV11's and DZ/DZV11's. The drawback is overhead, the RT11 MT service can't sustain a rate much past 1200 baud at most. This is not a problem for Kermit, however, due to it's half duplex nature and the fact that no packet received is ever longer than the ring buffer size. The only problem is in when Kermit-11 is running as a terminal emulator (the Kermit CONNECT command) where the data coming from the remote host can easily overrun the executive's buffer. A SET RT11 [NO]FLOW command was added to force Kermit-11 to send its own flow control to the host via XON and XOFF. TSX+ users can connect to CL: for dialing out, the exact means is documented in the Kermit-11 users guide. The disk i/o emulates the RSTS/E and RSX RMS11 version, and each executive directive has its error codes mapped into an unique global error code, with the symbolic names corresponding to the nearest RMS11 error name. Wildcarding is handled, of course, by non file-structured access to the directory on the desired volume, and supports full RT11 wildcard filenames. .s 1 Transmission of file attributes .s 1 One of the optional features of the Kermit protocol is the ATTRIBUTE packet. The attribute packets allow a Kermit program to send to a receiving Kermit information regarding the file organization, size, cluster/retrieval size, protection and so forth. There is even a system dependant attribute packet type that can be used to transfer things like the RMS11 IFAB (the RMS/FCS attributes). One of the things that two Kermits exchange before any file transfer is an information packet, this packet tells the receiving Kermit about itself. The last field in this packet, the CAPAS mask, tells Kermit if the other one can process attribute packets. If two Kermit-11's are communicating, they will find that each can do so, and the sender of a file will then send over attribute packets indicating the need (or lack of) for binary transmission, based on the file organization, filetype and protection code (for RSTS/E). If the sending Kermit-11 is running on RSTS/E, RSX11M/M+ or P/OS it will also send a copy of the RMS/FCS attributes so the received file will be identical (to FCS and/or RMS) to the copy on the sender's system. Since other implementations of Kermit may use this special system attribute packet, Kermit-11 always sends an attribute packet telling the receiver what hardware and operating system it is running on, and thus will only use such data if they are compatible. Of course, there will be times when a file may be binary and Kermit-11 can't tell so, many Kermit's have a SET FILE BINARY and SET FILE ASCII to allow the user to override defaults. Kermit-11 also has a SET FILE AUTO/NOAUTO to disable it from trying to determine a file's binary status. .s 1 Future directions .s 1 With the advent of packet switched networks and satellite communications the Kermit protocol will likely be extended to increase efficiency over such links. The main problem is the half duplex nature of Kermit, the packet acknowledgements can take up to several seconds in transit thus drastically reducing the throughput. There are several possibilities under discussion and a standard should be appearing shortly. .page Summary .s 1 #There are currently over 200 implementations of Kermit available. #This article describes only the PDP-11 Kermit-11 implementation, for further reading see: .lit Kermit: A File-transfer Protocol for Universities Frank da Cruz and Bill Catchings BYTE Magazine, June/July 1984 The Kermit Protocol Manual, version 5 Frank da Cruz April 1984 Columbia University Center for Computing Activities .eli .lit (slide GETKERMIT should be here) .eli .lit Digital hardware that Kermit is currently available for: Operating Program Machine System Language Contributor DEC PDP-11 MUMPS-11 MUMPS-1982 Cornell U DEC PDP-11 RSTS/E Macro-11 U of Toledo DEC PDP-11 RSX-11/M Macro-11 U of Toledo DEC PDP-11 RSX-11/M+ Macro-11 U of Toledo DEC PDP-11 RT-11 Macro-11 U of Toledo DEC PDP-11 RT-11 OMSI Pascal U of Toronto DEC PDP-11 TSX+ Macro-11 U of Toledo DEC PDP-11 Unix 2xBSD C Columbia U DEC PDP-11, ... Unix V7 C Columbia U DEC PDP-8 OS8, RTS8 PAL-8 R. Hippe DEC Pro-3xx P/OS Bliss, Macro Stevens I.T. DEC Pro-3xx P/OS Macro-11 U of Toledo DEC Pro-3xx Pro/RT Macro-11 U of Toledo DEC Pro-3xx Venix V1 C Columbia U DEC Pro-3xx Venix V2 C Columbia U DEC Rainbow CPM86 ASM86 Columbia U DEC Rainbow MS-DOS MASM Columbia U DEC Rainbow QNX 1.x C Merrell-Dow DEC VAX Ultrix-32 C Columbia U DEC VAX VMS Bliss,Macro Stevens I.T. DEC VAX VMS C (VAX-11 C) Columbia U DEC VAX VMS Pascal U of Toronto DEC VAX, ... Unix 4xBSD C Columbia U DEC VT-180 Robin CPM80 Turbo Pascal Jeff Duncan DEC VT-180 Robin CPM80 2.2 M80,LASM ACC DECmate-II,III CPM80 2.2 M80,LASM ACC DECsystem-10 TOPS-10 Bliss, Macro Stevens I.T. DECSYSTEM-20 TOPS-20 MACRO-20 Columbia U .eli