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
../../exercises/reliability.rst:42
English
when every second acknowledgment is discarded due to transmission errors
80/720 · 72
20
../../exercises/network.rst:178
English
`R3->R2->R4->R5` and `R1->R2->R5`
32/330 · 33
20
../../exercises/sockets.rst:175
English
Using this code, the program will read and print an arbitrary message received from an arbitrary peer who knows the program's socket address. If we want to know the address of the peer that sent us the message, we can use the ``recvfrom`` system call. This is what a modified version of ``bind_and_receive_from_peer`` is doing below.
369/3330 · 333
20
../../exercises/transport.rst:142
English
DATA segments contain a sequence number that is incremented for each DATA segment transmitted
108/930 · 93
20
../../principles/naming.rst:112
English
To retrieve the mapping for host `h2.dom`, a client sends its query to the name server that is responsible for domain `.dom`. The name server directly answers the query. To retrieve a mapping for `h3.a.sdom1.dom` a DNS client first sends a query to the name server that is responsible for the `.dom` domain. This nameserver returns the nameserver that is responsible for the `sdom1.dom` domain. This nameserver can now be contacted to obtain the nameserver that is responsible for the `a.sdom1.dom` domain. This nameserver can be contacted to retrieve the mapping for the `h3.a.sdom1.dom` name. Thanks to this structure, it is possible for a DNS client to obtain the mapping of any host inside the `.dom` domain or any of its subdomains. To ensure that any DNS client will be able to resolve any fully qualified domain name, there are special nameservers that are responsible for the root of the domain name hierarchy. These nameservers are called :term:`root nameserver`.
1014/9720 · 972
20
../../principles/network.rst:87
English
the network layer address of the destination host
55/490 · 49
20
../../principles/reliability.rst:54
English
:math:`10^{12}`
15/150 · 15
20
../../principles/transport.rst:50
English
Alice : `3.1415`
16/160 · 16
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
../../protocols/dns.rst:67
English
Reverse DNS
11/110 · 11