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 Sets the control-character prefix which C-Kermit uses to the ASCII character represented by the numeric . The 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 { ..., ALL } Says you think it's safe to include the control character represented by without prefixing in packets which C-Kermit sends. The 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 { ..., 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 Sets the repeat-count prefix to the ASCII character represented by the numeric . Normally it is 126 (tilde). The 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. 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.