2. cnp3-ebook
3. English
4. Zen

53 ../../protocols/tcp.rst:185
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Simultaneous establishment of a TCP connection 46/10000 · 46
53 ../../protocols/tls.rst:279
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — All the information required for the key exchange has now been transmitted. There are two important messages that will be sent by the client and the server to conclude the handshake and start the data transfer phase. 216/10000 · 216
53 ../../protocols/wifi.rst:152
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — IP over IEEE 802.11 19/10000 · 19
53 ../../exercises/sockets.rst:370
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — to wrap the ``recv_and_handle_message`` server function in a ``server`` executable, similarly to what you have done with the ``client`` executable. 147/10000 · 147
53 ../../bibliography.rst:73
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Floyd, S., and Jacobson, V., `The Synchronization of Periodic Routing Messages <https://dx.doi.org/10.1109/90.298431>`_, IEEE/ACM Transactions on Networking, V.2 N.2, p. 122-136, April 1994 189/10000 · 189
53 ../../principles/sharing.rst:352
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Another way to share the network resources is to distribute the load across multiple links. Many techniques have been designed to spread the load over the network. As an illustration, let us briefly consider how the load can be shared when accessing some content. Consider a large and popular file such as the image of a Linux distribution or the upgrade of a commercial operating system that will be downloaded by many users. There are many ways to distribute this large file. A naive solution is to place one copy of the file on a server and allow all users to download this file from the server. If the file is popular and millions of users want to download it, the server will quickly become overloaded. There are two classes of solutions that can be used to serve a large number of users. A first approach is to store the file on servers whose name is known by the clients. Before retrieving the file, each client will query the name service to obtain the address of the server. If the file is available from many servers, the name service can provide different addresses to different clients. This will automatically spread the load since different clients will download the file from different servers. Most large content providers use such a solution to distribute large files or videos. 1295/10000 · 1295
54 ../../exercises/network.rst:373 • ../../exercises/network.rst:373
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 1 via B 7/10000 · 7
54 ../../glossary.rst:183
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — HTTP 4/10000 · 4
54 ../../principles/network.rst:337
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — With the received `record route`, `B` can send a `data packet` to `A`. For this, it simply reverses the chosen `record route`. However, we still need to communicate the chosen path to `A`. This can be done by putting the `record route` inside a control packet which is sent back to `A` over the reverse path. An alternative is to simply send a `data packet` back to `A`. This packet will travel back to `A`. To allow `A` to inspect the entire path followed by the `data packet`, its `source route` must contain all intermediate routers when it is received by `A`. This can be achieved by encoding the `source route` using a data structure that contains an index and the ordered list of node addresses. The index always points to the next address in the `source route`. It is initialized at `0` when a packet is created and incremented by each intermediate node. 861/10000 · 861
54 ../../principles/reliability.rst:231
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 0001001001001001001000011 25/10000 · 25
54 ../../principles/transport.rst:198
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In practice, an `unreliable connectionless service` will usually deliver a large fraction of the SDUs. However, since the delivery of SDUs is not guaranteed, the user must be able to recover from the loss of any SDU. 216/10000 · 216
54 ../../principles/security.rst:559
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Unfortunately, this solution forces Bob to store Alice's password in clear. Any breach in the security of Bob's computer would reveal Alice's password. Such breaches unfortunately occur and some of them have led to the dissemination of millions of passwords. 258/10000 · 258
54 ../../exercises/ipv6.rst:517
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Assign IP subnets to all links in this network so that you can reduce the number of entries in the forwarding tables of all routers. Assume that you have received a ``/56`` prefix that you can use as you want. Each subnet containing a host must be allocated a ``/64`` subnet. 275/10000 · 275
54 ../../exercises/routing-protocols.rst:685
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — This router (`as1`) has two BGP neighbors: ``2001:cafe:1:12::2`` and ``2001:cafe:1:13::3``. Both BGP sessions are established using the current version of the protocol (version 4). About 50 messages were sent/received over each session. These messages are mainly the BGP Keepalive messages that are exchanged every 30 seconds. The last column indicates that two prefixes were received over each session. We can see more details about these two eBGP sessions with the `show bgp neighbors` command. 496/10000 · 496
54 ../../exercises/tcp-2.rst:686
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Can you explain why the congestion window is increased after the reception of the first acknowledgment ? 104/10000 · 104
54 ../../protocols/bgp.rst:164
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `Adj-RIB-Out` contains the BGP routes that have been advertised to each BGP peer. The `Adj-RIB-Out` for a given peer is built by applying the peer's `export filter` on the routes that have been installed in the `FIB`. There is one `export filter` per BGP peer. For this reason, the Adj-RIB-Out of a peer may contain different routes than the Adj-RIB-Out of another peer. 374/10000 · 374
54 ../../protocols/congestion.rst:236
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In this pseudo-code, we assume that TCP uses unlimited sequence and acknowledgment numbers. Furthermore, we do not detail how the `cwnd` is adjusted after the retransmission of the lost segment by fast retransmit. Additional details may be found in :rfc:`5681`. 261/10000 · 261
54 ../../protocols/email.rst:232
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — R 1/10000 · 1
54 ../../protocols/ethernet.rst:203
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Fortunately, IEEE was able to define the [IEEE802.3]_ frame format while maintaining backward compatibility with the Ethernet [DIX]_ frame format. The trick was to only assign values above 1500 as `EtherType` values. When a host receives a frame, it can determine whether the frame's format by checking its `EtherType/Length` field. A value lower smaller than `1501` is clearly a length indicator and thus an [IEEE802.3]_ frame. A value larger than `1501` can only be type and thus a [DIX]_ frame. 497/10000 · 497
54 ../../protocols/http.rst:187
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — All status codes starting with digit `2` indicate a valid response. `200 Ok` indicates that the HTTP request was successfully processed by the server and that the response is valid. 181/10000 · 181