2. cnp3-ebook
3. English
4. Zen

41 ../../protocols/email.rst:213
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `image`. The message part contains a binary representation of an image. The subtype indicates the format of the image such as `gif <http://en.wikipedia.org/wiki/Graphics_Interchange_Format>`_, `jpg <http://en.wikipedia.org/wiki/Jpeg>`_ or `png <http://en.wikipedia.org/wiki/Portable_Network_Graphics>`_. 303/10000 · 303
41 ../../protocols/ethernet.rst:177
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Two pairs shielded twisted pair, 25m maximum 44/10000 · 44
41 ../../protocols/http.rst:162
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — :rfc:`1945` and :rfc:`2616` define headers that are specific to HTTP responses. These server headers include: 109/10000 · 109
41 ../../protocols/ipv6.rst:155
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A `global routing prefix` that is assigned to the Internet Service Provider that owns this block of addresses 109/10000 · 109
41 ../../protocols/ethernet.rst:169 • ../../protocols/wifi.rst:19
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Standard 8/10000 · 8
41 ../../protocols/routing.rst:135
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To better represent LANs and reduce the number of OSPF packets that are exchanged, OSPF handles LAN differently. When OSPF routers boot on a LAN, they elect [#felection]_ one of them as the `Designated Router (DR)` :rfc:`2328`. The `DR` router `represents` the local area network, and advertises the LAN's subnet. Furthermore, LAN routers only exchange HELLO packets with the `DR`. Thanks to the utilization of a `DR`, the topology of the LAN appears as a set of point-to-point links connected to the `DR` router. 513/10000 · 513
41 ../../protocols/rpc.rst:151
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Footnotes 9/10000 · 9
41 ../../protocols/ssh.rst:305
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The exact algorithms used for the computation of these keys are defined in :rfc:`4253` 86/10000 · 86
41 ../../protocols/tcp.rst:127
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `acknowledgment number` set to the `sequence number` of the received `SYN+ACK` segment incremented by 1 :math:`\pmod{2^{32}}` 129/10000 · 129
41 ../../protocols/tls.rst:175
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The ``Server Name Indication (SNI)`` extension defined in :rfc:`6066` is an important TLS extension for web servers. It is used by the client to indicate the name of the server that it wishes to contact. The IP address associated to this name has been queried from the DNS and used to establish the TCP connection. Why should the client indicate the server name in the TLS ``ClientHello`` ? The motivation is the same as for the ``Host`` header line in HTTP/1.0. With the SNI extension, a single TLS server can support several web sites that use different domain names. Thanks to the SNI extension, the server knows the concerned domain name at the start of the TLS session. Without this extension, hosting providers would have been forced use one IP address per TLS-enabled server. 783/10000 · 783
41 ../../protocols/wifi.rst:105
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The astute reader may have noticed that the 802.11 data frames contain three 48-bits address fields [#f4addresses]_ . This is surprising compared to other protocols in the network and datalink layers whose headers only contain a source and a destination address. The need for a third address in the 802.11 header comes from the `infrastructure` networks. In such a network, frames are usually exchanged between routers and servers attached to the LAN and WiFi devices attached to one of the access points. The role of the three address fields is specified by bit flags in the `Frame Control` field. 598/10000 · 598
41 ../../exercises/reliability.rst:82
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A go-back-n sender has sent :math:`2^n` data frames. All the frames have been received correctly and in-order by the receiver, but all the returned acknowledgments have been lost. Show by using a time sequence diagram (e.g. by considering a window of four frames) what happens in this case. Can you fix the problem on the go-back-n sender ? 340/10000 · 340
41 ../../bibliography.rst:58
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Dimitropoulos, X., Krioukov, D., Fomenkov, M., Huffaker, B., Hyun, Y., Claffy, K., Riley, G., `AS Relationships: Inference and Validation <http://doi.acm.org/10.1145/1198255.1198259>`_, ACM SIGCOMM Computer Communication Review (CCR), Jan. 2007 245/10000 · 245
41 ../../principles/sharing.rst:240
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `Probabilistic drop`. Various random drop techniques have been proposed. A frequently cited technique is `Random Early Discard` (RED) [FJ1993]_. RED measures the average buffer occupancy and discards packets with a given probability when this average occupancy is too high. Compared to `tail drop` and `drop from front`, an advantage of `RED` is that thanks to the probabilistic drops, packets should be discarded from different flows in proportion of their bandwidth. 468/10000 · 468
42 ../../exercises/sockets.rst:330
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Besides character strings, some applications also need to exchange 16 bits and 32 bits fields such as integers. A naive solution would have been to send the 16- or 32-bits field as it is encoded in the host's memory. Unfortunately, there are different methods to store 16- or 32-bits fields in memory. Some CPUs store the most significant byte of a 16-bits field in the first address of the field while others store the least significant byte at this location. When networked applications running on different CPUs exchange 16 bits fields, there are two possibilities to transfer them over the transport service : 613/10000 · 613
42 ../../exercises/network.rst:369
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Routes on A 11/10000 · 11
42 ../../glossary.rst:60
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — frame 5/10000 · 5
42 ../../exercises/reliability.rst:84
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Same question as above, but assume now that both the sender and the receiver implement selective repeat. Note that the answer can be different from the above question. 167/10000 · 167
42 ../../principles/referencemodels.rst:275
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Footnotes 9/10000 · 9
42 ../../principles/network.rst:240
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Learning the location of the sources is not sufficient, nodes also need to forward packets towards their destination. When a node receives a packet whose destination address is already present inside its port-address table, it simply forwards the packet on the interface listed in the port-address table. In this case, the packet will follow the port-address table entries in the downstream nodes and will reach the destination. If the destination address is not included in the port-address table, the node simply forwards the packet on all its interfaces, except the interface from which the packet was received. Forwarding a packet over all interfaces is usually called `broadcasting` in the terminology of computer networks. Sending the packet over all interfaces except one is a costly operation since the packet is sent over links that do not reach the destination. Given the tree-shape of the network, the packet will explore all downstream branches of the tree and will finally reach its destination. In practice, the `broadcasting` operation does not occur too often and its performance impact remains limited. 1119/10000 · 1119