We still consider the case where the product of the link latency and bandwidth is 8 k B and the frame size is 1 k B. Let the sender prepare to send the ninth frame while receiving the c k of the first frame. The algorithm that allows us to do this is called a sliding window, as shown in timeline 2-2 1.
1. Sliding Window Algorithm The sliding window algorithm works as follows. First, the sender assigns a sequence number for each frame as s e Q n u m. Now, Let's ignore the fact that s e Q n u m is implemented by a finite header field, and assume that it can increase infinitely. The sender maintains three variables: the size of the sending window (send window size), which is recorded as s w s, indicating that the sender can send
Upper bound of the number of sent but unconfirmed frames; l a r indicates the sequence number of the recently received confirmation frame (last acknowledgement re c e I v e d; l f s indicates the sequence number of the last frame sent, and the sender maintains the following non-variant:
LAR-LFR ≤rws
When one confirmation arrives, the sender moves the l a r to the right to allow the sender to send another frame. At the same time, the sender sets a timer for each frame sent. If the timer times out before the arrival of a c k, the sender resends the frame. Note: The sender must store up to w s frames, because re-transmission must be prepared before they are confirmed. The receiver maintains the following three variables: the size of the receiving window (receive window size), which is recorded as rw s, and the upper bound of unordered frames that the receiver can receive; l a f indicates the sequence number of the received frame (l a rgest acceptable frame); l f r indicates the sequence number of the recently received frame (last frame re c e I v e d. The receiver also maintains the following variant:
LFS-LAR ≤sws
When a frame with the sequence number s e q n u m arrives, the receiver takes the following action: if s e Q n u m ≤ l f r or s e q n u m> l a f, frames are discarded because they are not in the receiving window; if l f r <se Q n u m ≤ l a f, the frame is received in the receiving window. Now the receiver needs to decide whether to send a c k. If s e Q n u m to a c k is set to indicate the maximum number of unconfirmed frames, then all frames with the serial number less than or equal to s e q n u m to a c k have been received. Even if you have received a group with a higher serial number, the receiver confirms the receipt of s e q n u m to a c k. This validation is called cumulative (c u m u l a t I V E ). Then it sets l f r = s e Q n u m to a c k, and adjusts l a f = l f r + rw s. For example, suppose l f r = 5 (that is, the c k sent by the last receiver is to confirm the sequence number 5), and RWS = 4. This means l a f = 9. If Frames 7 and 8 arrive, they are stored because they are in the receiving window. However, you do not need to send a c k because frame 6 has not yet arrived. Frames 7 and 8 are called arriving in wrong order. (Technically, the receiver can resend the c k of frame 5 when Frames 7 and 8 arrive .) If frame 6 arrives at the time (maybe it is re-sent and later after the first loss, maybe it is only delayed), the receiver confirms frame 8, l f r is set to 8, l a f is set to 1 2. If frame 6 is lost, the sender times out and frame 6 is resent. We can see that when a timeout occurs, the amount of data transmitted decreases because the sender cannot move the window forward before frame 6 is confirmed. This means that when the group is lost, this solution will no longer ensure that the pipeline is fully loaded. Note: the longer the group is lost, the more serious the problem is.
Note: In this example, the receiver can send a recognize frame n a K (negative acknowl edgment) for frame 6 as soon as frame 7 arrives ). However, because the sender's timeout mechanism is sufficient to detect this situation, sending n a k increases the complexity of the sender, so it is not necessary to do so. As we have mentioned, it is reasonable to send an additional a c k for frame 5 when Frames 7 and 8 arrive; in some cases, the sender can use the duplicate a c k as a clue to frame loss. Both methods allow early packet loss detection, which helps improve performance.
Another variant of this solution is the use of selective acknowledgements ). That is, the receiver can accurately confirm the received frames, not just those that receive the highest sequence number in sequence. Therefore, in the preceding example, the receiver can confirm the receipt of Frames 7 and 8. If more information is provided to the sender, the sender can easily keep the pipeline fully loaded, but the implementation complexity is increased. The size of the sending window is determined by the number of frames to be confirmed on the link within a given period of time. For the product of a given latency and bandwidth, s w s is easy to calculate. On the other hand, the receiver can set RW s to any desired value. The two common settings are rw s = 1, indicating that the receiver does not store frames arriving in any wrong order; rw s = s w s, indicating that the receiver can cache any frames transmitted by the sender. Since the number of frames in the wrong order cannot exceed w s, it is meaningless to set RWS> s w s.
2. Finite sequence number and sliding window Now let's discuss a simplification in the algorithm, That is, assuming that the sequence number can be infinitely increased. Of course, the sequence number of a frame is described in a finite header field. For example, a 3-bit field means eight available numbers 0 ~ 7. Therefore, serial numbers must be reusable, or can be bypassed. This brings about a problem: to be able to distinguish different sending instances with the same serial number, this means that the number of available serial numbers must be greater than the number of frames to be confirmed. For example, the Stop wait algorithm allows one frame to be confirmed at a time and two different sequence numbers.
Assume that the number of sequence numbers in the sequence number space is 1 larger than the number of frames to be confirmed, that is, s w s ≤ m a x s e q n u m-1, m a x seq n u m is the number of available serial numbers. Is that enough? The answer depends on rw s. If rw s = 1, maxseqnum ≥ SWS + 1 is sufficient. If rw s is equal to s w s, it is not enough to have a m a x s e q n u m which is 1 larger than the size of the sending window. To see this, consider eight numbers ranging from 0 ~ And s w s = rw s = 7. Assume that the sender transmits the frame 0 ~ 6. The receiver successfully receives the request, but the c k is lost. The receiver now wants to receive Frames 7, 0 ~ 5, but the sender times out, and then sends the frame 0 ~ 6. Unfortunately, what the receiver expects is the second frame 0 ~ 5. the first frame is 0 ~ 5. This is exactly what we want to avoid.
The result is that when rw s = s w s, the size of the sending window cannot be greater than half of the number of available serial numbers, or more accurately, SWS <(maxseqnum + 1) /2 intuitively, this indicates that the Sliding Window Protocol is transformed between two halves of the serial number space, just as the serial number of the Stop wait protocol is transformed between 0 and 1. The only difference is that it slides continuously between two halves of the serial number space rather than discrete transformation.
Note that this rule is especially applicable to rw s = s w s. We will leave a more general rule for determining any value for rw s and s w s for an exercise. Note that the relationship between the window size and serial number space depends on an assumption that frames are easily ignored, that is, frames are not re-ordered during transmission. This cannot happen on the point-to-point link of direct connection, because one frame cannot catch another frame during transmission. However, we will see in Chapter 5th the Sliding Window Algorithm Used in a different environment, and we need to design another rule.
3. Implementation of sliding windows The following routine describes how to implement the Sliding Window Algorithm in two aspects: sending and receiving. This routine is taken from an active protocol called the Sliding Window Protocol s w p (Sliding Window pro t o c o l ). In order not to involve the adjacent protocol in the Protocol diagram, we use h L p (high-level protocol) to represent the s w p upper-layer protocol, and use L I n k (Link Layer Protocol) indicates the protocol of s w p. First, we define a data structure. First, the frame header is very simple: it contains a sequence number (s e Q n u m) and a confirmation number (a c k n u m ). It also contains a flag (f l a g s) field, indicating whether the frame is a c k frame or a frame carrying data.
Secondly, the sliding window algorithm has the following structure. For protocol senders, the status includes the variables l a r and l f s described above, and a queue (s e n d q) that stores the sent but unconfirmed frames ). The sender's status also contains a count semaphore (counting semaphore) called s e n d wi n d o W n o t f u L. Next we will see how to use it, but in general, semaphores are a synchronization primitive that supports s e m wa I t and s e m s I g N A L operations. Each time s e m s I g n a l is called, the semaphore is incremented by 1. Each time s e m wa I t is called, the semaphore is reduced by 1. If the semaphore decreases and the value is less than 0, the calling process is blocked (suspended ). Once enough s e m s I g N A L operations are performed, the semaphore value is increased to greater than 0, the blocked process can be restored when s e m wa I t is called.
For the receiver of the Protocol, as described above, this State includes the variable l f r, plus a queue that stores received error sequence frames (r e c v q ). Finally, although not displayed, the size of the sliding window of the sender and receiver is represented by the constant s w s and RW s respectively.
The sender of s w p is implemented by s e n d s w p process. This routine is simple. First, the s e m wa I t blocks the process on a semaphore until it can send another frame. Once allowed, s e n d s w p sets the sequence number in the frame header and stores the copy of this frame in the sending Queue (s e n d Q, schedule a timeout event to handle unconfirmed frames and send the frames to the lower-layer protocol. One of the details worth noting is that S t o r e _ s w p _ h d r is called just before m s g a d r is called. This routine converts the C language structure (s t a t e-> h d r) containing the s w p header into a byte string (H B u f) that can be safely placed before the message ). This routine (not given) must convert each integer field in the header into a network byte sequence, and remove any padding that the compiler adds to the C language structure. Section will discuss in detail the issue of byte order, but now it is sufficient to put the highest effective bit in the Multi-character integer in the highest address byte.
Another complexity of this routine is the use of s e m wa I t and s e n dw I n d o W n o t f u l semaphores. S e n diffusion n d o W n o t f u L is initialized as a large small s w s of the sender sliding window (this initialization is not given ). For each transmission frame of the sender, the s e m wa I t operation reduces the number by 1. If it is reduced to 0, the sender process is blocked. Every time a c k is received, call the s e m s I g n a l operation in d e l I V E R S W P (see the following) to add 1 to this number, to activate the pending sender process.
Before continuing to introduce the receiver of s w p, you need to adjust a location that looks inconsistent. On the one hand, we have said that the high-level protocol calls the s e n d operation to request the services of the low-level protocol, therefore, we hope that the Protocol for sending messages through s w p can call s e n d (s w p, p a c k e t ). On the other hand, the process used to implement the sending operation of s w p is called s e n d s w p, and its first parameter is a state variable (s w p s t a t e ). What are the results? The answer is that the operating system provides the bonding code to convert general calls to s e n d to the bonding code for specific protocol calls to s e n d s w p. This bonding Code sets the first parameter of s e n d (Protocol variable s w p) maps to a function pointer pointing to s e n d s w p and a pointer pointing to the Protocol state required for s w p operation. The reason why we make the high-level protocol call a specific function indirectly through a general function call is that we want to limit the amount of information that the high-level protocol can encode in the lower-level protocol. This makes it easier to change the configuration of the Protocol diagram in the future. Now let's look at the specific implementation of the s w p protocol operated by d e l e r, which is implemented in the process d e l I V E R S W P. This routine actually processes two different types of input messages: the c k of the sent frame at the current node and the data frame arriving at the node. In a sense, the ACK part of this routine corresponds to the sender of the algorithm given in send SWP. The f l a g s field in the header can be used to determine whether the input message is an ACK or a data frame. Note that this special implementation does not support a c k in data frames. When the input frame is an ACK, delive rswp only finds the corresponding position (slot) of the ACK in the send Queue (send q) to cancel the timeout event, and release the frames stored in that position. Since a c k may be cumulative, this work is actually done in a loop. Another issue worth noting in this case is the call of the SWP in wind o w sub-routine. This subroutine is provided below, which ensures that the sequence number of the frame to be confirmed is within the range of a c k that the sender currently wants to receive.
When the input frame contains data, d e l I v e r s w p first calls m s g s t r I p H D R and l o a D _ S W P _ H D r so that extract the header. Routine l o a D _ s w p _ h d r corresponds to the previously discussed S t o r e _ s w p _ h d r, it converts a byte string into a C-language data structure containing the s w p header. Then, d e l I v e r s w p calls s w p I n wi n d o w to ensure that the frame sequence number is within the expected sequence number range. In this case, the routine loops over the set of received Consecutive Frames and passes them to the upper-layer protocol by calling the d e l I E R h L p routine. It also sends the accumulated a c k to the sender, but it is implemented through loops in the receiving Queue (it does not use the s e q n u m to a c k variable given earlier in this section ).
Finally, the s w p I n window is a simple subroutine that checks whether a given sequence number falls between a maximum and a minimum sequence number.
4. frame sequence and Traffic Control Sliding Window Protocol may be the most famous Algorithm in computer networks. However, the obfuscation of this algorithm is that it may have three different features. The first feature is the focus of this section, that is, frame transmission reliably on unreliable links. (Generally, this algorithm is used to transmit messages reliably on an unreliable network .) This is the core function of the algorithm. The second feature of the sliding window algorithm is to maintain the Transmission sequence of frames. This is easy to implement in the receiver, because each frame has a sequence number. the receiver must ensure that all frames whose sequence numbers are smaller than the current frame have been transferred to the upper-layer protocol to transfer the current frame up. That is, frames in the wrong sequence are cached by the receiver (that is, frames are not transmitted. The sliding window algorithm described in this section indeed maintains the frame sequence, even though we can imagine a variation in that the receiver will pass the frame to the next protocol without waiting for the frames to be transmitted earlier. One question we can ask is: do we really need to slide the window protocol to keep the frame Order, or whether such a function is unnecessary at the link layer. Unfortunately, we have not seen enough network architecture to answer this question. The first thing we need to understand is how the point-to-point link sequence is connected by a switch to form an end-to-end path.
The third feature of the sliding window algorithm is that it sometimes supports traffic control (f l o w c o n t ro L ), it is a feedback mechanism that the receiver can control the sender to reduce its speed. This mechanism is used to suppress the transmission speed of the sender, that is, to suppress the transmission of more data than the receiver can process. This is usually done by extending the Sliding Window Protocol so that the receiver not only confirms the received frame, but also notifies the sender of how many frames it can receive. The number of frames that can be received corresponds to the number of idle buffers of the receiver. In the case of Sequential transmission, we should be sure that traffic control is necessary at the link layer before incorporating traffic control into the Sliding Window Protocol.
An important concept that has not yet been discussed is the system design principle. We call it separation of concerns ). That is, you must be careful about the differences between different features that are sometimes intertwined in a mechanism, and you must be sure that each feature is necessary and is supported in the most effective way. In this particular case, reliable transmission, Sequential transmission, and traffic control are sometimes combined in a sliding window protocol. We should ask ourselves whether this is done correctly at the link layer. With such questions, we will go through chapter 3rd (description X. 2. 5. How to use it to implement hop-to-hop traffic control) and Chapter 2 (describe how t c p uses it to implement a reliable byte stream channel) Reconsider the sliding window algorithm. From http://tracestudio.spaces.live.com/blog/cns! D81037c53597a405! 223. Entry
