| [ Home ] [ Kermit 95 ] [ C-kermit ] [ Scripts ] [ Current ] [ New ] [ FAQ ] [ Support ] |
Kermit is an extensible file transfer protocol first developed at
Columbia University in New York City in 1981 for 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 transport-independent 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:
Kermit 95 and
MS-DOS Kermit
are full-featured communication software programs rivaling the quality of
anything else on the market. C-Kermit for UNIX, VMS, etc, and IBM
Mainframe Kermit are host-based packages with an unequaled range of
versatility. We
document this software thoroughly and
support and develop it aggressively.
And unlike most other providers of communications software, we
supply and can support the software for both ends of the connection.
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) elsewhere 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 protocol 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 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 configuration 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.
It's the old tradeoff. GUIs took the mass market by storm in the 1980s
(Macintosh) and 90s (Windows) because they were easy to learn. That does
not necessarily mean they are easy to use. Command and scripting languages
are harder learn but are more powerful than GUIs.
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 FreeBSD newsgroup discussion, circa
2000:
: >> 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 (which shell?),
Expect, Runscript, Perl, Tcl, etc, plus 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), and has all the same
capabilities on secure connections that it does on clear-text ones -- file
transfer and management, character-set conversion, scripting, etc.
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 to 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. In many cases, you can look through the
Kermit Script Library and find an example that
shows how to do what you want.
Finally, for those who abjure "feature bloat" and want a version of Kermit
that is "lean and mean" and "free" like in the old days, there is G-Kermit.
"Why Isn't C-Kermit Part of Linux?"
In fact C-Kermit is a part of increasingly many Linux and BSD
distributions, including SuSE and, most recently, Red Hat 9 (though
you might have to hunt for it on the CDs or perform a Custom installation).
The Kermit Project has to make money from its work to pay for itself; it is
not subsidized in any way. In fact we do give most of our software
away ("free" in the sense of "free beer"), but some packages such as
Kermit 95 and
E-Kermit are sold to raise the operating funds we need
to continue our work; others such as C-Kermit
and MS-DOS Kermit are free for "own use" or
internal use but must be licensed for commercial redistribution.
"Why Doesn't Kermit Have a Standard Open Source License?"
First, note that there is a GNU Public License (GPL) version of Kermit,
called G-Kermit, and you can find it in many
operating system distributions. However, it is strictly a remote-end file
transfer program and does not include the communication, scripting, security,
and other features of C-Kermit, Kermit 95, and MS-DOS Kermit.
About the larger licensing question, here's a discussion from a 2001
newsgroup thread:
On 25-Feb-2001 in one of the Linux newsgroups, somebody wrote, explaining
why they did not use C-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 (except that as programming jobs go offshore,
you're not likely to get ANY job).
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. (More and more
people are waking up to the necessary connection between labor and
compensation. Free software is a fine idea when everybody has a job and
time to work on software too. Now that programming jobs are increasingly
scarce, the true meaning of the free software movement begins to emerge --
READ THIS).
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 and E-Kermit
sales and licenses,
support contracts,
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's Text-Mode Interface Is a Throwback".
The time you invest in learning a command language pays off again and again as
you use it to automate complicated or repetitive tasks, especially when you
can depend on it not to lock you into a particular platform or change out from
under you in ways that break all your procedures.
"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
All Kermit software could be "free in the sense of freedom" if the Kermit
Project were dependably funded to produce free software, but this has not
been the case since about 1984.
:
: 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.)
Kermit Protocol / Columbia University /
kermit@columbia.edu /
29 June 2004