Exit Zen
19
../../protocols/rpc.rst:67
English
A second popular method to encode data is the JavaScript Object Notation (JSON). This syntax was initially defined to allow applications written in JavaScript to exchange data, but it has now wider usages. JSON :rfc:`4627` is a text-based representation. The simplest data type is the integer. It is represented as a sequence of digits in ASCII. Strings can also be encoding by using JSON. A JSON string always starts and ends with a quote character (`"`) as in the C language. As in the C language, some characters (like `"` or `\\`) must be escaped if they appear in a string. :rfc:`4627` describes this in details. Booleans are also supported by using the strings `false` and `true`. Like XDR, JSON supports more complex data types. A structure or object is defined as a comma separated list of elements enclosed in curly brackets. :rfc:`4627` provides the following example as an illustration.
0/8970 · 897
19
../../protocols/ssh.rst:151
English
This is a slightly modified authenticated Diffie Hellman key exchange with two interesting points. The first point is that when the server authenticates the key exchange it does not provide a certificate. This is because ``ssh`` assumes that the client will store inside its cache the public key of the servers that it uses on a regular basis. This assumption is valid for a protocol like ``ssh`` because users typically use it to interact with a small number of servers, typically a few or a few tens. Storing this information does not require a lot of storage. In practice, most ``ssh`` clients will accept to connect to remote servers without knowing their public key before the connection. In this case, the client issues a warning to the user who can decide to accept or reject the key. This warning can be associated with a fingerprint of the key, either as a sequence of letters or as an ASCII art which can be posted on the web or elsewhere [#fdnsssh]_ by the system administrator of the server. If a client connects to a server whose public key does not match the stored one, a stronger warning is issued because this could indicate a man-in-the-middle attack or that the remote server has been compromised. It can also indicate that the server has been upgraded and that a new key has been generated during this upgrade.
0/13300 · 1330
19
../../protocols/tcp.rst:45
English
the `Urgent pointer` is used to indicate that some data should be considered as urgent in a TCP bytestream. However, it is rarely used in practice and will not be described here. Additional details about the utilization of this pointer may be found in :rfc:`793`, :rfc:`1122` or [Stevens1994]_
0/2930 · 293
19
../../protocols/tls.rst:46
English
80
0/100 · 2
19
../../protocols/transport-service.rst:58
English
`2001:db8:0:0:8:800:200c:417a` is represented as `2001:db8::8:800:200c:417a`
0/770 · 77
19
../../protocols/udp.rst:64
English
In most Unix variants, only processes having system administrator privileges can be bound to port numbers smaller than `1024`. Well-known servers such as :term:`DNS`, :term:`NTP` or :term:`RPC` use privileged port numbers. When a client needs to use UDP, it usually does not require a specific port number. In this case, the UDP implementation will allocate the first available port number in the ephemeral range. The range of registered port numbers should be used by servers. In theory, developers of network servers should register their port number officially through IANA [#fportnum]_, but few developers do this.
0/6180 · 618
19
../../protocols/wifi.rst:23 • ../../protocols/wifi.rst:25
English
54 Mbps
0/100 · 7
20
../../bibliography.rst:66
English
Fletcher, J., `An Arithmetic Checksum for Serial Transmissions <https://dx.doi.org/10.1109/TCOM.1982.1095369>`_, Communications, IEEE Transactions on, Jan. 1982, Vol. 30, N. 1, pp. 247-252
0/1880 · 188
20
../../glossary.rst:156
English
BGP
0/100 · 3
20
../../exercises/ex-sharing.rst:432
English
In practice, a router is connected to multiple input links. The figure below shows an example with two hosts.
0/1090 · 109
20
../../principles/sharing.rst:103
English
In the above network, the allocation of all flows would grow until `A1-A2` and `B1-B2` reach 5 Mbps. At this point, link `R1-R2` becomes congested and these two flows have reached their maximum. The allocation for flow `C1-C2` can increase until reaching 15 Mbps. At this point, link `R2-R3` is congested. To increase the bandwidth allocated to `C1-C2`, one would need to reduce the allocation to flow `B1-B2`. Similarly, the only way to increase the allocation to flow `B1-B2` would require a decrease of the allocation to `A1-A2`.
0/5320 · 532
20
../../principles/security.rst:270
English
`A cryptographic algorithm should be secure even if the attacker knows everything about the system, except one parameter known as the secret key.`
0/1460 · 146
20
../../exercises/dns.rst:55
English
What is the lifetime associated to this IPv6 address ?
0/540 · 54
20
../../exercises/ipv6.rst:151 • ../../exercises/ipv6.rst:229
English
router ``R3`` uses address ``2001:db8:1341:34::3`` on its East interface and address ``2001:db8:1341:13::3`` on its North interface
0/1310 · 131
20
../../exercises/lan.rst:195
English
The network contains five nodes and six links.
0/460 · 46
20
../../exercises/routing-policies.rst:167
English
A ``traceroute6`` towards ``ipv6.google.com`` provides the following output :
0/770 · 77
20
../../exercises/routing-protocols.rst:261
English
The requested information is sent in a `LS Update` packet shortly after that.
0/770 · 77
20
../../exercises/tcp-2.rst:113
English
packetdrill_ writes 10 bytes of data through the :manpage:`write` system call. The stack immediately sends these 10 bytes inside a segment whose ``Push`` flag is set [#fpush]_. The payload starts at sequence number ``1`` and ends at sequence number ``10``. packetdrill_ replies by injecting an acknowledgment for the entire data after 100 milliseconds.
0/3520 · 352
20
../../exercises/trace.rst:109
English
When analyzing packet traces with wireshark_, it is often very useful to use `Display filters` that only show the packets that match some specific criteria. There filters are described in several online documents:
0/2130 · 213
20
../../protocols/bgp.rst:68
English
From a routing perspective, over a `shared-cost` peering relationship a domain only advertises its internal routes/prefixes and the routes that it has learned from its customers. This restriction ensures that only packets destined to the local domain or one of its customers is received over the `shared-cost` peering relationship. This implies that the routes that have been learned from a provider or from another `shared-cost` peer is not advertised over a `shared-cost` peering relationship. This is motivated by economical reasons. If a domain were to advertise the routes that it learned from a provider over a `shared-cost` peering relationship that does not bring revenue, it would have allowed its `shared-cost` peer to use the link with its provider without any payment. If a domain were to advertise the routes it learned over a `shared cost` peering over another `shared-cost` peering relationship, it would have allowed these `shared-cost` peers to use its own network (which may span one or more continents) freely to exchange packets.
0/10490 · 1049