Lynx (protocol)
Lua error in package.lua at line 80: module 'strict' not found.
Lynx is a protocol for the transfer of files over modems. The protocol uses a flow control batch data transmission protocol designed to achieve efficient, reliable, and flexibile file transfers. It was developed by Matthew Thomas in 1989.
Contents
Techniques
The Lynx protocol is based on the assumption that a connection between two sites is capable of full-duplex transmission. Lynx will send a stream of data while simultaneously polling the receive-buffer for any interruptions from the other end. On half duplex links this will not work, but almost all modems in use today are capable of full-duplex operation.[citation needed] Lynx makes use of full-duplex operations to insure efficient transfer speed. On certain occasions, after a file header is transmitted or after recovering from a line error, Lynx will wait for the other end to resynchronize.
Lynx can transfer up to 99 files in a single batch. Information which is passed from sender to receiver concerning each file includes:
- File name (8 character body, 3 character extension)
- Original time/date stamp (optional)
- File length (exact length of files is preserved by Lynx)
- Lynx version number (practically useless)
Lynx data transmissions are protected with CRC-32 error detection, and are recoverable either automatically by the protocol (Lynx will attempt to recover from up to twenty contiguous errors) or manually, by reconnecting (hoping for a cleaner connection) and using the resume option of Lynx. The resume option alerts the Lynx receive protocol to automatically test for the presence of a partially downloaded file before beginning the transfer, and to initiate the download at the point in the file where the last one ended, instead of resending the entire file.
During the course of the transmission, Lynx will adjust the block size from 2 packets up to 16 packets to optimize for speed on clean connections. A packet contains 64 bytes of data. The benefit of increasing the block size on error-free connections is in the fact that the overhead of block numbers, control sequences, and CRC-32 bytes is decreased for the entire file, actually decreasing the total number of bytes that must be transferred. Lynx will also shrink block sizes if continuous errors are detected in the connection. The benefit of this technique is that on an error-prone connection, short blocks take less time to retransmit (which is a natural occurrence during error recovery).
Lynx tests each block for compressibility before transmitting it. RLE compression is used for this operation. Generally, a block containing text information will be compressible. Archived, ZIPPED, or other compressed files will likely not be further condensed by this technique. Note that Lynx will always optimize transmission of each block, if RLE decreases the block length, it will be used; otherwise, the uncompressed packet will be sent. In some implementations of RLE encoding, the compression technique may actually increase the length of the data being encoded. This is not the case with Lynx.
Lynx supports CTS/RTS hardware handshaking. This type of handshaking is generally required when using Lynx at high speeds (9600 baud or faster). Modems such as the ATI 2400etc, the USR HST 14400, and other MNP or buffered modems require this type of handshaking.
Features
- Run-length encoding data compression on a block by block basis
- 32-bit CRC on each block for reliable error detection
- Fast recovery from data transmission errors
- Continuous data flow from the sender
- Block scaling for noisy connections
- Resume mode for recovery of crashed transmissions
- Passing full file name, size, date and time
- Up to 99 files may be transferred in a single batch
- Retaining exact file size
- Stamp received files with current or original time/date
- RTS/CTS handshaking
