Kermit protocol. Kermit is a well-known file transfer protocol used in numerous software packages designed for communication over telephone lines . Virtually any file transfer protocol used in microcomputers uses a basic unit called a packet: grouping of several elements or fields formed by bytes .
File transfer is the ability to transport files between two computers using two modems. Modems must employ a file transfer protocol, which can correct transmission errors and initiate the transfer process. Both modems must use the same protocol. When establishing a file transfer, the communications software will ask you to designate an appropriate protocol.
[ hide ]
- 1 Story
- 2 Features
- 1 Structure
- 3 Communication
- 4 Coding
- 5 Sources
- 6 External links
Kermit-uClinux transfer protocol.
Written by Frank Da Cruz and Hill Catchings in 1981 and is in the public domain for no commercial purpose. It was developed at Columbia University primarily as a method of transferring information between microcomputers and mainframes .
It is a well-known protocol that is used in numerous software packages designed for communication over telephone lines. Kermit can be used to transfer files or for terminal emulation. It is usually used with modem connections, although it also supports communications via other transport mechanisms, such as TCP / IP . Kermit is noted for its transmission precision and low transfer rates due to its default settings, optimized for the precision side. In the 1980s it was very important due to the proliferation of systems ( PC , Macintosh , Unix, mainframes) by recomposing 7 to 8 bit characters using a variable packet format. Depending on the noise conditions on the line, it can go up to 9 kB . It is a multi-file protocol that preserves the name and length of the files. It is usually successful when others fail.
It is not used by the general public, but Columbia University allows people to use the protocol for free, so almost all communications products support it. However, not all implementations support the full protocol. This has caused some people to refer to an advanced version of Kermit as Super Kermit. Currently, there is only one version of the Kermit protocol, which supports all the advanced features, usually attributed to Super Kermit, such as larger packages.
Kermit was carefully planned, with the future in mind (with what was then called universal compatibility), with expansion possibilities and great simplicity when sending filegroups. It does not have certain XModem restrictions ; although it is much more complex in its design and substantially slower than it. Like the latter, it is based on the sending of a block or package, waiting for confirmation of its correct reception, this being carried out with more than one character, unlike XModem, which only uses one octet. Its slowness is due to the fact that it sends small blocks of data, between 10 and 96 octets each, with several packaging characters in addition to encapsulating enough characters ( ASCIIor not) being subsequently expanded in two. It has a solid error check and is ready to send files with their names, dates and times without altering their sizes. However, its data compression method is simple, recovering the lost efficiency with the control characters. Its overall performance ranges from 50% to 66% of what XModem offers.
Its main characteristics are:
- The length of the blocks is variable and is indicated in the second character of the block.
- There are different types of blocks either: header, data, acknowledgment.
- Both devices do not exchange single characters, but always send blocks.
The structure of each block is as follows: the SOH character is sent first (first character, the only character less than 32; it is not modified). Below is the Length of the “characterized” message (length + 32). Then a character indicating the type of message. Example:
- “S” indicates starter package
- The “D” indicates Data.
- The “Y” indicates acknowledgment (ack).
- The “N” indicates non-recognition.
- The “Z” indicates end of file.
Then the data is sent, encoding those under 32, and finally the “characterized” checksum .
|| SOH ||| LENGTH ||| TYPE |||||||||||||| “DATA” ||||||||||||| CHECKSUM ||
The checksum or checksum will be in charge of protecting the integrity of the data, verifying that they have not been corrupted, it is a form of redundancy control of the data. The process consists of adding each of the basic components of a system (generally each byte) and store the result value. Subsequently, the same procedure is performed and the result is compared with the stored value. If both sums match it is assumed that the data has probably not been corrupted.
The development of a communication is as follows: the communication is initiated by the receiver sending a NAKand then the sender sends the initial block, in which the transmission parameters are indicated (maximum message length, maximum response waiting time, etc.). Then it waits for the receiver to send the correct or incorrect acknowledgment packet and if it does not recognize it, it is sent again. This process is done after sending each block. Once the initial block is sent, the file header block is sent, where the file name starts. The data blocks are then sent until the file is finished. Finally, the final block of the file is sent. If you want to send another file, the header block is sent again and the process is repeated from that point on. If you do not want to send more files, send the end of transmission block to end the process.
The Kermit protocol uses two strategies to deal with characters less than 32: characterization and encoding .
The characterization consists of adding 32 to the character and to decharacterize it it will therefore be necessary to subtract 32. This method is not used with data bytes, since for data greater than 223 it would not be valid.
The data bytes (Byte) are not encoded all, but only those less than 32 are encoded and for this the XOR function is done with the data and with 64. To decode it, the XOR function is done with 64 again. Likewise, the # character is inserted before the encoded data. If the # character is actually sent as data, then it is sent twice. The fact of not sending characters with ASCII codes less than 32, is due to the fact that in some systems these characters may be assigned a special mission that disrupts the operation of the transmission.