June, 1988
Kermit News is published periodically free of charge by Columbia University, Center for Computing Activities, 612 West 115th Street, New York, NY 10025, USA, phone 212-280-3703.
Editor: Christine Gianone
The Kermit file transfer protocol is named after Kermit the Frog, star of the television series The Muppet Show, used by permission of Henson Associates, Inc.
Christine Gianone Columbia University, New York City
Welcome to the third issue of Kermit News. This newsletter is published whenever enough news is gathered to report, and time permits. The two previous issues were Volume 1, Number 1 (July 1986) and Volume 2, Number 1 (November 1987). We hope to publish the newsletter more frequently in the future.
The Kermit newsletter attempts to inform Kermit users of new developments and report on some of the varied Kermit uses. Readers who are using Kermit in especially unusual, interesting, or beneficial ways are encouraged to submit articles of about 500 words for publication in future issues. Testimonials from satisfied Kermit users are always welcome too.
Everyone is permitted to copy and redistribute Kermit programs so long as it is not done for profit. If you make fixes, changes, improvements, or write new documentation of general interest, or especially if you develop a Kermit program for a system that didn't have one before, you are encouraged to send your work back to Columbia University so that we can maintain a definitive and comprehensive set of Kermit implementations for further distribution.
DEC's large systems, the DECsystem-10 and DECSYSTEM-20, have begun to sail smoothly into eternity. Our own DEC-20, CU20B, home of Kermit Distribution since its beginning in 1981, will be retired this Fall. After that time we will no longer be able to provide DEC-20 DUMPER or DEC-10 BACKUP/Interchange format tapes! If you need tapes in this format, this is your last chance to order. This offer expires September 1, 1988.
By popular demand, we have added some new items and formats to our catalog, which you may select on the enclosed order form:
Thanks to Digital Equipment Corporation for an equipment grant that allows us to make the MicroVAX TK50s and RX50s, and to International Business Machines for providing a PS/2 for 3.5-inch and 5 1/4-inch diskette production.
In the Summary of Recent Releases on the inside back cover you will see some of our current diskette and tape volunteers. If you would like to add your name to the list, please contact Kermit Distribution. Even better, perhaps, if you know of a user group for your kind of computer that does non-profit mail-order software distribution, please submit Kermit to them and let us know.
In November, 1987, Frank and I were invited to Tokyo to teach a Kermit course and give a Kermit presentation at Japan DECUS (Digital Equipment Corporation User Society). The course, Fast-Paced Introduction to Kermit, was conducted in English with Japanese translation. It covered the basics of terminal emulation and file transfer between MS-DOS PCs and VAX/VMS, with a brief introduction to RS-232 asynchronous data communication and modems, and techniques for troubleshooting.
The presentation, Kermit: Current Status and Future Directions, was similar to the one prepared for Nashville DECUS in April 1987, except for the UN-style simultaneous translation and headphones, the guest speakers, and the news itself. We discussed Kermit's history, design and philosophy, gave a brief overview of the major new releases, and talked about Kermit performance issues and how they are addressed by compression, long packets, and sliding windows. Then Japan's "Kermit-san, considerations for Japanese Kermits: implementations for Japanese computers, translation among the many computer representations for the different forms of Japanese text (Kana, Kanji, Romaji), Japanese-language Kermit documentation, and Kermit distribution in Japan. We were charmed by the generous hospitality of our hosts, and gratified by the high level of interest in, knowledge of, and support for Kermit in Japan. Many thanks to Kohichi Nishimoto, Administrator of Japan DECUS, for sponsoring the trip.
In March of this year, we were invited to Switzerland DECUS at St. Gallen to conduct a course, Advanced Kermit: Use, Installation, and Support, designed for computer professionals who are responsible for Kermit within their organizations. Unlike Japan, Switzerland has no common language, so Swiss DECUS is conducted in English. The all-day course was quite successful, and well-attended despite the blizzard outside. The topics ranged from tutorials in Kermit use and data communications to customization via script construction and key redefinition, illustrated using a MicroVAX 2000 and a Toshiba laptop connected to a projection screen. We are grateful to David Guerlet, Swiss DECUS Chairman, for the invitation and for his gracious hospitality. Course handouts included the new MS-DOS Kermit 2.30 and manual, plus MS-DOS Kermit documentation translated into German by Gisbert W. Selke of the Wissenschaftliches Institut der Ortskrankenkassen in Bonn, whom we had the opportunity to meet with in Ludwigsburg, West Germany.
Later in the month we met with the "Club Kermit Club Kermit is a non-profit association, founded by Jean Dutertre, devoted to the distribution and promulgation of Kermit in France. Club Kermit may be contacted at 9 Av. Vergriand, 78600 Maisons Laffitte, France.
The entire Kermit Distribution collection was presented to both Japan and Switzerland DECUS, as well as to Club Kermit in France.
Kermit User Guide, 7th Edition (May 1988). Detailed instructions for use of selected Kermit programs. New chapters for MS-DOS Kermit 2.30, UNIX Kermit 4E, IBM 370 Kermit 4.0 for VM/CMS and MVS/TSO, VAX/VMS Kermit 3.3, DEC-20 Kermit 4.2, PDP-11 Kermit 3.58, Apple II Kermit 3.81, Macintosh Kermit 0.9, and CP/M-80 Kermit 4.09. The printed version is typeset, with boldface, italics, underlining, etc, used to clarify the examples. The 7th edition of the User Guide is much thicker than the 6th, hence the higher price. Selected chapters are available separately: MS-DOS, Macintosh, UNIX, VMS.
Kermit, A File Transfer Protocol, by Frank da Cruz, Digital Press (1987). An introduction to, and comprehensive reference on, Kermit: its purpose, its use, its commands, its design. Complete with tables, illustrations, tutorials, appendices, a glossary, etc, as well as a troubleshooting guide and a complete specification of the Kermit protocol, with programming examples in the C language. Review clips:
Info-Kermit Digest, 1985-present. This is the electronic Kermit newsletter, issued approximately twice monthly, to thousands of readers on the international academic computer networks BITNET/EARN, CSNET, CCNET, etc, with contributions from Kermit users and developers all over the world. Printed versions are now available, paginated and indexed for easy reference. Included are announcements of new releases, discussions of proposed new features of the protocol, problems and solutions.
The Info-Kermit Digest was an Internet/Bitnet/CSnet/etc mailing list from 1983 to 1995. Here are the complete archives:
mail.83a • mail.84a • mail.84b • mail.85a • mail.85b • mail.86a • mail.86b • mail.87a • mail.88a • mail.88b • mail.89a • mail.89b • mail.90a • mail.90b • mail.91a • mail.91b • mail.92a • mail.92b • mail.93a • mail.93b • mail.94a • mail.94b • mail.95aThe Kermit newsgroups were started in 1994 and once they took root the mailing lists were phased out:
comp.protocols.kermit.announce (announcements, moderated, now defunct)
comp.protocols.kermit.misc (discussion, unmoderated)
Short on the heels of version 2.30 of MS-DOS Kermit comes another new release, this time 2.31, also from Professor Joe R. Doupnik of Utah State University. But before talking about 2.31, let's correct a major omission in the announcement of 2.30 in the last issue: Tektronix graphics terminal emulation. IBM PC Kermit 2.30 and later includes emulation of the Tek 4010, plus some 4014 line drawing features, on most popular displays, including CGA, EGA, Hercules, Olivetti, AT&T, and even character-mode simulation on systems with no graphics boards at all!
Major new features for version 2.31 include expanded support for local area networks (see article on page 4), and new support for Kermit file attribute packets, so that file sizes, creation dates, and other information can be conveyed along with the file itself (page 6). And there's now a transaction log, so that you can come back after a long unattended file transfer session and find out what happened.
But the biggest change for 2.31 is in the script and macro language. It is now possible to define variables, to call macros with parameters, to construct loops, to perform conditional GOTOs, to reexamine previous INPUT strings, to delay operations until a predetermined time of day, and much more.
Thanks once again to Joe for his excellent work and generous spirit, and to the many beta testers for bug reports and fixes. MS-Kermit 2.31 is available on Tape A, prefix MS, and on diskette.
Since MS-DOS Kermit runs on so many different machines, not all versions are updated at once. IBM PCs and compatibles are done first, with other systems like Rainbow, Sanyo, HP, NEC, and Victor following later. As of press time, version 2.31 is available only for the IBM's and compatibles, the DEC Rainbow, the HP-150, and "generic MS-DOS."
As of 0.9, MacKermit has been translated into Apple MPW C, so that it can be edited, compiled, and built on the Macintosh itself. Previous versions had to be cross-compiled on a Unix system. MacKermit's new features include correct operation on the Mac II and SE; compatibility with all Macintosh keyboards; long packet support; a built-in, expanded key redefinition function; expanded server operation; multifile (folder) send; screen capture; transaction logging; Multifinder support; improved VT102 emulation, including the addition of smooth scrolling; and a new manual.
Thanks to everyone who tested different prereleases of this program since last October, and apologies to those of you who ordered MacKermit from us in the last several months and received a 0.9(36) beta-test copy without an up-to-date manual. And many thanks to Paul and Matthias for putting this release together and making it available. Both the new MacKermit and the old MacKermit (version 0.8(34) for the 128K Macintosh) are available on Tape B, prefix CK, and on Macintosh diskette.
Kermit-370 retires several redundant versions of TSO and CMS Kermit, in particular the venerable 1.0 for TSO, which had separate incarnations for each of several types of front ends. Kermit-370 is available on Tape B, with file prefix IK. It is distributed in IBM 370 assembly language source form, with complete assembly and installation instructions.
New features for this version include a selection of terminal emulations; standardized file transfer command syntax; command-line arguments; command and initialization files; TYPE, PRINT, and COPY commands; increased speed on DIRECTORY and wildcard SEND operations. The program is written in 8080 assembly language, and can be assembled using LASM or the Microsoft M80 assembler.
Many thanks to Bertil for this long-term effort, to Alan Phillips and Steve Jenkins at Lancaster University for sending this new version to us via transoceanic magnetic tape, and to the many others in the UK and elsewhere who contributed to the new release. CP/M-80 Kermit 4.09 is available on Tape A, prefix CP. As always, diskette volunteers and user-group diskette distribution are welcome!
Joe R. Doupnik Utah State University
About one year ago Local Area Network support was incorporated in MS Kermit for IBM PCs, thanks to support and advice from AT&T. In contrast to the common use of LANs to connect workstations to network fileservers, Kermit uses the LAN to talk to other Kermits or to selected mainframe hosts; this is called peer-to-peer or any-to-any communications. The same MS Kermit program for IBM PC's which happily talks over a modem or a direct RS-232 connection can also use almost all popular LANs. These days when offices are wired for LANs but not RS-232, it is nice to know that Kermit can exploit the new high speed technology.
How does Kermit connect to a Local Area Network? Three kinds of network connections can be made. The first kind is through the industry standard NetBios interface (interrupt 5CH) which is supplied with virtually all current LAN systems. The Kermit command
SET PORT NET host-name
selects the LAN's NetBios channel, rather than the familiar serial port, and attempts to connect to the named host system. That is the only Kermit command which distinguishes network from serial port operations; everything else is exactly the same. All the LAN-specific work is carefully hidden behind the scenes and operates automatically. A BREAK signal can even be sent across STARLAN and Ungermann-Bass systems.
NetBios systems use names for each station and each active Kermit makes a unique name for itself. Connections to other Kermits are done by name. This technique works well even on LAN systems such as Novell Netware which do not otherwise really use NetBios names.
The second connection method is to send and receive through a vendor-supplied intercept package which masquerades as a serial port. Many LANs and X.25 systems provide such packages. The Kermit command
SET PORT BIOSn (n = 1..4)
tells Kermit to use the system Bios so that the interceptor can capture traffic. Commonly, one "logs on terminal (Kermit's Connect mode) and telling the interceptor the name of remote host, terminal type, and so forth according to the rules of the LAN system. Thereafter, Kermit operations are the same as using a modem or wired line. (BIOSn support requires 2.31.)
A third connection method is the Ungermann-Bass NetOne LAN system through UB's specialized NETCI (interrupt 6BH) LAN calls. The Kermit command
SET PORT UB-NET1
starts such a connection. Further "logon terminal emulator. UB support was provided by Rene Rehmann in Switzerland, and Henrik Levkowetz in Sweden. This kind of connection directs traffic to an outgoing bridge which simulates ordinary asynchronous character terminal activity to modems and other computers. (NetOne support is available only in Kermit version 2.31.)
What can MS Kermit do across a LAN? First, it works fast! As fast as the computers at each end can execute Kermit, roughly 40,000+ bits per second between standard AT's.
Second, Kermit can talk to other Kermits on the network as a Client (requestor) Kermit to a Server Kermit. Many such pairings can be active simultaneously without disturbing normal LAN operations. Each pair uses the NetBios unique names to make a formal connection, or "virtual circuit. Kermits can be named Servers and provide file exchanges between cooperating stations, at the whim of individual users. A Kermit Server (using the NetBios connection) left running all day can attend to many clients, one at a time of course. Since Kermit is not a Terminate-Stay-Resident program, workstation memory is freed when communications are finished.
Third, Kermit can act as a decent terminal (VT102, VT52, Heath-19 for text, and Tektronix 4010+ for both text and color graphics) for connections to mainframes and X.25 systems joined to the LAN; this seems to be one of the most popular options. Of course, where terminal traffic can flow usually one may find another Kermit to support file transfers.
What MS-Kermit cannot do: Well, it does not know how to converse with the LAN fileserver even though the network's pseudo disk drives work fine with Kermit. The reason is filesevers talk arcane proprietary languages across the LAN. Similarly, it does not know about other specialized operations associated with LAN servers, such as asynchronous modem servers, unless the LAN vendor supplies software replacing the normal serial port driver on the workstation (some X.25 systems and UB do this).
Kermit cannot act as a bridge to relay traffic from one source, say the LAN workstation, to another destination such as an attached modem. Kermit says "Packets stop here," to borrow from Harry Truman.
What is needed to use MS Kermit across a LAN? One each: MS-Kermit version 2.30 or later for IBM PCs (2.31 for BIOSn or NetOne support), a LAN of arbitrary size and manufacture, a matching LAN adapter board for the PC set to LAN adapter board number zero. Mix well, enjoy.
John Chandler Harvard University
Kermit-370 release 4.0 (for CMS and TSO and, potentially, other operating systems on IBM/370-type mainframes) has introduced a new feature with importance to the transmission of long packets, namely, dynamic tailoring of the packet size to noise conditions on the communication line. The implementation in release 4.0 is a greatly simplified version of a more detailed model that will be sketched out here. In essence, the model rests on a few simple assumptions:
With these assumptions, it is relatively straightforward to compute the throughput of a Kermit transmission in data bytes per second, given the relevant quantities:
In these terms, the throughput is:
(P-X) × exp(-P / (VL × TL ))
————————————————————————————
(P+5+B) × (1/VL +1/VC) + TD
A plot of throughput versus packet size for this model has a characteristic
shape, rising sharply at small P, then leveling off and finally declining
gently at large P. Since the throughput goes through a maximum, there is an
optimum packet size, which can be found analytically from the expression for
throughput. Indeed, if the average time between errors is reasonably long,
i.e., if the mean number of characters transmitted between errors is much
greater than 20, and if TD is much less than TE , the
optimum packet size can be approximated by:
sqrt((X+5+B+D) × VL × TE )
where D = TD / (1/VL + 1/VC ) is the number
of bytes that could have been transmitted during the unavailable dead time.
In order to use this model, Kermit must have the theoretical quantities in terms of observable ones. For example, VL × TE is, in the long run, equal to the total number of bytes transmitted (both ways) divided by the number of errors, i.e., by the number of packets that must be resent. In short, Kermit can keep a running tally of bytes, packets, and retries during a transmission and from them compute the optimum packet size dynamically. If TD is negligible, then Kermit needs only a total of bytes sent (and received) and a count of bad packets. Otherwise, Kermit must also have available the line speed VL plus a count of packets exchanged and the elapsed time. From the tallied quantities, b, the total number of bytes exchanged; e, the number of error retries; p, the number of packet exchanges; and t, the elapsed time, a Kermit program can obtain the approximate optimum packet size in either of two ways. Assuming negligible dead time gives:
sqrt((X+5+B) × b/e)
which underestimates the optimum, and making allowance for large dead time
gives:
sqrt((b/p - (X+5+B)) × (VL × t - b) / e)
which overestimates by virtue of assuming that VC far exceeds
VL.
Kermit-370 has an implementation of the first expression, with the handy
value 16 substituted for X+5+B (which would be 15 for B=1 and 19 for B=3).
It is clear from the two expressions that the optimum cannot be calculated
if there are no transmission errors; the optimum length would be infinite,
and the packet size can be just what the other Kermit requested. When the
long-packet protocol is in effect, Kermit-370 checks after every 20 packets
during a SEND to see if there have been any errors and, if so, computes the
optimum packet length based on the formula and uses that optimum size as an
upper bound on subsequent packets. Simulations (with VL at 120
bytes/sec) have shown that this method, while typically forcing the packet
sizes to be smaller than optimal, achieves at least 94% of the maximum
possible throughput as long as TD
is not significantly greater than one second and achieves essentially 100%
when TD is less than half a second. At higher speeds, the dead
time is correspondingly more critical.
There are three main drawbacks to this simplified implementation. First, it does poorly with extreme TD (but that could be remedied by adding an informational SET SPEED to Kermit). Second, it responds slowly to changes in the noise environment (but that could be improved by replacing the cumulative tallies with shorter-term subtotals). Third, it fails insofar as assumptions 4 or 5 do. For example, if errors caused packets to disappear, thereby triggering timeouts as well as retransmissions, a quite different model would be needed.
Frank da Cruz
Columbia University, New York City
The basic Kermit protocol allows one computer to send files to another, so that each file arrives at its destination correctly and completely, under its own name. But there are times when file transfer could be more useful if the receiving computer knew a little bit more about the file: its type (text or binary), its size, creation date, protection, or record format. These characteristics are called "file attributes".
Users of MS-DOS Kermit, for example, have long been able to watch the comforting "Percent Done" display when sending files, but when receiving them this information is missing. If the sending Kermit was able to tell the receiver in advance how big the file was, then not only could the receiver display the percent done, but it could also check whether there was enough space available for the file before agreeing to accept it, saving needless aggravation when disks fill up. Certain systems even require preallocated disk space before a file can be sent.
The Kermit protocol defines a way for Kermit programs to convey file attribute information along with the files they send. This is called the Attribute packet. One or more A-packets can be sent following Kermit's File header packet, and preceding the file data, provided both Kermit programs agree to do this during the feature negotiation phase. If they don't agree, files are transferred in the normal way, without attribute information.
The first implementation of the file attribute mechanism was done by Brian Nelson of the University of Toledo, Ohio, for PDP-11 Kermit in April 1984. This was necessary because transferring the name and contents of a file alone was not sufficient for the PDP-11's sometimes complex file and record structure. By using Kermit's "system-dependent" file attribute field, PDP-11 Kermit is able to transmit a file's entire directory entry along with the file, so that when the receiver is a PDP-11, any file can be stored in exactly the same way as on the originating system.
Kermit defines a series of "generic" file attributes, including size, date, type, and system of origin to allow the transferred file to reflect the original as much as possible. One attribute of particular interest is "disposition" - what to do with the file after it arrives. Normally, Kermit simply stores it on the current disk. The disposition attribute allows the sender to tell the receiver to print it instead, or to send it as mail to a specified user, or to submit it as a batch job, or to run it as a program, or to archive it. MS-DOS Kermit 2.31, for instance, includes a MAIL command, which allows the PC user to transfer a file to a Kermit server for forwarding to the given user as mail (unfortunately, there are no Kermits yet that can respond to this command, but the ability to mail should appear in the next release of C-Kermit).
Kermit file attributes are described in Chapter 12 of the Kermit book. Additional attributes are expected to be defined in the future, for instance to allow for representation of text files during data transfer in other than 7-bit US ASCII format according to evolving ISO 8859 standards for international character sets.
Like other advanced options, file attribute capability is gradually finding its way into Kermit programs. Those that support it today include MS-DOS Kermit 2.31 (A:MS), IBM PC Turbo Pascal Kermit 1.1a (A:TP4), Kermit-370 4.0 for VM/CMS and MVS/TSO (B:IK), PDP-11 Kermit (B:K11), as well as some of the commercial Kermit implementations. Attribute support is planned for the next release of C-Kermit.
Micros and PCs: