2. cnp3-ebook
3. English
4. Zen

177 ../../principles/linkstate.rst:57
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — LSP.Links[]: links advertised in the LSP. Each directed link is represented with the following information: 107/10000 · 107
178 ../../glossary.rst:81
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — TCP/IP 6/10000 · 6
178 ../../principles/sharing.rst:1409
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — When the connection starts, its congestion window is set to one segment. Segment `S0` is sent an acknowledgment at roughly :math:`t_{0}+4`. The congestion window is increased by one segment and `S1` and `S2` are transmitted at time :math:`t_{0}+4` and :math:`t_{0}+5`. The corresponding acknowledgments are received at times :math:`t_{0}+8` and :math:`t_{0}+10`. Upon reception of this last acknowledgment, the congestion window reaches `3` and segments can be sent (`S4` and `S5`). When segment `S6` reaches router `R1`, its buffers already contain `S5`. The packet containing `S6` is thus marked to inform the sender of the congestion. Note that the sender will only notice the congestion once it receives the corresponding acknowledgment at :math:`t_{0}+18`. In the meantime, the congestion window continues to increase. At :math:`t_{0}+16`, upon reception of the acknowledgment for `S5`, it reaches `4`. When congestion is detected, the congestion window is decreased down to `2`. This explains the idle time between the reception of the acknowledgment for `S*6` and the transmission of `S10`. 1097/10000 · 1097
178 ../../protocols/email.rst:278
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — F P u c A 9 l \+ 52/10000 · 52
178 ../../protocols/ipv6.rst:629
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — High-end hardware based routers use special purpose chips on their interfaces to forward IPv6 packets at line rate. These chips are optimized to process `correct` IP packets. They are not able to create ICMP messages at line rate. When such a chip receives an IP packet that triggers an ICMP message, it interrupts the main CPU of the router and the software running on this CPU processes the packet. This CPU is much slower than the hardware acceleration found on the interfaces [Gill2004]_. It would be overloaded if it had to process IP packets at line rate and generate one ICMP message for each received packet. To protect this CPU, high-end routers limit the rate at which the hardware can interrupt the main CPU and thus the rate at which ICMP messages can be generated. This implies that not all erroneous IP packets cause the transmission of an ICMP message. The risk of overloading the main CPU of the router is also the reason why using hop-by-hop IPv6 options, including the router alert option is discouraged [#falert]_. 1033/10000 · 1033
178 ../../protocols/wifi.rst:131
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Despite the utilization of acknowledgments, the 802.11 layer only provides an unreliable connectionless service like Ethernet networks that do not use acknowledgments. The 802.11 acknowledgments are used to minimize the probability of frame duplication. They do not guarantee that all frames will be correctly received by their recipients. Like Ethernet, 802.11 networks provide a high probability of successful delivery of the frames, not a guarantee. Furthermore, it should be noted that 802.11 networks do not use acknowledgments for multicast and broadcast frames. This implies that in practice such frames are more likely to suffer from transmission errors than unicast frames. 682/10000 · 682
178 ../../protocols/tcp.rst:605
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The first path is when the host receives a segment with sequence number `x` and the `FIN` flag set. The utilization of the `FIN` flag indicates that the byte before `sequence number` `x` was the last byte of the byte stream sent by the remote host. Once all of the data has been delivered to the user, the TCP entity sends an `ACK` segment whose `ack` field is set to :math:`(x+1) \pmod{2^{32}}` to acknowledge the `FIN` segment. The `FIN` segment is subject to the same retransmission mechanisms as a normal TCP segment. In particular, its transmission is protected by the retransmission timer. At this point, the TCP connection enters the `CLOSE\_WAIT` state. In this state, the host can still send data to the remote host. Once all its data have been sent, it sends a `FIN` segment and enter the `LAST\_ACK` state. In this state, the TCP entity waits for the acknowledgment of its `FIN` segment. It may still retransmit unacknowledged data segments, e.g., if the retransmission timer expires. Upon reception of the acknowledgment for the `FIN` segment, the TCP connection is completely closed and its :term:`TCB` can be discarded. 1133/10000 · 1133
178 ../../principles/linkstate.rst:59
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — LSP.Links[i].Id: identification of the neighbor 47/10000 · 47
178 ../../principles/reliability.rst:890
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A `go-back-n` sender is also very simple. It uses a sending buffer that can store an entire sliding window of frames [#fsizesliding]_. The frames are sent with increasing sequence numbers (modulo `maxseq`). The sender must wait for an acknowledgment once its sending buffer is full. When a `go-back-n` sender receives an acknowledgment, it removes from the sending buffer all the acknowledged frames and uses a retransmission timer to detect frame losses. A simple `go-back-n` sender maintains one retransmission timer per connection. This timer is started when the first frame is sent. When the `go-back-n sender` receives an acknowledgment, it restarts the retransmission timer only if there are still unacknowledged frames in its sending buffer. When the retransmission timer expires, the `go-back-n` sender assumes that all the unacknowledged frames currently stored in its sending buffer have been lost. It thus retransmits all the unacknowledged frames in the buffer and restarts its retransmission timer. 1011/10000 · 1011
179 ../../glossary.rst:83
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — refers to the :term:`TCP` and :term:`IP` protocols 50/10000 · 50
179 ../../principles/reliability.rst:932
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The operation of `go-back-n` is illustrated in the figure below. In this figure, note that upon reception of the out-of-sequence frame `D(2,c)`, the receiver returns a cumulative acknowledgment `C(OK,0)` that acknowledges all the frames that have been received in sequence. The lost frame is retransmitted upon the expiration of the retransmission timer. 354/10000 · 354
179 ../../principles/sharing.rst:1411
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In practice, a router is connected to multiple input links. The figure below shows an example with two hosts. 109/10000 · 109
179 ../../protocols/email.rst:286
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The last point to be discussed about `base64` is what happens when the length of the sequence of bytes to be encoded is not a multiple of three. In this case, the last group of bytes may contain one or two bytes instead of three. `Base64` reserves the `=` character as a padding character. This character is used once when the last group contains two bytes and twice when it contains one byte as illustrated by the two examples below. 434/10000 · 434
179 ../../protocols/ipv6.rst:633
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The IPv6 subnet 15/10000 · 15
179 ../../protocols/wifi.rst:135
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In addition to the data and control frames that we have briefly described above, 802.11 networks use several types of management frames. These management frames are used for various purposes. We briefly describe some of these frames below. A detailed discussion may be found in [IEEE802.11]_ and [Gast2002]_. 308/10000 · 308
179 ../../principles/linkstate.rst:60
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — LSP.Links[i].cost: cost of the link 35/10000 · 35
179 ../../protocols/tcp.rst:607
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The second path is when the host has transmitted all data. Assume that the last transmitted sequence number is `z`. Then, the host sends a `FIN` segment with sequence number :math:`(z+1) \pmod{2^{32}}` and enters the `FIN_WAIT1` state. In this state, it can retransmit unacknowledged segments but cannot send new data segments. It waits for an acknowledgment of its `FIN` segment (i.e. sequence number :math:`(z+1) \pmod{2^{32}}`), but may receive a `FIN` segment sent by the remote host. In the first case, the TCP connection enters the `FIN\_WAIT2` state. In this state, new data segments from the remote host are still accepted until the reception of the `FIN` segment. The acknowledgment for this `FIN` segment is sent once all data received before the `FIN` segment have been delivered to the user and the connection enters the `TIME\_WAIT` state. In the second case, a `FIN` segment is received and the connection enters the `Closing` state once all data received from the remote host have been delivered to the user. In this state, no new data segments can be sent and the host waits for an acknowledgment of its `FIN` segment before entering the `TIME\_WAIT` state. 1174/10000 · 1174
180 ../../glossary.rst:196
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — telnet 6/10000 · 6
180 ../../principles/reliability.rst:938
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Go-back-n : example 19/10000 · 19
180 ../../principles/linkstate.rst:62
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — These LSPs must be reliably distributed inside the network without using the router's routing table since these tables can only be computed once the LSPs have been received. The `Flooding` algorithm is used to efficiently distribute the LSPs of all routers. Each router that implements `flooding` maintains a `link state database` (LSDB) containing the most recent LSP sent by each router. When a router receives a LSP, it first verifies whether this LSP is already stored inside its LSDB. If so, the router has already distributed the LSP earlier and it does not need to forward it. Otherwise, the router forwards the LSP on all its links except the link over which the LSP was received. Flooding can be implemented by using the following pseudo-code. 752/10000 · 752