2. cnp3-ebook
3. English
4. Zen

46 ../../protocols/ipv6.rst:162
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the top half is divided in two smaller blocks, one for each small campus 72/10000 · 72
46 ../../protocols/ethernet.rst:172
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Thin coaxial cable, 185m 24/10000 · 24
46 ../../protocols/routing.rst:145
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — all routers update their routing table 38/10000 · 38
46 ../../protocols/tcp.rst:143
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In the original TCP specification :rfc:`793`, each TCP entity maintained a clock to compute the initial sequence number (:term:`ISN`) placed in the `SYN` and `SYN+ACK` segments. This made the ISN predictable and caused a security issue. The typical security problem was the following. Consider a server that trusts a host based on its IP address and allows the system administrator to log in from this host without giving a password [#frlogin]_. Consider now an attacker who knows this particular configuration and is able to send IP packets having the client's address as source. He can send fake TCP segments to the server, but does not receive the server's answers. If he can predict the `ISN` that is chosen by the server, he can send a fake `SYN` segment and shortly after the fake `ACK` segment confirming the reception of the `SYN+ACK` segment sent by the server. Once the TCP connection is open, he can use it to send any command to the server. To counter this attack, current TCP implementations add randomness to the `ISN`. One of the solutions, proposed in :rfc:`1948` is to compute the `ISN` as :: 1109/10000 · 1109
46 ../../protocols/tls.rst:215
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the ``ServerHelloDone`` indicates that the server has sent all the messages for the first phase of the handshake. 113/10000 · 113
46 ../../protocols/wifi.rst:126
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — IEEE 802.11 RTS frame format 28/10000 · 28
46 ../../principles/network.rst:296
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Assume that the network has started and all port-address and forwarding tables are empty. Host `A` sends a packet towards `B`. Upon reception of this packet, `R1` updates its port-address table. Since `B` is not present in the port-address table, the packet is broadcasted. Both `R2` and `R3` receive a copy of the packet sent by `A`. They both update their port-address table. Unfortunately, they also both broadcast the received packet. `B` receives a first copy of the packet, but `R3` and `R2` receive it again. `R3` will then broadcast this copy of the packet to `B` and `R1` while `R2` will broadcast its copy to `R1`. Although `B` has already received two copies of the packet, it is still inside the network and continues to loop. Due to the presence of the cycle, a single packet towards an unknown destination generates many copies of this packet that loop and will eventually saturate the network. Network operators who are using port-address tables to automatically compute the forwarding tables also use distributed algorithms to ensure that the network topology is always a tree. 1093/10000 · 1093
47 ../../exercises/sockets.rst:343
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Message format 14/10000 · 14
47 ../../bibliography.rst:66
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Dijkstra, E., `A Note on Two Problems in Connection with Graphs <https://dx.doi.org/10.1007/BF01386390>`_. Numerische Mathematik, 1:269- 271, 1959 146/10000 · 146
47 ../../exercises/network.rst:372
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A 1/10000 · 1
47 ../../glossary.rst:101
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The File Transfer Protocol defined in :rfc:`959` has been the `de facto` protocol to exchange files over the Internet before the widespread adoption of HTTP :rfc:`2616`. 169/10000 · 169
47 ../../principles/reliability.rst:215
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A first solution to this problem is to require the physical layer to remain idle for some time after the transmission of each frame. These idle periods can be detected by the receiver and serve as a marker to delineate frame boundaries. Unfortunately, this solution is not acceptable for two reasons. First, some physical layers cannot remain idle and always need to transmit bits. Second, inserting an idle period between frames decreases the maximum bit rate that can be achieved. 482/10000 · 482
47 ../../principles/transport.rst:124 • ../../principles/transport.rst:552
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The transport layer 19/10000 · 19
47 ../../principles/security.rst:458
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Another important point about cryptographic algorithms is that often these algorithms require random numbers to operate correctly (e.g. to generate keys). Generating good random numbers is difficult and any implementation of cryptographic algorithms should also include a secure random number generator. :rfc:`4086` provides useful recommendations. 348/10000 · 348
47 ../../exercises/ipv6.rst:476
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — ``p:0003::/64`` used on the link ``B2-R6``. ``B2`` uses address ``p:0003::B2/64`` 81/10000 · 81
47 ../../exercises/routing-protocols.rst:559
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — We can now explore the routes in this small Internet. Host ``h1`` can reach directly host ``h3``. 97/10000 · 97
47 ../../exercises/tcp-2.rst:643
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the delay required to transmit a single TCP segment containing MSS bytes is small and set to 1 milliseconds, independently of the MSS size 138/10000 · 138
47 ../../protocols/bgp.rst:138
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `Update message` to indicate a BGP `UPDATE` containing a new or updated route towards one destination prefix with its attributes 128/10000 · 128
47 ../../protocols/congestion.rst:221
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The first TCP congestion control scheme was proposed by `Van Jacobson`_ in [Jacobson1988]_. In addition to writing the scientific paper, `Van Jacobson`_ also implemented the slow-start and congestion avoidance schemes in release 4.3 `Tahoe` of the BSD Unix distributed by the University of Berkeley. Later, he improved the congestion control by adding the fast retransmit and the fast recovery mechanisms in the `Reno` release of 4.3 BSD Unix. Since then, many researchers have proposed, simulated and implemented modifications to the TCP congestion control scheme. Some of these modifications are still used today, e.g. : 622/10000 · 622
47 ../../protocols/email.rst:222
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The last MIME header line is `Content-Transfer-Encoding:`. This header line is used after the `Content-Type:` header line, within a message part, and specifies how the message part has been encoded. The default encoding is to use 7 bits ASCII. The most frequent encodings are `quoted-printable` and `Base64`. Both support encoding a sequence of bytes into a set of ASCII lines that can be safely transmitted by email servers. `quoted-printable` is defined in :rfc:`2045`. We briefly describe `base64` which is defined in :rfc:`2045` and :rfc:`4648`. 549/10000 · 549