2. cnp3-ebook
3. principles/reliability
4. English
5. Zen

183 ../../principles/reliability.rst:944
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `go-back-n` sender retransmits all unacknowledged frames once it has detected a loss 88/10000 · 88
184 ../../principles/reliability.rst:951
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `Selective repeat` is a better strategy to recover from losses. Intuitively, `selective repeat` allows the receiver to accept out-of-sequence frames. Furthermore, when a `selective repeat` sender detects losses, it only retransmits the frames that have been lost and not the frames that have already been correctly received. 324/10000 · 324
185 ../../principles/reliability.rst:953
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A `selective repeat` receiver maintains a sliding window of `W` frames and stores in a buffer the out-of-sequence frames that it receives. The figure below shows a five-frame receive window on a receiver that has already received frames `7` and `9`. 249/10000 · 249
186 ../../principles/reliability.rst:959
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The receiving window with selective repeat 42/10000 · 42
187 ../../principles/reliability.rst:961
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A `selective repeat` receiver discards all frames having an invalid CRC, and maintains the variable `lastack` as the sequence number of the last in-sequence frame that it has received. The receiver always includes the value of `lastack` in the acknowledgments that it sends. Some protocols also allow the `selective repeat` receiver to acknowledge the out-of-sequence frames that it has received. This can be done for example by placing the list of the correctly received, but out-of-sequence frames in the acknowledgments together with the `lastack` value. 557/10000 · 557
188 ../../principles/reliability.rst:963
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — When a `selective repeat` receiver receives a data frame, it first verifies whether the frame is inside its receiving window. If yes, the frame is placed in the receive buffer. If not, the received frame is discarded and an acknowledgment containing `lastack` is sent to the sender. The receiver then removes all consecutive frames starting at `lastack` (if any) from the receive buffer. The payloads of these frames are delivered to the user, `lastack` and the receiving window are updated, and an acknowledgment acknowledging the last frame received in sequence is sent. 572/10000 · 572
189 ../../principles/reliability.rst:965
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The `selective repeat` sender maintains a sending buffer that can store up to `W` unacknowledged frames. These frames are sent as long as the sending buffer is not full. Several implementations of a `selective repeat` sender are possible. A simple implementation associates one retransmission timer to each frame. The timer is started when the frame is sent and canceled upon reception of an acknowledgment that covers this frame. When a retransmission timer expires, the corresponding frame is retransmitted and this retransmission timer is restarted. When an acknowledgment is received, all the frames that are covered by this acknowledgment are removed from the sending buffer and the sliding window is updated. 714/10000 · 714
190 ../../principles/reliability.rst:967
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The figure below illustrates the operation of `selective repeat` when frames are lost. In this figure, `C(OK,x)` is used to indicate that all frames, up to and including sequence number `x` have been received correctly. 219/10000 · 219
191 ../../principles/reliability.rst:973
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Selective repeat : example 26/10000 · 26
192 ../../principles/reliability.rst:977
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Pure cumulative acknowledgments work well with the `go-back-n` strategy. However, with only cumulative acknowledgments a `selective repeat` sender cannot easily determine which frames have been correctly received after a data frame has been lost. For example, in the figure above, the second `C(OK,0)` does not inform explicitly the sender of the reception of `D(2,c)` and the sender could retransmit this frame although it has already been received. A possible solution to improve the performance of `selective repeat` is to provide additional information about the received frames in the acknowledgments that are returned by the receiver. For example, the receiver could add in the returned acknowledgment the list of the sequence numbers of all frames that have already been received. Such acknowledgments are sometimes called `selective acknowledgments`. This is illustrated in the figure above. 899/10000 · 899
193 ../../principles/reliability.rst:986
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In the figure above, when the sender receives `C(OK,0,[2])`, it knows that all frames up to and including `D(0,...)` have been correctly received. It also knows that frame `D(2,...)` has been received and can cancel the retransmission timer associated to this frame. However, this frame should not be removed from the sending buffer before the reception of a cumulative acknowledgment (`C(OK,2)` in the figure above) that covers this frame. 440/10000 · 440
194 ../../principles/reliability.rst:990
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Maximum window size with `go-back-n` and `selective repeat` 59/10000 · 59
195 ../../principles/reliability.rst:992
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A reliable protocol that uses `n` bits to encode its sequence number can send up to :math:`2^n` successive frames. However, to ensure a reliable delivery of the frames, `go-back-n` and `selective repeat` cannot use a sending window of :math:`2^n` frames. Consider first `go-back-n` and assume that a sender sends :math:`2^n` frames. These frames are received in-sequence by the destination, but all the returned acknowledgments are lost. The sender will retransmit all frames. These frames will all be accepted by the receiver and delivered a second time to the user. It is easy to see that this problem can be avoided if the maximum size of the sending window is :math:`{2^n}-1` frames. A similar problem occurs with `selective repeat`. However, as the receiver accepts out-of-sequence frames, a sending window of :math:`{2^n}-1` frames is not sufficient to ensure a reliable delivery. It can be easily shown that to avoid this problem, a `selective repeat` sender cannot use a window that is larger than :math:`\frac{2^n}{2}` frames. 1035/10000 · 1035
196 ../../principles/reliability.rst:1038
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Reliable protocols often need to send data in both directions. To reduce the overhead caused by the acknowledgments, most reliable protocols use `piggybacking`. Thanks to this technique, a datalink entity can place the acknowledgments and the receive window that it advertises for the opposite direction of the data flow inside the header of the data frames that it sends. The main advantage of piggybacking is that it reduces the overhead as it is not necessary to send a complete frame to carry an acknowledgment. This is illustrated in the figure below where the acknowledgment number is underlined in the data frames. Piggybacking is only used when data flows in both directions. A receiver will generate a pure acknowledgment when it does not send data in the opposite direction as shown in the bottom of the figure. 821/10000 · 821
197 ../../principles/reliability.rst:1044
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Piggybacking example 20/10000 · 20
198 ../../principles/reliability.rst:1052
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — SDU is the acronym of Service Data Unit. We use it as a generic term to represent the data that is transported by a protocol. 125/10000 · 125
199 ../../principles/reliability.rst:1054
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The size of the sliding window can be either fixed for a given protocol or negotiated during the connection establishment phase. Some protocols allow to change the maximum window size during the data transfer. We will explain these techniques with real protocols later. 269/10000 · 269
The translation has come to an end.