Exit Zen
80
../../principles/network.rst:346
English
sending a control packet back to the source if a router detects that a packet is looping inside the network
0/1070 · 107
80
../../principles/reliability.rst:261
English
**1** **2** **3** **DLE** **STX** **4**
0/390 · 39
80
../../principles/transport.rst:447
English
To ensure a reliable delivery of the SDUs sent by each user over a connection, we need to consider the two streams that compose a connection as independent. A user should be able to release the stream that it uses to send SDUs once it has sent all the SDUs that it planned to send over this connection, but still continue to receive SDUs over the opposite stream. This `graceful` connection release is usually performed as shown in the figure below. One user issues a `Disconnect.request` primitive to its provider once it has issued all its `Data.request` primitives. The service provider will wait until all `Data.indication` primitives have been delivered to the receiving user before issuing the `Disconnnect.indication` primitive. This primitive informs the receiving user that it will no longer receive SDUs over this connection, but it is still able to issue `Data.request` primitives on the stream in the opposite direction. Once the user has issued all of its `Data.request` primitives, it issues a `Disconnnect.request` primitive to request the termination of the remaining stream. The service provider will process the request and deliver the corresponding `Disconnect.indication` to the other user once it has delivered all the pending `Data.indication` primitives. At this point, all data has been delivered, the two streams have been released successfully and the connection is completely closed.
0/14100 · 1410
80
../../principles/sharing.rst:338
English
[Abramson1970]_ analyzed the performance of ALOHANet under particular assumptions and found that ALOHANet worked well when the channel was lightly loaded. In this case, the frames are rarely retransmitted and the `channel traffic`, i.e. the total number of (correct and retransmitted) frames transmitted per unit of time is close to the `channel utilization`, i.e. the number of correctly transmitted frames per unit of time. Unfortunately, the analysis also reveals that the `channel utilization` reaches its maximum at :math:`\frac{1}{2 \times e}=0.186` times the channel bandwidth. At higher utilization, ALOHANet becomes unstable and the network collapses due to collided retransmissions.
0/6920 · 692
80
../../principles/security.rst:920
English
When users want to communicate securely through a network, they need to exchange information such as the keys that will be used by an encryption algorithm even in the presence of an eavesdropper. The most widely used algorithm that allows two users to safely exchange an integer in the presence of an eavesdropper is the one proposed by Diffie and Hellman [DH1976]_. It operates with (large) integers. Two of them are public, the modulus, p, which is prime and the base, g, which must be a primitive root of p. The communicating users select a random integer, :math:`a` for Alice and :math:`b` for Bob. The exchange starts as :
0/6270 · 627
80
../../exercises/ipv6.rst:734
English
The ``nodes`` command lists the routers and hosts that have been created in the mininet topology.
0/970 · 97
80
../../exercises/routing-protocols.rst:1158
English
What are the BGP messages that will be exchanged when the link between ``AS3`` and ``AS4`` fails ? How does this affect the reachability of the different hosts ?
0/1610 · 161
80
../../protocols/bgp.rst:313
English
When comparing routes towards the same destination prefix, a BGP router always prefers the routes with the highest `local-pref`. If the BGP router knows several routes with the same `local-pref`, it prefers among the routes having this `local-pref` the ones with the shortest AS-Path.
0/2840 · 284
80
../../protocols/email.rst:240 • ../../protocols/email.rst:242
English
4
0/100 · 1
80
../../protocols/ethernet.rst:353
English
Bandwidth
0/100 · 9
80
../../protocols/http.rst:444
English
An example of a non-retrievable URI is `urn:isbn:0-380-81593-1` which is an unique identifier for a book, through the urn scheme (see :rfc:`3187`). Of course, any URI can be made retrievable via a dedicated server or a new protocol but this one has no explicit protocol. Same thing for the scheme tag (see :rfc:`4151`), often used in Web syndication (see :rfc:`4287` about the Atom syndication format). Even when the scheme is retrievable (for instance with `http`), it is often used only as an identifier, not as a way to get a resource. See http://norman.walsh.name/2006/07/25/namesAndAddresses for a good explanation.
0/6200 · 620
80
../../protocols/ipv6.rst:323
English
The IPv6 packet format was heavily inspired by the packet format proposed for the SIPP protocol in :rfc:`1710`. The standard IPv6 header defined in :rfc:`2460` occupies 40 bytes and contains 8 different fields, as shown in the figure below.
0/2400 · 240
80
../../protocols/ethernet.rst:305
English
The `MAC address learning` algorithm allows switches to be plug-and-play. Unfortunately, the loops that arise when the network topology is not a tree are a severe problem. Forcing the switches to only be used in tree-shaped networks as hubs would be a severe limitation. To solve this problem, the inventors of Ethernet switches have developed the `Spanning Tree Protocol`. This protocol allows switches to automatically disable ports on Ethernet switches to ensure that the network does not contain any cycle that could cause frames to loop forever.
0/5500 · 550
80
../../protocols/tcp.rst:251
English
`window`. a TCP receiver uses this 16 bits field to indicate the current size of its receive window expressed in bytes.
0/1190 · 119
80
../../protocols/tls.rst:408
English
Since 2014, latency has become an important concern for web services. As access networks bandwidth continue to grow, latency is becoming a key factor that affects the performance of interactive web services. With TLS 1.2, the download of a web page requires a minimum of four round-trip-times, one to create the underlying TCP connection, one to exchange the ClientHello/ServerHello, one to exchange the keys and then one to send the HTTP GET and retrieve the response. This can be very long when the server is not near the client. TLS 1.3 aimed at reducing this handshake to one round-trip-time and even zero by placing some of the cryptographic handshake in the TCP handshake. This part will be discussed in the TCP chapter. We focus here on the reducing the TLS handshake to a single round-trip-time.
0/8030 · 803
81
../../glossary.rst:75
English
IP
0/100 · 2
81
../../principles/network.rst:347
English
verifying that packets can reach a given destination
0/520 · 52
81
../../principles/reliability.rst:261
English
`DLE STX` **1** **2** **3** **DLE** `DLE` **STX** `4` `DLE ETX`
0/630 · 63
81
../../principles/transport.rst:487
English
Reliability of the connection-oriented service
0/460 · 46
81
../../principles/sharing.rst:341
English
Amateur packet radio
0/200 · 20