cnp3-ebook - English @ Weblate

Component	Unfinished	Unfinished words	Unfinished characters	Untranslated	Checks	Suggestions	Comments
bibliography CC-BY-SA-3.0	0	0	0	0	0	0	0

Glossary cnp3-ebook CC-BY-SA-3.0	0	0	0	0	0	0	0

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

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

exercises/ex-sharing CC-BY-SA-3.0	0	0	0	0	0	0	0

exercises/http 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/ipv6 CC-BY-SA-3.0	0	0	0	0	1	0	0

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

exercises/network CC-BY-SA-3.0	0	0	0	0	1	0	0

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

exercises/routing-policies CC-BY-SA-3.0	0	0	0	0	1	0	0

exercises/routing-protocols CC-BY-SA-3.0	0	0	0	0	0	0	0

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

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

exercises/tcp-2 CC-BY-SA-3.0	0	0	0	0	1	0	0

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

exercises/trace 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

glossary CC-BY-SA-3.0	0	0	0	0	0	0	0

index CC-BY-SA-3.0	0	0	0	0	2	0	0

links 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/network CC-BY-SA-3.0	0	0	0	0	5	0	0

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

principles/reliability CC-BY-SA-3.0	0	0	0	0	7	0	0

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

principles/sharing CC-BY-SA-3.0	0	0	0	0	7	0	0

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

protocols/bgp CC-BY-SA-3.0	0	0	0	0	1	0	0

protocols/congestion CC-BY-SA-3.0	0	0	0	0	1	0	0

protocols/dns CC-BY-SA-3.0	0	0	0	0	0	0	0

protocols/dnssec CC-BY-SA-3.0	0	0	0	0	0	0	0

protocols/email CC-BY-SA-3.0	0	0	0	0	0	0	0

protocols/ethernet CC-BY-SA-3.0	0	0	0	0	2	0	0

protocols/http CC-BY-SA-3.0	0	0	0	0	1	0	0

protocols/http2 CC-BY-SA-3.0	0	0	0	0	2	0	0

protocols/ipv6 CC-BY-SA-3.0	0	0	0	0	3	0	0

protocols/lan CC-BY-SA-3.0	0	0	0	0	2	0	0

protocols/ppp CC-BY-SA-3.0	0	0	0	0	0	0	0

protocols/routing CC-BY-SA-3.0	0	0	0	0	1	0	0

protocols/rpc CC-BY-SA-3.0	0	0	0	0	4	0	0

protocols/ssh CC-BY-SA-3.0	0	0	0	0	2	0	0

protocols/tcp CC-BY-SA-3.0	0	0	0	0	7	0	0

protocols/tls CC-BY-SA-3.0	0	0	0	0	0	0	0

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

protocols/transport-service CC-BY-SA-3.0	0	0	0	0	0	0	0

protocols/udp CC-BY-SA-3.0	0	0	0	0	0	0	0

protocols/wifi CC-BY-SA-3.0	0	0	0	0	0	0	0

Overview

Project website	www.computer-networking.info
Project maintainers	obonaventure qdeconinck
Translation license	CC-BY-SA-3.0 ^{exercises/ex-sharing} ^{exercises/intro} ^{exercises/reliability} ^{exercises/transport} ^{principles/naming} ^{principles/referencemodels} ^{principles/security} ^{exercises/dns} ^{exercises/http} ^{exercises/lan} ^{exercises/routing-protocols} ^{exercises/tcp} ^{exercises/tls} ^{protocols/bgp} ^{protocols/dnssec} ^{protocols/http2} ^{protocols/ppp} ^{protocols/rpc} ^{protocols/ipv6} ^index ^bibliography ^{exercises/network} ^{protocols/tls} ^{protocols/transport-service} ^links ^{principles/sharing} ^{protocols/udp} ^{protocols/wifi} ^{exercises/sockets} ^{principles/network} ^{protocols/dns} ^{exercises/email} ^{exercises/ipv6} ^{exercises/routing-policies} ^{exercises/tcp-2} ^{protocols/email} ^{exercises/trace} ^{protocols/http} ^{protocols/congestion} ^glossary ^{protocols/routing} ^{protocols/ssh} ^{protocols/tcp} ^{protocols/transport} ^cnp3-ebook ^{principles/transport} ^{protocols/ethernet} ^{protocols/lan} ^{principles/reliability}

String statistics

	Strings percent	Hosted strings	Words percent	Hosted words	Characters percent	Hosted characters
Total		3,655		158,232		993,048
Translated	100%	3,655	100%	158,232	100%	993,048
Needs editing	0%	0	0%	0	0%	0
Read-only	100%	3,655	100%	158,232	100%	993,048
Failing checks	1%	57	3%	5,909	3%	36,211
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


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

Quick numbers

158 k

Hosted words

3,655

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 / protocols/wifi — English	File `locale/pot/protocols/wifi.pot` was added. a year ago
None Resource update cnp3-ebook / protocols/udp — English	File `locale/pot/protocols/udp.pot` was added. a year ago
None Resource update cnp3-ebook / principles/transport — English	File `locale/pot/principles/transport.pot` was added. a year ago
None String updated in the repository cnp3-ebook / principles/transport — English	English The first solution to release a transport connection is to define a new control segment (e.g. the `DR` segment for Disconnection Request) and consider the connection to be released once this segment has been sent or received. This is illustrated in the figure below. English 266 characters edited Current translation Read only The first solution to release a transport connection is to define a new control segment (e.g. the `DR` segment for Disconnection Request) and consider the connection to be released once this segment has been sent or received. This is illustrated in the figure below. a year ago
None String updated in the repository cnp3-ebook / principles/transport — English	English Compared to reliable protocols in the datalink layer, reliable transport protocols encode their sequence numbers using more bits. 32 bits and 64 bits sequence numbers are frequent in the transport layer while some datalink layer protocols encode their sequence numbers in an 8 bits field. This large sequence number space is motivated by two reasons. First, since the sequence number is incremented for each transmitted byte, a single segment may consume one or several thousands of sequence numbers. Second, a reliable transport protocol must be able to detect delayed segments. This can only be done if the number of bytes transmitted during the MSL period is smaller than the sequence number space. Otherwise, there is a risk of accepting duplicate segments. English 761 characters edited Current translation Read only Compared to reliable protocols in the datalink layer, reliable transport protocols encode their sequence numbers using more bits. 32 bits and 64 bits sequence numbers are frequent in the transport layer while some datalink layer protocols encode their sequence numbers in an 8 bits field. This large sequence number space is motivated by two reasons. First, since the sequence number is incremented for each transmitted byte, a single segment may consume one or several thousands of sequence numbers. Second, a reliable transport protocol must be able to detect delayed segments. This can only be done if the number of bytes transmitted during the MSL period is smaller than the sequence number space. Otherwise, there is a risk of accepting duplicate segments. a year ago
None String updated in the repository cnp3-ebook / principles/transport — English	English Reliable transport protocols also use sequence numbers and acknowledgment numbers. While reliable protocols in the datalink layer use one sequence number per frame, reliable transport protocols consider all the data transmitted as a stream of bytes. In these protocols, the sequence number placed in the segment header corresponds to the position of the first byte of the payload in the bytestream. This sequence number allows detecting losses but also enables the receiver to reorder the out-of-sequence segments. This is illustrated in the figure below. English 555 characters edited Current translation Read only Reliable transport protocols also use sequence numbers and acknowledgment numbers. While reliable protocols in the datalink layer use one sequence number per frame, reliable transport protocols consider all the data transmitted as a stream of bytes. In these protocols, the sequence number placed in the segment header corresponds to the position of the first byte of the payload in the bytestream. This sequence number allows detecting losses but also enables the receiver to reorder the out-of-sequence segments. This is illustrated in the figure below. a year ago
None String updated in the repository cnp3-ebook / principles/transport — English	English The first point which is common between the two layers is that both use CRCs or checksums to detect transmission errors. Each segment contains a CRC/checksum which is computed over the entire segment (header and payload) by the sender and inserted in the header. The receiver recomputes the CRC/checksum for each received segment and discards all segments with an invalid CRC. English 376 characters edited Current translation Read only The first point which is common between the two layers is that both use CRCs or checksums to detect transmission errors. Each segment contains a CRC/checksum which is computed over the entire segment (header and payload) by the sender and inserted in the header. The receiver recomputes the CRC/checksum for each received segment and discards all segments with an invalid CRC. a year ago
None String updated in the repository cnp3-ebook / principles/transport — English	English The last scenario is less likely, but it is important to consider it as well. The remote entity receives an old `CR` segment. It notes the connection attempt and acknowledges it by sending a `CA` segment. The initiating entity does not have a matching connection attempt and replies by sending a `REJECT`. Unfortunately, this segment never reaches the remote entity. Instead, the remote entity receives a retransmission of an older `CA` segment that contains the same sequence number as the first `CR` segment. This `CA` segment cannot be accepted by the remote entity as a confirmation of the transport connection as its acknowledgment number cannot have the same value as the sequence number of the first `CA` segment. English 720 characters edited Current translation Read only The last scenario is less likely, but it is important to consider it as well. The remote entity receives an old `CR` segment. It notes the connection attempt and acknowledges it by sending a `CA` segment. The initiating entity does not have a matching connection attempt and replies by sending a `REJECT`. Unfortunately, this segment never reaches the remote entity. Instead, the remote entity receives a retransmission of an older `CA` segment that contains the same sequence number as the first `CR` segment. This `CA` segment cannot be accepted by the remote entity as a confirmation of the transport connection as its acknowledgment number cannot have the same value as the sequence number of the first `CA` segment. a year ago
None String updated in the repository cnp3-ebook / principles/transport — English	English Unfortunately, this scheme is not sufficient given the unreliable network layer. Since the network layer is imperfect, the `CR` or `CA` segments can be lost, delayed, or suffer from transmission errors. To deal with these problems, the control segments must be protected by a CRC or a checksum to detect transmission errors. Furthermore, since the `CA` segment acknowledges the reception of the `CR` segment, the `CR` segment can be protected using a retransmission timer. English 472 characters edited Current translation Read only Unfortunately, this scheme is not sufficient given the unreliable network layer. Since the network layer is imperfect, the `CR` or `CA` segments can be lost, delayed, or suffer from transmission errors. To deal with these problems, the control segments must be protected by a CRC or a checksum to detect transmission errors. Furthermore, since the `CA` segment acknowledges the reception of the `CR` segment, the `CR` segment can be protected using a retransmission timer. a year ago
None String updated in the repository cnp3-ebook / principles/transport — English	English The simplest approach to establish a transport connection would be to define two special control segments : `CR` (Connection Request) and `CA` (Connection Acknowledgment). The `CR` segment is sent by the transport entity that wishes to initiate a connection. If the remote entity wishes to accept the connection, it replies by sending a `CA` segment. The `CR` and `CA` segments contain `port numbers` that allow identifying the communicating applications. The transport connection is considered to be established once the `CA` segment has been received. At that point, data segments can be sent in both directions. English 614 characters edited Current translation Read only The simplest approach to establish a transport connection would be to define two special control segments : `CR` (Connection Request) and `CA` (Connection Acknowledgment). The `CR` segment is sent by the transport entity that wishes to initiate a connection. If the remote entity wishes to accept the connection, it replies by sending a `CA` segment. The `CR` and `CA` segments contain `port numbers` that allow identifying the communicating applications. The transport connection is considered to be established once the `CA` segment has been received. At that point, data segments can be sent in both directions. a year ago

Browse all language changes

Search

Advanced query builder

Query examples

Review strings changed by other users	`changed:>=2024-03-25 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-03-25 AND state:<=needs-editing`	Add