SMODEM

Smodem refers to a bidirectional protocol for file transfer used between modems and the DOS program in which the protocol is implemented, both of which were developed by a Finnish company named Arisoft. It was mainly used in bulletin board systems because it could transfer files in both directions at the same time and allowed users to chat with each other with AriSoft's GroupChat software. Other popular bidirectional protocols such as BiModem, HS/Link and HydraCom also offered a chat option with the operator, but not with the system's other users.

Smodem protocol overview
Unlike ZMODEM and other older protocols, SMODEM has a separate low-level multiplexed transfer layer (MSLP) and a high-level file transfer layer. This simplifies the protocol design and provides a very high efficiency of 99.5%. The multiplexing makes it possible to send one or more files in a continuous stream without any breaks between the files, boosting the throughput dramatically when transferring multiple files.

The multiplexing also made possible to add a full-screen ANSI terminal emulator with a local full-featured line editor and colored scroll-back buffer of 'unlimited' size. The locally buffered terminal emulation allowed users to chat during full-speed bidirectional file transfers.

The protocol is symmetrical and can connect with itself in loop-back mode. Files can be simultaneously transmitted and received without noticeable performance loss.

SMODEM detects DESQview and DPMI (Windows, OS/2) and releases all unused processor capacity to the host system. It is written in the C language and compiled with Microsoft Visual C++ v1.0 compiler, optimized for an 80286 CPU. It needs at least 200 kB free memory to function properly and more to allow shelling from the program. Files can not be transferred while the shell is being used.

Multiplexed Serial Link Protocol (MSLP)
MSLP has the capability to simultaneously manage 32 independent channels. Every single channel uses a traditional two-phase ACK/NAK type sub protocol. Maximum efficiency is achieved by simultaneously using multiple parallel channels to keep the transmitter busy.

The maximum packet size floats between 16 and 1024 bytes. Transfer errors reduce the packet size depending on error frequency. The transmitter window size (the total size of transmitted packets pending acknowledgment) can be limited to get a faster response.

The packet frame contains one byte for the channel number and two bytes for a 16-bit CCITT(ITU)-CRC, using the same algorithm as in error correcting modems. The acknowledgements and inquiries are included in the packet frame when needed.

The packet separators contain two bytes, which if found in transferred data, one additional byte is inserted for encapsulation of control data. The probability of the packet separator sequence appearing in random data is so small, that it does not affect protocol efficiency like old style one byte separators do.

The maximum efficiency in one-direction error-free transfers will be:

$$\frac{max\ packetsize}{max\ packetsize\ +\ frame\ size} = \frac{1024}{1024+5} = 0.9951 = 99.5\%$$

If the packet size is limited to 256 bytes, the efficiency is 98.1%, which is still better than original Zmodem.

If the data link can not transfer some special characters, then the traditional character encapsulation mode can be activated. In this mode the selected character codes are encapsulated, which reduces the performance by about 0.4% + additional 0.4% for every selected character code.

In case the data link is limited to seven data bits, a special bit collection mode can be activated. The highest bits for every seven bytes are collected to one byte (which is eight bits under normal conditions). This collection reduces the performance about 12.4% and doubles the character encapsulation capacity.

The maximum transfer line correction mode of MSLP uses five characters to transmit four characters that use only printable 7-bit ASCII codes (Ascii85). This mode should work on almost every non-transparent transmission line. The maximum correction mode reduces the performance by 20%. It should only be used for test purposes if the default settings do not work or if the limitations of transfer line are unknown or too complex to handle with separate adjustments.