2. cnp3-ebook
3. English
4. Zen

32 ../../protocols/rpc.rst:117
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `result`: if the request succeeded, this member contains the result of the request (in our example, value `4`). 111/10000 · 111
32 ../../protocols/ssh.rst:231
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — ``MAC`` : this field is present if a Message Authentication Code has been negotiated for the session (in practice, using ``ssh`` without authentication is risky and this field should always be present). Note that to compute the MAC, an ``ssh`` implementation must maintain a message counter. This counter is incremented by one every time a message is sent and the MAC is computed with the negotiated authentication algorithm using the MAC key over the concatenation of the message counter and the cleartext message. The message counter is not transmitted, but the recipient can easily recover its value. The ``MAC`` is computed as :math:`mac = MAC(key, sequence\_number || unencrypted\_message)` where the key is the negotiated authentication key. 747/10000 · 747
32 ../../protocols/tcp.rst:107
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — TCP connection establishment 28/10000 · 28
32 ../../protocols/tls.rst:105
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The TLS handshake is a four-way handshake illustrated in the figure below. 74/10000 · 74
32 ../../protocols/wifi.rst:29
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — When developing its family of standards, the `IEEE 802.11 working group <http://www.ieee802.org/11/>`_ took a similar approach as the `IEEE 802.3 working group <http://www.ieee802.org/3/>`_ that developed various types of physical layers for Ethernet networks. 802.11 networks use the CSMA/CA Medium Access Control technique described earlier and they all assume the same architecture and use the same frame format. 415/10000 · 415
32 ../../bibliography.rst:44
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Gont, F., `Security Assessment of the Transmission Control Protocol (TCP) <http://tools.ietf.org/html/draft-ietf-tcpm-tcp-security-02>`_,Security Assessment of the Transmission Control Protocol (TCP), Internet draft, work in progress, Jan. 2011 244/10000 · 244
33 ../../exercises/ex-sharing.rst:611
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Same question as above, but now host `A` uses the simple DECBIT congestion control mechanism and a maximum window size of four segments. 136/10000 · 136
33 ../../exercises/sockets.rst:285
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The ``::1`` IPv6 address identifies the computer on which the current program is running. 89/10000 · 89
33 ../../principles/naming.rst:144
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — See http://www.donelan.com/dnstimeline.html for a time line of DNS related developments. 88/10000 · 88
33 ../../principles/referencemodels.rst:224
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the Transport layer 19/10000 · 19
33 ../../exercises/network.rst:285
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The network below uses port forwarding tables. What happens if host `A` moves by removing its link with `R1` and replacing it with a link with `R3`? How should networks using port forwarding deal with such mobile hosts ? 220/10000 · 220
33 ../../glossary.rst:170
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — An eBGP session is a BGP session between two directly connected routers that belong to two different Autonomous Systems. Also called an external BGP session. 157/10000 · 157
33 ../../principles/sharing.rst:218
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — If the buffer's occupancy continues to grow, it will overflow and packets will need to be discarded. Discarding packets during congestion is the second possible reaction of a network node to congestion. Before looking at how a node can discard packets, it is interesting to discuss qualitatively the impact of the buffer occupancy on the reliable delivery of data through a network. This is illustrated by the figure below, adapted from [Jain1990]_. 449/10000 · 449
33 ../../principles/transport.rst:86
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `line feed` (`LF`) : `0001010b` 31/10000 · 31
33 ../../principles/security.rst:371
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — These two keys are generated together and they are linked by a complex mathematical relationship that is such that it is computationally difficult to compute :math:`K_{priv}` from :math:`K_{pub}`. 196/10000 · 196
33 ../../exercises/dns.rst:112
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Footnotes 9/10000 · 9
33 ../../exercises/ipv6.rst:297
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — ... 3/10000 · 3
33 ../../exercises/routing-protocols.rst:378
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Exploring BGP 13/10000 · 13
33 ../../exercises/tcp-2.rst:259
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Another very interesting utilization of packetdrill_ is to explore how a TCP stack reacts to acknowledgments that would correspond to lost or reordered segments. For this analysis, we configure a very large initial congestion window to ensure that the connection does not start with a slow-start. 296/10000 · 296
33 ../../protocols/bgp.rst:110
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — BGP routers exchange routes over BGP sessions. A BGP session is established between two routers belonging to two different domains that are directly connected. As explained earlier, the physical connection between the two routers can be implemented as a private peering link or over an Internet eXchange Point. A BGP session between two adjacent routers runs above a TCP connection (the default BGP port is 179). In contrast with intradomain routing protocols that exchange IP packets or UDP segments, BGP runs above TCP because TCP ensures a reliable delivery of the BGP messages sent by each router without forcing the routers to implement acknowledgments, checksums, etc. Furthermore, the two routers consider the peering link to be up as long as the BGP session and the underlying TCP connection remain up [#flifetimebgp]_. The two endpoints of a BGP session are called `BGP peers`. 886/10000 · 886