The TCP/IP stack provides whatever still-lower-layer functions are needed in order for the winsock API to look to the applications programs like a direct TCP/IP connection to the Internet, even if it has to communicate over an analog telephone line through a MOdulator/DEModulator (modem) sending streams of eight-bit data bytes to your computer through a bit-serial (RS-232) communications port using a serial/parallel converter device called a Universal Asynchronous Receiver/Transmitter (UART).
The com port address (on your ISA bus) is supposed to point to the parallel (byte) end of a UART function. That UART can be a chip on a serial card whose serial (bit) end is connected to an RS232 driver; a cell in an integrated circuit on your motherboard; a firmware function on an internal modem card; or a subroutine in a software driver in RAM for a parallel port modem.
NOTE: If that one-byte register is backed-up by 15 more in a First-In-First-Out (FIFO) buffer, your CPU can afford to be distracted for longer by all the other peripherals and programs clamoring for attention, and still respond to com port Interrupt ReQuests (IRQs) in time to avoid the UART's contents being overwritten (overruns) by a modem that believed your com port unloading rate setting.
In order to mask all of these details from higher-layer protocols, the TCP/IP stack talks to its counterpart on the communications server at your Internet Service Provider (ISP) with a synchronizing protocol for sending frames of data bytes that contain the IP datagrams which, in turn, contain the TCP data segments and address information needed for routing.
NOTE: These frames of data bytes are sent to/from your modem over your computer's serial com(munications) port using an RS-232 physical transmission layer, which sends each byte as a serial stream of 8 bits preceeded by a start bit and followed by a stop bit. The modem collects the bits, throws away the start and stop bits, and encodes them into multi-bit analog symbols which it wraps into "symbol frames" for synchronous transmission between itself and another modem. The other modem is connected to your Internet access provider's communications server's com port, so the two computers act as if they had a direct RS232 link.
One group of software protocols designed to provide this function of simulating a TCP/IP connection over a serial (RS232) link are collectively referred-to as Serial Line IP (SLIP). The more modern, standardized protocol for this purpose is called the Point-to-Point Protocol (PPP).
Underneath the PPP (or SLIP) layer, is a data link layer providing each TCP/IP stack with a reliable stream of eight-bit data bytes into and out of the area of RAM dedicated for its use as data buffers.
A PPP frame includes a check-sum used to ensure error-free reception of all of the bytes of the IP datagram. If it doesn't check, a PPP frame check error is generated, rather than an ACKnowledgement of successful receipt. This causes the TCP sender to back-up and send that entire packet of up to 1500 bytes all over again, resulting in stuttering downloads. Furthermore, if this happens too frequently, PPP's link quality sub-routine can conclude that the link is intollerably noisy and drop the connection.
When sending a PPP frame (or any other stream of data bytes) modern modems using V.42 error control employ the Link Access Procedure for Modems (LAP-M), or a Microcom Network Protocol (MNP-2 or -3 plus MNP-4 adaptive packet assembly), to replace an asynchronous stream of 8-bit bursts enclosed between start- and stop-bits from a serial port with a synchronous stream of frames of multi-bit analog symbols.
For example, a modem employing V.32bis modulation sends an analog symbol stream with 64 separate symbol values (6 bits-per-symbol) at 2400 baud (symbols/sec) to achieve a 14,400 bit-per-second (bps) information transmission rate.
Due to the PSTN's limited bandwidth (typically from 300 Hz to 3400 Hz, at best) the rate at which symbols can be sent is limited, typically, to no more than 3429 baud. With V.34 modulation techniques, even with the limited signal-to-noise ratio imposed by A/D (analog/digital) conversion at central office switches (typically no more than 36 db), it is possible to encode and decode symbols with enough bits-per-baud to allow 28,800 bps information transmission rates (33,600 bps in the latest modems).
For example, one V.34 modulation mode employs an 1829 Hz audio carrier signal to carry 3200 symbols/sec with a 9 bits-per-symbol coding scheme, yielding a 28,800 bps transmission rate. A pair of V.34 modems can choose among several modes, employing different codes and symbol rates, in order to maintain a 28.8 Kbps rate while adapting to changing line error rates through retraining. (They can drop back to lower-rate modulation modes, if necessary, and then retrain upwards to higher rates if the noise level drops.)
This synchronous protocol provides a 20% speed advantage by eliminating the necessity of sending the start- and stop-bits overhead over the PSTN; a sufficient reason to never turn it off.
Note: The modem's replacing of the start- and stop-bits around each byte before sending it to the RS232 serial port requires a 28.8 Kbps modem data stream to be un-loaded by the serial port at a 36 Kbps com port rate. This is true even without the rate-multiplying effect of de-compressing V.42bis modem-compressed data.
More importantly, the modem's V.42 firmware protocol automatically corrects for the byte-garbling errors invariably induced by the noise on analog telephone circuits trying to operate at 28,800 bps data rates. The large number of garbled bytes that would appear without this data-link-layer error correction would completely overwhelm the primitive "send the whole frame again" technique used by TCP/IP for error correction at higher (and slower) software protocol layers.
Inadvertently turning-off the modem's error correction is a common cause of PPP frame check errors. Another cause is failure to enable its RTS/CTS (hardware) handshaking and/or to disable its Xon/Xoff (software) handshaking. However, a very common cause is the computer CPU's taking too long to respond to interrupts from the serial (com) port requesting that the data in the UART be taken away before the modem writes more on top of it. This is called a com (port) overrun error.
Note: Apparently, the implementation of PPP in version 2.0 of Trumpet WinSock had a bug in it. If MTU was set to only accommodate the maximum size TCP segments (i.e. MSS + 40) it worked for all the common SLIP values (like 256, 552, 556 and 1006). However, it would generate PPP Frame Check Errors with the PPP (and Ethernet) default MTU of 1500. This bug has been corrected in version 2.1f.
This FAQ is available as a Windows Help® file for off-line viewing
Copyright© 1995 by Albert P. Belle Isle