The translation has come to an end.

Translation status

158 Strings
0%
Browse Translate
8,063 Words
0%
48,930 Characters
0%

Strings status

Strings Words Characters
158 8,063 48,930
All strings Browse Translate Zen
158 8,063 48,930
Unfinished strings Browse Translate Zen
158 8,063 48,930
Untranslated strings Browse Translate Zen

Summary

Project website www.computer-networking.info
Project maintainers2 User avatar obonaventureUser avatar qdeconinck
Translation license Creative Commons Attribution Share Alike 3.0 Unported
Translation process
  • Translations can be made directly.
  • Translation suggestions can be made.
  • Any authenticated user can contribute.
  • The translation uses bilingual files.
Source code repository https://github.com/cnp3/ebook
Repository branch master
Last remote commit Merge pull request #159 from bhesmans/docker-build 5d27036
Olivier Bonaventure authored 7 months ago
Last commit in Weblate Merge pull request #159 from bhesmans/docker-build 5d27036
Olivier Bonaventure authored 7 months ago
Weblate repository https://weblate.info.ucl.ac.be/git/cnp3-ebook/index/
File mask locale/*/LC_MESSAGES/principles/network.po
Translation file Download locale/cs/LC_MESSAGES/principles/network.po
Last change Oct. 14, 2019, 10:39 a.m.
Last change made by None
Language Czech
Language code cs
Text direction Left to right
Case sensitivity Case-sensitive
Number of speakers 13,236,057
Number of plurals 3
Plural type One/few/other
Plurals One 1
Few 2, 3, 4
Other 0, 5, 6, 7, 8, 9, 10, 11, 12, 13, …
Plural formula (n==1) ? 0 : (n>=2 && n<=4) ? 1 : 2
3 weeks ago

String statistics

Strings percent Hosted strings Words percent Hosted words Characters percent Hosted characters
Total 158 8,063 48,930
Translated 0% 0 0% 0 0% 0
Needs editing 0% 0 0% 0 0% 0
Read-only 0% 0 0% 0 0% 0
Failing checks 0% 0 0% 0 0% 0
Strings with suggestions 0% 0 0% 0 0% 0
Untranslated strings 100% 158 100% 8,063 100% 48,930
Last 12 months Previous

Activity in last 12 months

0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes
JanFebMarAprMayJunJulAugSepOctNovDec

Quick numbers

8,063
Hosted words
158
Hosted strings
0%
Translated
0
Contributors
and previous 30 days

Trends of last 30 days

+98%
Hosted words
+100%
+100%
Hosted strings
—
—
Translated
—
—
Contributors
—
User avatar None

Resource updated
The “locale/cs/LC_MESSAGES/principles/network.po” file was changed. 6 years ago
User avatar None

Source string added
It should be noted that link state routing assumes that all routers in the network have enough memory to store the entire LSDB. The routers that do not have enough memory to store the entire LSDB cannot participate in link state routing. Some link state routing protocols allow routers to report that they do not have enough memory and must be removed from the graph by the other routers in the network, but this is outside the scope of this e-book.
6 years ago
User avatar None

Source string added
To compute its forwarding table, each router computes the spanning tree rooted at itself by using Dijkstra's shortest path algorithm [Dijkstra1959]_. The forwarding table can be derived automatically from the spanning as shown in the figure below.
6 years ago
User avatar None

Source string added
When a router has failed, its LSP must be removed from the LSDB of all routers [#foverload]_. This can be done by using the `age` field that is included in each LSP. The `age` field is used to bound the maximum lifetime of a link state packet in the network. When a router generates a LSP, it sets its lifetime (usually measured in seconds) in the `age` field. All routers regularly decrement the `age` of the LSPs in their LSDB and a LSP is discarded once its `age` reaches `0`. Thanks to the `age` field, the LSP from a failed router does not remain in the LSDBs forever.
6 years ago
User avatar None

Source string added
When a link fails, the two routers attached to the link detect the failure by the absence of HELLO messages received during the last :math:`k \times N` seconds. Once a router has detected the failure of one of its local links, it generates and floods a new LSP that no longer contains the failed link. This new LSP replaces the previous LSP in the network. In practice, the two routers attached to a link do not detect this failure exactly at the same time. During this period, some links may be announced in only one direction. This is illustrated in the figure below. Router `E` has detected the failure of link `E-B` and flooded a new LSP, but router `B` has not yet detected this failure.
6 years ago
User avatar None

Source string added
As link state packets are flooded regularly, routers are able to measure the quality (e.g. delay or load) of their links and adjust the metric of each link according to its current quality. Such dynamic adjustments were included in the ARPANET routing protocol [MRR1979]_ . However, experience showed that it was difficult to tune the dynamic adjustments and ensure that no forwarding loops occur in the network [KZ1989]_. Today's link state routing protocols use metrics that are manually configured on the routers and are only changed by the network operators or network management tools [FRT2002]_.
6 years ago
User avatar None

Source string added
Static or dynamic link metrics ?
6 years ago
User avatar None

Source string added
To ensure that all routers receive all LSPs, even when there are transmissions errors, link state routing protocols use `reliable flooding`. With `reliable flooding`, routers use acknowledgments and if necessary retransmissions to ensure that all link state packets are successfully transferred to each neighboring router. Thanks to reliable flooding, all routers store in their LSDB the most recent LSP sent by each router in the network. By combining the received LSPs with its own LSP, each router can build a graph that represents the entire network topology.
6 years ago
User avatar None

Source string added
Flooding allows LSPs to be distributed to all routers inside the network without relying on routing tables. In the example above, the LSP sent by router `E` is likely to be sent twice on some links in the network. For example, routers `B` and `C` receive `E`'s LSP at almost the same time and forward it over the `B-C` link. To avoid sending the same LSP twice on each link, a possible solution is to slightly change the pseudo-code above so that a router waits for some random time before forwarding a LSP on each link. The drawback of this solution is that the delay to flood an LSP to all routers in the network increases. In practice, routers immediately flood the LSPs that contain new information (e.g. addition or removal of a link) and delay the flooding of refresh LSPs (i.e. LSPs that contain exactly the same information as the previous LSP originating from this router) [FFEB2005]_.
6 years ago
User avatar None

Source string added
Flooding is illustrated in the figure below. By exchanging HELLO messages, each router learns its direct neighbors. For example, router `E` learns that it is directly connected to routers `D`, `B` and `C`. Its first LSP has sequence number `0` and contains the directed links `E->D`, `E->B` and `E->C`. Router `E` sends its LSP on all its links and routers `D`, `B` and `C` insert the LSP in their LSDB and forward it over their other links.
6 years ago
Browse all translation changes