Exit Zen
27
../../protocols/http2.rst:193
English
With HTTP/2.0 frames, the server could send the first 1250 bytes of the long object during 10 milliseconds, then send a second frame that contains the short object during one millisecond and later send a longer frame that contains the remaining 11250 bytes of the long object. In this case, the client has received the short object after 10 milliseconds. Given the HTTP/2.0 streams, the transmission of long web objects does not anymore blocks the transmission of shorter ones.
0/4770 · 477
27
../../protocols/ipv6.rst:113
English
``abcd:ef01:2345:6789:abcd:ef01:2345:6789``
0/430 · 43
27
../../protocols/ethernet.rst:81
English
The Ethernet frame format shown above is specified in [DIX]_. This is the format used to send both IPv4 :rfc:`894` and IPv6 packets :rfc:`2464`. After the publication of [DIX]_, the Institute of Electrical and Electronic Engineers (IEEE) began to standardize several Local Area Network technologies. IEEE worked on several LAN technologies, starting with Ethernet, Token Ring and Token Bus. These three technologies were completely different, but they all agreed to use the 48 bits MAC addresses specified initially for Ethernet [IEEE802]_ . While developing its Ethernet standard [IEEE802.3]_, the IEEE 802.3 working group was confronted with a problem. Ethernet mandated a minimum payload size of 46 bytes, while some companies were looking for a LAN technology that could transparently transport short frames containing only a few bytes of payload. Such a frame can be sent by an Ethernet host by padding it to ensure that the payload is at least 46 bytes long. However since the Ethernet header [DIX]_ does not contain a length field, it is impossible for the receiver to determine how many useful bytes were placed inside the payload field. To solve this problem, the IEEE decided to replace the `Type` field of the Ethernet [DIX]_ header with a length field [#ftypelen]_. This `Length` field contains the number of useful bytes in the frame payload. The payload must still contain at least 46 bytes, but padding bytes are added by the sender and removed by the receiver. In order to add the `Length` field without significantly changing the frame format, IEEE had to remove the `Type` field. Without this field, it is impossible for a receiving host to identify the type of network layer packet inside a received frame. To solve this new problem, IEEE developed a completely new sublayer called the Logical Link Control [IEEE802.2]_. Several protocols were defined in this sublayer. One of them provided a slightly different version of the `Type` field of the original Ethernet frame format. Another contained acknowledgments and retransmissions to provide a reliable service... In practice, [IEEE802.2]_ is never used to support IP in Ethernet networks. The figure below shows the official [IEEE802.3]_ frame format.
0/22230 · 2223
27
../../protocols/routing.rst:86
English
Inside each non-backbone area, routers distribute the topology of the area by exchanging link state packets with the other routers in the area. The internal routers do not know the topology of other areas, but each router knows how to reach the backbone area. Inside an area, the routers only exchange link-state packets for all destinations that are reachable inside the area. In OSPF, the inter-area routing is done by exchanging distance vectors. This is illustrated by the network topology shown below.
0/5060 · 506
27
../../protocols/rpc.rst:105
English
`id`: an identifier chosen by the caller
0/400 · 40
27
../../protocols/ssh.rst:218
English
At this point, all the messages sent over the TCP connection will be encrypted with the negotiated keys. The ``ssh`` protocol uses messages that are encoded according to the Binary Packet Protocol defined in :rfc:`4253`. Each of these messages contains the following information :
0/2800 · 280
27
../../protocols/tcp.rst:55
English
the `checksum` field contains the value of the Internet checksum computed over the entire TCP segment and a pseudo-header as with UDP
0/1330 · 133
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