2. cnp3-ebook
3. English
4. Zen

175 ../../glossary.rst:113
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The Transmission Control Block is the set of variables that are maintained for each established TCP connection by a TCP implementation. 135/10000 · 135
175 ../../principles/reliability.rst:849
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — a `retransmission strategy` to retransmit the lost frames 57/10000 · 57
175 ../../principles/linkstate.rst:55
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — LSP.age: age or remaining lifetime of the LSP 45/10000 · 45
175 ../../principles/sharing.rst:1231
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A congestion control scheme for our simple transport protocol could be implemented as follows. 94/10000 · 94
175 ../../protocols/email.rst:274
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 000101 001111 101110 011100 000000 111101 100101 111110 56/10000 · 56
175 ../../protocols/ipv6.rst:583
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Two types of informational ICMPv6 messages are defined in :rfc:`4443` : `echo request` and `echo reply`, which are used to test the reachability of a destination by using :manpage:`ping6(8)`. Each host is supposed [#fpingproblems]_ to reply with an ICMP `Echo reply` message when it receives an ICMP `Echo request` message. A sample usage of :manpage:`ping6(8)` is shown below. 378/10000 · 378
175 ../../protocols/wifi.rst:120
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 802.11 RTS/CTS frames are used to reserve the transmission channel, in order to transmit one data frame and its acknowledgment. The RTS frames contain a `Duration` and the transmitter and receiver addresses. The `Duration` field of the RTS frame indicates the duration of the entire reservation (i.e. the time required to transmit the CTS, the data frame, the acknowledgments and the required SIFS delays). The CTS frame has the same format as the acknowledgment frame. 469/10000 · 469
175 ../../protocols/tcp.rst:567
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The designers of TCP implementations should ensure that two TCP entities never enter a TCP `RST` war where host `A` is sending a `RST` segment in response to a previous `RST` segment that was sent by host `B` in response to a TCP `RST` segment sent by host `A` ... To avoid such an infinite exchange of `RST` segments that do not carry data, a TCP entity is *never* allowed to send a `RST` segment in response to another `RST` segment. 435/10000 · 435
176 ../../glossary.rst:84
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — TCP 3/10000 · 3
176 ../../principles/linkstate.rst:56
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — LSP.seq: sequence number of the LSP 35/10000 · 35
176 ../../principles/sharing.rst:1251
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In the above pseudocode, `cwin` contains the congestion window stored as a real number of segments. This congestion window is updated upon the arrival of each acknowledgment and when congestion is detected. For simplicity, we assume that `cwin` is stored as a floating point number but only full segments can be transmitted. 324/10000 · 324
176 ../../protocols/email.rst:276 • ../../protocols/email.rst:295 • ../../protocols/email.rst:309
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Decimal 7/10000 · 7
176 ../../protocols/ipv6.rst:605
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Another very useful debugging tool is :manpage:`traceroute6(8)`. The traceroute man page describes this tool as `"print the route packets take to network host"`. traceroute uses the `Time exceeded` ICMP messages to discover the intermediate routers on the path towards a destination. The principle behind traceroute is very simple. When a router receives an IP packet whose `Hop Limit` is set to ``1`` it is forced to return to the sending host a `Time exceeded` ICMP message containing the header and the first bytes of the discarded packet. To discover all routers on a network path, a simple solution is to first send a packet whose `Hop Limit` is set to `1`, then a packet whose `Hop Limit` is set to `2`, etc. A sample traceroute6 output is shown below. 758/10000 · 758
176 ../../protocols/wifi.rst:126
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — IEEE 802.11 RTS frame format 28/10000 · 28
176 ../../protocols/tcp.rst:570
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The normal way of terminating a TCP connection is by using the graceful TCP connection release. This mechanism uses the `FIN` flag of the TCP header and allows each host to release its own direction of data transfer. As for the `SYN` flag, the utilization of the `FIN` flag in the TCP header consumes one sequence number. The figure :ref:`fig-tcprelease` shows the part of the TCP FSM used when a TCP connection is released. 424/10000 · 424
176 ../../principles/reliability.rst:854
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The simplest sliding window protocol uses the `go-back-n` recovery. Intuitively, `go-back-n` operates as follows. A `go-back-n` receiver is as simple as possible. It only accepts the frames that arrive in-sequence. A `go-back-n` receiver discards any out-of-sequence frame that it receives. When `go-back-n` receives a data frame, it always returns an acknowledgment containing the sequence number of the last in-sequence frame that it has received. This acknowledgment is said to be `cumulative`. When a `go-back-n` receiver sends an acknowledgment for sequence number `x`, it implicitly acknowledges the reception of all frames whose sequence number is earlier than `x`. A key advantage of these cumulative acknowledgments is that it is easy to recover from the loss of an acknowledgment. Consider for example a `go-back-n` receiver that received frames `1`, `2` and `3`. It sent `OK1`, `OK2` and `OK3`. Unfortunately, `OK1` and `OK2` were lost. Thanks to the cumulative acknowledgments, when the sender receives `OK3`, it knows that all three frames have been correctly received. 1082/10000 · 1082
177 ../../glossary.rst:86
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The Transmission Control Protocol is a protocol of the transport layer in the TCP/IP protocol suite that provides a reliable bytestream connection-oriented service on top of IP 176/10000 · 176
177 ../../principles/reliability.rst:856
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The figure below shows the FSM of a simple `go-back-n` receiver. This receiver uses two variables : `lastack` and `next`. `next` is the next expected sequence number and `lastack` the sequence number of the last data frame that has been acknowledged. The receiver only accepts the frame that are received in sequence. `maxseq` is the number of different sequence numbers (:math:`2^n`). 385/10000 · 385
177 ../../principles/sharing.rst:1254
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — As an illustration, let us consider the network scenario above and assume that the router implements the DECBit binary feedback scheme [RJ1995]_. This scheme uses a form of Forward Explicit Congestion Notification and a router marks the congestion bit in arriving packets when its buffer contains one or more packets. In the figure below, we use a `*` to indicate a marked packet. 380/10000 · 380
177 ../../protocols/email.rst:276
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 5 15 46 28 0 61 37 62 51/10000 · 51