Kermit is the name given to some communications software that was originally developed in 1981 at
Columbia University,
New York, for file transfer between different computers. It is named after the
muppet Kermit the
Frog.
As it was ported onto an increasing number of operating system and hardware platforms, Kermit rapidly grew into a piece of software that could get any machine to talk to any other machine. If Perl is the universal Swiss army knife or Swiss army chainsaw, Kermit is the universal hosepipe adaptor.
What is Kermit?
Kermit is a
file transfer program and protocol. The program also provides
terminal emulation and a
scripting language.
How Kermit happened
The job that Kermit was designed to do was
file transfer between two computers connected together over a serial link. However, to do this requires setting up the
serial ports on either side of the link. This requires that one end of the wire is the
client, and one is the
server.
It is usual that the client will need to set up the port at the other end. To achieve this, the client needs to connect through to the server and log in, then run the Kermit server sofware.
To do this, the Kermit client software needs to pretend to be a terminal on the server. In the old days, you would be connecting to the client from a terminal anyway. All that happens is that the Kermit client works in connect-thru mode, and passes every ASCII character from the terminal to the line, and echoing back what appears on the line. A special control character is required to escape from connect-thru to command mode - this was usually <ctrl-\> or <ctrl-]>, as these characters are extremely rarely needed.
If the client is a Unix box, the same still applies. But if the client is a desktop machine, such as a PC, Mac, BBC micro, etc. terminal emulation is required to make the desktop machine behave like a Dec VT100 / Wyse / whatever, and obey all the escape sequences, key mappings and cursor controls that the device supports.
Over time, terminal emulation became important in its own right, as you could use it to run Unix and mainframe applications from a PC without needing a terminal. Kermit is often used to do just that, without ever using the file transfer facility.
Also, the facility was available to automate the login sequence: How to get the server computer's attention, username, password etc. and the sequence of prompts expected from the remote end. This grew into a full blown scripting language, useful for more than just logging in. Kermit scripting can be used as a form of automated test tool.
Criticisms levelled at Kermit
- Kermit is obsolete
The ubiquity of the Internet, with TCP-IP and the FTP application, has removed most file transfer needs for Kermit that existed 20 years ago. However, not to be outdone, the latest versions of Kermit can be used to connect with terminal access over the internet with SSL.
Who needs terminal emulation? Ask a Unix developer or SysAdmin. Unfortunately, Kermit does not provide an X-Terminal application for its terminal, so loses favour among the Unix folk to the likes of Hummingbird and Walker Richer and Quinn, whose terminal emulation software: Exceed and Reflection respectively, does run over X-Window.
In terms of terminal scripting, there is more flexibility in using a scripting language such as Python, Tcl or Perl. Also, there are many more testing tools available, in which the scripting can drive the mouse and/or access Windows objects directly.
- Kermit file transfer is slow
There is a benchmark on the Kermit website (see below) that I do not quite believe. The kermit protocol works on 7 bit ASCII, and introduces an overhead on any 8 bit characters. Any lightweight protocol such as XMODEM will win, especially for transmitting binary or unicode files.
However, if you are talking about how to use a dedicated line optimally, The TCP-IP approach loses to Kermit, as there is an overhead of FTP over TCP-IP over PPP.
- Kermit is hard to set up
In my opinion, Kermit is just as hard to configure as the other terminal emulation packages mentioned.
The Kermit website:
http://www.columbia.edu/kermit/kermit.html presents a sales pitch to try and counter the three criticisms above.
Where Kermit is useful
Kermit will work over anything from
wet string(qv) to Internet
secure sockets. It is also available for a very wide range of platforms, including many machines which do not support TCP-IP access.
Also, Kermit is useful for technical support, to gain access to machines that are off the net. There may be security requirements to limit access to a secure leased line or a dialback; Kermit provides the end to end communication, with a file transfer facility thrown in as a bonus.
Licensing
Kermit was one of the first really popular
public domain programs. It pre-dated, the
GNU General Public License, and allowed the software to be commercially exploited in several unforseen ways. Commercial software vendors were able to include "Kermit file transfer" as an option in terminal emulation software.
The original software was free and open source. However, the Win32 version of Kermit is not, and the Kermit project is dependent on sales revenue from this and commercial licences. Their site goes to great lengths to defend their position and attack open source development.