cnp3-ebook/principles/sharing — English @ Weblate

Source strings

187	Strings		100%	Browse Translate
15,702	Words		100%	Browse Translate

This translation is being used as source strings within this component.

Strings status

187	All strings — 15,702 words	Browse Translate Zen
187	Read-only strings — 15,702 words	Browse Translate Zen
7	Strings with any failing checks — 1,283 words	Browse Translate Zen
1	Failing check: Unpluralised — 22 words	Browse Translate Zen
6	Failing check: Ellipsis — 1,261 words	Browse Translate Zen

Other components

Component	Unfinished	Unfinished words	Unfinished characters	Untranslated	Checks	Suggestions	Comments
exercises/ex-sharing CC-BY-SA-3.0	0	0	0	0	0	0	0

exercises/intro CC-BY-SA-3.0	0	0	0	0	0	0	0

exercises/reliability CC-BY-SA-3.0	0	0	0	0	0	0	0

exercises/transport CC-BY-SA-3.0	0	0	0	0	0	0	0

principles/naming CC-BY-SA-3.0	0	0	0	0	1	0	0

principles/referencemodels CC-BY-SA-3.0	0	0	0	0	0	0	0

principles/security CC-BY-SA-3.0	0	0	0	0	1	0	0

exercises/dns CC-BY-SA-3.0	0	0	0	0	3	0	0

exercises/http CC-BY-SA-3.0	0	0	0	0	0	0	0

exercises/lan CC-BY-SA-3.0	0	0	0	0	0	0	0

Browse all components

Overview

Project website	www.computer-networking.info
Project maintainers	obonaventure qdeconinck
Translation process	Translations can be made directly. Translation suggestions can be made. Any authenticated user can contribute. The translation uses bilingual files.
Translation license	Creative Commons Attribution Share Alike 3.0 Unported
Source code repository	`https://github.com/cnp3/ebook`
Repository branch	master
Last remote commit	Merge pull request #126 from INGIbot/weblate-cnp3-ebook-index `d9f8d8f` Olivier Bonaventure authored 7 months ago
Weblate repository	`https://weblate.info.ucl.ac.be/git/cnp3-ebook/index/`
File mask	`locale/*/LC_MESSAGES/principles/sharing.po`
Translation file	Download `locale/pot/principles/sharing.pot`
Last change	None
Last author	None

String statistics

	Strings percent	Hosted strings	Words percent	Hosted words	Characters percent	Hosted characters
Total		187		15,702		97,031
Translated	100%	187	100%	15,702	100%	97,031
Needs editing	0%	0	0%	0	0%	0
Read-only	100%	187	100%	15,702	100%	97,031
Failing checks	3%	7	8%	1,283	8%	7,789
Strings with suggestions	0%	0	0%	0	0%	0
Untranslated strings	0%	0	0%	0	0%	0

Last 12 months Previous

Activity in last 12 months


Nov	Dec	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct

Quick numbers

15,702

Hosted words

187

Hosted strings

100%

Translated

Contributors

and previous 30 days

Trends of last 30 days

—

Hosted words

—

Hosted strings

—

Translated

—

Contributors

—

None Resource update cnp3-ebook / principles/sharing — English	File `locale/pot/principles/sharing.pot` was added. 2 years ago
None String updated in the repository cnp3-ebook / principles/sharing — English	English 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 English 303 characters edited Current translation Read only 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 2 years ago
None String updated in the repository cnp3-ebook / principles/sharing — English	English 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]_. English 189 characters edited Current translation Read only 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]_. 2 years ago
None String updated in the repository cnp3-ebook / principles/sharing — English	English 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. English 481 characters edited Current translation Read only 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. 2 years ago
None String updated in the repository cnp3-ebook / principles/sharing — English	English 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. English 801 characters edited Current translation Read only 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. 2 years ago
None String updated in the repository cnp3-ebook / principles/sharing — English	English 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. English 647 characters edited Current translation Read only 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. 2 years ago
None String updated in the repository cnp3-ebook / principles/sharing — English	English 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. English 1332 characters edited Current translation Read only 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. 2 years ago
None String updated in the repository cnp3-ebook / principles/sharing — English	English 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. English 585 characters edited Current translation Read only 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. 2 years ago
None String updated in the repository cnp3-ebook / principles/sharing — English	English 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. English 1277 characters edited Current translation Read only 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. 2 years ago
None String updated in the repository cnp3-ebook / principles/sharing — English	English 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. English 2352 characters edited Current translation Read only 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. 2 years ago

Browse all translation changes

Quick downloads

187	File in original format as translated in the repository	gettext PO file
187	All strings, converted files enriched with comments; suitable for offline translation	CSV	gettext MO	gettext PO	TBX	TMX	XLIFF 1.1 with gettext extensions	XLIFF 1.1	XLSX

Customize download

Search

Advanced query builder

Query examples

Review strings changed by other users	`changed:>=2024-10-22 AND NOT changed_by:anonymous`	Add
Translated strings	`state:>=translated`	Add
Strings with comments	`has:comment`	Add
Strings with any failing checks	`has:check`	Add
Strings with suggestions from others	`has:suggestion AND NOT suggestion_author:anonymous`	Add
Approved strings with suggestions	`state:approved AND has:suggestion`	Add
All untranslated strings added the past month	`added:>=2024-10-22 AND state:<=needs-editing`	Add