Exit Zen
41
../../exercises/network.rst:360
English
Routes on C
12/110 · 11
41
../../exercises/sockets.rst:328
English
Besides character strings, some applications also need to exchange 16 bits and 32 bits fields such as integers. A naive solution would have been to send the 16- or 32-bits field as it is encoded in the host's memory. Unfortunately, there are different methods to store 16- or 32-bits fields in memory. Some CPUs store the most significant byte of a 16-bits field in the first address of the field while others store the least significant byte at this location. When networked applications running on different CPUs exchange 16 bits fields, there are two possibilities to transfer them over the transport service :
731/6130 · 613
41
../../principles/referencemodels.rst:148
English
Compared to the five layers reference model explained above, the :term:`OSI` reference model defined in [X200]_ is divided in seven layers. The four lower layers are similar to the four lower layers described above. The OSI reference model refined the application layer by dividing it in three layers :
342/3020 · 302
41
../../principles/reliability.rst:184
English
Computer networks use a similar approach. Each layer provides a service that is built above the underlying layer and is closer to the needs of the applications. The datalink layer builds upon the service provided by the physical layer. We will see that it also contains several functions.
335/2880 · 288
41
../../principles/transport.rst:88
English
send the most significant byte followed by the least significant byte
75/690 · 69
41
../../principles/security.rst:401
English
Another interesting property of public key cryptography is its ability to compute `signatures` that can be used to authenticate a message. This capability comes from the utilization of two different keys that are linked together. If Alice wants to sign a message `M`, she can compute :math:`SM=E_p(A_{priv},M)`. Anyone who receives this signed messaged can extract its content as :math:`D_p(A_{pub},SM)=D_p(A_{pub},E_p(A_{priv},M))=M`. Everyone can use :math:`A_{pub}` to check that the message was signed by using Alice's private key (:math:`A_{priv}`). Since this key is only known by Alice, the ability to decrypt `SM` is a proof that the message was signed by Alice herself.
0/6780 · 678
41
../../exercises/ipv6.rst:433
English
What do you think about the proposed configuration?
0/510 · 51
41
../../exercises/routing-protocols.rst:510
English
The script ends by launching the full topology. The entire script is available from :download:`/exercises/ipmininet_scripts/ebgp-simple.py`.
0/1400 · 140
41
../../exercises/tcp-2.rst:546
English
Another interesting scenario is when the loss happens early in the data transfer. This is shown in the script below where the second segment is lost. We observe that by triggering transmissions of unacknowledged data, the :rfc:`3042` rule speeds up the recovery since a fast retransmit happens. This script is available from :download:`/exercises/packetdrill_scripts/slow-start-frr2.pkt`.
0/3880 · 388
41
../../protocols/bgp.rst:129
English
As explained earlier, BGP relies on incremental updates. This implies that when a BGP session starts, each router first sends BGP `UPDATE` messages to advertise to the other peer all the exportable routes that it knows. Once all these routes have been advertised, the BGP router only sends BGP `UPDATE` messages about a prefix if the route is new, one of its attributes has changed or the route became unreachable and must be withdrawn. The BGP `UPDATE` message allows BGP routers to efficiently exchange such information while minimizing the number of bytes exchanged. Each `UPDATE` message contains :
0/6020 · 602
41
../../protocols/congestion.rst:209
English
More detailed models and the analysis of simulations have shown that a first order model of the TCP throughput when losses occur was :math:`Throughput \approx \frac{k \times MSS}{rtt \times \sqrt{p}}`. This is an important result which shows that :
0/2480 · 248
41
../../protocols/email.rst:213
English
`image`. The message part contains a binary representation of an image. The subtype indicates the format of the image such as `gif <http://en.wikipedia.org/wiki/Graphics_Interchange_Format>`_, `jpg <http://en.wikipedia.org/wiki/Jpeg>`_ or `png <http://en.wikipedia.org/wiki/Portable_Network_Graphics>`_.
0/3030 · 303
41
../../protocols/ethernet.rst:177
English
Two pairs shielded twisted pair, 25m maximum
0/440 · 44
41
../../protocols/http.rst:162
English
:rfc:`1945` and :rfc:`2616` define headers that are specific to HTTP responses. These server headers include:
0/1090 · 109
41
../../protocols/ipv6.rst:155
English
A `global routing prefix` that is assigned to the Internet Service Provider that owns this block of addresses
0/1090 · 109
41
../../protocols/ethernet.rst:169 • ../../protocols/wifi.rst:19
English
Standard
0/100 · 8
41
../../protocols/routing.rst:135
English
To better represent LANs and reduce the number of OSPF packets that are exchanged, OSPF handles LAN differently. When OSPF routers boot on a LAN, they elect [#felection]_ one of them as the `Designated Router (DR)` :rfc:`2328`. The `DR` router `represents` the local area network, and advertises the LAN's subnet. Furthermore, LAN routers only exchange HELLO packets with the `DR`. Thanks to the utilization of a `DR`, the topology of the LAN appears as a set of point-to-point links connected to the `DR` router.
0/5130 · 513
41
../../protocols/rpc.rst:151
English
Footnotes
0/100 · 9
41
../../protocols/ssh.rst:305
English
The exact algorithms used for the computation of these keys are defined in :rfc:`4253`
0/860 · 86
41
../../protocols/tcp.rst:127
English
the `acknowledgment number` set to the `sequence number` of the received `SYN+ACK` segment incremented by 1 :math:`\pmod{2^{32}}`
0/1290 · 129