WAYS OF TRANSFERRING FILES WITH KERMIT

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.


METHOD 1: THE ORIGINAL FULLY MANUAL METHOD

Or "Manual Transmission" :-)   In Method 1, the user interacts directly with both the local and remote computers.

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.


METHOD 1.5: METHOD 1 WITH FEWER STEPS

The same as Method 1, except the user starts C-Kermit with command line options; that is, the command(s) which Kermit is to execute are given in the same shell command that invokes Kermit:

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


METHOD 2: CLIENT/SERVER MODE

If a Kermit program is commanded to enter server mode, its protocol engine is started and it accepts all further instructions from Kermit packets sent by its partner on the other computer. A Kermit server can not only send and receive files, but also perform the same file management functions as an FTP server; send directory listings, delete files, rename files, create directories, change directories, and so on.

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:

  1. An FTP server is always waiting for incoming connections, whereas the Kermit user has to log in to the remote computer and start the Kermit server "by hand" each time.
  2. An FTP server works only on the Internet, whereas Kermit works on any kind of network and any other kind of connection.

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.


METHOD 3: AUTODOWNLOAD AND AUTOUPLOAD IN TERMINAL MODE

In more recent Kermit versions, beginning about 1996 (the feature was first coded 11 September 1995), the manual switching between screens and separately instructing each Kermit program what to do (send, receive) is no longer necessary. A new feature allows the terminal emulator to detect when a Kermit packet arrives, such as this one:

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).


METHOD 4: AUTODOWNLOAD AND AUTOUPLOAD IN COMMAND MODE

When the local Kermit program is in command mode and the user gives a SEND, GET, or other protocol command, Kermit sends the appropriate shell command to the remote to automatically start the remote Kermit in the appropriate mode in case it has not been started already. For example, if the user types "send foo.bar", the local Kermit sends:

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


METHOD 5: THE INTERNET KERMIT SERVICE

The Internet Kermit Service is similar to Method 2, except that a specially configure Kermit server is actually installed on the remote computer. Anybody on the Internet can make a connection to it, just like an FTP server, it's always there. You don't have to log in to a shell and start it yourself. It is described HERE, and specified in IETF RFCs 2839 and 2840. The main aspect of the special configuration is that the Internet Kermit Service, unlike a regular Kermit server, must perform authentication, just like an FTP server.

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.


METHOD 6: DO-IT-YOURSELF

Until now we have assumed all connections are between desktop PCs and remote "servers" that accept and authenticate logins from outside. It is also possible, however, to make a connection between (for example) two PCs. In this case there is no login program, no shell, none of the procedures listed above apply. In this case, the user of one PC can start Kermit in such a way that it listens for an incoming connection and then enters the desired mode (normally server mode). The user of the other PC makes the connection and then uses the complementary mode (e.g. client). Of course the two PCs can be physically proximate and controllable by one person, or conversely, they might one person's home and office PCs. For example; the office PC is left in server mode overnight to be connected to from home.

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:

  1. The C-Kermit Tutorial
  2. The Kermit 95 Tutorial
  3. The Kermit Script Programming Tutorial

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.