Changes
Translation components API.
See the Weblate's Web API documentation for detailed description of the API.
GET /api/components/cnp3-ebook/principlessharing/changes/?format=api&page=13
{ "count": 280, "next": "https://weblate.info.ucl.ac.be/api/components/cnp3-ebook/principlessharing/changes/?format=api&page=14", "previous": "https://weblate.info.ucl.ac.be/api/components/cnp3-ebook/principlessharing/changes/?format=api&page=12", "results": [ { "unit": "https://weblate.info.ucl.ac.be/api/units/37713/?format=api", "component": "https://weblate.info.ucl.ac.be/api/components/cnp3-ebook/principlessharing/?format=api", "translation": "https://weblate.info.ucl.ac.be/api/translations/cnp3-ebook/principlessharing/en/?format=api", "user": null, "author": null, "timestamp": "2022-09-17T01:14:37.608000+02:00", "action": 59, "target": "`Probabilistic drop`. Various random drop techniques have been proposed. A frequently cited technique is `Random Early Discard` (RED) [FJ1993]_. RED measures the average buffer occupancy and discards packets with a given probability when this average occupancy is too high. Compared to `tail drop` and `drop from front`, an advantage of `RED` is that thanks to the probabilistic drops, packets should be discarded from different flows in proportion of their bandwidth.", "id": 14969, "action_name": "String updated in the repository", "url": "https://weblate.info.ucl.ac.be/api/changes/14969/?format=api" }, { "unit": "https://weblate.info.ucl.ac.be/api/units/37714/?format=api", "component": "https://weblate.info.ucl.ac.be/api/components/cnp3-ebook/principlessharing/?format=api", "translation": "https://weblate.info.ucl.ac.be/api/translations/cnp3-ebook/principlessharing/en/?format=api", "user": null, "author": null, "timestamp": "2022-09-17T01:14:37.608050+02:00", "action": 59, "target": "If the packet header does not contain any bit in the header to represent the current congestion level, an alternative is to allow the network nodes to send a control packet to the source to indicate the current congestion level. Some networking technologies use such control packets to explicitly regulate the transmission rate of sources. However, their usage is mainly restricted to small networks. In large networks, network nodes usually avoid using such control packets. These control packets are even considered to be dangerous in some networks. First, using them increases the network load when the network is congested. Second, while network nodes are optimized to forward packets, they are usually pretty slow at creating new packets.", "id": 14970, "action_name": "String updated in the repository", "url": "https://weblate.info.ucl.ac.be/api/changes/14970/?format=api" }, { "unit": "https://weblate.info.ucl.ac.be/api/units/37715/?format=api", "component": "https://weblate.info.ucl.ac.be/api/components/cnp3-ebook/principlessharing/?format=api", "translation": "https://weblate.info.ucl.ac.be/api/translations/cnp3-ebook/principlessharing/en/?format=api", "user": null, "author": null, "timestamp": "2022-09-17T01:14:37.608101+02:00", "action": 59, "target": "A very simple scheduler is the `round-robin scheduler`. This scheduler serves all the queues in a round-robin fashion. If all flows send packets of the same size, then the round-robin scheduler fairly allocates the bandwidth among the different flows. Otherwise, it favors flows that are using larger packets. Extensions to the `round-robin scheduler` have been proposed to provide a fair distribution of the bandwidth with variable-length packets [SV1995]_ but these are outside the scope of this chapter.", "id": 14971, "action_name": "String updated in the repository", "url": "https://weblate.info.ucl.ac.be/api/changes/14971/?format=api" }, { "unit": "https://weblate.info.ucl.ac.be/api/units/37716/?format=api", "component": "https://weblate.info.ucl.ac.be/api/components/cnp3-ebook/principlessharing/?format=api", "translation": "https://weblate.info.ucl.ac.be/api/translations/cnp3-ebook/principlessharing/en/?format=api", "user": null, "author": null, "timestamp": "2022-09-17T01:14:37.608151+02:00", "action": 59, "target": "Delays, packet discards, packet markings and control packets are the main types of information that the network can exchange with the end hosts. Discarding packets is the main action that a network node can perform if the congestion is too severe. Besides tackling congestion at each node, it is also possible to divert some traffic flows from heavily loaded links to reduce congestion. Early routing algorithms [MRR1980]_ have used delay measurements to detect congestion between network nodes and update the link weights dynamically. By reflecting the delay perceived by applications in the link weights used for the shortest paths computation, these routing algorithms managed to dynamically change the forwarding paths in reaction to congestion. However, deployment experience showed that these dynamic routing algorithms could cause oscillations and did not necessarily lower congestion. Deployed datagram networks rarely use dynamic routing algorithms, except in some wireless networks. In datagram networks, the state of the art reaction to long term congestion, i.e. congestion lasting hours, days or more, is to measure the traffic demand and then select the link weights [FRT2002]_ that allow minimizing the maximum link loads. If the congestion lasts longer, changing the weights is not sufficient anymore and the network needs to be upgraded with additional or faster links. However, in Wide Area Networks, adding new links can take months.", "id": 14972, "action_name": "String updated in the repository", "url": "https://weblate.info.ucl.ac.be/api/changes/14972/?format=api" }, { "unit": "https://weblate.info.ucl.ac.be/api/units/37717/?format=api", "component": "https://weblate.info.ucl.ac.be/api/components/cnp3-ebook/principlessharing/?format=api", "translation": "https://weblate.info.ucl.ac.be/api/translations/cnp3-ebook/principlessharing/en/?format=api", "user": null, "author": null, "timestamp": "2022-09-17T01:14:37.608206+02:00", "action": 59, "target": "Another way to share the network resources is to distribute the load across multiple links. Many techniques have been designed to spread the load over the network. As an illustration, let us briefly consider how the load can be shared when accessing some content. Consider a large and popular file such as the image of a Linux distribution or the upgrade of a commercial operating system that will be downloaded by many users. There are many ways to distribute this large file. A naive solution is to place one copy of the file on a server and allow all users to download this file from the server. If the file is popular and millions of users want to download it, the server will quickly become overloaded. There are two classes of solutions that can be used to serve a large number of users. A first approach is to store the file on servers whose name is known by the clients. Before retrieving the file, each client will query the name service to obtain the address of the server. If the file is available from many servers, the name service can provide different addresses to different clients. This will automatically spread the load since different clients will download the file from different servers. Most large content providers use such a solution to distribute large files or videos.", "id": 14973, "action_name": "String updated in the repository", "url": "https://weblate.info.ucl.ac.be/api/changes/14973/?format=api" }, { "unit": "https://weblate.info.ucl.ac.be/api/units/37718/?format=api", "component": "https://weblate.info.ucl.ac.be/api/components/cnp3-ebook/principlessharing/?format=api", "translation": "https://weblate.info.ucl.ac.be/api/translations/cnp3-ebook/principlessharing/en/?format=api", "user": null, "author": null, "timestamp": "2022-09-17T01:14:37.608260+02:00", "action": 59, "target": "There is another solution that allows spreading the load among many sources without relying on the name service. The popular `bittorent <https://www.bittorrent.com>`_ service is an example of this approach. With this solution, each file is divided in blocks of fixed size. To retrieve a file, a client needs to retrieve all the blocks that compose the file. However, nothing forces the client to retrieve all the blocks in sequence and from the same server. Each file is associated with metadata that indicates for each block a list of addresses of hosts that store this block. To retrieve a complete file, a client first downloads the metadata. Then, it tries to retrieve each block from one of the hosts that store the block. In practice, implementations often try to download several blocks in parallel. Once one block has been successfully downloaded, the next block can be requested. If a host is slow to provide one block or becomes unavailable, the client can contact another host listed in the metadata. Most deployments of bittorrent allow the clients to participate to the distribution of blocks. Once a client has downloaded one block, it contacts the server which stores the metadata to indicate that it can also provide this block. With this scheme, when a file is popular, its blocks are downloaded by many hosts that automatically participate in the distribution of the blocks. Thus, the number of `servers` that are capable of providing blocks from a popular file automatically increases with the file's popularity.", "id": 14974, "action_name": "String updated in the repository", "url": "https://weblate.info.ucl.ac.be/api/changes/14974/?format=api" }, { "unit": "https://weblate.info.ucl.ac.be/api/units/37719/?format=api", "component": "https://weblate.info.ucl.ac.be/api/components/cnp3-ebook/principlessharing/?format=api", "translation": "https://weblate.info.ucl.ac.be/api/translations/cnp3-ebook/principlessharing/en/?format=api", "user": null, "author": null, "timestamp": "2022-09-17T01:14:37.608315+02:00", "action": 59, "target": "TDM and FDM are widely used in telephone networks to support fixed bandwidth conversations. Using them in Local Area Networks that support computers would probably be inefficient. Computers usually do not send information at a fixed rate. Instead, they often have an on-off behavior. During the on period, the computer tries to send at the highest possible rate, e.g. to transfer a file. During the off period, which is often much longer than the on period, the computer does not transmit any packet. Using a static allocation scheme for computers attached to a LAN would lead to huge inefficiencies, as they would only be able to transmit at :math:`\\frac{1}{N}` of the total bandwidth during their on period, despite the fact that the other computers are in their off period and thus do not need to transmit any information. The dynamic MAC algorithms discussed in the remainder of this chapter aim to solve this problem.", "id": 14975, "action_name": "String updated in the repository", "url": "https://weblate.info.ucl.ac.be/api/changes/14975/?format=api" }, { "unit": "https://weblate.info.ucl.ac.be/api/units/37720/?format=api", "component": "https://weblate.info.ucl.ac.be/api/components/cnp3-ebook/principlessharing/?format=api", "translation": "https://weblate.info.ucl.ac.be/api/translations/cnp3-ebook/principlessharing/en/?format=api", "user": null, "author": null, "timestamp": "2022-09-17T01:14:37.608367+02:00", "action": 59, "target": "In the 1960s, computers were mainly mainframes with a few dozen terminals attached to them. These terminals were usually in the same building as the mainframe and were directly connected to it. In some cases, the terminals were installed in remote locations and connected through a :term:`modem` attached to a :term:`dial-up line`. The university of Hawaii chose a different organization. Instead of using telephone lines to connect the distant terminals, they developed the first `packet radio` technology [Abramson1970]_. Until then, computer networks were built on top of either the telephone network or physical cables. ALOHANet showed that it is possible to use radio signals to interconnect computers.", "id": 14976, "action_name": "String updated in the repository", "url": "https://weblate.info.ucl.ac.be/api/changes/14976/?format=api" }, { "unit": "https://weblate.info.ucl.ac.be/api/units/37721/?format=api", "component": "https://weblate.info.ucl.ac.be/api/components/cnp3-ebook/principlessharing/?format=api", "translation": "https://weblate.info.ucl.ac.be/api/translations/cnp3-ebook/principlessharing/en/?format=api", "user": null, "author": null, "timestamp": "2022-09-17T01:14:37.608417+02:00", "action": 59, "target": "The first version of ALOHANet, described in [Abramson1970]_, operated as follows. First, the terminals and the mainframe exchanged fixed-length frames composed of 704 bits. Each frame contained 80 8-bit characters, some control bits and parity information to detect transmission errors. Two channels in the 400 MHz range were reserved for the operation of ALOHANet. The first channel was used by the mainframe to send frames to all terminals. The second channel was shared among all terminals to send frames to the mainframe. As all terminals share the same transmission channel, there is a risk of collision. To deal with this problem as well as transmission errors, the mainframe verified the parity bits of the received frame and sent an acknowledgment on its channel for each correctly received frame. The terminals on the other hand had to retransmit the unacknowledged frames. As for TCP, retransmitting these frames immediately upon expiration of a fixed timeout is not a good approach as several terminals may retransmit their frames at the same time leading to a network collapse. A better approach, but still far from perfect, is for each terminal to wait a random amount of time after the expiration of its retransmission timeout. This avoids synchronization among multiple retransmitting terminals.", "id": 14977, "action_name": "String updated in the repository", "url": "https://weblate.info.ucl.ac.be/api/changes/14977/?format=api" }, { "unit": "https://weblate.info.ucl.ac.be/api/units/37722/?format=api", "component": "https://weblate.info.ucl.ac.be/api/components/cnp3-ebook/principlessharing/?format=api", "translation": "https://weblate.info.ucl.ac.be/api/translations/cnp3-ebook/principlessharing/en/?format=api", "user": null, "author": null, "timestamp": "2022-09-17T01:14:37.608479+02:00", "action": 59, "target": "The pseudo-code below shows the operation of an ALOHANet terminal. We use this python syntax for all Medium Access Control algorithms described in this chapter. The algorithm is applied to each new frame that needs to be transmitted. It attempts to transmit a frame at most `max` times (`while loop`). Each transmission attempt is performed as follows. First, the frame is sent. Each frame is protected by a timeout. Then, the terminal waits for either a valid acknowledgment frame or the expiration of its timeout. If the terminal receives an acknowledgment, the frame has been delivered correctly and the algorithm terminates. Otherwise, the terminal waits for a random time and attempts to retransmit the frame.", "id": 14978, "action_name": "String updated in the repository", "url": "https://weblate.info.ucl.ac.be/api/changes/14978/?format=api" }, { "unit": "https://weblate.info.ucl.ac.be/api/units/37723/?format=api", "component": "https://weblate.info.ucl.ac.be/api/components/cnp3-ebook/principlessharing/?format=api", "translation": "https://weblate.info.ucl.ac.be/api/translations/cnp3-ebook/principlessharing/en/?format=api", "user": null, "author": null, "timestamp": "2022-09-17T01:14:37.608534+02:00", "action": 59, "target": "CSMA improves channel utilization compared to ALOHA. However, the performance can still be improved, especially in wired networks. Consider the situation of two terminals that are connected to the same cable. This cable could, for example, be a coaxial cable as in the early days of Ethernet [Metcalfe1976]_. It could also be built with twisted pairs. Before extending CSMA, it is useful to understand, more intuitively, how frames are transmitted in such a network and how collisions can occur. The figure below illustrates the physical transmission of a frame on such a cable. To transmit its frame, host A must send an electrical signal on the shared medium. The first step is thus to begin the transmission of the electrical signal. This is point `(1)` in the figure below. This electrical signal will travel along the cable. Although electrical signals travel fast, we know that information cannot travel faster than the speed of light (i.e. 300.000 kilometers/second). On a coaxial cable, an electrical signal is slightly slower than the speed of light and 200.000 kilometers per second is a reasonable estimation. This implies that if the cable has a length of one kilometer, the electrical signal will need 5 microseconds to travel from one end of the cable to the other. The ends of coaxial cables are equipped with termination points that ensure that the electrical signal is not reflected back to its source. This is illustrated at point `(3)` in the figure, where the electrical signal has reached the left endpoint and host B. At this point, B starts to receive the frame being transmitted by A. Notice that there is a delay between the transmission of a bit on host A and its reception by host B. If there were other hosts attached to the cable, they would receive the first bit of the frame at slightly different times. As we will see later, this timing difference is a key problem for MAC algorithms. At point `(4)`, the electrical signal has reached both ends of the cable and occupies it completely. Host A continues to transmit the electrical signal until the end of the frame. As shown at point `(5)`, when the sending host stops its transmission, the electrical signal corresponding to the end of the frame leaves the coaxial cable. The channel becomes empty again once the entire electrical signal has been removed from the cable.", "id": 14979, "action_name": "String updated in the repository", "url": "https://weblate.info.ucl.ac.be/api/changes/14979/?format=api" }, { "unit": "https://weblate.info.ucl.ac.be/api/units/37724/?format=api", "component": "https://weblate.info.ucl.ac.be/api/components/cnp3-ebook/principlessharing/?format=api", "translation": "https://weblate.info.ucl.ac.be/api/translations/cnp3-ebook/principlessharing/en/?format=api", "user": null, "author": null, "timestamp": "2022-09-17T01:14:37.608592+02:00", "action": 59, "target": "Both the proponents of the deterministic and the opportunistic techniques lobbied to develop standards for Local Area networks that would incorporate their solution. Instead of trying to find an impossible compromise between these diverging views, the IEEE 802 committee that was chartered to develop Local Area Network standards chose to work in parallel on three different LAN technologies and created three working groups. The `IEEE 802.3 working group <http://www.ieee802.org/3/>`_ became responsible for CSMA/CD. The proponents of deterministic MAC algorithms agreed on the basic principle of exchanging special frames called tokens between devices to regulate the access to the transmission medium. However, they did not agree on the most suitable physical layout for the network. IBM argued in favor of Ring-shaped networks while the manufacturing industry, led by General Motors, argued in favor of a bus-shaped network. This led to the creation of the `IEEE 802.4 working group <http://www.ieee802.org/4/>`_ to standardize Token Bus networks and the `IEEE 802.5 working group <http://www.ieee802.org/5/>`_ to standardize Token Ring networks. Although these techniques are not widely used anymore today, the principles behind a token-based protocol are still important.", "id": 14980, "action_name": "String updated in the repository", "url": "https://weblate.info.ucl.ac.be/api/changes/14980/?format=api" }, { "unit": "https://weblate.info.ucl.ac.be/api/units/37725/?format=api", "component": "https://weblate.info.ucl.ac.be/api/components/cnp3-ebook/principlessharing/?format=api", "translation": "https://weblate.info.ucl.ac.be/api/translations/cnp3-ebook/principlessharing/en/?format=api", "user": null, "author": null, "timestamp": "2022-09-17T01:14:37.608645+02:00", "action": 59, "target": "Now that we have explained how the token can be forwarded on the ring, let us analyze how a station can capture a token to transmit a data frame. For this, we need some information about the format of the data frames. An 802.5 data frame begins with the `Starting Delimiter` followed by the `Access Control` field whose `Token` bit is reset, a `Frame Control` field that enables the definition of several types of frames, destination and source address, a payload, a CRC, the `Ending Delimiter` and a `Frame Status` field. The format of the Token Ring data frames is illustrated below.", "id": 14981, "action_name": "String updated in the repository", "url": "https://weblate.info.ucl.ac.be/api/changes/14981/?format=api" }, { "unit": "https://weblate.info.ucl.ac.be/api/units/37726/?format=api", "component": "https://weblate.info.ucl.ac.be/api/components/cnp3-ebook/principlessharing/?format=api", "translation": "https://weblate.info.ucl.ac.be/api/translations/cnp3-ebook/principlessharing/en/?format=api", "user": null, "author": null, "timestamp": "2022-09-17T01:14:37.608697+02:00", "action": 59, "target": "Let us consider that host `A` uses a window of three segments. It thus sends three back-to-back segments at `10 Mbps` and then waits for an acknowledgment. Host `A` stops sending segments when its window is full. These segments reach the buffers of router `R1`. The first segment stored in this buffer is sent by router `R1` at a rate of `2 Mbps` to the destination host. Upon reception of this segment, the destination sends an acknowledgment. This acknowledgment allows host `A` to transmit a new segment. This segment is stored in the buffers of router `R1` while it is transmitting the second segment that was sent by host `A`... Thus, after the transmission of the first window of segments, the reliable transport protocol sends one data segment after the reception of each acknowledgment returned by the destination. In practice, the acknowledgments sent by the destination serve as a kind of `clock` that allows the sending host to adapt its transmission rate to the rate at which segments are received by the destination. This `self-clocking` is the first mechanism that allows a window-based reliable transport protocol to adapt to heterogeneous networks [Jacobson1988]_. It depends on the availability of buffers to store the segments that have been sent by the sender but have not yet been transmitted to the destination.", "id": 14982, "action_name": "String updated in the repository", "url": "https://weblate.info.ucl.ac.be/api/changes/14982/?format=api" }, { "unit": "https://weblate.info.ucl.ac.be/api/units/37727/?format=api", "component": "https://weblate.info.ucl.ac.be/api/components/cnp3-ebook/principlessharing/?format=api", "translation": "https://weblate.info.ucl.ac.be/api/translations/cnp3-ebook/principlessharing/en/?format=api", "user": null, "author": null, "timestamp": "2022-09-17T01:14:37.608761+02:00", "action": 59, "target": "The links between the hosts and the routers have a bandwidth of 1 Mbps while the link between the two routers has a bandwidth of 500 Kbps. There is no significant propagation delay in this network. For simplicity, assume that hosts `A` and `B` send 1000 bits packets. The transmission of such a packet on a `host-router` (resp. `router-router` ) link requires 1 msec (resp. 2 msec). If there is no traffic in the network, the round-trip-time measured by host `A` to reach `D` is slightly larger than 4 msec. Let us observe the flow of packets with different window sizes to understand the relationship between sending window and transmission rate.", "id": 14983, "action_name": "String updated in the repository", "url": "https://weblate.info.ucl.ac.be/api/changes/14983/?format=api" }, { "unit": "https://weblate.info.ucl.ac.be/api/units/37728/?format=api", "component": "https://weblate.info.ucl.ac.be/api/components/cnp3-ebook/principlessharing/?format=api", "translation": "https://weblate.info.ucl.ac.be/api/translations/cnp3-ebook/principlessharing/en/?format=api", "user": null, "author": null, "timestamp": "2022-09-17T01:14:37.608817+02:00", "action": 59, "target": "From the above example, we can adjust the transmission rate by adjusting the sending window of a reliable transport protocol. A reliable transport protocol cannot send data faster than :math:`\\frac{window}{rtt}` segments per second where :math:`window` is the current sending window. To control the transmission rate, we introduce a `congestion window`. This congestion window limits the sending window. At any time, the sending window is restricted to :math:`\\min(swin,cwin)`, where `swin` is the sending window and `cwin` the current `congestion window`. Of course, the window is further constrained by the receive window advertised by the remote peer. With the utilization of a congestion window, a simple reliable transport protocol that uses fixed size segments could implement `AIMD` as follows.", "id": 14984, "action_name": "String updated in the repository", "url": "https://weblate.info.ucl.ac.be/api/changes/14984/?format=api" }, { "unit": "https://weblate.info.ucl.ac.be/api/units/37729/?format=api", "component": "https://weblate.info.ucl.ac.be/api/components/cnp3-ebook/principlessharing/?format=api", "translation": "https://weblate.info.ucl.ac.be/api/translations/cnp3-ebook/principlessharing/en/?format=api", "user": null, "author": null, "timestamp": "2022-09-17T01:14:37.608868+02:00", "action": 59, "target": "For the `Additive Increase` part our simple protocol would simply increase its `congestion window` by one segment every round-trip-time. The `Multiplicative Decrease` part of `AIMD` could be implemented by halving the congestion window when congestion is detected. For simplicity, we assume that congestion is detected thanks to a binary feedback and that no segments are lost. We will discuss in more details how losses affect a real transport protocol like TCP in later sections.", "id": 14985, "action_name": "String updated in the repository", "url": "https://weblate.info.ucl.ac.be/api/changes/14985/?format=api" }, { "unit": "https://weblate.info.ucl.ac.be/api/units/37730/?format=api", "component": "https://weblate.info.ucl.ac.be/api/components/cnp3-ebook/principlessharing/?format=api", "translation": "https://weblate.info.ucl.ac.be/api/translations/cnp3-ebook/principlessharing/en/?format=api", "user": null, "author": null, "timestamp": "2022-09-17T01:14:37.608918+02:00", "action": 59, "target": "There are still some vendors that try to put as many buffers as possible on their routers. A recent example is the buffer bloat problem that plagues some low-end Internet routers [GN2011]_.", "id": 14986, "action_name": "String updated in the repository", "url": "https://weblate.info.ucl.ac.be/api/changes/14986/?format=api" }, { "unit": "https://weblate.info.ucl.ac.be/api/units/37731/?format=api", "component": "https://weblate.info.ucl.ac.be/api/components/cnp3-ebook/principlessharing/?format=api", "translation": "https://weblate.info.ucl.ac.be/api/translations/cnp3-ebook/principlessharing/en/?format=api", "user": null, "author": null, "timestamp": "2022-09-17T01:14:37.608966+02:00", "action": 59, "target": "Some examples of the performance of various types of commercial networks nodes (routers and switches) may be found in http://www.cisco.com/web/partners/downloads/765/tools/quickreference/routerperformance.pdf and http://www.cisco.com/web/partners/downloads/765/tools/quickreference/switchperformance.pdf", "id": 14987, "action_name": "String updated in the repository", "url": "https://weblate.info.ucl.ac.be/api/changes/14987/?format=api" }, { "unit": null, "component": "https://weblate.info.ucl.ac.be/api/components/cnp3-ebook/principlessharing/?format=api", "translation": "https://weblate.info.ucl.ac.be/api/translations/cnp3-ebook/principlessharing/en/?format=api", "user": null, "author": null, "timestamp": "2022-09-17T01:14:37.609013+02:00", "action": 0, "target": "", "id": 14988, "action_name": "Resource update", "url": "https://weblate.info.ucl.ac.be/api/changes/14988/?format=api" } ] }