Exit Zen
49
../../glossary.rst:104
English
The File Transfer Protocol defined in :rfc:`959` has been the `de facto` protocol to exchange files over the Internet before the widespread adoption of HTTP :rfc:`2616`.
0/1690 · 169
49
../../exercises/network.rst:363
English
4 via D
7/100 · 7
49
../../exercises/sockets.rst:348
English
Here are some exercises that will help you to learn how to use sockets.
81/710 · 71
49
../../principles/reliability.rst:208
English
Bit rate and bandwidth
0/220 · 22
49
../../principles/sharing.rst:197
English
In virtual circuit networks, packet marking can be improved if the return packets follow the reverse path of the forward packets. It this case, a network node can detect congestion on the forward path (e.g. due to the size of its buffer), but mark the packets on the return path. Marking the return packets (e.g. the acknowledgments used by reliable protocols) provides a faster feedback to the sending hosts compared to FECN. This technique is usually called `Backward Explicit Congestion Notification (BECN)`.
0/5110 · 511
49
../../principles/security.rst:471
English
We can now combine the cryptographic operations described in the previous section to build some protocols to securely exchange information. Let us first go back to the problem of authenticating Alice on Bob's computer. We have shown earlier that using a simple password for this purpose is insecure in the presence of attackers.
0/3280 · 328
49
../../exercises/ipv6.rst:480
English
All packets sent by ``B1`` and ``B2`` to ``A1`` and ``A2`` are always forwarded via ``R2`` while all packets from ``A1`` and ``A2`` are always forwarded via ``R4``
0/1630 · 163
49
../../exercises/routing-protocols.rst:581
English
The same applies for the paths between ``h1`` and ``h2``
0/560 · 56
49
../../exercises/tcp-2.rst:645
English
the initial value of the congestion window is one MSS-sized segment
0/670 · 67
49
../../protocols/bgp.rst:151
English
Organization of a BGP router
0/280 · 28
49
../../protocols/congestion.rst:224
English
`TCP Vegas`, which uses changes in the round-trip-time to estimate congestion in order to avoid it [BOP1994]_. This is one of the examples of the delay-based congestion control algorithms. A Vegas sender continuously measures the evolution of the round-trip-time and slows down when the round-trip-time increases significantly. This enables Vegas to prevent congestion when used alone. Unfortunately, if Vegas senders compete with more aggressive TCP congestion control schemes that only react to losses, Vegas senders may have difficulties to user their fair share of the available bandwidth.
0/5930 · 593
49
../../protocols/email.rst:230 • ../../protocols/email.rst:230 • ../../protocols/email.rst:230 • ../../protocols/email.rst:230
English
Value
0/100 · 5
49
../../protocols/ethernet.rst:193
English
Additional information about the history of the Ethernet technology may be found at http://ethernethistory.typepad.com/
0/1190 · 119
49
../../protocols/http.rst:173
English
the `Host:` header contains the fully qualified domain name of the URI being requested.
0/870 · 87
49
../../protocols/ipv6.rst:168
English
In today's deployments, interface identifiers are always 64 bits wide. This implies that while there are :math:`2^{128}` different IPv6 addresses, they must be grouped in :math:`2^{64}` subnets. This could appear as a waste of resources, however using 64 bits for the host identifier allows IPv6 addresses to be auto-configured and also provides some benefits from a security point of view, as explained in section ICMPv6_.
0/4230 · 423
49
../../protocols/ethernet.rst:174
English
10Base-F
0/100 · 8
49
../../protocols/routing.rst:152
English
A second approach is to install all equal cost paths [#fmaxpaths]_ in the forwarding table and load-balance the packets on the different paths. Consider the case where a router has `N` different outgoing interfaces to reach destination `d`. A first possibility to load-balance the traffic among these interfaces is to use `round-robin`. `Round-robin` allows equally balancing the packets among the `N` outgoing interfaces. This equal load-balancing is important in practice because it allows better spreading the load throughout the network. However, few networks use this `round-robin` strategy to load-balance traffic on routers. The main drawback of `round-robin` is that packets that belong to the same flow (e.g. TCP connection) may be forwarded over different paths. If packets belonging to the same TCP connection are sent over different paths, they will probably experience different delays and arrive out-of-sequence at their destination. When a TCP receiver detects out-of-order segments, it sends duplicate acknowledgments that may cause the sender to initiate a fast retransmission and enter congestion avoidance. Thus, out-of-order segments may lead to lower TCP performance. This is annoying for a load-balancing technique whose objective is to improve the network performance by spreading the load.
0/13130 · 1313
49
../../protocols/tcp.rst:157
English
TCP connection establishment rejected by peer
0/450 · 45
49
../../protocols/tls.rst:236
English
``DHE_RSA``. This key exchange algorithm is the Ephemeral Diffie Hellman key exchange with RSA signatures to authenticate the key exchange. It operates as a classical authenticated Diffie Hellman key exchange. If this key exchange has been selected by the server, it sends its Diffie Hellman parameters in the ``ServerKeyExchange`` message and signs them with its private key. The client then continues the key exchange and sends the results of its own computation in the ``ClientKeyExchange`` message. ``DHE_RSA`` is thus an authenticated Diffie Hellman key exchange where the initial message is sent by the server (instead of the client as in our first example but since the protocol is symmetric, this does not matter).
0/7220 · 722
49
../../protocols/wifi.rst:135
English
In addition to the data and control frames that we have briefly described above, 802.11 networks use several types of management frames. These management frames are used for various purposes. We briefly describe some of these frames below. A detailed discussion may be found in [IEEE802.11]_ and [Gast2002]_.
0/3080 · 308