2. cnp3-ebook
3. English
4. Zen

22 ../../exercises/sockets.rst:215
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — This function is now using the ``recvfrom`` system call that will also provide the address of the peer who sent the message. As addresses are generic and can have different sizes, ``recvfrom`` also tells us the size of the address that it has written. 251/10000 · 251
22 ../../principles/naming.rst:119
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To be able to contact the root nameservers, each DNS client must know their addresses. This implies, that DNS clients must maintain an up-to-date list of the addresses of the root nameservers. Without this list, it is impossible to contact the root nameservers. Forcing all Internet hosts to maintain the most recent version of this list would be difficult from an operational point of view. To solve this problem, the designers of the DNS introduced a special type of DNS server : the DNS resolvers. A :term:`resolver` is a server that provides the name resolution service for a set of clients. A network usually contains a few resolvers. Each host in these networks is configured to send all its DNS queries via one of its local resolvers. These queries are called `recursive queries` as the :term:`resolver` must recursively send requests through the hierarchy of nameservers to obtain the `answer`. 902/10000 · 902
22 ../../principles/network.rst:105
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To understand the datagram organization, let us consider the figure below. A network layer address, represented by a letter, has been assigned to each host and router. To send some information to host `J`, host `A` creates a packet containing its own address, the destination address and the information to be exchanged. 320/10000 · 320
22 ../../principles/referencemodels.rst:201
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In the remaining chapters of this text, we will often refer to the information exchanged between entities located in different layers. To avoid any confusion, we will stick to the terminology defined earlier, i.e. : 215/10000 · 215
22 ../../principles/reliability.rst:63
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — On the sender side : 20/10000 · 20
22 ../../exercises/network.rst:187
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `R3->R2->R4->R5` and `R1->R2->R5` 33/10000 · 33
22 ../../exercises/reliability.rst:45
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Practice 8/10000 · 8
22 ../../glossary.rst:223
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — BNF 3/10000 · 3
22 ../../exercises/transport.rst:150
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Some transport protocols use 32 bits sequence numbers while others use 64 bits sequence number. What are the advantages and drawbacks of each approach ? 152/10000 · 152
22 ../../principles/sharing.rst:190
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Congestion collapse is unfortunately not only an academic experience. Van Jacobson reports in [Jacobson1988]_ one of these events that affected him while he was working at the Lawrence Berkeley Laboratory (LBL). LBL was two network nodes away from the University of California in Berkeley. At that time, the link between the two sites had a bandwidth of 32 Kbps, but some hosts were already attached to 10 Mbps LANs. "In October 1986, the data throughput from LBL to UC Berkeley ... dropped from 32 Kbps to 40 bps. We were fascinated by this sudden factor-of-thousand drop in bandwidth and embarked on an investigation of why things had gotten so bad." This work lead to the development of various congestion control techniques that have allowed the Internet to continue to grow without experiencing widespread congestion collapse events. 839/10000 · 839
22 ../../principles/security.rst:287
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — With the Kerckhoff principle, we can now discuss a simple but powerful encryption scheme that relies on the `XOR` logic operation. This operation is easily implemented in hardware and is supported by all microprocessors. Given a secret, :math:`K`, it is possible to encode a message `M` by computing :math:`C_M = K \oplus M`. The receiver of this messages can recover the original message as since :math:`M = K \oplus (K \oplus M)`. This `XOR` operation is the key operation of the perfect cipher that is also called the Vernam cipher or the one-time pad. This cipher relies on a key that contains purely random bits. The encrypted message is then produced by XORing all the bits of the message with all the bits of the key. Since the key is random, it is impossible for an attacker to recover the original text (or plain text) from the encrypted one. From a security viewpoint, the one-time-pad is the best solution provided that the key is as long as the message. 965/10000 · 965
22 ../../exercises/dns.rst:59
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Use `dig` to find the mail relays used by the `uclouvain.be` and `student.uclouvain.be` domains. What is the `TTL` of these records ? Can you explain the preferences used by the `MX` records. You can find more information about the MX records in :rfc:`5321`. 258/10000 · 258
22 ../../exercises/ipv6.rst:193
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — How do you configure the forwarding tables on ``R1`` and ``R4`` so that ``A`` can reach ``B`` and the reverse ? 111/10000 · 111
22 ../../exercises/lan.rst:246
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The first part of the output of the :manpage:`brctl(8)` command shows the state of the Spanning Tree software on the switch. The identifier of this switch is ``0003.f63545ab5f79`` and the root switch is itself. There is no root port on this switch since it is the root. The path cost is the cost of the path to reach the root switch, i.e. 0 on the root. Then the switch reports the different timers. 399/10000 · 399
22 ../../exercises/routing-policies.rst:193
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `Section 3.3 <https://tools.ietf.org/html/rfc4443#section-3.3>`_ of :rfc:`4443` explains two different reasons why an IPv6 enabled device could generate an ICMPv6 Time Exceeded message. Explain when a router could generate such a message with ``Code==0`` and when a host could generate such a message with ``Code==1``. 318/10000 · 318
22 ../../exercises/routing-protocols.rst:269
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A more detailed discussion of the packets that routing protocols exchange may be found in [Goralski2009]_. 106/10000 · 106
22 ../../exercises/tcp-2.rst:123
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In the example above, packetdrill_ injects a segment containing two bytes. This segment is acknowledged and after that the :manpage:`read` system call succeeds and reads the available data with a buffer of 1000 bytes. It returns the amount of read bytes, i.e. ``2``. 266/10000 · 266
22 ../../exercises/trace.rst:112
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — a nice `list of Wireshark Display Filters <https://networksecuritytools.com/list-wireshark-display-filters/>`_ by Robert Allen 126/10000 · 126
22 ../../protocols/bgp.rst:76
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — These different types of relationships are implemented in the `interdomain routing policies` defined by each domain. The `interdomain routing policy` of a domain is composed of three main parts : 195/10000 · 195
22 ../../protocols/congestion.rst:115
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The TCP flags 13/10000 · 13