2. cnp3-ebook
3. English
4. Zen

24 ../../principles/network.rst:191
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The figure illustrates some possible forwarding tables in this network. By inspecting the forwarding tables of the different routers, one can find the path followed by packets sent from a source to a particular destination. In the example above, host `A` sends its packet to router `R1`. `R1` consults its forwarding table and forwards the packet towards `R2`. Based on its own table, `R2` decides to forward the packet to `R5` that can deliver it to its destination. Thus, the path from `A` to `J` is `A -> R1 -> R2 -> R5 -> J`. 529/10000 · 529
24 ../../principles/referencemodels.rst:204
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — datalink layer entities exchange *frames* 41/10000 · 41
24 ../../principles/reliability.rst:63
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — set the voltage on the electrical wire at ``-5V`` during one millisecond to transmit a bit set to `0` 101/10000 · 101
24 ../../exercises/network.rst:191 • ../../exercises/network.rst:223
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Same question with virtual circuits. 36/10000 · 36
24 ../../exercises/reliability.rst:49
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Reliable protocols rely on different types of checksums to verify whether frames have been affected by transmission errors. The most frequently used checksums are : 164/10000 · 164
24 ../../glossary.rst:24
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — broadcast 9/10000 · 9
24 ../../exercises/transport.rst:154
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — What is piggybacking and what are the benefits of this technique ? 66/10000 · 66
24 ../../principles/sharing.rst:194
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Packets per second versus bits per second 41/10000 · 41
24 ../../principles/transport.rst:73
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Let us first discuss the syntactical rules. We will later explain how the information flow can be organized by analyzing real networked applications. 149/10000 · 149
24 ../../protocols/dns.rst:80
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Some DNS resolvers allow any host to send queries. Google operates a `public DNS resolver <https://developers.google.com/speed/public-dns/docs/using>`_ at addresses `2001:4860:4860::8888` and `2001:4860:4860::8844`. Other companies provide similar services. 257/10000 · 257
24 ../../principles/security.rst:310
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A secret key encryption scheme is a perfectly reversible functions, i.e. given an encryption function `E`, there is an associated decryption function `D` such that :math:`\forall k \forall M : D(K, E(M,K))=M`. 209/10000 · 209
24 ../../exercises/dns.rst:73
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A DNS implementation such as `dig`, and more importantly a name resolver such as bind_ or unbound_, always checks that the received DNS reply contains the same identifier as the DNS request that it sent. Why is this so important ? 230/10000 · 230
24 ../../exercises/ipv6.rst:220
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Assuming that the following IPv6 addresses are used : 53/10000 · 53
24 ../../exercises/lan.rst:250
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The state of switch ``s9`` is different. The output of :manpage:`brctl(8)` indicates that the root identifier is ``0003.f63545ab5f79`` which is at a distance of ``1`` from switch ``s9``. The root port on ``s9`` is port `1`, i.e. ``s9-eth1``. Two of the ports of this switch forward data packets, the root port and the ``s9-eth3`` which is a designated port. The ``s9-eth2`` port is a blocked port. 397/10000 · 397
24 ../../exercises/routing-policies.rst:197
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — ``Code==0`` 11/10000 · 11
24 ../../exercises/routing-protocols.rst:274
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — IPMininet_ can also be used to perform experiments with RIP. A simple script that uses RIPng is provided below. 111/10000 · 111
24 ../../exercises/tcp-2.rst:133
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — packetdrill_ injects the ``FIN`` segment and the instrumented kernel returns an acknowledgment. If packetdrill_ issues the :manpage:`close` system call, the kernel will send a ``FIN`` segment to terminate the connection. packetdrill_ injects an acknowledgment to confirm the end of the connection. 297/10000 · 297
24 ../../protocols/bgp.rst:79
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `export filter` that specifies, for each peering relationship, the routes that can be advertised to the neighboring domain 126/10000 · 126
24 ../../protocols/congestion.rst:122
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Thanks to the `ECT`, `CE` and `ECE`, routers can mark packets during congestion and receivers can return the congestion information back to the TCP senders. However, these three bits are not sufficient to allow a server to reliably send the `ECE` bit to a TCP sender. TCP acknowledgments are not sent reliably. A TCP acknowledgment always contains the next expected sequence number. Since TCP acknowledgments are cumulative, the loss of one acknowledgment is recovered by the correct reception of a subsequent acknowledgment. 525/10000 · 525
24 ../../protocols/dnssec.rst:263
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The last record introduced by DNSSEC is the `NSEC` record. It is used to authenticate a negative response returned by a DNS server. If a resolver requests a domain name that is not defined in the zone, the server replies with an error message. The designers of the original version of the DNS thought that these errors would not be very frequent and resolvers were not required to cache those negative responses. However, operational experience showed that queries for invalid domain names are more frequent than initially expected and a large fraction of the load on some servers is caused by repeated queries for invalid names. Typical examples include queries for invalid TLDs to the root DNS servers or queries caused by configuration errors [WF2003]_. Current DNS deployments allow resolvers to cache those negative answers to reduce the load on the entire DNS :rfc:`2308`. 878/10000 · 878