Exit Zen
15
../../exercises/trace.rst:94
English
The wireshark_ window is divided in three parts. The top part of the window is a summary of the first packets from the trace. By clicking on one of the lines, you can show the detailed content of this packet in the middle part of the window. The middle of the window allows you to inspect all the fields of the captured packet. The bottom part of the window is the hexadecimal representation of the packet, with the field selected in the middle window being highlighted.
0/4700 · 470
15
../../protocols/bgp.rst:57
English
over a `customer->provider` relationship, the `customer` domain advertises to its `provider` its own prefixes and all the routes that it has learned from its own customers.
0/1730 · 173
15
../../protocols/congestion.rst:91
English
Initial congestion window
0/250 · 25
15
../../protocols/dnssec.rst:166
English
the `RRSIG` record is used to encode the signature of a DNS record. This record contains several sub-fields. The most important ones are the algorithm used to generate the signature, the identifier of the public key used to sign the record, the original TTL of the signed record and the validity period for the signature.
0/3210 · 321
15
../../protocols/email.rst:100
English
The sender address. This header line starts with `From:`. This contains the (optional) name of the sender followed by its email address between `<` and `>`. Email addresses are always composed of a username followed by the `@` sign and a domain name.
0/2500 · 250
15
../../protocols/ethernet.rst:94
English
An Ethernet network provides an unreliable connectionless service. It supports three different transmission modes : `unicast`, `multicast` and `broadcast`. While the Ethernet service is unreliable in theory, a good Ethernet network should, in practice, provide a service that:
0/2760 · 276
15
../../protocols/http.rst:75
English
The first component of a URI is its `scheme`. A `scheme` can be seen as a selector, indicating the meaning of the fields after it. In practice, the scheme often identifies the application-layer protocol that must be used by the client to retrieve the document, but it is not always the case. Some schemes do not imply a protocol at all and some do not indicate a retrievable document [#furiretrieve]_. The most frequent schemes are `http` and `https`. We focus on `http` in this section. A URI scheme can be defined for almost any application layer protocol [#furilist]_. The characters `:` and `//` follow the `scheme` of any URI.
0/6310 · 631
15
../../protocols/ipv6.rst:91
English
SIPP proposed in :rfc:`1710`
0/280 · 28
15
../../protocols/ppp.rst:37
English
The IANA maintains the registry of all assigned PPP protocol fields at : http://www.iana.org/assignments/ppp-numbers
0/1160 · 116
15
../../protocols/routing.rst:50
English
Each RIP message contains a set of route entries. Each route entry is encoded as a 20 bytes field whose format is shown below. RIP was initially designed to be suitable for different network layer protocols. Some implementations of RIP were used in XNS or IPX networks :rfc:`2453`. The format of the route entries used by :rfc:`2080` is shown below. `Prefix length` is the length of the subnet identifier in bits and the `metric` is encoded as one byte. The maximum metric supported by RIP is `15`.
0/4980 · 498
15
../../protocols/rpc.rst:43
English
XDR also supports 64 bits integers and booleans. The booleans are mapped onto integers (`0` for `false` and `1` for `true`). For the floating point numbers, the encoding defined in the IEEE standard is used.
0/2070 · 207
15
../../protocols/ssh.rst:131
English
Once the cryptographic algorithms have been negotiated, the key exchange algorithm is used to negotiate a secret key that will be shared by the client and the server. These key exchange algorithms include some variations over the basic algorithms. As an example, let us analyze how the Diffie Hellman key exchange algorithm is used within the ``ssh`` protocol. In this case, each host has both a private and a public key.
0/4210 · 421
15
../../protocols/tcp.rst:40
English
the address of the server
0/250 · 25
15
../../protocols/tls.rst:45
English
NNTP
0/100 · 4
15
../../protocols/transport-service.rst:51
English
`abcd:ef01:2345:6789:abcd:ef01:2345:6789`
0/410 · 41
15
../../protocols/udp.rst:58
English
As the port numbers are encoded as a 16 bits field, there can be up to only 65535 different server processes that are bound to a different UDP port at the same time on a given server. In practice, this limit is never reached. However, it is worth noticing that most implementations divide the range of allowed UDP port numbers into three different ranges :
0/3560 · 356
15
../../protocols/wifi.rst:22
English
20/100
0/100 · 6
16
../../bibliography.rst:52
English
Donahoo, M., Calvert, K., `TCP/IP Sockets in C: Practical Guide for Programmers <http://books.google.com/books?id=dmt_mERzxV4C>`_ , Morgan Kaufman, 2009
0/1520 · 152
16
../../glossary.rst:99
English
ASN.1
0/100 · 5
16
../../exercises/ex-sharing.rst:343
English
Fairness and congestion control
0/310 · 31