Exit Zen
22
../../protocols/bgp.rst:76
English
These different types of relationships are implemented in the `interdomain routing policies` defined by each domain. The `interdomain routing policy` of a domain is composed of three main parts :
0/1950 · 195
22
../../protocols/congestion.rst:115
English
The TCP flags
0/130 · 13
22
../../protocols/dnssec.rst:215
English
Thanks to the `DS` record, a resolver can validate the public keys of client zones as long as their is a chain of `DS` -> `DNSKEY` records from an anchored key. If the resolver trusts the public key of the root zone, it can validate all DNS replies for which this chain exists.
0/2770 · 277
22
../../protocols/email.rst:122
English
Note the empty line after the `Date:` header line; this empty line contains only the `CR` and `LF` characters, and marks the boundary between the header and the body of the message.
0/1810 · 181
22
../../protocols/ethernet.rst:149
English
Computers can directly be attached to Ethernet hubs. Ethernet hubs themselves can be attached to other Ethernet hubs to build a larger network. However, some important guidelines must be followed when building a complex network with hubs. First, the network topology must be a tree. As hubs are relays in the physical layer, adding a link between `Hub2` and `Hub3` in the network below would create an electrical shortcut that would completely disrupt the network. This implies that there cannot be any redundancy in a hub-based network. A failure of a hub or of a link between two hubs would partition the network into two isolated networks. Second, as hubs are relays in the physical layer, collisions can happen and must be handled by CSMA/CD as in a 10Base5 network. This implies that the maximum delay between any pair of devices in the network cannot be longer than the 51.2 microseconds `slot time`. If the delay is longer, collisions between short frames may not be correctly detected. This constraint limits the geographical spread of 10BaseT networks containing hubs.
0/10770 · 1077
22
../../protocols/http.rst:104
English
The HTML document shown below is composed of two parts: a header, delineated by the `<head>` and `</head>` markers, and a body (between the `<body>` and `</body>` markers). In the example below, the header only contains a title, but other types of information can be included in the header. The body contains an image, some text and a list with three hyperlinks. The image is included in the web page by indicating its URI between brackets inside the `<img src="...">` marker. It is important to note that the image can reside on any server. The client will automatically download it when rendering the web page. The `<h1>...</h1>` marker is used to specify the first level of headings. The `<ul>` marker indicates an unnumbered list while the `<li>` marker indicates a list item. The `<a href="URI">text</a>` indicates a hyperlink. The `text` will be underlined in the rendered web page and the client will fetch the specified URI when the user clicks on the link.
0/9650 · 965
22
../../protocols/http2.rst:153
English
The HTTP/2.0 Frame header
0/250 · 25
22
../../protocols/ipv6.rst:102
English
When the work on IPng started, it was clear that 32 bits was too small to encode an IPng address and all proposals used longer addresses. However, there were many discussions about the most suitable address length. A first approach, proposed by SIPP in :rfc:`1710`, was to use 64 bit addresses. A 64 bits address space was 4 billion times larger than the IPv4 address space and, furthermore, from an implementation perspective, 64 bit CPUs were being considered and 64 bit addresses would naturally fit inside their registers. Another approach was to use an existing address format. This was the TUBA proposal (:rfc:`1347`) that reuses the ISO CLNP 20 bytes addresses. The 20 bytes addresses provided room for growth, but using ISO CLNP was not favored by the IETF partially due to political reasons, despite the fact that mature CLNP implementations were already available. 128 bits appeared to be a reasonable compromise at that time.
0/9360 · 936
22
../../protocols/ethernet.rst:56
English
Impact of the frame length on the maximum channel utilisation [SH1980]_
0/710 · 71
22
../../protocols/routing.rst:73
English
OSPF imposes restrictions on how a network can be divided into areas. An area is a set of routers and links that are grouped together. Usually, the topology of an area is chosen so that a packet sent by one router inside the area can reach any other router in the area without leaving the area [#fvirtual]_ . An OSPF area contains two types of routers :rfc:`2328`:
0/3640 · 364
22
../../protocols/rpc.rst:98
English
Reaching the callee
0/190 · 19
22
../../protocols/ssh.rst:195
English
Thanks to the Diffie Hellman key exchange, the client and the servers share key :math:`K`. A naive implementation would probably directly use this key for all the cryptographic algorithms that have been negotiated for this session. Like most security protocols, ``ssh`` does not directly use key :math:`K`. Instead, it uses the negotiated hash function with different parameters [#fsshkeys]_ to allow the client and the servers to compute six keys from :math:`K` :
0/4640 · 464
22
../../protocols/tcp.rst:49
English
the `FIN` flag is used during connection release
0/480 · 48
22
../../protocols/tls.rst:47
English
21
0/100 · 2
22
../../protocols/transport-service.rst:61
English
`0:0:0:0:0:0:0:0` is represented as `\:\:`
0/420 · 42
22
../../protocols/udp.rst:73
English
a pseudo header :rfc:`2460` containing the source address, the destination address, the packet length encoded as a 32 bits number and a 32 bits bit field containing the three most significant bytes set to 0 and the low order byte set to 17
0/2390 · 239
22
../../protocols/wifi.rst:24
English
4.3 Mbps
0/100 · 8
23
../../bibliography.rst:72
English
Fortz, B. Rexford, J. ,Thorup, M., `Traffic engineering with traditional IP routing protocols <https://dx.doi.org/10.1109/MCOM.2002.1039866>`_, IEEE Communication Magazine, October 2002
0/1850 · 185
23
../../glossary.rst:237
English
A Backus-Naur Form (BNF) is a formal way to describe a language by using syntactic and lexical rules. BNFs are frequently used to define programming languages, but also to define the messages exchanged between networked applications. :rfc:`5234` explains how a BNF must be written to specify an Internet protocol.
0/3130 · 313
23
../../exercises/ex-sharing.rst:558
English
In this network, compute the minimum round-trip-time between `A` (resp. `B`) and `D`. Perform the computation if the hosts send segments containing 1000 bits.
0/1580 · 158