ckcbwr.txt

C-Kermit源码。是使用串口/Modem和网络通讯的程序

Most modern modems support RTS/CTS (if they support any hardware flow control
at all), but some computers use different RS-232 circuits for the same
purposes, e.g. DTR and CD, or DTR and CTS.  In such cases, you might be able
to make your computer work with your modem by appropriately cross-wiring the
circuits in the cable connector, for example the computer's DTR to the modem's
RTS, and modem's CD to the computer's CTS.  HOWEVER, C-Kermit does not know
you have done this.  So if you have (say) SET FLOW DTR/CD, C-Kermit will make
no attempt to tell the modem to use RTS/CTS.  You probably did this yourself
when you configured the modem.

(7.2) ESCAPE SEQUENCE GUARD TIME

A "TIES" (Time-Independent Escape Sequence) modem does not require any guard
time around its escape sequence.  The following text:

+++ATH0

if sent through a TIES modem, for example because you were uploading this
file through it, could pop the modem back into command mode and make it hang
up the connection.  Newer versions of the Telebit T1600 and T3000 (version
LA3.01E firmware and later), and all WorldBlazers, use TIES.

Although the probability of "+++" appearing in a Kermit packet is markedly
lower than with most other protocols (see the File Transfer section below), it
can still happen under certain circumstances.  It can also happen when using
C-Kermit's TRANSMIT command.  If you are using a Telebit TIES modem, you can
change the modem's escape sequence to an otherwise little-used control
character such as Ctrl-_ (Control-Underscore):

  AT S2=31

A sequence of three consecutive Ctrl-_ characters will not appear in a
Kermit packet unless you go to extraordinary lengths to defeat more than a few
of Kermit's built-in safety mechanisms.  And if you do this, then you should
also turn off the modem's escape-sequence recognition altogether:

  AT S48=0 S2=255

But when escape sequence recognition is turned off, "modem hangup"
(<pause>+++<pause>ATH0<CR>) will not work, so you should also be sure to SET
DIAL MODEM-HANGUP OFF.


(8) TERMINAL SERVERS

How to DIAL from a TCP/IP reverse terminal server (modem server):

 1. (only if necessary) SET TELNET ECHO REMOTE
 2. SET HOST <terminal-server-ip-name-or-address> [ <port> ]
 3. SET MODEM <modem-type>
 4. (only if necessary) SET DIAL HANGUP OFF
 5. DIAL <phone-number>

The order is important.

Watch out for terminal server's escape character -- usually a control
character such as Ctrl-Circumflex (Ctrl-^).  Don't unprefix it in Kermit !

Ciscos -- must often be told to "terminal download"...  Cisco ASM models don't
have hardware flow control in both directions.

Many terminal servers only give you a 7-bit connection, so if you can't make
it 8-bit, tell Kermit to "set parity space".

The following story, regarding trouble transferring 8-bit files through a
reverse terminal server, was contributed by an Annex terminal server user
(begin quote):

Using C-Kermit on an HP 9000 712/80 running the HP-UX 10.0 operating system.
The HP was connected to a Xylogics Annex MICRO-ELS-UX R7.1 8 port terminal
server via ethernet.  On the second port of the terminal server is an AT&T
Paradyne 3810 modem, which is connected to a telephone line.  There is a
program which runs on the HP to establish a Telnet connection between a serial
line on the Annex and a character special file on the HP (/dev file).  This is
an Annex specific program called rtelnet (reverse telnet) and is provided with
the terminal server software. The rtelnet utility runs on top of the
pseudo-terminal facility provided by UNIX.  It creates host-originiated
connections to devices attached ot Annex serial ports.  There are several
command line arguments to be specified with this program: the IP address of
the terminal server, the number of the port to attach to, and the name of the
pseudo-device to create.  In addition to these there are options to tell
rtelnet how to operate on the connect: -b requests negotiation for Telnet
binary mode, -d turns on socket-leve debugging, -f enables "connect on the
fly" mode, -r removes the device-name if it already exists, etc.  The most
important of these to be specified when using 8 data bits and no parity, as we
found out, was the -t option.  This creates a transparent TCP connection to
the terminal server.  Again, what we assumed to be happening was that the
rtelnet program encountered a character sequence special to itself and then
"eating" those kermit packets.  I think this is all of the information I can
give you on the configuration, short of the values associated with the port on
the terminal server.  If I can provide any other details, just let me know.
Thanks again for your help.

(end quote)


(9) TERMINAL EMULATION

Except for the Windows, OS/2, and Macintosh versions, C-Kermit does not
emulate any kind of terminal.  Rather, it acts more or less as a "transparent
pipe", passing the characters you type during a CONNECT session to the remote
host, and sending the characters received from the remote host to your screen.
Whatever is controlling your keyboard and screen provides the specific
terminal emulation: a real terminal, a PC running a terminal emulator, etc, or
(in the case of a self-contained workstation) your console driver, a terminal
window, xterm, etc.

There are several exceptions to the "transparent pipe" rule:

 - During a TELNET ("set host") session, C-Kermit itself executes the
   TELNET protocol and performs TELNET negotiations.  (But it does not
   perform TN3270 protocol or any other type of 3270 terminal emulation.)

 - If you have changed your keyboard mapping using SET KEY, C-Kermit replaces
   the characters you type with the characters or strings they are mapped to.

 - If you SET your TERMINAL CHARACTER-SET to anything but TRANSPARENT,
   C-Kermit translates your keystrokes (after applying any SET KEY
   definitions) before transmitting them, and translates received characters
   before showing them on your screen.

 - If your remote and/or local TERMINAL CHARACTER-SET is an ISO 646 7-bit
   national character set, such as German, French, Italian, Swedish, etc, or
   Short KOI used for Cyrillic, C-Kermit's CONNECT command automatically skips
   over ANSI escape sequences to avoid translating their characters.  Only
   ANSI/ISO standard (VT100/200/300-like) 7-bit escape sequence formats are
   supported for this purpose, no proprietary schemes like H-P, Televideo,
   Tektronix, etc.

 - If your version of C-Kermit includes SET TERMINAL APC command, then
   C-Kermit's CONNECT command will handle APC escape sequences if TERMINAL
   APC is not set to OFF (which is the default).

If you are running C-Kermit under a console driver, or in a terminal window,
that emulates the VT100, and use C-Kermit to log in to a VMS system, the
console driver or terminal window (not Kermit) is supposed to reply to the
"what are you?" query (ESC Z) from the VAX.  If it doesn't, and you can't make
it do so, then you can (a) live with the "unknown terminal" problem; (b) tell
VMS to SET TERMINAL/DEVICE=VT100; (c) program a key using SET KEY to send the
appropriate sequence and then punch the key at the right time; or (d) use the
VMSLOGIN macro that is defined in CKERMIT.INI to do this for you
automatically.

SET SESSION-LOG { TEXT, BINARY }, which is effective in UNIX and AOS/VS but
not other C-Kermit versions, removes CR, DEL, NUL, XON, and XOFF characters
("Using C-Kermit" neglects to mention that XON and XOFF are removed).  The
TEXT-mode setting is ineffective during SCRIPT command execution, as well as
on X.25 connections.


(10) KEY MAPPING

Except in the terminal-emulating versions, C-Kermit's key mapping facilities
are limited to normal "ASCII" keys, and cannot be used with function keys,
arrow keys, arcane key combinations, etc.  Since C-Kermit runs on such a wide
variety of hardware platforms (including, for example, more than 360 different
UNIX platforms), it is not possible for C-Kermit to support every conceivable
keyboard under every release of every UNIX (or VMS, or ...) product on every
different kind of computer possibly under all manner of different console
drivers.

In technical terms, C-Kermit uses the read() function to read keystrokes, and
read() returns a single byte (value 0 through 255).  C-Kermit's SET KEY
function applies to these single-byte codes.  "Extended function" keys, such
as F-keys, arrow keys, etc, usually return either a 2-byte "scan code" or else
a character string (such as an escape sequence like "ESC O p").  In both
cases, C-Kermit has no way to tell the difference between such multibyte key
values, and the corresponding series of single-byte key values.  This could
only be done by accessing the keyboard at a much lower level in a highly
system-dependent manner, probably requiring tens of thousands of lines of code
to support even a sampling of the most popular workstation / OS combinations.

However, most workstation console drivers (terminal emulation windows, etc)
include their own key-mapping facility.  For example, on an IBM RS/6000, the
AIXterm program (in whose window you would run C-Kermit) allows rebinding of
the F1-F12 keys to arbitrary strings.  The same might or might not be true of
DECterm windows, Sun "vttool" or "crttool" windows, etc.  Consult the
technical documentation for your workstation or emulator.

The SET KEY command (except in OS/2) does not allow a key definition to be
(or contain) the NUL (\0) character.


(11) THE TRANSMIT COMMAND

Session logging is inactive during the TRANSMIT command, even if you have
given a LOG SESSION command.


(12) FILE TRANSFER

C-Kermit 7.0 is the first release of C-Kermit to use fast (rather than robust
and therefore slow) protocol defaults: long packets, sliding windows,
control-character unprefixing, and streaming where possible.  This makes most
transfers (partner willing) dramatically faster "out of the box" but might
break some combinations that worked before.  If transfers with C-Kermit 7.0
fail where transfers worked with earlier C-Kermit versions, try the following:

 a. ROBUST: this command reverts to the most conservative protocol settings.
 b. CAUTIOUS: Selects medium but cautious protocol settings.
 c. SET PREFIXING ALL: Disables control-character unprefixing.
 d. SET STREAMING OFF: Disables streaming.

File transfer failures can occur for all sorts of reasons, many of them listed
in Chapter 10 of the manual.  Another one came up recently when using Kermit
on a certain laptop with its built-in modem: the modem's "auto timeout delay"
was hanging up the connection in the middle of a file transfer.  Most modems,
even if they have this feature, do not have it enabled by default.  But if you
experience otherwise inexplicable disconnections in the midst of your Kermit
sessions, check the modem manual for such things as "idle timeout", "auto
timeout", etc, and add the command to disable this feature to Kermit's init
string for this modem.

If you have a multihop connection, with the interior nodes in CONNECT
mode (Kermit, Telnet, Rlogin, or any other), you can expect (a) file transfer
to be slower, and (b) the connection to be less transparent (to control
characters, perhaps to the 8th bit) than a more direct connection.  C-Kermit
7.0 has a "-0" (dash-zero) command-line option to make it 100% transparent
in cases where it is to be used in the middle.

The recovery feature (RESEND command) that was added in edit 190 works only
for binary-mode transfers.  In order for this feature to be useful at all, the
default for SET FILE INCOMPLETE was changed from DISCARD to KEEP.  Otherwise
an interrupted transfer would leave no partial file behind unless you had
remembered to change the default.  But now you have to pay closer attention to
Kermit's messages to know whether a transfer succeeded or failed --
previously, if it failed, the file would not show up on the receiving end at
all; in edit 190 and later, you'll get a partial file which could easily be
mistaken for the complete file unless you change the default back to DISCARD
or read the screen messages, or keep a transaction log.

Watch out for SET FILE COLLISION RENAME, especially when used in conjunction
with recovery.  Recall that this option (which is NOT the default) renames
the incoming file if a file already exists with the same name (the default is
to rename the previously existing file, and store the incoming file with its
own name).  It is strongly recommended that you do not use SET FILE COLLISION
RENAME if you ever intend to use the recovery feature:

 . When the file is first received by C-Kermit, its name will be changed if
   another file already has the same name.  When you RESEND the same file
   after a failure, C-Kermit will probably try to append the re-sent portion
   to the wrong file.

 . Assuming that you get RESEND to work with FILE COLLISION RENAME, C-Kermit,
   when receiving the remainder of the file during a RESEND operation, will
   report back the wrong name.  Nothing can be done about this because the
   name is reported back before the receiving Kermit program finds out that
   it is a recovery operation.

Also watch out for DISABLE DELETE, since this implicitly sets FILE COLLISION
RENAME.  And note tht DELETE is DISABLEd automatically any time you Kermit
is in local mode (i.e. it makes a connection).  Also note that for purposes
of DISABLE and ENABLE, "set host *" connections do not count as local mode
even though, strictly speaking, they are.

When using ADD SEND-LIST and entering a wildcard in the list, there is no way
to specify "automatic switching" -- the file type still must be text or
binary.  To work around, use regular expressions to create separate wildcards
for the text and binary files.

Automatic directory creation for received files does not work for pathnames
given in the "-a" command-line argument.

There are no command-line arguments for "set file names { literal, converted }"
or "set { send, receive } pathnames { on, off }", but you can include these
(or any other) commands on the command line in the -C option string.

When referring to MS-DOS, Windows, Atari ST, OS/2, or other file
specifications that contain backslash characters in a C-Kermit command, you
might have to double each backslash, for example:

  C-Kermit>get c:\\directory\\foo.txt

This is because backslash is used in C-Kermit commands for introducing special
character codes, variables, functions, etc.  If you are sending this GET
command to another copy of C-Kermit running as a server, for example on OS/2
or the Atari ST, it too treats backslashes as prefix characters, so you will
need 4 (yes, 4) copies of each backslash:

  C-Kermit>get c:\\\\directory\\\\foo.txt

But read about SET COMMAND QUOTING OFF in the manual.

ANOTHER NOTE: In Kermit 95, this restriction is lifted as far as referring
to files on the local PC.  You can now refer to these files using natural PC
notation, e.g.

  C-Kermit>send c:\letters\oofa.txt

in any command field that knowingly parses a filename.

Attempting to cancel local-mode file reception at a very early stage (i.e.
before data packets are exchanged) with X or Z does not work.  Workarounds:
Use E or Ctrl-C instead, or wait until the first data packets are sent.

If you cancel a transfer that is underway using X or Z, and a lot of window
slots are in use, it might take a long time for the cancellation to take
effect, especially if you do this on the receiving end; that's because a lot
of packets might already be on their way to you.  In that case, just be