2. cnp3-ebook
3. English
4. Zen

17 ../../exercises/routing-protocols.rst:249
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — We can then observe the Database description packet that is sent by routers to announce the state of their OSPFv3 database. The details of this packet are beyond the scope of this simple exercise. 196/10000 · 196
17 ../../exercises/tcp-2.rst:95
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — This TCP segment is sent immediately by the stack. The ``SYN`` flag is set and the dot next to the ``S`` character indicates that the ACK flag is also set. The SYN+ACK segment does not contain any data but its acknowledgment number is set to 1 (relative to the initial sequence number). For outgoing packets, packetdrill_ does not verify the value of the advertised window. In this line, it also accepts any TCP options (``<...>``). 432/10000 · 432
17 ../../exercises/trace.rst:98
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The second tool is the flow graph that is part of the `Statistics` menu. It provides a time sequence diagram of the packets exchanged with some comments about the packet contents. See below for an example. 205/10000 · 205
17 ../../protocols/bgp.rst:60
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The second rule ensures that the customer domain receives a route towards all destinations that are reachable via its provider. The first rule allows the prefixes of the customer domain to be distributed throughout the Internet. 228/10000 · 228
17 ../../protocols/congestion.rst:98
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Controlling congestion without losing data 42/10000 · 42
17 ../../protocols/dnssec.rst:173
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `NSEC` record is used when non-existent domain names are queried. Its usage will be explained later 103/10000 · 103
17 ../../protocols/email.rst:103
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Other header lines appear in most email messages. The `Subject:` header line allows the sender to indicate the topic discussed in the email. Three types of header lines can be used to specify the recipients of a message : 221/10000 · 221
17 ../../protocols/ethernet.rst:97
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — does not reorder the transmitted frames 39/10000 · 39
17 ../../protocols/http.rst:80
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The third part of the URI is the path to the document. This path is structured as filenames on a Unix host (but it does not imply that the files are indeed stored this way on the server). If the path is not specified, the server will return a default document. The last two optional parts of the URI are used to provide a query parameter and indicate a specific part (e.g. a section in an article) of the requested document. Sample URIs are shown below. 453/10000 · 453
17 ../../protocols/http2.rst:109
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — With `pipelining`, the client sends the five requests immediately and receives the five responses after 200 msec. The figure below illustrates the benefits of `pipelining`. 172/10000 · 172
17 ../../protocols/ipv6.rst:95
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — IPv6 addresses are encoded as a 128 bits field 46/10000 · 46
17 ../../protocols/ethernet.rst:12
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Ethernet was designed in the 1970s at the Palo Alto Research Center [Metcalfe1976]_. The first prototype [#fethernethistory]_ used a coaxial cable as the shared medium and 3 Mbps of bandwidth. Ethernet was improved during the late 1970s and in the 1980s, Digital Equipment, Intel and Xerox published the first official Ethernet specification [DIX]_. This specification defines several important parameters for Ethernet networks. The first decision was to standardize the commercial Ethernet at 10 Mbps. The second decision was the duration of the `slot time`. In Ethernet, a long `slot time` enables networks to span a long distance but forces the host to use a larger minimum frame size. The compromise was a `slot time` of 51.2 microseconds, which corresponds to a minimum frame size of 64 bytes. 798/10000 · 798
17 ../../protocols/routing.rst:58
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A note on timers 16/10000 · 16
17 ../../protocols/rpc.rst:58
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In some situations, it is necessary to encode fixed or variable length arrays. XDR :rfc:`1832` supports such arrays. For example, the encoding below corresponds to a variable length array containing n elements. The encoded representation starts with an integer that contains the number of elements and follows with all elements in sequence. It is also possible to encode a fixed-length array. In this case, the first integer (the `n` field) is missing. 452/10000 · 452
17 ../../protocols/ssh.rst:140
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the server generates the random number :math:`b`. It then computes :math:`B=g^{b} \mod p`, :math:`K=B^{a} \mod p` and signs with its private key :math:`hash(V_{Client} || V_{Server} || KEX\_INIT_{Client} || KEX\_INIT_{Server} || Server_{pub} || A || B || K )` where :math:`V_{Server}` (resp. :math:`V_{Client}`) is the initial messages sent by the client (resp. server), :math:`KEX\_INIT_{Client}` (resp. :math:`KEX\_INIT_{Server}`) is the key exchange message sent by the client (resp. server) and :math:`A`, :math:`B` and :math:`K` are the messages of the Diffie Hellman key exchange 586/10000 · 586
17 ../../protocols/tcp.rst:42
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the port chosen by the server 29/10000 · 29
17 ../../protocols/tls.rst:45
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 563 3/10000 · 3
17 ../../protocols/transport-service.rst:53
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `fe80:0:0:0:219:e3ff:fed7:1204` 31/10000 · 31
17 ../../protocols/udp.rst:61
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the ephemeral port numbers ( officially [#fephemeral]_ 49152 <= port <= 65535 ) 79/10000 · 79
17 ../../protocols/wifi.rst:23
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 5 GHz 5/10000 · 5