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: a grouping of several elements or fields made up of 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 a suitable protocol.
[ hide ]
- 1 History
- 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 information transfer 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 for transferring 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 stands out for its precision in transmissions and low transfer speeds 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 the 7 to 8 bit characters using a variable packet format. Depending on the noise conditions on the line, it can reach up to 9 kB . It is a multi-file protocol that preserves the name and length of the files. You are 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 led 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 packets.
Kermit was carefully planned with the future in mind (with what was then called universal compatibility), with expandability and great simplicity when sending groups of files. 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 packet waiting for the 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 many characters ( ASCIIor not) being subsequently expanded in two. It has robust error checking and is ready to send files with their names, dates and times without altering their sizes. However, its data compression method is straightforward, making up for lost efficiency with control characters. Its overall performance ranges from 50% to 66% of that offered by XModem.
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: header, data, acknowledgment.
- Both devices do not exchange individual characters, but always send blocks.
The structure of each block is as follows: first the SOH character is sent (first character, the only character less than 32; it is not modified). Then the Length of the “characterized” message (length + 32). Then a character that indicates the type of message. Example:
- The “S” indicates initial package
- The “D” indicates Data.
- The “Y” indicates acknowledgment (ack).
- The “N” indicates no recognition.
- The “Z” indicates end of file.
The data is then sent, encoding those under 32, and finally the “characterized” checksum .
|| SOH ||| LENGTH ||| TYPE ||||||||||||| “DATA” ||||||||||||| CHECKSUM ||
The checksum or verification sum will be in charge of protecting the integrity of the data, verifying that they have not been corrupted, it is a form of data redundancy control The process consists of adding each of the basic components of a system (generally each byte) and store the value of the result. Later the same procedure is carried out and the result is compared with the stored value. If both sums agree, 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 by sending a NAKand then the sender sends the initial block, in which the transmission parameters are indicated (maximum message length, maximum response time, etc.). Afterwards, we wait 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 each block is sent. Once the initial block is sent, the file header block is sent, where the name of the file is started. 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, the end of transmission block is sent to finish the process.
The Kermit protocol uses two strategies to handle characters less than 32: characterization and encoding .
The characterization consists of adding 32 to the character and to de-characterize 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 bytes (Byte) of data are not encoded all, but only those under 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 that characters with ASCII codes less than 32 are not sent is due to the fact that in some systems these characters may be assigned a special mission that disrupts the operation of the transmission.