Exit Zen
30
../../protocols/ssh.rst:227
English
``payload`` : the data (after optional compression) passed by the user
0/700 · 70
30
../../protocols/tcp.rst:58
English
the `Optional header extension` is used to add optional information to the TCP header. Thanks to this header extension, it is possible to add new fields to the TCP header that were not planned in the original specification. This allowed TCP to evolve since the early eighties. The details of the TCP header extension are explained in sections :ref:`TCPOpen` and :ref:`TCPReliable`.
0/3810 · 381
30
../../protocols/tls.rst:100
English
Verify that the client interacts with a valid server
0/520 · 52
30
../../protocols/wifi.rst:26
English
150 Mbps
0/100 · 8
31
../../bibliography.rst:99
English
Kerrisk, M., `The Linux Programming Interface <http://nostarch.com/tlpi>`_, No Starch Press, 2010
0/970 · 97
31
../../exercises/ex-sharing.rst:609
English
In this network, a 250 Kbps link is used between the routers. The propagation delays in the network are negligible. Host `A` sends 1000 bits long segments so that it takes one msec to transmit one segment on the `A-R1` link. Neglecting the transmission delays for the acknowledgments, what is the minimum round-trip time measured on host `A` with such segments ?
0/3620 · 362
31
../../principles/network.rst:118
English
Any solution which is used to compute the forwarding tables of a network must ensure that all destinations are reachable from any source. This implies that it must guarantee the absence of black holes and forwarding loops.
0/2220 · 222
31
../../principles/transport.rst:66
English
`space` : `0100000b`
0/200 · 20
31
../../principles/sharing.rst:150
English
the node's capacity measured in bits per second
0/470 · 47
31
../../principles/security.rst:367
English
a public key (:math:`K_{pub}`) that he can distribute to everyone
0/650 · 65
31
../../exercises/dns.rst:93
English
The next three questions ask you to go one step further by predicting the values of specific fields in the DNS messages.
0/1200 · 120
31
../../exercises/ipv6.rst:295
English
``p:13/64`` for the link between ``R1`` and ``R3``. On this subnet, ``R1`` uses address ``p:13::1`` while router ``R3`` uses address ``p:13::3``
0/1440 · 144
31
../../exercises/tcp-2.rst:213
English
As for the establishment of a connection, it is also possible for the two communicating hosts to close the connection at the same time. This is shown in the example below where the remote host sends its own ``FIN`` when acknowledging the first one. This script is available from :download:`/exercises/packetdrill_scripts/local-close2.pkt`.
0/3390 · 339
31
../../protocols/bgp.rst:101
English
The figure below shows a simple example of the BGP routes that are exchanged between domains. In this example, prefix `2001:db8:cafe::/48` is announced by `AS1`. `AS1` advertises a BGP route towards this prefix to `AS2`. The AS-Path of this route indicates that `AS1` is the originator of the prefix. When `AS4` receives the BGP route from `AS1`, it re-announces it to `AS2` and adds its AS number to the AS-Path. `AS2` has learned two routes towards prefix `2001:db8:cafe::/48`. It compares the two routes and prefers the route learned from `AS4` based on its own ranking algorithm. `AS2` advertises to `AS5` a route towards `2001:db8:cafe::/48` with its AS-Path set to `AS2:AS4:AS1`. Thanks to the AS-Path, `AS5` knows that if it sends a packet towards `2001:db8:cafe::/48` the packet first passes through `AS2`, then through `AS4` before reaching its destination inside `AS1`.
0/8790 · 879
31
../../protocols/congestion.rst:180
English
Routers that use a single queue measure their buffer occupancy as the number of bytes of packets stored in the queue [#fslot]_. A first method to detect congestion is to measure the instantaneous buffer occupancy and consider the router to be congested as soon as this occupancy is above a threshold. Typical values of the threshold could be 40% of the total buffer. Measuring the instantaneous buffer occupancy is simple since it only requires one counter. However, this value is fragile from a control viewpoint since it changes frequently. A better solution is to measure the *average* buffer occupancy and consider the router to be congested when this average occupancy is too high. Random Early Detection (RED) [FJ1993]_ is an algorithm that was designed to support Explicit Congestion Notification. In addition to measuring the average buffer occupancy, it also uses probabilistic marking. When the router is congested, the arriving packets are marked with a probability that increases with the average buffer occupancy. The main advantage of using probabilistic marking instead of marking all arriving packets is that flows will be marked in proportion of the number of packets that they transmit. If the router marks 10% of the arriving packets when congested, then a large flow that sends hundred packets per second will be marked 10 times while a flow that only sends one packet per second will not be marked. This probabilistic marking allows marking packets in proportion of their usage of the network resources.
0/15240 · 1524
31
../../protocols/email.rst:174
English
The `MIME-Version:` header line indicates the version of the MIME specification that was used to encode the email message. The current version of MIME is 1.0. Other versions of MIME may be defined in the future. Thanks to this header line, the software that processes email messages will be able to adapt to the MIME version used to encode the message. Messages that do not contain this header are supposed to be formatted according to the original :rfc:`822` specification.
0/4740 · 474
31
../../protocols/ethernet.rst:172
English
Thin coaxial cable, 185m
0/240 · 24
31
../../protocols/http.rst:123
English
a `header`, that contains additional information about the response. The response header ends with an empty line.
0/1130 · 113
31
../../protocols/http2.rst:228
English
By using multiple streams, the server can multiplex different web objects over the same underlying transport connection. However, these objects are only sent in response to requests from clients. There are some situations where the server might know in advance that the client will request a given object. It could speedup the transfer by sending it before having received a client request. This is the `push` feature of HTTP/2.0. A server can independently push web objects to a client without having received any request. This feature can only be used by the server if the client has enabled it by sending `SETTINGS_ENABLE_PUSH` in its `Settings` frame. A classical use case for this `push` feature is to enable a server to automatically send an object which cannot be cached by the client, such as a dynamic javascript code, when another web object that references it is requested. However, measurement studies indicate that very few web servers seem to have adopted this feature [ZWH2018]_.
0/9940 · 994
31
../../protocols/ipv6.rst:119
English
``2001:db8:0:0:8:800:200c:417a`` is represented as ``2001:db8::8:800:200c:417a``
0/820 · 82