4.2. Control-Character Unprefixing
This feature allows you to improve C-Kermit's file transfer performance on
connections that you know are transparent to certain control characters. It
lets you tell C-Kermit exactly which control characters need to be prefixed
and encoded, and which ones can be transmitted "bare" when sending files.
SET { SEND, RECEIVE } CONTROL-PREFIX <code>
Sets the control-character prefix which C-Kermit uses to the ASCII character
represented by the numeric <code>. The <code> must be in the range 33-63 or
96-126. Normally it is 35 (#, number sign). SEND is the one that C-Kermit
should use in packets it is sending. RECEIVE should normally never be used,
except to override some kind of protocol negotiation foulup with a buggy
commercial or shareware Kermit implementation.
Synonym: SET { SEND, RECEIVE } QUOTE.
SET CONTROL-CHARACTER UNPREFIXED { <code>..., ALL }
Says you think it's safe to include the control character represented by
<code> without prefixing in packets which C-Kermit sends. The <code> is the
numeric ASCII code for a control character, 1-31, 127-159, or 255. For
example, linefeed (code 10) is normally sent as two printable characters,
#J. SET CONTROL UNPREFIXED 10 lets linefeed be sent literally. Include the
word ALL to unprefix all control characters (except 0). Or you can specify
a list of one or more numeric values, separated by spaces, e.g.:
SET CONTROL UNPREFIXED 2 4 5 18 20
If you can safely declare a lot of control characters to be UNPREFIXED, you
can send binary files (esp. precompressed ones) up to about 20-25% faster.
If you include a control character in this category that causes trouble,
however, the transfer will fail, so experimentation is necessary. This
command will not let you "unprefix" the NUL character (0), nor the following
characters if C-Kermit's current FLOW-CONTROL setting is XON/XOFF: 17, 19,
145, 147. Nor can you unprefix character 255 on a TELNET connection (if
C-Kermit *knows* it's a TELNET connection).
SET CONTROL-CHARACTER PREFIXED { <code>..., ALL }
Says that the given control character(s) must be prefixed in Kermit packets.
By default, all control characters, 0-31, 127-159, and 255, are prefixed.
SHOW CONTROL-PREFIXING
Displays the current control prefix and a table of all control-character
values, showing 1 for each one that will be prefixed and 0 for each one that
will not be prefixed.
SET REPEAT PREFIX <code>
Sets the repeat-count prefix to the ASCII character represented by the
numeric <code>. Normally it is 126 (tilde). The <code> must be in the
range 33-63 or 96-126.
SET REPEAT COUNTS { OFF, ON }
Turns the repeat-count compression mechanism off and on. REPEAT COUNTS are
ON by default. Turn them OFF in case they cause trouble when used against a
faulty Kermit implementation in a shareware or commercial communications
program. Or when transferring precompressed files (like .ZIP or .Z files),
since it is very rare to find runs of repeated characters, and disabling the
repeat-count mechanism frees another character from prefixing, thus
resulting in slightly more efficient transfers.
The purpose of the SET CONTROL UNPREFIX command is to UNILATERALLY configure
C-Kermit to skip prefixing and printable encoding of selected control
characters to achieve higher performance when sending files. This feature
takes advantage of the fact that most Kermit programs will accept control
characters within packet data-fields literally, provided they get through at
all, and provided they do not have a special meaning to the receiving Kermit
program (such as, in many cases, the packet-start and packet-end characters).
There is no protocol negotiation between the two Kermit programs to determine
a "safe set" of control characters, and in fact any such negotiation would be
largely meaningless, because in most cases the two Kermit programs don't have
all the needed information. For example, there might be a terminal server or
PAD between them that is sensitive to a particular control character, even
though the two Kermit programs are not.
If you include in your SET CONTROL UNPREFIXED list one or more control
characters that are unsafe, any of several things might happen:
1. Transfer of any file containing these characters will fail.
2. The receiving Kermit program might be interrupted or halted.
3. Your connection might become hung, stuck, or broken. For example because
a control character causes a PAD, terminal server, modem, or similar
device to go from online mode to command mode.
The set of safe control characters depends on the two Kermit programs, their
settings, the host operating systems and their settings, the communication and
flow control methods, and all the devices, drivers, and protocols that lie
between the two Kermit programs. Therefore, this feature is recommended only
for use on well-known and often-used connections, so the time invested in
finding an optimal unprefixed control-character set will pay off over many
file transfers.
<give them a test file to transfer...>
You must be willing to experiment in order to achieve the optimal safe set.
To send the file to MS-DOS Kermit from either C-Kermit or MS-DOS Kermit,
try the following settings:
SET CONTROL UNPREFIXED ALL ; Turn prefixing off for all but 0
SET CONTROL PREFIXED 1 ; Turn it back on for packet-start character
SET CONTROL PREFIXED 129 ; and 8-bit version thereof
(HINT: Abbreviate SET CON U and SET CON P)
Or to send the file from MS-DOS Kermit to C-Kermit, tell MS-DOS Kermit to:
SET CON U ALL ; Turn prefixing off for all
SET CON P 0 ; Turn it back on for NUL
SET CON P 3 ; and for Ctrl-C
SET CON P 131 ; as well as Ctrl-C + parity bit
NOTE 1: 3 and 131 normally need not be prefixed when sending to C-Kermit
5A(190) or later, nor to 5A(189) if you have SET TRANSFER CANCELLATION OFF.
NOTE 2: 1 and 129 need not be prefixed when sending files *to* C-Kermit, but
must be prefixed when sending files to MS-DOS Kermit.
NOTE 3: 13 (carriage return, the customary packet terminator) normally need
not be prefixed when sending files to either C-Kermit or MS-DOS Kermit,
except on a TELNET connection (because TELNET servers are likely to change
CRLF into CR).
Try to send the test file in binary mode. If it works, fine. If not, try
prefixing some of the other likely control characters (see below). Once you
find the minimum set of prefixed control characters for the test file, it is
likely they will also work for any other file on the same connection. Try
sending a large precompressed (e.g. ZIP or .Z or GZIP) file. And, of course,
for maximum performance, also use a window size greater than 1 (say, 3) and a
packet length of 1000 or more.
Under ideal conditions (totally transparent and clean serial connection, no
Xon/Xoff, and C-Kermit has been told to SET TRANSFER CANCELLATION OFF, see
below), the minimum set of control characters that need to be prefixed is:
SENDER RECEIVER PREFIXED CONTROLS
MS-DOS Kermit MS-DOS Kermit 1 129
MS-DOS Kermit C-Kermit 0
C-Kermit MS-DOS Kermit 0 1 129
C-Kermit C-Kermit 0
For example, to set up C-Kermit to unprefix the minimum set of prefixed
control characters for sending files to MS-DOS Kermit, tell C-Kermit to:
SET FLOW NONE ; Or SET FLOW RTS/CTS
SET CONTROL UNPREFIX ALL
SET CONTROL PREFIX 1 129 ; C-Kermit always prefixes character 0
When the mininum set doesn't work, consult this list of control characters
that are apt to cause trouble and are therefore likely candidates for
prefixing. In particular, note that unprefixing of the packet-start character
(normally 1 and 129), can cause problems when sending to C-Kermit if the
communication link (including device input buffers) is noisy or apt to lose
characters.
set con p 0 ; Ctrl-@ = NUL, internal string terminator in C-Kermit.
; Also, often discarded as padding.
set con p 1 ; Ctrl-A = Packet-start character.
set con p 3 ; Ctrl-C = Packet breakout for remote-mode C-Kermit,
; packet breakout for server-mode MS-DOS Kermit,
; likely to cause interruptions on other systems.
set con p 13 ; Ctrl-M = Carriage return, packet-end character.
; Always prefix on TELNET connections.
set con p 14 ; Ctrl-N = Shift Out
set con p 15 ; Ctrl-O = Shift In
set con p 16 ; Ctrl-P = Commonly-used X.25/X.3 PAD escape character
set con p 17 ; Ctrl-Q = XON, must be prefixed with Xon/Xoff flow control
set con p 19 ; Ctrl-S = XOFF, must be prefixed with Xon/Xoff flow control
set con p 27 ; Ctrl-[ = ESC, prefix if going through some kind of ANSI device
set con p 28 ; Ctrl-\ = CONNECT-mode escape for C-Kermit
set con p 29 ; Ctrl-] = CONNECT-mode escape for TELNET
set con p 30 ; Ctrl-^ = Cisco terminal server escape.
set con p 127 ; Ctrl-? = DEL, often discarded as padding.
; Also becomes TELNET IAC if parity bit is added.
set con p 128 ; = NUL + 128 (i.e. NUL + parity bit)
set con p 129 ; = Ctrl-A + 128
set con p 131 ; = Ctrl-C + 128
set con p 141 ; = CR + 128
set con p 145 ; = XON + 128
set con p 147 ; = XOFF + 128
set con p 255 ; 255 = TELNET IAC, must be prefixed on TCP/IP TELNET connections
INCLUDING TELNET connections through terminal servers!
Note, by the way, that nothing special need be done for SLIP connections,
since the four special SLIP characters are in the G1 printable range:
192 SLIP END character
219 SLIP ESC character
220 SLIP END quote
221 SLIP ESC quote
Here is a suggested (conservative) starting point for experimenting with
control-character unprefixing. Tell the file sender to:
SET CONTROL UNPREFIX ALL
SET CONTROL PREFIX 0 1 3 13 17 19 127 129 131 141 145 147 255
Perhaps some of these can be removed, depending on the connection, and maybe
others need to be added. If you are going through a terminal server or an
intermediate Kermit or TELNET program, also add the appropriate escape
character values (bare, and plus 128).
Kermit will not let you unprefix XON (17), XOFF (19), XON+128 (145), or
XOFF+128 (147) if its FLOW-CONTROL setting is XON/XOFF. If you want to
unprefix these, make sure *both* Kermits have first been told to SET FLOW
NONE (or RTS/CTS), and that XON/XOFF flow control is not in effect anywhere
along the communication path between the two Kermits.