2. cnp3-ebook
3. English
4. Zen

21 ../../protocols/ethernet.rst:49
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The fourth part of the Ethernet frame is the payload. The minimum length of the payload is 46 bytes to ensure a minimum frame size, including the header of 512 bits. The Ethernet payload cannot be longer than 1500 bytes. This size was found reasonable when the first Ethernet specification was written. At that time, Xerox had been using its experimental 3 Mbps Ethernet that offered 554 bytes of payload and :rfc:`1122` required a minimum MTU of 572 bytes for IPv4. 1500 bytes was large enough to support these needs without forcing the network adapters to contain overly large memories. Furthermore, simulations and measurement studies performed in Ethernet networks revealed that CSMA/CD was able to achieve a very high utilization. This is illustrated in the figure below based on [SH1980]_, which shows the channel utilization achieved in Ethernet networks containing different numbers of hosts that are sending frames of different sizes. 943/10000 · 943
21 ../../protocols/routing.rst:71
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Compared to the basics of link-state routing protocols that we discussed in section :ref:`linkstate`, there are some particularities of OSPF that are worth discussing. First, in a large network, flooding the information about all routers and links to thousands of routers or more may be costly as each router needs to store all the information about the entire network. A better approach would be to introduce hierarchical routing. Hierarchical routing divides the network into regions. All the routers inside a region have detailed information about the topology of the region but only learn aggregated information about the topology of the other regions and their interconnections. OSPF supports a restricted variant of hierarchical routing. In OSPF's terminology, a region is called an `area`. 796/10000 · 796
21 ../../protocols/rpc.rst:94
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Compared with XDR, the main advantage of JSON is that the transfer syntax is easily readable by a human. However, this comes at the expense of a less compact encoding. Some data encoded in JSON will usually take more space than when it is encoded with XDR. More compact encoding schemes have been defined, see e.g. [BH2013]_ and the references therein. 352/10000 · 352
21 ../../protocols/ssh.rst:193
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Single use keys 15/10000 · 15
21 ../../protocols/tcp.rst:48
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `SYN` flag is used during connection establishment 54/10000 · 54
21 ../../protocols/tls.rst:47
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — FTP 3/10000 · 3
21 ../../protocols/transport-service.rst:60
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `0:0:0:0:0:0:0:1` is represented as `::1` 41/10000 · 41
21 ../../protocols/udp.rst:71
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The checksum of the UDP segment is computed over : 50/10000 · 50
21 ../../protocols/wifi.rst:24
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 802.11b 7/10000 · 7
21 ../../bibliography.rst:30
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Brakmo, L. S., O'Malley, S. W., and Peterson, L. L., `TCP Vegas: new techniques for congestion detection and avoidance <http://doi.acm.org/10.1145/190314.190317>`_. In Proceedings of the Conference on Communications Architectures, Protocols and Applications (London, United Kingdom, August 31 - September 02, 1994). SIGCOMM '94. ACM, New York, NY, 24-35. 354/10000 · 354
21 ../../principles/transport.rst:68
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Human conversations can be very formal, e.g. when soldiers communicate with their hierarchy, or informal such as when friends discuss. Computers that communicate are more akin to soldiers and require well-defined rules to ensure a successful exchange of information. There are two types of rules that define how information can be exchanged between computers : 361/10000 · 361
22 ../../exercises/ex-sharing.rst:538 • ../../exercises/ex-sharing.rst:613
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Consider the network depicted in the figure below. 50/10000 · 50
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