2. cnp3-ebook
3. English
4. Zen

27 ../../protocols/congestion.rst:168
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The `CWR` bit of the TCP header provides some form of acknowledgment for the `ECE` bit. When a TCP receiver detects a packet marked with the `CE` bit, it sets the `ECE` bit in all segments that it returns to the sender. Upon reception of an acknowledgment with the `ECE` bit set, the sender reduces its congestion window to reflect a mild congestion and sets the `CWR` bit. This bit remains set as long as the segments received contained the `ECE` bit set. A sender should only react once per round-trip-time to marked packets. 527/10000 · 527
27 ../../protocols/dnssec.rst:302
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In this domain, the DNSSEC server adds three `NSEC` records. A `RRSIG` signature is also computed for each of these records. 124/10000 · 124
27 ../../protocols/email.rst:130
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The figure below shows the header lines of one email message. The message originated at a host named `wira.firstpr.com.au` and was received by `smtp3.sgsi.ucl.ac.be`. The `Received:` lines have been wrapped for readability. 223/10000 · 223
27 ../../protocols/ethernet.rst:169
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Comments 8/10000 · 8
27 ../../protocols/http.rst:117
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — a `header`, that is used by the client to specify optional parameters for the request. An empty line is used to mark the end of the header 138/10000 · 138
27 ../../protocols/http2.rst:193
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — With HTTP/2.0 frames, the server could send the first 1250 bytes of the long object during 10 milliseconds, then send a second frame that contains the short object during one millisecond and later send a longer frame that contains the remaining 11250 bytes of the long object. In this case, the client has received the short object after 10 milliseconds. Given the HTTP/2.0 streams, the transmission of long web objects does not anymore blocks the transmission of shorter ones. 477/10000 · 477
27 ../../protocols/ipv6.rst:113
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — ``abcd:ef01:2345:6789:abcd:ef01:2345:6789`` 43/10000 · 43
27 ../../protocols/ethernet.rst:81
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The Ethernet frame format shown above is specified in [DIX]_. This is the format used to send both IPv4 :rfc:`894` and IPv6 packets :rfc:`2464`. After the publication of [DIX]_, the Institute of Electrical and Electronic Engineers (IEEE) began to standardize several Local Area Network technologies. IEEE worked on several LAN technologies, starting with Ethernet, Token Ring and Token Bus. These three technologies were completely different, but they all agreed to use the 48 bits MAC addresses specified initially for Ethernet [IEEE802]_ . While developing its Ethernet standard [IEEE802.3]_, the IEEE 802.3 working group was confronted with a problem. Ethernet mandated a minimum payload size of 46 bytes, while some companies were looking for a LAN technology that could transparently transport short frames containing only a few bytes of payload. Such a frame can be sent by an Ethernet host by padding it to ensure that the payload is at least 46 bytes long. However since the Ethernet header [DIX]_ does not contain a length field, it is impossible for the receiver to determine how many useful bytes were placed inside the payload field. To solve this problem, the IEEE decided to replace the `Type` field of the Ethernet [DIX]_ header with a length field [#ftypelen]_. This `Length` field contains the number of useful bytes in the frame payload. The payload must still contain at least 46 bytes, but padding bytes are added by the sender and removed by the receiver. In order to add the `Length` field without significantly changing the frame format, IEEE had to remove the `Type` field. Without this field, it is impossible for a receiving host to identify the type of network layer packet inside a received frame. To solve this new problem, IEEE developed a completely new sublayer called the Logical Link Control [IEEE802.2]_. Several protocols were defined in this sublayer. One of them provided a slightly different version of the `Type` field of the original Ethernet frame format. Another contained acknowledgments and retransmissions to provide a reliable service... In practice, [IEEE802.2]_ is never used to support IP in Ethernet networks. The figure below shows the official [IEEE802.3]_ frame format. 2223/10000 · 2223
27 ../../protocols/routing.rst:86
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Inside each non-backbone area, routers distribute the topology of the area by exchanging link state packets with the other routers in the area. The internal routers do not know the topology of other areas, but each router knows how to reach the backbone area. Inside an area, the routers only exchange link-state packets for all destinations that are reachable inside the area. In OSPF, the inter-area routing is done by exchanging distance vectors. This is illustrated by the network topology shown below. 506/10000 · 506
27 ../../protocols/rpc.rst:105
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `id`: an identifier chosen by the caller 40/10000 · 40
27 ../../protocols/ssh.rst:218
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — At this point, all the messages sent over the TCP connection will be encrypted with the negotiated keys. The ``ssh`` protocol uses messages that are encoded according to the Binary Packet Protocol defined in :rfc:`4253`. Each of these messages contains the following information : 280/10000 · 280
27 ../../protocols/tcp.rst:55
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `checksum` field contains the value of the Internet checksum computed over the entire TCP segment and a pseudo-header as with UDP 133/10000 · 133
27 ../../protocols/tls.rst:93
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The TLS handshake 17/10000 · 17
27 ../../protocols/udp.rst:92
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A discussion of the ephemeral port ranges used by different TCP/UDP implementations may be found in http://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html 157/10000 · 157
27 ../../protocols/wifi.rst:26
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 802.11n 7/10000 · 7
27 ../../exercises/network.rst:221
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Are these paths possible with link-state or distance vector routing ? If so, how do you configure the link weights? If not, explain your answer. 144/10000 · 144
27 ../../exercises/reliability.rst:53
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the Fletcher checksum [Fletcher1982]_, see https://en.wikipedia.org/wiki/Fletcher%27s_checksum for implementation details. 122/10000 · 122
28 ../../exercises/ex-sharing.rst:582
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Compute the max-min fair bandwidth allocation in the network below. 67/10000 · 67
28 ../../exercises/sockets.rst:263
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Until now, we learned how to use sockets that were already created. When writing a whole program, you will have to create you own sockets and choose the concrete technology that it will use to communicate with others. In this section, we will create new sockets and allow a program to communicate with processes located on another computer using a network. The most recent standardized technology used to communicate through a network is the :term:`IPv6` network protocol. In the IPv6 protocol, hosts are identified using *IPv6 addresses*. Modern operating systems allow IPv6 network communications between programs to be done using the socket API, just as we did in the previous sections. 689/10000 · 689
28 ../../principles/network.rst:203
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A second type of problem may exist in networks using the datagram organization. Consider a path that contains a cycle. For example, router `R1` sends all packets towards destination `D` via router `R2`. Router `R2` forwards these packets to router `R3` and finally router `R3`'s forwarding table uses router `R1` as its nexthop to reach destination `D`. In this case, if a packet destined to `D` is received by router `R1`, it will loop on the `R1 -> R2 -> R3 -> R1` cycle and will never reach its final destination. As in the black hole case, the destination is not reachable from all sources in the network. In practice the loop problem is more annoying than the black hole problem because when a packet is caught in a forwarding loop, it unnecessarily consumes bandwidth. In the black hole case, the problematic packet is quickly discarded. We will see later that network layer protocols include techniques to minimize the impact of such forwarding loops. 958/10000 · 958