2. cnp3-ebook
3. English
4. Zen

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
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