Asynchronous Versus Synchronous Data Transmission in Linux
It is important to differentiate between asynchronous and synchronous
methods of data transmission. Asynchronous data transmission has more
overhead and doesn’t scale to higher rates the way synchronous methods
do. The early methods discussed on the history of data communications
were done by sending sequences of characters in a sequential linear
fashion. If transmission is done this way, every character transmitted
adds to the overhead. Each character has framing bits adding to the
amount of data that needs to be transmitted. In addition, with
asynchronous methods, there are no synchronizing external clock sources,
nor are there are any synchronizing pulses embedded within the data
stream. Each character is separately framed with start and stop bits.
The receiving station must resynchronize on each character, which is why
the maximum speeds are limited.
In contrast, synchronous data transmission methods don’t frame every character with individual start and stop bits. Instead, the characters are grouped together in sequence into frames, and the frames are transmitted as a stream of bits or characters. Each frame consists of a sequence of beginning bits or characters, followed by a data payload and then followed by a terminating sequence of bits or characters. The overhead is far higher for asynchronous methods and could be as high as 25% depending on the character length and how many framing bits there are for each character. However, the overhead for synchronous protocols is far lower and could be as little as 5%.
Flow
Control and Reliable Transmission
Flow control and reliable transmission are really two topics. In this section, we discuss these topics in the context of low-level transmission control. At the lower layers, we are concerned with how to provide acknowledged frames for error recovery and sequenced delivery. In addition, we maintain queues at the transmission side to accumulate data waiting to be sent and provide an even flow of information. Before we begin, it is important to note that TCP/IP does not require either reliable or sequenced packet delivery service. TCP/IP is designed to work with LANs that don’t implement retransmission in the case of dropped packets at the lower layers.
The method of low-level flow control used is different with simple character-oriented protocols than when it is used with faster synchronous-oriented protocols. Character-oriented protocols in their simplest form provide the most basic method of flow control. The sending station must wait for an Acknowledge (ACK) from the receiving station before sending the next character. This mechanism is known as stop and wait acknowledgment. With this method, it is impossible to fully use the channel’s bandwidth because one station sometimes has to send empty sync characters or otherwise mark time while waiting to receive an acknowledgment of an earlier frame. This problem is solved with bit-synchronous protocols by using a technique called slidingwindows, which is far more efficient. The sliding windows technique has less overhead by using multiple acknowledgments where one ACK can collectively acknowledge multiple incoming frames. After sending the first frame, the sending station can continue to send additional frames without stopping to wait for the receiving station to acknowledge the first frame.
The data link layer typically provides a link status indication to be used with flow control. Queues of frames waiting for transmission are maintained below the network layer but above the data link layer. When the higher layer has a packet ready, it is added to the end of the queue. When the lower layer is ready to transmit a packet, it removes the next packet from the bottom of the queue. This ensures that higher layers continue processing independently from the lowerlayer link status.
In contrast, synchronous data transmission methods don’t frame every character with individual start and stop bits. Instead, the characters are grouped together in sequence into frames, and the frames are transmitted as a stream of bits or characters. Each frame consists of a sequence of beginning bits or characters, followed by a data payload and then followed by a terminating sequence of bits or characters. The overhead is far higher for asynchronous methods and could be as high as 25% depending on the character length and how many framing bits there are for each character. However, the overhead for synchronous protocols is far lower and could be as little as 5%.
Flow
Control and Reliable Transmission
Flow control and reliable transmission are really two topics. In this section, we discuss these topics in the context of low-level transmission control. At the lower layers, we are concerned with how to provide acknowledged frames for error recovery and sequenced delivery. In addition, we maintain queues at the transmission side to accumulate data waiting to be sent and provide an even flow of information. Before we begin, it is important to note that TCP/IP does not require either reliable or sequenced packet delivery service. TCP/IP is designed to work with LANs that don’t implement retransmission in the case of dropped packets at the lower layers.
The method of low-level flow control used is different with simple character-oriented protocols than when it is used with faster synchronous-oriented protocols. Character-oriented protocols in their simplest form provide the most basic method of flow control. The sending station must wait for an Acknowledge (ACK) from the receiving station before sending the next character. This mechanism is known as stop and wait acknowledgment. With this method, it is impossible to fully use the channel’s bandwidth because one station sometimes has to send empty sync characters or otherwise mark time while waiting to receive an acknowledgment of an earlier frame. This problem is solved with bit-synchronous protocols by using a technique called slidingwindows, which is far more efficient. The sliding windows technique has less overhead by using multiple acknowledgments where one ACK can collectively acknowledge multiple incoming frames. After sending the first frame, the sending station can continue to send additional frames without stopping to wait for the receiving station to acknowledge the first frame.
The data link layer typically provides a link status indication to be used with flow control. Queues of frames waiting for transmission are maintained below the network layer but above the data link layer. When the higher layer has a packet ready, it is added to the end of the queue. When the lower layer is ready to transmit a packet, it removes the next packet from the bottom of the queue. This ensures that higher layers continue processing independently from the lowerlayer link status.
No comments:
Post a Comment