Exit Zen
40
../../principles/security.rst:398
English
The Elliptic Curve Cryptography techniques [#fecc]_ that rely on special properties of elliptic curves.
0/1030 · 103
40
../../exercises/ipv6.rst:416
English
on router ``R6``
0/160 · 16
40
../../exercises/routing-protocols.rst:491
English
The last step is to specify to which AS each router belongs and to configure the eBGP sessions and their routing policies. IPMininet_ abstracts most of the complexity of the configuration of these policies by supporting two policies
0/2320 · 232
40
../../exercises/tcp-2.rst:502
English
We can now explore how TCP's retransmission techniques interact with the congestion control scheme. The Linux TCP code that combines these two techniques contains several heuristics to improve their performance. We start with a transfer of 8KBytes where the penultimate segment is not received by the remote host. In this case, TCP does not receive enough acknowledgments to trigger the fast retransmit and it must wait for the expiration of the retransmission timer. This script is available from :download:`/exercises/packetdrill_scripts/slow-start-rto2.pkt`.
0/5610 · 561
40
../../protocols/bgp.rst:127
English
`KEEPALIVE` : this message is used to ensure a regular exchange of messages on the BGP session, even when no route changes. When a BGP router has not sent an `UPDATE` message during the last 30 seconds, it shall send a `KEEPALIVE` message to confirm to the other peer that it is still up. If a peer does not receive any BGP message during a period of 90 seconds [#fdefaultkeepalive]_, the BGP session is considered to be down and all the routes learned over this session are withdrawn.
0/4850 · 485
40
../../protocols/congestion.rst:205
English
:math:`Throughput=\frac{area \times MSS}{time} = \frac{ \frac{3 \times W^2}{8}}{\frac{W}{2} \times rtt}` or, after having eliminated `W`, :math:`Throughput=\sqrt{\frac{3}{2}} \times \frac{MSS}{rtt \times \sqrt{p}}`
0/2140 · 214
40
../../protocols/email.rst:212
English
`text`. The message part contains information in textual format. There are several subtypes : `text/plain` for regular ASCII text, `text/html` defined in :rfc:`2854` for documents in :term:`HTML` format or the `text/enriched` format defined in :rfc:`1896`. The `Content-Type:` header line may contain a second parameter that specifies the character set used to encode the text. `charset=us-ascii` is the standard ASCII character table. Other frequent character sets include `charset=UTF8` or `charset=iso-8859-1`. The `list of standard character sets <http://www.iana.org/assignments/character-sets>`_ is maintained by :term:`IANA`.
0/6330 · 633
40
../../protocols/ethernet.rst:177
English
1000Base-CX
0/110 · 11
40
../../protocols/http.rst:160
English
the `Content-Encoding:` header indicates how the :term:`MIME document` has been encoded. For example, this header would be set to `x-gzip` for a document compressed using the gzip_ software.
0/1900 · 190
40
../../protocols/http2.rst:267
English
See https://en.wikipedia.org/wiki/HTTP_pipelining for additional information.
0/770 · 77
40
../../protocols/ipv6.rst:153
English
An IPv6 unicast address is composed of three parts :
0/520 · 52
40
../../protocols/ethernet.rst:164
English
The evolution of Ethernet did not stop. In 1998, the IEEE published a first standard to provide Gigabit Ethernet over optical fibers. Several other types of physical layers were added afterwards. The `10 Gigabit Ethernet <http://en.wikipedia.org/wiki/10_gigabit_Ethernet>`_ standard appeared in 2002. Work is ongoing to develop `standards <http://www.ieee802.org/3/ba/public/index.html>`_ for 40 Gigabit and 100 Gigabit Ethernet and some are thinking about `Terabit Ethernet <http://www.networkworld.com/news/2009/042009-terabit-ethernet.html>`_. The table below lists the main Ethernet standards. A more detailed list may be found at http://en.wikipedia.org/wiki/Ethernet_physical_layer.
0/6880 · 688
40
../../protocols/routing.rst:133
English
Remote routers, when looking at the topology distributed by OSPF, consider that there is a full-mesh of links between all the LAN routers. Such a full-mesh implies a lot of redundancy in case of failure, while in practice the entire LAN may completely fail. In case of a failure of the entire LAN, all routers need to detect the failures and flood link state packets before the LAN is completely removed from the OSPF topology by remote routers.
0/4450 · 445
40
../../protocols/rpc.rst:146
English
ONC-RPC uses a more complex method to allow a caller to reach the callee. On a host, server processes can run on different ports and given the limited number of port values (:math:`2^{16}` per host on the Internet), it is impossible to reserve one port number for each method. The solution used in ONC-RPC :rfc:`1831` is to use a special method which is called the `portmapper` :rfc:`1833`. The `portmapper` is a kind of directory that runs on a server that hosts methods. The `portmapper` runs on a standard port (`111` for ONC-RPC :rfc:`1833`). A server process that implements a method registers its method on the local `portmapper`. When a caller needs to call a method on a remote server, it first contacts the `portmapper` to obtain the port number of the server process which implements the method. The response from the portmapper allows it to directly contact the server process which implements the method.
0/9160 · 916
40
../../protocols/ssh.rst:302
English
For example, :rfc:`4255` describes a DNS record that can be used to associate an ``ssh`` fingerprint to a DNS name.
0/1150 · 115
40
../../protocols/tcp.rst:124
English
This segment is often called a `SYN+ACK` segment. The acknowledgment confirms to the client that the server has correctly received the `SYN` segment. The `sequence number` of the `SYN+ACK` segment is used by the server host to verify that the `client` has received the segment. Upon reception of the `SYN+ACK` segment, the client host replies with a segment containing :
0/3700 · 370
40
../../protocols/tls.rst:173
English
The ``Server Name Indication (SNI)``
0/360 · 36
40
../../protocols/wifi.rst:102
English
The first part of the 802.11 header is the 16 bit `Frame Control` field. This field contains flags that indicate the type of frame (data frame, RTS/CTS, acknowledgment, management frames, etc), whether the frame is sent to or from a fixed LAN, etc [IEEE802.11]_. The `Duration` is a 16 bit field that is used to reserve the transmission channel. In data frames, the `Duration` field is usually set to the time required to transmit one acknowledgment frame after a SIFS delay. Note that the `Duration` field must be set to zero in multicast and broadcast frames. As these frames are not acknowledged, there is no need to reserve the transmission channel after their transmission. The `Sequence control` field contains a 12 bits sequence number that is incremented for each data frame and a 4 bits fragment number.
0/8120 · 812
41
../../bibliography.rst:127
English
McQuillan, J.M., Richer, I., Rosen, E., `The New Routing Algorithm for the ARPANET <https://dx.doi.org/10.1109/TCOM.1980.1094721>`_ Communications, IEEE Transactions on , vol.28, no.5, pp.711,719, May 1980
0/2050 · 205
41
../../glossary.rst:327
English
The most widely used LAN technology.
0/360 · 36