2. cnp3-ebook
3. English
4. Zen

54 ../../principles/sharing.rst:359
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — There is another solution that allows spreading the load among many sources without relying on the name service. The popular `bittorent <https://www.bittorrent.com>`_ service is an example of this approach. With this solution, each file is divided in blocks of fixed size. To retrieve a file, a client needs to retrieve all the blocks that compose the file. However, nothing forces the client to retrieve all the blocks in sequence and from the same server. Each file is associated with metadata that indicates for each block a list of addresses of hosts that store this block. To retrieve a complete file, a client first downloads the metadata. Then, it tries to retrieve each block from one of the hosts that store the block. In practice, implementations often try to download several blocks in parallel. Once one block has been successfully downloaded, the next block can be requested. If a host is slow to provide one block or becomes unavailable, the client can contact another host listed in the metadata. Most deployments of bittorrent allow the clients to participate to the distribution of blocks. Once a client has downloaded one block, it contacts the server which stores the metadata to indicate that it can also provide this block. With this scheme, when a file is popular, its blocks are downloaded by many hosts that automatically participate in the distribution of the blocks. Thus, the number of `servers` that are capable of providing blocks from a popular file automatically increases with the file's popularity. 1531/10000 · 1531
55 ../../bibliography.rst:76
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Fortz, B. Rexford, J. ,Thorup, M., `Traffic engineering with traditional IP routing protocols <https://dx.doi.org/10.1109/MCOM.2002.1039866>`_, IEEE Communication Magazine, October 2002 185/10000 · 185
55 ../../exercises/network.rst:373 • ../../exercises/network.rst:375
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 2 via C 7/10000 · 7
55 ../../glossary.rst:185
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The HyperText Transport Protocol is defined in :rfc:`2616` 58/10000 · 58
55 ../../principles/reliability.rst:231
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 01111110000100100100100100100001101111110 41/10000 · 41
55 ../../principles/sharing.rst:363
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Now that we have provided a broad overview of the techniques that can be used to spread the load and allocate resources in the network, let us analyze two techniques in more details : Medium Access Control and Congestion control. 229/10000 · 229
55 ../../principles/transport.rst:200
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A second imperfection that may affect an `unreliable connectionless service` is that it may duplicate SDUs. Some packets may be duplicated in a network and be delivered twice to their destination. This is illustrated by the time-sequence diagram below. 252/10000 · 252
55 ../../principles/security.rst:571
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A better approach would be to authenticate Alice without storing her password in clear on Bob's computer. For this, Alice computes a `hash chain` as proposed by Lamport in [Lamport1981]_. A hash chain is a sequence of applications of a hash function (`H`) on an input string. If Alice's password is `P`, then her 10 steps hash chain is : :math:`H(H(H(H(H(H(H(H(H(H(P))))))))))`. The result of this hash chain will be stored on Bob's computer together with the value `10`. This number is the maximum number of remaining authentications for Alice on Bob's computer. To authenticate Alice, Bob sends the remaining number of authentications, i.e. `10` in this example. Since Alice knows her password, `P`, she can compute :math:`H^9(P)=H(H(H(H(H(H(H(H(H(P)))))))))` and send this information to Bob. Bob computes the hash of the value received from Alice (:math:`H(H^9(P))`) and verifies that this value is equal to the value stored in his database. It then decrements the number of authorized authentications and stores :math:`H^9(P)` in his database. Bob is now ready for the next authentication of Alice. When the number of authorized authentications reaches zero, the hash chain needs to be reinitialized. If Eve captures :math:`(H^n(P))`, she cannot use it to authenticate herself as Alice on Bob's computer because Bob will have decremented its number of authorized authentications. Furthermore, given that hash functions are not invertible, Eve cannot compute :math:`H^{n-1}(P)` from :math:`H^{n}(P)`. 1504/10000 · 1504
55 ../../exercises/ipv6.rst:527
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Configuring IPv6 Networks 25/10000 · 25
55 ../../exercises/routing-protocols.rst:812
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — We can now observe the BGP-Loc-RIB of the router with the ``show bgp ipv6 command`` command. 92/10000 · 92
55 ../../exercises/tcp-2.rst:688
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — How long does it take for the sender to deliver 3 KBytes to the receiver ? 74/10000 · 74
55 ../../protocols/bgp.rst:166
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — When a BGP session starts, the routers first exchange `OPEN` messages to negotiate the options that apply throughout the entire session. Then, each router extracts from its FIB the routes to be advertised to the peer. It is important to note that, for each known destination prefix, a BGP router can only advertise to a peer the route that it has itself installed inside its `FIB`. The routes that are advertised to a peer must pass the peer's `export filter`. The `export filter` is a set of rules that define which routes can be advertised over the corresponding session, possibly after having modified some of its attributes. One `export filter` is associated to each BGP session. For example, on a `shared-cost peering`, the `export filter` only selects the internal routes and the routes that have been learned from a `customer`. The pseudo-code below shows the initialization of a BGP session. 899/10000 · 899
55 ../../protocols/congestion.rst:238
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In enterprise networks or datacenters, the situation is different since a single company typically controls all the sources and all the routers. In such networks it is possible to ensure that all hosts and routers have been upgraded before turning on ECN on the routers. 270/10000 · 270
55 ../../protocols/email.rst:232
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 34 2/10000 · 2
55 ../../protocols/ethernet.rst:207
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Ethernet Switches 17/10000 · 17
55 ../../protocols/http.rst:188
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — All status codes starting with digit `3` indicate that the requested document is no longer available on the server. `301 Moved Permanently` indicates that the requested document is no longer available on this server. A `Location:` header containing the new URI of the requested document is inserted in the HTTP response. `304 Not Modified` is used in response to an HTTP request containing the `If-Modified-Since:` header. This status line is used by the server if the document stored on the server is not more recent than the date indicated in the `If-Modified-Since:` header. 577/10000 · 577
55 ../../protocols/ipv6.rst:181
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — ``/64`` for a single user (e.g. a home user connected via ADSL) 63/10000 · 63
55 ../../protocols/ethernet.rst:177
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 1000Base-CX 11/10000 · 11
55 ../../protocols/routing.rst:170
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — See http://bgp.potaroo.net/index-as.html for reports on the evolution of the number of Autonomous Systems over time. 116/10000 · 116
55 ../../protocols/tcp.rst:192
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — When a TCP entity opens a TCP connection, it creates a Transmission Control Block (:term:`TCB`). The TCB contains the entire state that is maintained by the TCP entity for each TCP connection. During connection establishment, the TCB contains the local IP address, the remote IP address, the local port number, the remote port number, the current local sequence number and the last sequence number received from the remote entity. Until the mid 1990s, TCP implementations had a limit on the number of TCP connections that could be in the `SYN RCVD` state at a given time. Many implementations set this limit to about 100 TCBs. This limit was considered sufficient even for heavily load http servers given the small delay between the reception of a `SYN` segment and the reception of the `ACK` segment that terminates the establishment of the TCP connection. When the limit of 100 TCBs in the `SYN Rcvd` state is reached, the TCP entity discards all received TCP `SYN` segments that do not correspond to an existing TCB. 1019/10000 · 1019