Exit Zen
184
../../principles/reliability.rst:763
English
Go-back-n : example
0/190 · 19
184
../../protocols/email.rst:297
English
F A \= \=
0/170 · 17
184
../../protocols/ipv6.rst:641
English
some multiplexing information to indicate the network layer protocol that is responsible for the payload of the frame
0/1170 · 117
184
../../protocols/wifi.rst:154
English
The second important utilization of the management frames is to allow a WiFi station to be associated with an access point. When a WiFi station starts, it listens to beacon frames to find the available SSIDs. To be allowed to send and receive frames via an access point, a WiFi station must be associated to this access point. If the access point does not use any security mechanism to secure the wireless transmission, the WiFi station simply sends an `Association request` frame to its preferred access point (usually the access point that it receives with the strongest radio signal). This frame contains some parameters chosen by the WiFi station and the SSID that it requests to join. The access point replies with an `Association response frame` if it accepts the WiFI station.
0/7830 · 783
184
../../protocols/tcp.rst:621
English
A detailed presentation of all standardization documents concerning TCP may be found in :rfc:`4614`
0/990 · 99
185
../../glossary.rst:204
English
telnet
0/100 · 6
185
../../principles/linkstate.rst:71
English
Current link state routing protocols usually use 32 bits sequence numbers and include a special mechanism in the unlikely case that a sequence number reaches the maximum value (with a 32 bits sequence number space, it takes 136 years to cycle the sequence numbers if a link state packet is generated every second).
0/3140 · 314
185
../../principles/reliability.rst:766
English
The main advantage of `go-back-n` is that it can be easily implemented, and it can also provide good performance when only a few frames are lost. However, when there are many losses, the performance of `go-back-n` quickly drops for two reasons :
0/2450 · 245
185
../../protocols/email.rst:303
English
0x14b9
0/100 · 6
185
../../protocols/ipv6.rst:643
English
LANs also provide a broadcast and a multicast service. The broadcast service enables a device to send a single frame to all the devices attached to the same LAN. This is done by reserving a special broadcast MAC address (typically all bits of the address are set to one). To broadcast a frame, a device simply needs to send a frame whose destination is the broadcast address. All devices attached to the datalink network will receive the frame.
0/4450 · 445
185
../../protocols/wifi.rst:158
English
The 802.11 working group defined the `basic service set (BSS)` as a group of devices that communicate with each other. We continue to use `network` when referring to a set of devices that communicate.
0/2000 · 200
185
../../protocols/tcp.rst:623
English
Several researchers have analyzed the utilization of TCP and UDP in the global Internet. Most of these studies have been performed by collecting all the packets transmitted over a given link during a period of a few hours or days and then analyzing their headers to infer the transport protocol used, the type of application, ... Recent studies include http://www.caida.org/research/traffic-analysis/tcpudpratio/, https://research.sprintlabs.com/packstat/packetoverview.php or http://www.nanog.org/meetings/nanog43/presentations/Labovitz_internetstats_N43.pdf
0/5590 · 559
186
../../glossary.rst:206
English
The telnet protocol is defined in :rfc:`854`
0/440 · 44
186
../../principles/linkstate.rst:73
English
To deal with the memory corruption problem, link state packets contain a checksum or CRC. This checksum is computed by the router that generates the LSP. Each router must verify the checksum when it receives or floods an LSP. Furthermore, each router must periodically verify the checksums of the LSPs stored in its LSDB. This enables them to cope with memory errors that could corrupt the LSDB as the one that occurred in the ARPANET.
0/4350 · 435
186
../../principles/reliability.rst:768
English
the `go-back-n` receiver does not accept out-of-sequence frames
0/630 · 63
186
../../principles/sharing.rst:1041
English
A congestion control scheme for our simple transport protocol could be implemented as follows.
0/940 · 94
186
../../protocols/email.rst:305
English
00010100 11111011
0/180 · 18
186
../../protocols/ipv6.rst:645
English
The broadcast service allows easily reaching all devices attached to a datalink layer network. It has been widely used to support IP version 4. A drawback of using the broadcast service to support a network layer protocol is that a broadcast frame that contains a network layer packet is always delivered to all devices attached to the datalink network, even if some of these devices do not support the network layer protocol. The multicast service is a useful alternative to the broadcast service. To understand its operation, it is important to understand how a datalink layer interface operates. In shared media LANs, all devices are attached to the same physical medium and all frames are delivered to all devices. When such a frame is received by a datalink layer interface, it compares the destination address with the MAC address of the device. If the two addresses match, or the destination address is the broadcast address, the frame is destined to the device and its payload is delivered to the network layer protocol. The multicast service exploits this principle. A multicast address is a logical address. To receive frames destined to a multicast address in a shared media LAN, a device captures all frames having this multicast address as their destination. All IPv6 nodes are capable of capturing datalink layer frames destined to different multicast addresses.
0/13760 · 1376
186
../../protocols/wifi.rst:160
English
In fact, the [IEEE802.11]_ frame format contains a fourth optional address field. This fourth address is only used when an 802.11 wireless network is used to interconnect bridges attached to two classical LAN networks.
0/2180 · 218
186
../../protocols/tcp.rst:625
English
This 32 bits counter was specified in :rfc:`793`. A 32 bits counter that is incremented every 4 microseconds wraps in about 4.5 hours. This period is much larger than the Maximum Segment Lifetime that is fixed at 2 minutes in the Internet (:rfc:`791`, :rfc:`1122`).
0/2650 · 265