UNIX and Modems Introduction to Modems

AT commands are beyond the scope of this text; we will strictly address UNIX modem−related issues. However, AT commands are parts of communication programs which support data transmission, and familiarity with AT commands is always instrumental in fully understanding how modems work. Once a modem is put in operation, the central issue becomes how to efficiently transfer data over such a low−speed device for many years even 300 bps modems have been rare. In other words, how to optimally organize data transfer keeping in mind all the frustrating modem characteristics. Many file transfer protocols have been introduced, and some of them remained in use till nowadays: Xmodem is one of the most used file transfer protocols. Originally it used 128B packets and simple checksum method of error detection. Later enhancements, Xmodem−CRC and Xmodem−1K, present improved versions of the original Xmodem protocol. • Ymodem is essentially the Xmodem−1K protocol that allows multiple batch file transfer. Its improved variant is Ymodem−g that supports error−control modems. • Zmodem is generally the best protocol that has two significant features: it is more efficient and it provides crash recovery. If a Zmodem transfer is interrupted for any reason, the transfer can be resurrected later and already transferred data need not be re−sent. • Listed protocols are supported by following sendreceive programs: sx and rx, sy and ry, and sz and rz, respectively, which are available also on UNIX platform.

24.1.1 UNIX and Modems

To clarify the relationship between UNIX and modems, we must keep in mind that for a long time, a modem has been treated primarily as a part of the transmission line and not the computer system itself. The modem, as a terminating part of the transmission line, was connected to a serial interface, and correspondingly UNIX has focused on how to control the serial interface. So modem control actually refers to controlling serial lines that traditionally have been dedicated to connect user terminals. A long−standing deficiency of most UNIX implementations was the inability for the same modem to be used to dial in and dial out simultaneously, in a full−duplex mode. The two main reasons for this were: The driver that controls the serial port was designed for another purpose — to control data flow between a terminal and the system. So, the driver monitors for the specific signal that identifies the presence of data on the line, the data carrier detect signal DCD, to start any communication with the attached terminal. 1. And, when a DCD signal is detected, a getty program is invoked to start a login process, i.e., to put the login prompt on the line. 2. This is quite OK when an attached terminal dials in, even if it is done over a modem. However, what happens if the system itself should initialize the communication over the modem? Obviously, when the system dials out, the DCD signal is missing. Another obstacle presents the getty program itself. If a remote system attempts to start a communication, getty may respond to the dialed remote 591 It is also fair to say that modems have never been a real UNIX concern. Once networking boomed, and UNIX so successfully merged with networking, modems were pushed even more to the side. UNIX focused on providing basic network services, and a network connection became an integral part of each UNIX system. Modems are more attractive for the desktop side where UNIX never dominated. It does not mean that UNIX has completely ignored modem topics; each UNIX flavor provides some kind of modem control. It also gave a chance to third−party developers to fill the existing gap, providing needed software widely implemented on all UNIX platforms.

24.2 UNIX Modem Control