2. cnp3-ebook
3. English
4. Zen

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
54 ../../protocols/ipv6.rst:180
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — ``/56`` for small user sites 28/10000 · 28
54 ../../protocols/ethernet.rst:176
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Two multi-mode optical fiber, 2 km maximum 42/10000 · 42
54 ../../protocols/routing.rst:169
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Footnotes 9/10000 · 9
54 ../../protocols/tcp.rst:None
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Denial of Service attacks 25/10000 · 25
54 ../../protocols/tls.rst:283
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The client sends the ``ChangeCipherSpec`` message followed by the ``Finished`` message. The ``ChangeCipherSpec`` message indicates that the client has received all the information required to generate the security keys for this TLS session. This messages can also appear later in the session to indicate a change in the encryption algorithms that are used, but this usage is outside the scope of this book. The ``Finished`` message is more important. It confirms to the server that the TLS handshake has been performed correctly and that no attacker has been able to modify the data sent by the client or the server. This is the first message that is encrypted with the selected security keys. It contains a hash of all the messages that were exchanged during the handshake. 774/10000 · 774
54 ../../protocols/wifi.rst:154
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The second important utilization of the management frames is to allow a WiFi station to be associated with an access point. When a WiFi station starts, it listens to beacon frames to find the available SSIDs. To be allowed to send and receive frames via an access point, a WiFi station must be associated to this access point. If the access point does not use any security mechanism to secure the wireless transmission, the WiFi station simply sends an `Association request` frame to its preferred access point (usually the access point that it receives with the strongest radio signal). This frame contains some parameters chosen by the WiFi station and the SSID that it requests to join. The access point replies with an `Association response frame` if it accepts the WiFI station. 783/10000 · 783
54 ../../exercises/sockets.rst:372
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — As an example, here is what you could have to invoke your programs. 67/10000 · 67
54 ../../bibliography.rst:74
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Freier, A., Karlton, P., Kocher, C., `The SSL Protocol Version 3.0`, Internet draft, November 1996, https://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00 159/10000 · 159
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