Exit Zen
27
../../protocols/tls.rst:93
English
The TLS handshake
0/170 · 17
27
../../protocols/udp.rst:92
English
A discussion of the ephemeral port ranges used by different TCP/UDP implementations may be found in http://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html
0/1570 · 157
27
../../protocols/wifi.rst:26
English
802.11n
0/100 · 7
28
../../bibliography.rst:94
English
Jacobson, V., `Congestion avoidance and control <http://doi.acm.org/10.1145/52324.52356>`_. In Symposium Proceedings on Communications Architectures and Protocols (Stanford, California, United States, August 16 - 18, 1988). V. Cerf, Ed. SIGCOMM '88. ACM, New York, NY, 314-329.
0/2770 · 277
28
../../glossary.rst:283
English
dial-up line
0/120 · 12
28
../../exercises/ex-sharing.rst:582
English
Compute the max-min fair bandwidth allocation in the network below.
0/670 · 67
28
../../principles/network.rst:108
English
In a network, a path can be defined as the list of all intermediate routers for a given source destination pair. For a given source/destination pair, the path can be derived by first consulting the forwarding table of the router attached to the source to determine the next router on the path towards the chosen destination. Then, the forwarding table of this router is queried for the same destination... The queries continue until the destination is reached. In a network that has valid forwarding tables, all the paths between all source/destination pairs contain a finite number of intermediate routers. However, if forwarding tables have not been correctly computed, two types of invalid paths can occur.
0/7090 · 709
28
../../principles/transport.rst:63
English
`0` : `0110000b`
0/160 · 16
28
../../principles/security.rst:329
English
AES or the Advanced Encryption Standard is an encryption scheme that was designed by the Belgian cryptographers Joan Daemen and Vincent Rijmen in 2001 [DR2002]_. This algorithm has been standardized by the U.S. National Institute of Standards and Technology (NIST). It is now used by a wide range of applications and various hardware and software implementations exist. Many microprocessors include special instructions that ease the implementation of AES. AES divides the message to be encrypted in blocks of 128 bits and uses keys of length 128, 192 or 256 bits. The block size and the key length are important parameters of an encryption scheme. The block size indicates the smallest message that can be encrypted and forces the sender to divide each message in blocks of the supported size. If the message is larger than an integer number of blocks, then the message must be padded before being encrypted and this padding must be removed after decryption. The key size indicates the resistance of the encryption scheme against brute force attacks, i.e. attacks where the attacker tries all possible keys to find the correct one.
0/11330 · 1133
28
../../exercises/dns.rst:79
English
sends DNS requests containing random identifiers
0/480 · 48
28
../../exercises/ipv6.rst:290
English
Do your forwarding tables impose the path used to reach host ``B`` which is attached to router ``R4`` or do you need to configure an additional entry in these tables ?
0/1670 · 167
28
../../exercises/routing-protocols.rst:360
English
the responses that contain the router's routing table
0/530 · 53
28
../../exercises/tcp-2.rst:165
English
The ``tcpi_state`` variable used in this script is returned by ``TCP_INFO`` [#ftcpinfo]_. It tracks the state of the TCP connection according to TCP's finite state machine [#fstates]_. This script is available from :download:`/exercises/packetdrill_scripts/client.pkt`.
0/2690 · 269
28
../../protocols/bgp.rst:92
English
Import and export policies
0/260 · 26
28
../../protocols/congestion.rst:175
English
The last point that needs to be discussed about Explicit Congestion Notification is the algorithm that is used by routers to detect congestion. On a router, congestion manifests itself by the number of packets that are stored inside the router buffers. As explained earlier, we need to distinguish between two types of routers :
0/3280 · 328
28
../../protocols/dnssec.rst:317
English
If a resolver queries `delta.example.org`, the server will parse its zone. If this name were present, it would have been placed, in lexicographical order, between the `beta.example.org` and the `gamma.example.org` names. To confirm that the `delta.example.org` name does not exist, the server returns the `NSEC` record for `beta.example.org` that indicates that the next valid name after `beta.example.org` is `gamma.example.org`. If the server receives a query for `pi.example.org`, this is the `NSEC` record for `gamma.example.org` that will be returned. Since this record contains a name that is before `pi.example.org` in lexicographical order, this indicates that `pi.example.org` does not exist.
0/7010 · 701
28
../../protocols/email.rst:166
English
Initially, email was used to exchange small messages of ASCII text between computer scientists. However, with the growth of the Internet, supporting only ASCII text became a severe limitation for two reasons. First of all, non-English speakers wanted to write emails in their native language that often required more characters than those of the ASCII character table. Second, many users wanted to send other content than just ASCII text by email such as binary files, images or sound.
0/4850 · 485
28
../../protocols/ethernet.rst:171
English
10Base5
0/100 · 7
28
../../protocols/http.rst:118
English
an optional MIME document attached to the request
0/490 · 49
28
../../protocols/http2.rst:195
English
The length of the HTTP/2.0 frames obviously affects how different web objects can be multiplexed over the underlying transport connection. If HTTP/2.0 frames are long, the overhead of the frame header is minimal, but long frames can block short web objects. On the other hand, if the frame length is small, then the overhead due to the HTTP/2.0 frame header could become significant.
0/3830 · 383