Kermit is a file transfer protocol first developed at Columbia
University in New York City in 1981 for the specific purpose of
transferring text and binary files without errors between diverse types of
computers over potentially hostile communication links, and it is a
suite of communications software programs from the
Over the years, the Kermit Project has grown into a worldwide
cooperative nonprofit software development effort, headquartered at and
coordinated from Columbia University. The Kermit
Project is dedicated to production of cross-platform, long-lasting,
standards-conformant, interoperable communications software, and is actively
engaged in the standards process.
Since its inception in 1981, the Kermit protocol has developed into a
sophisticated and powerful tool for file transfer and management,
incorporating, among other things:
Kermit software has been written for
hundreds
of different computers
and operating systems, some of it by volunteer programmers all over the world,
some of it by the Kermit Project professional staff.
The major features of the most popular Kermit programs are:
Our premiere Kermit software implementations are:
The feature that distinguishes Kermit protocol from most others is its
wide range of settings to allow adaptation to any kind of connection between
any two kinds of computers. Most other protocols are designed to work only
on certain kinds or qualities of connections, and/or between certain kinds of
computers, and therefore work poorly (or not at all) in other settings and
offer few if any methods to adapt to unplanned-for situations. Kermit, on the
other hand, allows you to achieve successful file transfer and the highest
possible performance on any given connection.
Unlike FTP or X-, Y-, and ZMODEM (the other protocols with which Kermit is most
often compared) Kermit software does not assume or require:
(although Kermit does not require any of these conditions, it can take
advantage of them when they are available).
A feature article on Kermit protocol by Tim Kientzle
in the February 1996 issue of
Dr. Dobb's Journal noted that "Kermit's
windowing approach is faster than protocols such as XModem and YModem
. . . What many people don't realize is that under less-than-ideal conditions,
Kermit's windowing approach is significantly faster than ZModem, a protocol
with a well-deserved reputation for fast transfers over good-quality lines."
Thus Kermit transfers usually work "out of the box" almost every time.
The Kermit file transfer protocol specification is given in the book,
Kermit, A File Transfer Protocol.
A
formal specification and verification of the Kermit protocol
was published by James Huggins of the University of Michigan in 1995.
Kermit originally was designed to operate under the worst conditions, and
its robust default tuning was at the expense of speed. Thus there has been
a widespread misconception that Kermit is a slow protocol. This misconception
is bolstered by the fact that most Kermit implementations that do not come
from the Kermit Project are, indeed, quite slow since they implement only the
barest minimum (robust) subset of the protocol. Unfortunately, Kermit
protocol itself is often judged by such implementations, as, for example in:
or in well-known communications software such as Windows HyperTerminal.
To illustrate, here are measurements of file-transfer throughput for Kermit 95 1.1.20 and HyperTerminal on the same Windows 95
PC, using the same built-in 56K Winmodem for a
connection to the same host at the same phone number, with a serial port speed
of 115200 BPS, transferring a (precompressed) ZIP file 108K in length with
Kermit protocol
In both cases, C-Kermit 7.0 is on the other end,
with all its default settings (the higher download speeds are a feature of 56K
modem technology). Small wonder that people whose only experience with Kermit
protocol is through products like HyperTerminal think Kermit is slow.
Kermit's reputation also suffers from:
In fact, Kermit protocol can be just as fast or faster than other popular
protocols on any given connection, while retaining its superior error recovery
and data conversion characteristics, as shown in:
For further information about performance, see:
Beginning in early 2000, the major Kermit software releases (Kermit 95,
C-Kermit, MS-DOS Kermit) implement a new "streaming" form of the Kermit
protocol that is negotiated automatically on reliable connections, such
as a Telnet connection; in this case file-transfer speeds are about the
same as FTP, and often faster, since Kermit adds compression.
Since Web browsers have largely replaced terminal emulators among mass-market
end users for online connections, many people believe that Kermit software is
no longer used. In fact, Kermit software is more popular than ever,
especially among computer professionals within organizations where diverse
platforms and communication methods are used for demanding tasks such as
network management, alpha and numeric paging, software distribution and
patching, remote troubleshooting, setting up automated data transfer
procedures, EDI, mobile applications, automated configurations of PBXs,
routers, hubs, and terminal servers, and so forth, and as the bundled
communications piece in numerous products including barcode readers, postal
sorters, operating-room anesthesia monitors, fast-food cash registers,
scientific instruments, networking equipment, program-driven milling and
die-cutting machines, healthcare management systems, medical and
pharmaceutical claim submission packages, inventory control systems, and car
and auto-parts dealership packages.
The software is fast, robust, and flexible, and the scripting language is
powerful and easy to learn. Scripts are portable across platforms and
communication methods. Even in a TCP/IP-only setting, modern Kermit software
has distinct advantages:
(*) The Internet Kermit Service, described in
Internet RFCs 2839 and
2840, offers a flexible,
high-function alternative to FTP service, now available for Unix (most
varieties: Linux, Solaris, FreeBSD, AIX, HP-UX, etc) and Windows NT/2000/XP.
Of course FTP is everywhere. Wouldn't it be great if all the features of
Kermit -- scriptability, automatic text/binary mode switching, recursion,
recovery, character-set conversion, etc -- were available in an FTP client?
Now they are -- CLICK HERE for more information.
Kermit has been around for a long time. Features are added -- and rarely,
if ever, removed -- as time goes on, so it seems to become increasingly
complicated: more commands, more options, more syntax rules. Is that
good or bad? Here's an excerpt from a recent FreeBSD newsgroup discussion:
: >> What's a good, simple terminal emulator to use on my 4.0-RELEASE laptop
The tradeoff is as follows...
Some tools like Minicom do just one thing (in the UNIX spirit). So to
do that thing, you have to learn how to use that tool (Minicom in this case).
But the thing that Minicom does is very similar to the things that
Telnet and Rlogin do, except on different kinds of connections.
So if you make network connections too, you also have to learn Telnet and/or
Rlogin.
But Kermit does both things: it makes both serial (direct or dialed) and
network connections. But this means you have to tell it which thing to do
("set this, configure that"). The advantage is: everything else is the
same on both kinds of connections, whereas it can be very different with
the other packages (e.g. Rlogin quoting rules, Telnet escaping rules,
sending BREAK, etc).
Of course we can carry this further. Maybe you want to transfer files
with the same computers you connect to with minicom, cu,
tip, seyon, pcomm, telnet, or rlogin. For
this you would need Zmodem, FTP, rcp, etc etc -- again,
lots more programs and interfaces to learn. Or you can use Kermit to transfer
files on all these kinds of connections, using just one interface -- the same
one you were already using.
Then maybe you're not an American, so you might need to have character
sets translated on your connection -- telnet, rlogin, FTP, dialout,
whatever. Here you're getting into deeper water. Where are the Telnet,
Rlogin, FTP, and dialout clients that do this? I don't know. But Kermit does
it. Plus it can also convert character sets of local files, just like
iconv or recode (oops, more user interfaces to learn!).
And on and on. Now, suppose you want to automate some complicated
task, like dialing out, logging in, checking for some new files,
downloading them if they are there, uploading some other files, etc. Maybe
you could do this with some combination of shell scripts,
expect, Perl, Tcl, cu, Zmodem, etc (more
interfaces!), or you could do it with Kermit, using the same commands you
already learned.
Now suppose you want to do the same thing, but this time on a network
connection. No worries: Just use the same script, but change a line or two
to tell it to make a network connection instead of a dialout one.
Everything else stays the same.
Now suppose you want your network connection to be secure. For this
you could use ssh, scp, ktelnet, srp-telnet, etc.
Or you could use Kermit, which supports Kerberos IV, Kerberos V, SSL/TLS, and
SRP security (and in some versions, also SSH).
Now suppose your boss tells you to stop using FreeBSD (boo!) and move
all your applications to some other operating system: Linux,
AIX, Solaris, SCO, QNX, HP-UX, VMS,
VOS, even Windows. No problem. Since Kermit is available for
all those platforms, the same script runs on them too, and lots more; just
change a line here and there to account for different file and device name
formats.
Now suppose you have all these wonderful scripts, dialing directories,
and so forth, but then you have fly to another state and demo them there.
Will they still work? After all, you're dialing from another area code.
Again, no problem: Kermit takes care of all that. How about another country?
Same thing. Kermit knows all about area codes, country codes, and dialing
rules.
These days I suppose Kermit is something like EMACS. You have to put some
effort into learning it, but once you do, it can save you huge amounts of
time and work from then on.
"Why Isn't Kermit Free and Why Isn't it Part of Linux?"
From a recent newsgroup discussion:
On 25-Feb-2001 in one of the Linux newsgroups, somebody wrote, explaining
why they did not use Kermit:
So what? Lots of software isn't free. Everybody is happy to pay money
for retail software and in return receive bugs, headaches, no
documentation, no upgrades, and no technical support.
C-Kermit is free to you if you want to use it. If you ask for technical support, you get it. C-Kermit is free to
Linux packagers if they want to include it. But it's not free to people or
companies who want to make money directly from it. Seems fair to me.
The Kermit Project was giving software away before there was a GNU project
or FSF, before there was a Linux or FreeBSD. We all grew out of the same
environment -- university computer centers and CS departments in the early
days of the ARPANET, where we were paid to develop software. We had
secure jobs, so free software made sense. We all shared everything and it
was fun. But those days are gone. Virtually nobody is paid to develop
publicly available software in universities any more. The very foundation
of the free software movement no longer exists. Now free software is
developed by:
This is all fine with me -- everybody should do what they please if it
doesn't hurt anyone else. But it's not exactly a sound and stable system.
Unpaid developers have little incentive to care about what their users want.
And, with very few exceptions, the unpaid development model does not provide a
career path except in the sense that if you become famous for some free
creation, then you can get a high-paying job at an investment bank and
disappear from the scene.
The Kermit Project is one of the last surviving university-based nonprofit
software development projects. We're here full-time to serve and help our
users, year after year, decade after decade. The money has to come from
somewhere, and believe me, we've tried every funding model. Sure, Kermit
would be more popular if it was "free in the sense of freedom", but that would
also kill it.
In the end, I think doctrinaire insistence on license
purity is kind of silly, if not disingenuous. If the software is free to you,
then what do you care if it's not free to somebody else who wants to sell it?
If you yourself want to sell it, why do you think you have the right to
expropriate somebody else's labor for your own enrichment? If everybody
thought that way, nobody would do any useful work and we'd all starve to
death.
Suppose your company had a commercial product of which Kermit was a critical
component (as many do). Doesn't it make good sense to pay for it, thus
assuring its survival and continued development, as well as giving you a voice
in its future directions? Lots of companies think so. If they don't mind,
why should you?
The fact is, C-Kermit is highly functional, useful, modern, well-documented,
aggressively developed and supported software that can be in Linux if you
want it to be. As of C-Kermit 7.0, 1 January 2000, nothing is stopping
Linux packagers from including it. They'll do it if their customers ask
them to.
- Frank da Cruz
The nonprofit Kermit project is funded entirely by the income it
generates: Kermit 95 sales and licenses, licensing of other Kermit programs for commercial
redistribution, and book sales.
Links:
KERMIT SOFTWARE
Kermit's user interface and script programming language are consistent across
platforms and communication methods, allowing the investment in learning to
pay off time and again as you move from one platform to another, one
communication method to another.
KERMIT PROTOCOL
POPULAR MISCONCEPTIONS
HyperTerminal Kermit 95
Upload 227 CPS = 7.9 Minutes 2831 CPS = 36 Seconds
Download 358 CPS = 5.0 Minutes 5121 CPS = 21 Seconds
"Kermit Is a Relic of a Bygone Era".
"Kermit Is Too Complicated!"
: >> for serial /console connections to routers and switches?
: >
: >kermit wins here hands down!
:
: I beg to differ. Consider minicom.
:
: If you come from the dos world, you will feel at home with minicom, which
: is modelled after Telix' user interface.
:
: Also, it has the habit to do the right thing in quite a number of
: situations (but don't press alt-b, when you're connected to your
: company's sun server console :-)
:
: If you need All bells and whistles, scripting, you name it, of course
: kermit is the software of choice, but for simple task I found
: it too awkward to get running most of the time. Too much set this
: and configure that before it starts to do anything. No comfortable
: dialer configuration, automatic phonebook and whatnot...
:
Well, C-Kermit has all that too -- just not in "GUI" or curses form, so
you have to put in a little effort to learn it.
THE LICENSING DISCUSSION
:
: But it still isn't free software.
:
(Meaning: it does not have an Open-Source license such as GPL or BSD,
permitting anybody to do whatever they want with it, including sell it.)
More about Kermit licensing HERE
and HERE.
Note: G-Kermit is included with most Linux
distributions because it has the GNU Public License (GPL); however, G-Kermit
is strictly a remote-end file transfer program and does not include the
communication, scripting, security, and other features of C-Kermit.
Kermit Protocol / Columbia University /
kermit@columbia.edu / 21 March 2002