[ Previous ] [ Next ] [ Index ] [ C-Kermit Home ] [ Kermit Home ]
Article: 10886 of comp.protocols.kermit.misc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Case Study #3: Autodownload
Date: 9 Jan 2000 15:32:17 GMT
Organization: Columbia University
Today we're showcasing C-Kermit's "autodownload" feature. Kermit 95 and MS-DOS Kermit have this feature too. If you use Kermit as a terminal emulator (or in C-Kermit's case, to make terminal connections) and for file transfer, autodownload makes file transfer ridiculously easy.
First, recall the contortions needed when you don't have this feature: you have to tell Kermit on the host to send (or receive), then "escape back" to your terminal emulator, tell it to receive (or send), wait for the transfer to complete, and then tell your terminal emulator to resume terminal emulation. Four steps, not counting the waiting. With autodownload, there's just one step.
To illustrate, let's say you have a Linux PC on your desk, and you use C-Kermit 7.0 there to place a call (or make a Telnet connection) to a VMS host, which also has C-Kermit. You log in, read your mail, etc, and then when you want to send (download) a file, say oofa.txt, from VMS to Linux, you just tell VMS C-Kermit to send it. Assuming VMS C-Kermit is installed correctly, you simply type:
kermit -s oofa.txt
at the DCL prompt. Ditto if this were UNIX instead of VMS, except in UNIX it's the "shell prompt". Ditto for AOS/VS, except there it's the "CLI prompt", and so on. (Of course you could also start C-Kermit and type "send oofa.txt" at the C-Kermit> prompt, and then exit when done, but who needs the extra steps?)
Now, after a second or two (or more -- we'll discuss the delay below), Kermit on the host sends its first file-transfer packet, and C-Kermit on your desktop PC recognizes it and instantly switches from terminal mode to file-transfer mode, in which it puts up a running progress display, in most cases complete with thermometer and statistics. When the transfer is complete, C-Kermit automatically goes back to its terminal screen.
That's it; that's autodownload. Try it! Notice that, after making the initial connection, you never had to interact directly with your desktop Kermit again. Even when (eventually) you log out from the host, your desktop Kermit pops back to its prompt automatically when the connection closes. Thus, you control everything from within the terminal screen by the commands that you give to the host. All that confusing "escaping back" and "reconnecting" is no longer needed.
What about uploading? It works exactly the same way, except in this case you have to tell the host Kermit to GET a file, rather than to SEND one. Suppose you have just saved a web page from your Web browser on your PC (as, say, "oofa.html") and you want to upload it to the host. Just give the following command at the DCL (shell, CLI, ...) prompt on your host:
kermit -g oofa.html
(Or equivalently, start C-Kermit on the host, tell it to "get oofa.html", and then exit when done.)
When your desktop Kermit sees the first packet, it automatically pops back to file-transfer mode and awaits further instructions from the host Kermit, which then sends the name of the file it wants; your desktop Kermit sends the file and then returns to the terminal screen automatically when done.
Now let's talk about the delay. If it takes a little while for the transfer to start, it's because (a) the host Kermit is processing its initialization file; (b) it has its DELAY parameter set to some annoying number of seconds, like 5 or 10 or 20; or (c) both. The DELAY parameter is there for the benefit of terminal emulators that don't have the autodownload feature. It gives the user time to manually put the emulator into the appropriate file-transfer mode. But we don't need a delay if we are autodownloading. The way to get rid of it is to include:
set delay 0
in the host Kermit's initialization or customization file, or to include the equivalent "-D 0" command-line option:
kermit -D 0 -g oofa.html
Now let's consider the host Kermit's initialization file. The standard C-Kermit initialization file is rather big -- it defines all sorts of macros and services that you won't need in this situation. However, it also "chains" to your customization file, where you might well have set some performance-enhancing parameters to override Kermit's (former) conservative default settings.
But C-Kermit 7.0, unlike its predecessors, uses fast settings by default because computers and connections are much faster and more reliable now than they were when the Kermit protocol was first designed. So C-Kermit on the host doesn't need to execute its initialization file -- or your customization file -- at all, unless you are actually making a connection FROM the host to somewhere else.
There are two ways to start host Kermit without executing its initialization file. First, you can change the name of the standard initialization file so C-Kermit won't find it automatically (and then explicitly execute it any time you actually need it), and second you can give the -Y (uppercase) command-line option, which tells C-Kermit to skip its initialization file:
kermit -YD 0 -g oofa.html
If the host is VMS, you have to enclose uppercase command-line items in doublequotes:
kermit "-YD" 0 -g oofa.html
Since the -Y option does not take an argument, it can be "bundled" before the -D option. But it need not be; the following is OK too:
kermit -Y -D 0 -g oofa.html
Finally, if the remote host is UNIX, you might consider using G-Kermit there instead of C-Kermit. It's perfect for use with a Kermit autodownload-capable terminal emulator on your desktop -- in fact, that's what it's designed for. G-Kermit is small, its delay is 1 second, and it has no initialization file to slow it down:
gkermit -s oofa.txt gkermit -r oofa.html
In most cases, G-Kermit goes just as fast as C-Kermit.
Still reading? OK... Are there any situations where autodownload is a BAD thing? Indeed there are. First, consider a multihop connection in which both your desktop computer and the intermediate one are capable of autodownloads. When the remote(st) Kermit sends its first packet, BOTH Kermits see it at the same time, both automatically enter file-transfer mode, and both reply to it. This can't work. C-Kermit 7.0 solves this problem by filtering out "autodetected" packets and not passing them down the line, but earlier versions don't do this.
A second scenario in which autodownload is inappropriate is when you are using your terminal emulator to look at a C-Kermit packet log on the host. (Try it some time :-)
In such situations, you can disable autodownload in C-Kermit with the command:
SET TERMINAL AUTODOWNLOAD OFF
You would also do this on a multihop connection when you want the intermediate C-Kermit to be the transparent one, and autodownloads to go through it to your desktop. There is, by the way, a (new) C-Kermit command-line option that tells it to be 100% transparent, intended for exactly this situation: "C-Kermit in the Middle":
kermit -0
(that's hyphen followed by digit 0). This sets TERMINAL AUTODOWNLOAD OFF, disables the escape character, APC, and everything else.
Still there? Perhaps you're wondering if autodownload works with external protocols like Zmodem? In a word, yes. If you have a Zmodem program that works with C-Kermit as an external protocol, then C-Kermit will indeed start it up automatically when you initiate a Zmodem download from the host. AutoUPloads, however, are not possible with Zmodem. External protocols are described in detail in the manual, Using C-Kermit, Chapter 14.
- Frank
[ Top ] [ Previous ] [ Next ] [ Index ] [ C-Kermit Home ] [ Kermit Home ]
C-Kermit 7.0 / Columbia University / kermit@kermitproject.org / 9 Jan 2000