Frank da Cruz
Columbia University
25 March 2005
We'll assume an arrangement in which the user is seated at a desktop computer, let's call it "the PC", and has already started the PC version of Kermit (let's assume it is Kermit 95, or K95 for short). The PC is the local computer. The Kermit program on the local computer is used to make a connection to a distant computer, the remote computer. The remote computer gives the user a login and password prompt and then a command processor or "shell" that can execute commands and programs. Let's assume the user is in PC Kermit's terminal emulation screen, viewing the shell prompt on the remote. Let's assume the remote computer has C-Kermit installed. In the following, when I say "type", I mean to press the indicated keys on the keyboard, and then to press the key marked Return or Enter, which transmits a Carriage Return. For simplicity, I talk about transferring "a file", but indeed Kermit can transfer 0, 1, 2, 3, or any number of files with a single command.
At the shell prompt, the user types "kermit". The C-Kermit program starts on the remote, prints a greeting (such as version information and an indication of how to get help), and then issues its prompt:
C-Kermit>
To download a file called (say) foo.bar, the user types "send foo.bar". C-Kermit waits a certain amount time (anywhere between 0 and 5 seconds) and then sends the first Kermit packet. The delay (if any) is to give the user time to "escape back" to the local Kermit (K95 in this case), which is done by pressing a tricky series or combination of keys, traditionally Ctrl-] followed by the letter "c", but K95 also allows Alt-x, or even a mouse click for this. If the user does not escape back quickly enough, the first Kermit packet will appear as some strange text on the screen, something like:
9 S~/ @-#Y3~^>J)0___N"U1@G
This has no effect, since the Kermit protocol engine on the local computer has not yet been started. The remote Kermit will receive no reply, will time out, and after a few seconds, retransmit this first packet.
Having escaped back, the user has the local Kermit's command prompt (K-95> for Kermit 95), and types "receive". The file is transferred, the user watches the progress on the screen. When the transfer is finished (or fails), this is announced on the screen, and then the user can connect back to the remote by typing the CONNECT command. Now the user is at the remote C-Kermit> prompt again, and types the EXIT command to return to the shell.
The procedure for uploading a file is the same, except the RECEIVE command is given to the remote and the SEND command is given to the local. This method of downloading and uploading is fundamental to all Kermit programs, no matter how old. It works with any combination of desktop and remote computers.
Steps: 6.
kermit -s foo.bar
This starts C-Kermit in such a way that it does one and only one task (sends foo.bar) and then exits. Thus there is no C-Kermit> prompt and no interaction with C-Kermit. Everything else is the same. For uploading, use:
kermit -r
on the remote and tell the local Kermit to "send foo.bar". This availability of this depends on the remote operating system. Syntax may vary from one to another, since different platforms (e.g. Unix and IBM mainframes) have different rules for command-line options.
Steps: 4
Having placed the remote Kermit into server mode, the user escapes back to the PC and gives any number of commands at the K-95> prompt to send files, get files, and so on. When done using the server, the user types "finish" and "connect" to get back to the remote shell prompt, or simply "bye" to terminate (logout) the host session and disconnect.
In the client/server arrangement, everything is controlled by the client. Note, however, that the client is not necessarily the local Kermit, nor is the server necessarily the remote. The roles can be reversed, as we will see in Method 3.
The command that tells the client to tell a server to send a file is GET rather than RECEIVE. GET is active, it actively requests a file by name. RECEIVE is passive, it silently waits for an as-yet-unknown file to arrive from the other Kermit, which has already been given a SEND command.
A Kermit server is conceptually equivalent to an FTP server, except that:
Steps: To transfer one file, the same as Method 1 or 1.5. To perform additional operations, only 1 step per operation; in other words 5+n or 3+n.
9 S~/ @-#Y3~^>J)0___N"U1@G
and to switch automatically to server mode long enough to handle the requested action. The user tells the remote Kermit to SEND or GET a file, the local Kermit automatically activates its protocol engine to receive or send the file, and then automatically returns to server mode when the transfer is complete. Everything is conrolled by the remote side.
Older Kermit programs can't do this, they must use Methods 1 or 2. But since most modern Kermit programs can do this, the file-send delay (which was 5 seconds in the early days) has been completely removed. This way when you start a transfer from the remote, it begins immediately. Of course all parameters, settings, and preferences can be adjusted by the user.
Steps: 1 (when using Method 1.5 on the remote) or 3 (Method 1).
kermit -r
and a carriage return before it sends its first Kermit protocol packet. If the user types "get foo.bar", the local kermit sends "kermit -x", and so on (-x is the command line option to start Kermit in server mode). This works if the remote session is at its shell prompt. It also works if Kermit has already been started.
This feature allows everything to be controlled from the local end, without having a server on the remote end.
Steps: 1
Steps: 3+n: Just like with FTP service; you have to make the connection, authenticate, perform n operations (each one requiring one step), and then disconnect. It is also possible (conceptually) to transfer a file with the Internet Kermit Service in one step by clicking on a "kermit:" URL. This works but has not been offially approved by the IETF.
In fact, there is no end of combinations. Suppose, for example, you want to deliver a certain file to any caller from your PC. You have your Kermit program wait for an incoming call, then send that file, then hang up and wait for the next call. The caller's Kermit program automatically receives the file by Method 3.
Finally note that everything described here, like anything else Kermit does, can be scripted. Anything that can be done by "hand, eye, and brain" can be done by a script, without human intervention or attendance. For further information, see:
As noted in the latter document, in a Kermit script the INPUT command takes the place of your eyes, the OUTPUT command of your fingers, and the IF command your brain; i.e. it makes decisions. For example, every command can succeed or fail, and this can be tested by the IF command. Of course this includes file transfer commands such as SEND and GET, as well as RESEND and REGET, and this is what allows us to detect and automatically resume failed transfers.