PK H}X cnp3-ebook/glossary-1/fr.tbx
Translate Toolkit
PK$xz PK H}X 6 cnp3-ebook/index/locale/fr/LC_MESSAGES/bibliography.po# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2019 Olivier Bonaventure
# This file is distributed under the same license as the Computer networking
# : Principles, Protocols and Practice package.
# FIRST AUTHOR , 2019.
#
msgid ""
msgstr ""
"Project-Id-Version: Computer networking : Principles, Protocols and Practice "
"3\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2019-10-09 12:39+0000\n"
"PO-Revision-Date: 2021-02-16 20:35+0000\n"
"Last-Translator: Philippe D \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n > 1;\n"
"X-Generator: Weblate 3.9.1\n"
"Generated-By: Babel 2.7.0\n"
#: ../../bibliography.rst:5
msgid "Bibliography"
msgstr "Bibliographie"
#: ../../bibliography.rst:7
msgid ""
"Whenever possible, the bibliography includes stable hypertext links to "
"the references cited."
msgstr ""
#: ../../bibliography.rst:9
msgid ""
"LAN/MAN Standards Committee of the IEEE Computer Society. `IEEE Standard "
"for Information Technology - Telecommunications and information exchange "
"between systems - local and metropolitan area networks - specific "
"requirements - Part 11 : Wireless LAN Medium Access Control (MAC) and "
"Physical Layer (PHY) Specifications "
"`_. IEEE, 1999."
msgstr ""
#: ../../bibliography.rst:13
msgid ""
"LAN/MAN Standards Committee of the IEEE Computer Society. IEEE Standard "
"for Information Technology - Telecommunications and information exchange "
"between systems - local and metropolitan area networks - specific "
"requirements - Part 3 : Carrier Sense multiple access with collision "
"detection (CSMA/CD) access method and physical layer specification. IEEE,"
" 2000. Available from http://standards.ieee.org/getieee802/802.3.html"
msgstr ""
#: ../../bibliography.rst:14
msgid ""
"LAN/MAN Standards Committee of the IEEE Computer Society. IEEE Standard "
"for Information technology--Telecommunications and information exchange "
"between systems--Local and metropolitan area networks--Specific "
"requirements--Part 5: Token Ring Access Method and Physical Layer "
"Specification. IEEE, 1998. available from "
"http://standards.ieee.org/getieee802"
msgstr ""
#: ../../bibliography.rst:17
msgid ""
"Androutsellis-Theotokis, S. and Spinellis, D.. .. 2004. `A survey of "
"peer-to-peer content distribution technologies "
"`_. ACM Computing Surveys 36,"
" 4 (December 2004), 335-371."
msgstr ""
#: ../../bibliography.rst:20
msgid ""
"Abramson, N., `THE ALOHA SYSTEM: another alternative for computer "
"communications `_. In "
"Proceedings of the November 17-19, 1970, Fall Joint Computer Conference "
"(Houston, Texas, November 17 - 19, 1970). AFIPS '70 (Fall). ACM, New "
"York, NY, 281-285."
msgstr ""
#: ../../bibliography.rst:24
msgid ""
"Bonomi, F. and Fendick, K.W., `The rate-based flow control framework for"
" the available bit rate ATM service "
"`_, IEEE Network, Mar/Apr 1995, "
"Volume: 9, Issue: 2, pages : 25-39"
msgstr ""
#: ../../bibliography.rst:28
msgid ""
"Beech, W., Nielsen, D., Taylor, J., `AX.25 Link Access Protocol for "
"Amateur Packet Radio `_, version "
"2.2, Revision: July 1998"
msgstr ""
#: ../../bibliography.rst:35
msgid ""
"Bux, W., `Token-ring local-area networks and their performance "
"`_, "
"Proceedings of the IEEE, Vol 77, No 2, p. 238-259, Feb. 1989"
msgstr ""
#: ../../bibliography.rst:36
msgid ""
"Buford, J., Yu, H., Lua, E.K., `P2P Networking and Applications "
"`_, Morgan Kaufmann, 2008"
msgstr ""
#: ../../bibliography.rst:39
msgid ""
"Calvert, K., Donahoo, M., `TCP/IP Sockets in Java : Practical Guide for "
"Programmers `_, Morgan "
"Kaufman, 2008"
msgstr ""
#: ../../bibliography.rst:40
msgid ""
"Chiu, D., Jain, R., `Analysis of the Increase and Decrease Algorithms for"
" Congestion Avoidance in Computer Networks "
"`_, Computer Networks "
"and ISDN Systems Vol 17, pp 1-14, 1989"
msgstr ""
#: ../../bibliography.rst:48
msgid ""
"Clark D., `The Design Philosophy of the DARPA Internet Protocols "
"`_, Computer Communications "
"Review 18:4, August 1988, pp. 106-114"
msgstr ""
#: ../../bibliography.rst:51
msgid ""
"Cohen, D., `On Holy Wars and a Plea for Peace`, IEN 137, April 1980, "
"http://www.ietf.org/rfc/ien/ien137.txt"
msgstr ""
#: ../../bibliography.rst:52
msgid ""
"Donahoo, M., Calvert, K., `TCP/IP Sockets in C: Practical Guide for "
"Programmers `_ , Morgan "
"Kaufman, 2009"
msgstr ""
#: ../../bibliography.rst:62
msgid ""
"Davik, F. Yilmaz, M. Gjessing, S. Uzun, N., `IEEE 802.17 resilient "
"packet ring tutorial `_, "
"IEEE Communications Magazine, Mar 2004, Vol 42, N 3, p. 112-118"
msgstr ""
#: ../../bibliography.rst:63
msgid ""
"Dijkstra, E., `A Note on Two Problems in Connection with Graphs "
"`_. Numerische Mathematik, 1:269- "
"271, 1959"
msgstr ""
#: ../../bibliography.rst:64
msgid ""
"Wikipedia, `Dijkstra's algorithm "
"`_"
msgstr ""
#: ../../bibliography.rst:66
msgid ""
"Fletcher, J., `An Arithmetic Checksum for Serial Transmissions "
"`_, Communications, IEEE "
"Transactions on, Jan. 1982, Vol. 30, N. 1, pp. 247-252"
msgstr ""
#: ../../bibliography.rst:67
msgid ""
"Francois, P., Filsfils, C., Evans, J., and Bonaventure, O., `Achieving "
"sub-second IGP convergence in large IP networks "
"`_. SIGCOMM Computer "
"Communication Review 35, 3 (Jul. 2005), 35-44."
msgstr ""
#: ../../bibliography.rst:68
msgid ""
"Sally Floyd and Van Jacobson. 1993. `Random early detection gateways for "
"congestion avoidance `_. IEEE/ACM "
"Transactions Networking 1, 4 (August 1993), 397-413."
msgstr ""
#: ../../bibliography.rst:72
msgid ""
"Fortz, B. Rexford, J. ,Thorup, M., `Traffic engineering with traditional "
"IP routing protocols `_, "
"IEEE Communication Magazine, October 2002"
msgstr ""
#: ../../bibliography.rst:74
msgid ""
"Feldmeier, D. C., `Fast software implementation of error detection codes "
"`_. IEEE/ACM Transactions "
"Networking 3, 6 (Dec. 1995), 640-651."
msgstr ""
#: ../../bibliography.rst:80
msgid ""
"Gettys, J., Nichols, K., `Bufferbloat: dark buffers in the internet "
"`_. Communications of the ACM"
" 55, no. 1 (2012): 57-65."
msgstr ""
#: ../../bibliography.rst:85
msgid ""
"Garcia-Lunes-Aceves, J., `Loop-Free Routing Using Diffusing Computations "
"`_, IEEE/ACM Transactions on "
"Networking, Vol. 1, No, 1, Feb. 1993"
msgstr ""
#: ../../bibliography.rst:93
msgid ""
"ISO, `Intermediate System to Intermediate System intra-domain routeing "
"information exchange protocol for use in conjunction with the protocol "
"for providing the connectionless-mode network service (ISO 8473) "
"`_"
" , 2002"
msgstr ""
#: ../../bibliography.rst:94
msgid ""
"Jacobson, V., `Congestion avoidance and control "
"`_. In Symposium Proceedings on "
"Communications Architectures and Protocols (Stanford, California, United "
"States, August 16 - 18, 1988). V. Cerf, Ed. SIGCOMM '88. ACM, New York, "
"NY, 314-329."
msgstr ""
#: ../../bibliography.rst:95
msgid ""
"Jain, R., `Congestion control in computer networks : Issues and trends "
"`_, IEEE Network Magazine, May 1990,"
" pp. 24-30"
msgstr ""
#: ../../bibliography.rst:97
msgid ""
"Jung, J., Sit, E., Balakrishnan, H., and Morris, R. 2002. `DNS "
"performance and the effectiveness of caching "
"`_. IEEE/ACM Transactions "
"Networking 10, 5 (Oct. 2002), 589-603."
msgstr ""
#: ../../bibliography.rst:99
msgid ""
"Kerrisk, M., `The Linux Programming Interface "
"`_, No Starch Press, 2010"
msgstr ""
#: ../../bibliography.rst:103
msgid ""
"Karn, P., Price, H., Diersing, R., `Packet radio in amateur service "
"`_, IEEE Journal on "
"Selected Areas in Communications, 3, May, 1985"
msgstr ""
#: ../../bibliography.rst:106
msgid ""
"Kung, N.T. Morris, R., `Credit-based flow control for ATM networks "
"`_, IEEE Network, Mar/Apr 1995, "
"Volume: 9, Issue: 2, pages: 40-48"
msgstr ""
#: ../../bibliography.rst:107
msgid ""
"Kleinrock, L., Tobagi, F., `Packet Switching in Radio Channels: Part I--"
"Carrier Sense Multiple-Access Modes and their Throughput-Delay "
"Characteristics `_, IEEE "
"Transactions on Communications, Vol. COM-23, No. 12, pp. 1400-1416, "
"December 1975."
msgstr ""
#: ../../bibliography.rst:109
msgid ""
"Khanna, A. and Zinky, J. 1989. `The revised ARPANET routing metric "
"`_. SIGCOMM Computer "
"Communication Review 19, 4 (Aug. 1989), 45-56."
msgstr ""
#: ../../bibliography.rst:114
msgid ""
"Eng Keong Lua, Crowcroft, J., Pias, M., Sharma, R., Lim, S., `A survey "
"and comparison of peer-to-peer overlay network schemes "
"`_, Communications Surveys"
" & Tutorials, IEEE, Volume: 7 , Issue: 2, 2005, pp. 72-93"
msgstr ""
#: ../../bibliography.rst:117
msgid ""
"Leffler, S., Fabry, R., Joy, W., Lapsley, P., Miller, S., Torek, C., `An "
"Advanced 4.4BSD Interprocess Communication Tutorial "
"`_, 4.4 BSD "
"Programmer's Supplementary Documentation"
msgstr ""
#: ../../bibliography.rst:120
msgid ""
"Leboudec, J.-Y., `Rate Adaptation Congestion Control and Fairness : a "
"tutorial `_, Dec. 2008"
msgstr ""
#: ../../bibliography.rst:121
msgid ""
"McKeown N, Anderson T, Balakrishnan H, Parulkar G, Peterson L, Rexford J,"
" Shenker S, Turner J., `OpenFlow: enabling innovation in campus networks "
"`_. ACM SIGCOMM Computer "
"Communication Review. 2008 Mar 31;38(2):69-74."
msgstr ""
#: ../../bibliography.rst:126
msgid ""
"McQuillan, J. M., Richer, I., and Rosen, E. C., `An overview of the new "
"routing algorithm for the ARPANET "
"`_. In Proceedings of the Sixth"
" Symposium on Data Communications (Pacific Grove, California, United "
"States, November 27 - 29, 1979). SIGCOMM '79. ACM, New York, NY, 63-68."
msgstr ""
#: ../../bibliography.rst:127
msgid ""
"McQuillan, J.M., Richer, I., Rosen, E., `The New Routing Algorithm for "
"the ARPANET `_ "
"Communications, IEEE Transactions on , vol.28, no.5, pp.711,719, May 1980"
msgstr ""
#: ../../bibliography.rst:132
msgid ""
"Metcalfe R., Boggs, D., `Ethernet: Distributed packet-switching for local"
" computer networks `_. "
"Communications of the ACM, 19(7):395--404, 1976."
msgstr ""
#: ../../bibliography.rst:133
msgid ""
"Mills, D.L., `Computer Network Time Synchronization: the Network Time "
"Protocol `_. CRC Press, "
"March 2006, 304 pp."
msgstr ""
#: ../../bibliography.rst:147
msgid ""
"Rago, S., `UNIX System V network programming "
"`_, Addison Wesley, 1993"
msgstr ""
#: ../../bibliography.rst:308
msgid ""
"Ramakrishnan, K. K. and Jain, R., `A binary feedback scheme for "
"congestion avoidance in computer networks with a connectionless network "
"layer `_. SIGCOMM Computer "
"Communication Review 25, 1 (Jan. 1995), 138-156."
msgstr ""
#: ../../bibliography.rst:311
msgid ""
"Ramakrishnan, K.K. and Henry Yang, `The Ethernet Capture Effect: Analysis"
" and Solution "
"`_, "
"Proceedings of IEEE 19th Conference on Local Computer Networks, MN, Oct. "
"1994."
msgstr ""
#: ../../bibliography.rst:312
msgid ""
"Roberts, L., `ALOHA packet system with and without slots and capture "
"`_. SIGCOMM Computer "
"Communication Review 5, 2 (Apr. 1975), 28-42."
msgstr ""
#: ../../bibliography.rst:313
msgid ""
"Ross, F., `An overview of FDDI: The fiber distributed data interface "
"`_, IEEE J. Selected Areas in Comm.,"
" vol. 7, no. 7, pp. 1043-1051, Sept. 1989"
msgstr ""
#: ../../bibliography.rst:314
msgid ""
"Russell A., `Rough Consensus and Running Code and the Internet-OSI "
"Standards War `_, IEEE Annals of"
" the History of Computing, July-September 2006"
msgstr ""
#: ../../bibliography.rst:317
msgid ""
"Sechrest, S., `An Introductory 4.4BSD Interprocess Communication Tutorial"
" `_, 4.4BSD "
"Programmer's Supplementary Documentation"
msgstr ""
#: ../../bibliography.rst:318
msgid ""
"Scheifler, R., Gettys, J., `X Window System: The Complete Reference to "
"Xlib "
"`_,"
" X Protocol, ICCCM, XLFD, X Version 11, Release 4, Digital Press"
msgstr ""
#: ../../bibliography.rst:319
msgid ""
"Stone, J., Greenwald, M., Partridge, C., and Hughes, J., `Performance of "
"checksums and CRC's over real data "
"`_. IEEE/ACM Transactions "
"Networking 6, 5 (Oct. 1998), 529-543."
msgstr ""
#: ../../bibliography.rst:323
msgid ""
"Semke, J., Mahdavi, J., and Mathis, M., `Automatic TCP buffer tuning "
"`_. SIGCOMM Computer "
"Communication Review 28, 4 (Oct. 1998), 315-323."
msgstr ""
#: ../../bibliography.rst:329
msgid ""
"Stevens R. and Fenner, and Rudoff, A., `UNIX Network Programming: The "
"sockets networking API `_,"
" Addison Wesley, 2004"
msgstr ""
#: ../../bibliography.rst:330
msgid ""
"Sklower, K. 1989. `Improving the efficiency of the OSI checksum "
"calculation `_. SIGCOMM Computer "
"Communication Review 19, 5 (Oct. 1989), 32-43."
msgstr ""
#: ../../bibliography.rst:335
msgid ""
"Stevens, R., `UNIX Network Programming, Volume 1, Second Edition: "
"Networking APIs: Sockets and XTI "
"`_, Prentice Hall, 1998"
msgstr ""
#: ../../bibliography.rst:338
msgid ""
"Shreedhar and G. Varghese. `Efficient fair queueing using deficit round "
"robin `_ SIGCOMM Computer "
"Communication Review 25, 4 (October 1995), 231-242."
msgstr ""
#: ../../bibliography.rst:350
msgid ""
"Williams, R. `A painless guide to CRC error detection algorithms`, August"
" 1993, unpublished manuscript, "
"https://web.archive.org/web/20060101004751/http://www.ross.net/crc/download/crc_v3.txt"
msgstr ""
#: ../../bibliography.rst:353
msgid ""
"ITU-T, recommendation X.200, `Open Systems Interconnection - Model and "
"Notation `_, 1994"
msgstr ""
#: ../../bibliography.rst:357
msgid ""
"Zimmermann, H., `OSI Reference Model - The ISO Model of Architecture for"
" Open Systems Interconnection "
"`_, IEEE Transactions on "
"Communications, vol. 28, no. 4, April 1980, pp. 425 - 432."
msgstr ""
#: ../../bibliography.rst:358
msgid ""
"Zakon, R., `Hobbes Internet Timeline "
"`_, online, "
"https://www.zakon.org/robert/internet/timeline/"
msgstr ""
#: ../../bibliography.rst:359
msgid ""
"Zheng, X., `Phishing with Unicode Domains "
"`_, April 14, 2017, "
"https://www.xudongz.com/blog/2017/idn-phishing/"
msgstr ""
#~ msgid ""
#~ "LAN/MAN Standards Committee of the IEEE"
#~ " Computer Society, `IEEE Standard for "
#~ "Local and metropolitan area networks "
#~ "Media Access Control (MAC) Bridges "
#~ "`_ "
#~ ", IEEE Std 802.1DTM-2004, 2004,"
#~ msgstr ""
#~ msgid ""
#~ "LAN/MAN Standards Committee of the IEEE"
#~ " Computer Society, `IEEE Standard for "
#~ "Local and metropolitan area networks— "
#~ "Virtual Bridged Local Area Networks "
#~ "`_, "
#~ "2005,"
#~ msgstr ""
#~ msgid ""
#~ "IEEE 802.2-1998 (ISO/IEC 8802-2:1998), IEEE"
#~ " Standard for Information technology--"
#~ "Telecommunications and information exchange "
#~ "between systems--Local and metropolitan "
#~ "area networks--Specific requirements--Part "
#~ "2: Logical Link Control. Available from"
#~ " http://standards.ieee.org/getieee802/802.2.html"
#~ msgstr ""
#~ msgid ""
#~ "IEEE, Std 802-2001 : IEEE Standard "
#~ "for Local and Metropolitan Area "
#~ "Networks: Overview and Architecture, Available"
#~ " from "
#~ "http://standards.ieee.org/getieee802/download/802-2001.pdf"
#~ msgstr ""
#~ msgid ""
#~ "Augustin, B., Cuvellier, X., Orgogozo, "
#~ "B., Viger, F., Friedman, T., Latapy, "
#~ "M., Magnien, C., Teixeira, R., `Avoiding"
#~ " traceroute anomalies with Paris traceroute"
#~ " `_, Internet "
#~ "Measurement Conference, October 2006, See "
#~ "also http://www.paris-traceroute.net/"
#~ msgstr ""
#~ msgid ""
#~ "Androutsellis-Theotokis, S. and Spinellis, "
#~ "D.. 2004. `A survey of peer-to-"
#~ "peer content distribution technologies "
#~ "`_. ACM "
#~ "Comput. Surv. 36, 4 (December 2004), "
#~ "335-371."
#~ msgstr ""
#~ msgid ""
#~ "Labovitz, C., Iekel-Johnson, S., "
#~ "McPherson, D., Oberheide, J. and "
#~ "Jahanian, F., `Internet inter-domain "
#~ "traffic `_. In"
#~ " Proceedings of the ACM SIGCOMM 2010"
#~ " conference on SIGCOMM (SIGCOMM '10). "
#~ "ACM, New York, NY, USA, 75-86."
#~ msgstr ""
#~ msgid ""
#~ "Arlitt, M. and Williamson, C. 2005. "
#~ "`An analysis of TCP reset behaviour "
#~ "on the internet "
#~ "`_. SIGCOMM "
#~ "Comput. Commun. Rev. 35, 1 (Jan. "
#~ "2005), 37-44."
#~ msgstr ""
#~ msgid ""
#~ "Berners-Lee, T., `Information Management: "
#~ "A Proposal "
#~ "`_, March "
#~ "1989"
#~ msgstr ""
#~ msgid ""
#~ "Baran, P., `On distributed communications "
#~ "series`, http://www.rand.org/about/history/baran.list.html,"
#~ msgstr ""
#~ msgid ""
#~ "Biondi, P. and A. Ebalard, `IPv6 "
#~ "Routing Header Security `_, CanSecWest Security "
#~ "Conference 2007, April 2007."
#~ msgstr ""
#~ msgid ""
#~ "Bonomi, F. and Fendick, K.W., `The "
#~ "rate-based flow control framework for"
#~ " the available bit rate ATM service"
#~ " `_, IEEE Network,"
#~ " Mar/Apr 1995, Volume: 9, Issue: 2,"
#~ " pages : 25-39"
#~ msgstr ""
#~ msgid ""
#~ "Bertsekas, D., Gallager, G., `Data "
#~ "networks `_, "
#~ "second edition, Prentice Hall, 1992"
#~ msgstr ""
#~ msgid ""
#~ "Bhatia, M., Manral, V., Ohara, Y., "
#~ "`IS-IS and OSPF Difference Discussions"
#~ " `_, work in progress, "
#~ "Internet draft, Jan. 2006"
#~ msgstr ""
#~ msgid ""
#~ "Bagnulo, M., Matthews, P., van Beijnum,"
#~ " I., `NAT64: Network Address and "
#~ "Protocol Translation from IPv6 Clients "
#~ "to IPv4 Servers `_, "
#~ "Internet draft, work in progress, "
#~ "October 2009,"
#~ msgstr ""
#~ msgid ""
#~ "Brakmo, L. S., O'Malley, S. W., "
#~ "and Peterson, L. L., `TCP Vegas: "
#~ "new techniques for congestion detection "
#~ "and avoidance "
#~ "`_. In "
#~ "Proceedings of the Conference on "
#~ "Communications Architectures, Protocols and "
#~ "Applications (London, United Kingdom, August"
#~ " 31 - September 02, 1994). SIGCOMM"
#~ " '94. ACM, New York, NY, 24-35."
#~ msgstr ""
#~ msgid ""
#~ "Benvenuti, C., `Understanding Linux Network"
#~ " Internals `_,"
#~ " O'Reilly Media, 2005"
#~ msgstr ""
#~ msgid ""
#~ "Bormann, C., Hoffman, P., `Concise "
#~ "Binary Object Representation (CBOR) "
#~ "`_, "
#~ "Internet draft, draft-bormann-cbor-09, "
#~ "work in progress, 2013"
#~ msgstr ""
#~ msgid ""
#~ "Barrett, R. Silverman, R. Byrnes, `SSH:"
#~ " The Secure Shell (The Definitive "
#~ "Guide) `_, "
#~ "O'Reilly 2005 (2nd edition)."
#~ msgstr ""
#~ msgid ""
#~ "Bush, V. `As we may think "
#~ "`_ The Atlantic Monthly "
#~ "176 (July 1945), pp. 101–108"
#~ msgstr ""
#~ msgid ""
#~ "Bush, R., `FidoNet: technology, tools, "
#~ "and history `_."
#~ " Commun. ACM 36, 8 (Aug. 1993), "
#~ "31-35."
#~ msgstr ""
#~ msgid ""
#~ "Cheswick, William R., Bellovin, Steven "
#~ "M., Rubin, Aviel D., `Firewalls and "
#~ "internet security - Second edition - "
#~ "Repelling the Wily Hacker "
#~ "`_, "
#~ "Addison-Wesley 2003"
#~ msgstr ""
#~ msgid ""
#~ "Cardwell, N., Cheng, Y., Brakmo, L., "
#~ "Mathis, M., Raghavan, B., Dukkipati, N.,"
#~ " Chu, H., Terzis, A., and Herbert,"
#~ " T., `packetdrill: scriptable network stack"
#~ " testing, from sockets to packets "
#~ "`_. In Proceedings of the 2013"
#~ " USENIX conference on Annual Technical "
#~ "Conference (USENIX ATC'13). USENIX "
#~ "Association, Berkeley, CA, USA, 213-218."
#~ msgstr ""
#~ msgid ""
#~ "Chiu, D., Jain, R., `Analysis of "
#~ "the Increase and Decrease Algorithms for"
#~ " Congestion Avoidance in Computer Networks"
#~ " `_, Computer"
#~ " Networks and ISDN Systems Vol 17,"
#~ " pp 1-14, 1989"
#~ msgstr ""
#~ msgid ""
#~ "Cerf, V., Kahn, R., `A Protocol "
#~ "for Packet Network Intercommunication "
#~ "`_, IEEE "
#~ "Transactions on Communications, May 1974"
#~ msgstr ""
#~ msgid ""
#~ "Gont, F., `Security Assessment of the"
#~ " Transmission Control Protocol (TCP) "
#~ "`_,Security Assessment of the "
#~ "Transmission Control Protocol (TCP), Internet"
#~ " draft, work in progress, Jan. 2011"
#~ msgstr ""
#~ msgid ""
#~ "Chi, Y., Oliveira, R., Zhang, L., "
#~ "`Cyclops: The Internet AS-level "
#~ "Observatory `_, "
#~ "ACM SIGCOMM Computer Communication Review "
#~ "(CCR), October 2008"
#~ msgstr ""
#~ msgid ""
#~ "Carr, B., Sury, O., Palet Martinez, "
#~ "J., Davidson, A., Evans, R., Yilmaz, "
#~ "F., Wijte, Y., `IPv6 Address Allocation"
#~ " and Assignment Policy "
#~ "`_, RIPE "
#~ "document ripe-481, September 2009"
#~ msgstr ""
#~ msgid ""
#~ "Crane, R., Taft, E., `Practical "
#~ "considerations in Ethernet local network "
#~ "design "
#~ "`_,"
#~ " Proc. of the 13th Hawaii "
#~ "International Conference on Systems Sciences,"
#~ " Honolulu, January, 1980, pp. 166--"
#~ "174"
#~ msgstr ""
#~ msgid ""
#~ "Cheshire, S., `Connect-By-Name for "
#~ "IPv6 `_,"
#~ " presentation at IETF 79th, November "
#~ "2010"
#~ msgstr ""
#~ msgid ""
#~ "Cheswick, B., `An Evening with Berferd"
#~ " In Which a Cracker is Lured, "
#~ "Endured, and Studied "
#~ "`_, Proc. "
#~ "Winter USENIX Conference, 1990, pp. "
#~ "163-174"
#~ msgstr ""
#~ msgid ""
#~ "Clark D., `The Design Philosophy of "
#~ "the DARPA Internet Protocols "
#~ "`_, Computer "
#~ "Communications Review 18:4, August 1988, "
#~ "pp. 106-114"
#~ msgstr ""
#~ msgid ""
#~ "Comer, D., `Internetworking with TCP/IP "
#~ ": principles, protocols & architecture`, "
#~ "Prentice Hall, 1988"
#~ msgstr ""
#~ msgid ""
#~ "Comer D., `Internetworking With TCP/IP :"
#~ " Design Implementation and Internals`, "
#~ "Prentice Hall, 1991"
#~ msgstr ""
#~ msgid ""
#~ "Diffie, W., Hellman, M., `New directions"
#~ " in cryptography`, in Information Theory,"
#~ " IEEE Transactions on , vol.22, no.6,"
#~ " pp.644-654, Nov 1976, "
#~ "http://dx.doi.org/10.1109/TIT.1976.1055638"
#~ msgstr ""
#~ msgid ""
#~ "Digital, Intel, Xerox, `The Ethernet: a"
#~ " local area network: data link layer"
#~ " and physical layer specifications "
#~ "`_. SIGCOMM "
#~ "Comput. Commun. Rev. 11, 3 (Jul. "
#~ "1981), 20-66."
#~ msgstr ""
#~ msgid ""
#~ "Dimitropoulos, X., Krioukov, D., Fomenkov, "
#~ "M., Huffaker, B., Hyun, Y., Claffy, "
#~ "K., Riley, G., `AS Relationships: "
#~ "Inference and Validation "
#~ "`_, ACM "
#~ "SIGCOMM Computer Communication Review (CCR),"
#~ " Jan. 2007"
#~ msgstr ""
#~ msgid ""
#~ "Dalal, Y. K. and Printis, R. S.,"
#~ " `48-bit absolute internet and Ethernet "
#~ "host numbers `_."
#~ " In Proceedings of the Seventh "
#~ "Symposium on Data Communications (Mexico "
#~ "City, Mexico, October 27 - 29, "
#~ "1981). SIGCOMM '81. ACM, New York, "
#~ "NY, 240-245."
#~ msgstr ""
#~ msgid ""
#~ "Dukkipati, N., Refice, T., Cheng, Y.,"
#~ " Chu, J., Herbert, T., Agarwal, A.,"
#~ " Jain, A., Sutin, N., `An Argument"
#~ " for Increasing TCP's Initial Congestion"
#~ " Window `_, "
#~ "ACM SIGCOMM Computer Communications Review,"
#~ " vol. 40 (2010), pp. 27-33"
#~ msgstr ""
#~ msgid ""
#~ "Dubuisson, `ASN.1 : Communication between "
#~ "Heterogeneous Systems `, "
#~ "Morgan Kauffman, 2000"
#~ msgstr ""
#~ msgid ""
#~ "Dunkels, A., `Full TCP/IP for 8-Bit "
#~ "Architectures `_. "
#~ "In Proceedings of the first "
#~ "international conference on mobile "
#~ "applications, systems and services (MOBISYS"
#~ " 2003), San Francisco, May 2003."
#~ msgstr ""
#~ msgid ""
#~ "Daemen, J., Rijmen, V., `The Design "
#~ "of Rijndael: AES – The Advanced "
#~ "Encryption Standard "
#~ "`_ Springer, "
#~ "2002. ISBN 3-540-42580-2."
#~ msgstr ""
#~ msgid ""
#~ "Donnet, B. and Friedman, T., `Internet"
#~ " Topology Discovery: a Survey "
#~ "`_. IEEE Communications Surveys"
#~ " and Tutorials, 9(4):2-15, December 2007"
#~ msgstr ""
#~ msgid ""
#~ "Davik, F. Yilmaz, M. Gjessing, S. "
#~ "Uzun, N., `IEEE 802.17 resilient packet"
#~ " ring tutorial "
#~ "`_, IEEE "
#~ "Communications Magazine, Mar 2004, Vol "
#~ "42, N 3, p. 112-118"
#~ msgstr ""
#~ msgid ""
#~ "Dijkstra, E., `A Note on Two "
#~ "Problems in Connection with Graphs "
#~ "`_. Numerische "
#~ "Mathematik, 1:269- 271, 1959"
#~ msgstr ""
#~ msgid ""
#~ "ANSI. `Information systems - Fiber "
#~ "Distributed Data Interface (FDDI) - "
#~ "token ring media access control (MAC)`."
#~ " ANSI X3.139-1987 (R1997), 1997"
#~ msgstr ""
#~ msgid ""
#~ "Fletcher, J., `An Arithmetic Checksum "
#~ "for Serial Transmissions "
#~ "`_, Communications,"
#~ " IEEE Transactions on, Jan. 1982, "
#~ "Vol. 30, N. 1, pp. 247-252"
#~ msgstr ""
#~ msgid ""
#~ "Francois, P., Filsfils, C., Evans, J.,"
#~ " and Bonaventure, O., `Achieving sub-"
#~ "second IGP convergence in large IP "
#~ "networks `_. "
#~ "SIGCOMM Comput. Commun. Rev. 35, 3 "
#~ "(Jul. 2005), 35-44."
#~ msgstr ""
#~ msgid ""
#~ "Sally Floyd and Van Jacobson. 1993. "
#~ "`Random early detection gateways for "
#~ "congestion avoidance "
#~ "`_. IEEE/ACM Trans."
#~ " Netw. 1, 4 (August 1993), 397-413."
#~ msgstr ""
#~ msgid ""
#~ "Floyd, S., and Jacobson, V., `The "
#~ "Synchronization of Periodic Routing Messages"
#~ " `_, IEEE/ACM "
#~ "Transactions on Networking, V.2 N.2, p."
#~ " 122-136, April 1994"
#~ msgstr ""
#~ msgid ""
#~ "Freier, A., Karlton, P., Kocher, C., "
#~ "`The SSL Protocol Version 3.0`, Internet"
#~ " draft, November 1996, "
#~ "https://tools.ietf.org/html/draft-ietf-tls-ssl-"
#~ "version3-00"
#~ msgstr ""
#~ msgid ""
#~ "Fuller, V., Lear, E., Meyer, D., "
#~ "`Reclassifying 240/4 as usable unicast "
#~ "address space `_, Internet draft, March "
#~ "2008, workin progress"
#~ msgstr ""
#~ msgid ""
#~ "Fortz, B. Rexford, J. ,Thorup, M., "
#~ "`Traffic engineering with traditional IP "
#~ "routing protocols "
#~ "`_, IEEE "
#~ "Communication Magazine, October 2002"
#~ msgstr ""
#~ msgid ""
#~ "Theodore Faber, Joe Touch, and Wei "
#~ "Yue, `The TIME-WAIT state in TCP"
#~ " and Its Effect on Busy Servers "
#~ "`_, Proc. "
#~ "Infocom '99, pp. 1573"
#~ msgstr ""
#~ msgid ""
#~ "Feldmeier, D. C., `Fast software "
#~ "implementation of error detection codes "
#~ "`_. IEEE/ACM Trans."
#~ " Netw. 3, 6 (Dec. 1995), 640-651."
#~ msgstr ""
#~ msgid ""
#~ "Govindan, R., Alaettinoglu, C., Varadhan, "
#~ "K., Estrin, D., `An Architecture for "
#~ "Stable, Analyzable Internet Routing "
#~ "`_, IEEE Network "
#~ "Magazine, Vol. 13, No. 1, pp. 29"
#~ "--35, January 1999"
#~ msgstr ""
#~ msgid ""
#~ "Grier, D., Campbell, M., `A social "
#~ "history of Bitnet and Listserv "
#~ "`_, "
#~ "1985-1991, Annals of the History of "
#~ "Computing, IEEE, Volume 22, Issue 2, "
#~ "Apr-Jun 2000, pp. 32 - 41"
#~ msgstr ""
#~ msgid ""
#~ "Genilloud, G., `X.400 MHS: first steps"
#~ " towards an EDI communication standard "
#~ "`_. SIGCOMM "
#~ "Comput. Commun. Rev. 20, 2 (Apr. "
#~ "1990), 72-86."
#~ msgstr ""
#~ msgid ""
#~ "Greenwald, `No Place to Hide: Edward "
#~ "Snowden, the NSA, and the U.S. "
#~ "Surveillance State "
#~ "`_, Metropolitan"
#~ " books, 2014"
#~ msgstr ""
#~ msgid ""
#~ "Gao, L., Griffin, T., Rexford, J., "
#~ "`Inherently safe backup routing with BGP"
#~ " `_, Proc. "
#~ "IEEE INFOCOM, April 2001"
#~ msgstr ""
#~ msgid ""
#~ "Gao, L., Rexford, J., `Stable Internet"
#~ " routing without global coordination "
#~ "`_, IEEE/ACM "
#~ "Transactions on Networking, December 2001, "
#~ "pp. 681-692"
#~ msgstr ""
#~ msgid ""
#~ "Griffin, T. G., Shepherd, F. B., "
#~ "and Wilfong, G., `The stable paths "
#~ "problem and interdomain routing "
#~ "`_. IEEE/ACM Trans."
#~ " Netw. 10, 2 (Apr. 2002), 232-243"
#~ msgstr ""
#~ msgid ""
#~ "Griffin, T. G. and Wilfong, G., "
#~ "`An analysis of BGP convergence "
#~ "properties `_. "
#~ "SIGCOMM Comput. Commun. Rev. 29, 4 "
#~ "(Oct. 1999), 277-288."
#~ msgstr ""
#~ msgid ""
#~ "Griffin, T. and Wilfong, G. T., "
#~ "`Analysis of the MED Oscillation Problem"
#~ " in BGP "
#~ "`_. In "
#~ "Proceedings of the 10th IEEE "
#~ "international Conference on Network Protocols"
#~ " (November 12 - 15, 2002). ICNP. "
#~ "IEEE Computer Society, Washington, DC, "
#~ "90-99"
#~ msgstr ""
#~ msgid ""
#~ "Garcia-Lunes-Aceves, J., `Loop-Free "
#~ "Routing Using Diffusing Computations "
#~ "`_, IEEE/ACM "
#~ "Transactions on Networking, Vol. 1, No,"
#~ " 1, Feb. 1993"
#~ msgstr ""
#~ msgid ""
#~ "Gast, M., `802.11 Wireless Networks :"
#~ " The Definitive Guide "
#~ "`_, "
#~ "O'Reilly, 2002"
#~ msgstr ""
#~ msgid ""
#~ "Gill, V. , `Lack of Priority "
#~ "Queuing Considered Harmful "
#~ "`_, ACM Queue,"
#~ " December 2004"
#~ msgstr ""
#~ msgid ""
#~ "Goralski, W., `The Illustrated network :"
#~ " How TCP/IP works in a modern "
#~ "network `_, "
#~ "Morgan Kaufmann, 2009"
#~ msgstr ""
#~ msgid ""
#~ "Huffaker, B., Fomenkov, M., Plummer, D.,"
#~ " Moore, D., Claffy, K., `Distance "
#~ "Metrics in the Internet "
#~ "`_, "
#~ "Presented at the IEEE International "
#~ "Telecommunications Symposium (ITS) in 2002."
#~ msgstr ""
#~ msgid ""
#~ "Ha, S., Rhee, I., and Xu, L., "
#~ "`CUBIC: a new TCP-friendly high-"
#~ "speed TCP variant "
#~ "`_. SIGOPS "
#~ "Oper. Syst. Rev. 42, 5 (Jul. "
#~ "2008), 64-74."
#~ msgstr ""
#~ msgid ""
#~ "Hogg, S. Vyncke, E., `IPv6 Security "
#~ "`_, "
#~ "Cisco Press, 2008"
#~ msgstr ""
#~ msgid ""
#~ "Ishihara, K., Mukai, M., Hiromi, R., "
#~ "Mawatari, M., `Packet Filter and Route"
#~ " Filter Recommendation for IPv6 at "
#~ "xSP routers `_, 2013"
#~ msgstr ""
#~ msgid ""
#~ "Jain, R., `Congestion control in "
#~ "computer networks : Issues and trends"
#~ " `_, IEEE Network"
#~ " Magazine, May 1990, pp. 24-30"
#~ msgstr ""
#~ msgid ""
#~ "Jesup, R., Loreto, S., Tuexen, M., "
#~ "`RTCWeb Data Channels `_, "
#~ "Internet draft, draft-ietf-rtcweb-"
#~ "data-channel, work in progress, 2013"
#~ msgstr ""
#~ msgid ""
#~ "Jung, J., Sit, E., Balakrishnan, H., "
#~ "and Morris, R. 2002. `DNS performance"
#~ " and the effectiveness of caching "
#~ "`_. IEEE/ACM "
#~ "Trans. Netw. 10, 5 (Oct. 2002), "
#~ "589-603."
#~ msgstr ""
#~ msgid ""
#~ "JSON-RPC Working group, `JSON-RPC "
#~ "2.0 Specification "
#~ "`_, available on "
#~ "http://www.jsonrpc.org, 2010"
#~ msgstr ""
#~ msgid ""
#~ "Kent, C. A. and Mogul, J. C., "
#~ "`Fragmentation considered harmful "
#~ "`_. SIGCOMM "
#~ "Comput. Commun. Rev. 25, 1 (Jan. "
#~ "1995), 75-87."
#~ msgstr ""
#~ msgid ""
#~ "Kühlewind, M., Neuner, S., Trammell, B.,"
#~ " `On the state of ECN and TCP"
#~ " Options on the Internet "
#~ "`_."
#~ " Proceedings of the 14th Passive and"
#~ " Active Measurement conference (PAM 2013),"
#~ " Hong Kong, March 2013"
#~ msgstr ""
#~ msgid ""
#~ "Karn, P. and Partridge, C., `Improving"
#~ " round-trip time estimates in "
#~ "reliable transport protocols "
#~ "`_. ACM Trans."
#~ " Comput. Syst. 9, 4 (Nov. 1991), "
#~ "364-373."
#~ msgstr ""
#~ msgid ""
#~ "Karn, P., Price, H., Diersing, R., "
#~ "`Packet radio in amateur service "
#~ "`_, IEEE "
#~ "Journal on Selected Areas in "
#~ "Communications, 3, May, 1985"
#~ msgstr ""
#~ msgid ""
#~ "Kaufman, C., Perlman, R., and "
#~ "Sommerfeld, B. `DoS protection for "
#~ "UDP-based protocols "
#~ "`_. In "
#~ "Proceedings of the 10th ACM Conference"
#~ " on Computer and Communications Security"
#~ " (Washington D.C., USA, October 27 -"
#~ " 30, 2003). CCS '03. ACM, New "
#~ "York, NY, 2-7."
#~ msgstr ""
#~ msgid ""
#~ "Kaufman, C., Perlman, R., Speciner, M.,"
#~ " `Network Security : Private communication"
#~ " in a public world "
#~ "`_, 2nd "
#~ "edition, Prentice Hall, 2002"
#~ msgstr ""
#~ msgid ""
#~ "Kung, N.T. Morris, R., `Credit-based"
#~ " flow control for ATM networks "
#~ "`_, IEEE Network, "
#~ "Mar/Apr 1995, Volume: 9, Issue: 2, "
#~ "pages: 40-48"
#~ msgstr ""
#~ msgid ""
#~ "Kleinrock, L., Tobagi, F., `Packet "
#~ "Switching in Radio Channels: Part I--"
#~ "Carrier Sense Multiple-Access Modes and"
#~ " their Throughput-Delay Characteristics "
#~ "`_, IEEE "
#~ "Transactions on Communications, Vol. COM-23,"
#~ " No. 12, pp. 1400-1416, December "
#~ "1975."
#~ msgstr ""
#~ msgid ""
#~ "Katz, D., Ward, D., `Bidirectional "
#~ "Forwarding Detection`, :rfc:`5880`, June 2010"
#~ msgstr ""
#~ msgid ""
#~ "Khanna, A. and Zinky, J. 1989. "
#~ "`The revised ARPANET routing metric "
#~ "`_. SIGCOMM "
#~ "Comput. Commun. Rev. 19, 4 (Aug. "
#~ "1989), 45-56."
#~ msgstr ""
#~ msgid ""
#~ "Kurose J. and Ross K., `Computer "
#~ "networking : a top-down approach "
#~ "featuring the Internet "
#~ "`_, "
#~ "Addison-Wesley, 2009"
#~ msgstr ""
#~ msgid ""
#~ "Lamport, L., `Password authentication with "
#~ "insecure communication "
#~ "`_. Commun. ACM"
#~ " 24, 11 (November 1981), 770-772."
#~ msgstr ""
#~ msgid ""
#~ "Licklider, J., `Memorandum For Members "
#~ "and Affiliates of the Intergalactic "
#~ "Computer Network "
#~ "`_, "
#~ "1963"
#~ msgstr ""
#~ msgid ""
#~ "Leiner, B. M., Cerf, V. G., Clark,"
#~ " D. D., Kahn, R. E., Kleinrock, "
#~ "L., Lynch, D. C., Postel, J., "
#~ "Roberts, L. G., and Wolff, S., `A"
#~ " brief history of the internet "
#~ "`_. SIGCOMM "
#~ "Comput. Commun. Rev. 39, 5 (Oct. "
#~ "2009), 22-31."
#~ msgstr ""
#~ msgid ""
#~ "Eng Keong Lua, Crowcroft, J., Pias, "
#~ "M., Sharma, R., Lim, S., `A survey"
#~ " and comparison of peer-to-peer "
#~ "overlay network schemes "
#~ "`_, Communications"
#~ " Surveys & Tutorials, IEEE, Volume: 7"
#~ " , Issue: 2, 2005, pp. 72-93"
#~ msgstr ""
#~ msgid ""
#~ "Leroy, D. and O. Bonaventure, `Preparing"
#~ " network configurations for IPv6 "
#~ "renumbering `_, International of Network "
#~ "Management, 2009"
#~ msgstr ""
#~ msgid ""
#~ "Lakshman, Arnold Neidhardt, and Teunis "
#~ "J. Ott. 1996. `The drop from front"
#~ " strategy in TCP and in TCP "
#~ "over ATM `_."
#~ " INFOCOM'96, Vol. 3. IEEE Computer "
#~ "Society, Washington, DC, USA, 1242-1250."
#~ msgstr ""
#~ msgid ""
#~ "Lamport, L., Shostak, R., and Pease, "
#~ "M., `The Byzantine Generals Problem "
#~ "`_. ACM Trans."
#~ " Program. Lang. Syst. 4, 3 (Jul. "
#~ "1982), 382-401."
#~ msgstr ""
#~ msgid ""
#~ "Malamud, C., `Analyzing DECnet/OSI phase "
#~ "V `_, Van"
#~ " Nostrand Reinhold, 1991"
#~ msgstr ""
#~ msgid ""
#~ "McFadyen, J., `Systems Network Architecture:"
#~ " An overview `_,"
#~ " IBM Systems Journal, Vol. 15, N. "
#~ "1, pp. 4-23, 1976"
#~ msgstr ""
#~ msgid ""
#~ "McKusick, M., `Twenty Years of Berkeley"
#~ " Unix : From AT&T-Owned to Freely "
#~ "Redistributable "
#~ "`_, in"
#~ " Open Sources: Voices from the Open"
#~ " Source Revolution, Oreilly, 1999, "
#~ "http://oreilly.com/catalog/opensources/book/toc.html"
#~ msgstr ""
#~ msgid ""
#~ "Minei I. and Lucek J. ,`MPLS-"
#~ "Enabled Applications: Emerging Developments "
#~ "and New Technologies `_ (Wiley Series on"
#~ " Communications Networking & Distributed "
#~ "Systems), Wiley, 2011"
#~ msgstr ""
#~ msgid ""
#~ "McQuillan, J.M., Richer, I., Rosen, E.,"
#~ " `The New Routing Algorithm for the"
#~ " ARPANET `_ "
#~ "Communications, IEEE Transactions on , "
#~ "vol.28, no.5, pp.711,719, May 1980"
#~ msgstr ""
#~ msgid ""
#~ "Mathis, M., Semke, J., Mahdavi, J., "
#~ "and Ott, T. 1997. `The macroscopic "
#~ "behavior of the TCP congestion avoidance"
#~ " algorithm `_. "
#~ "SIGCOMM Comput. Commun. Rev. 27, 3 "
#~ "(Jul. 1997), 67-82."
#~ msgstr ""
#~ msgid ""
#~ "Molle, M., Sohraby, K., Venetsanopoulos, "
#~ "A., `Space-Time Models of Asynchronous"
#~ " CSMA Protocols for Local Area "
#~ "Networks `_, "
#~ "IEEE Journal on Selected Areas in "
#~ "Communications, Volume: 5 Issue: 6, Jul"
#~ " 1987 Page(s): 956 -96"
#~ msgstr ""
#~ msgid ""
#~ "Mühlbauer, W., Uhlig, S., Fu, B., "
#~ "Meulle, M., and Maennel, O., `In "
#~ "search for an appropriate granularity to"
#~ " model routing policies "
#~ "`_. In "
#~ "Proceedings of the 2007 Conference on"
#~ " Applications, Technologies, Architectures, and"
#~ " Protocols For Computer Communications "
#~ "(Kyoto, Japan, August 27 - 31, "
#~ "2007). SIGCOMM '07. ACM, New York, "
#~ "NY, 145-156."
#~ msgstr ""
#~ msgid ""
#~ "Malkin, G., `RIP: An Intra-Domain "
#~ "Routing Protocol "
#~ "`_, Addison "
#~ "Wesley, 1999"
#~ msgstr ""
#~ msgid ""
#~ "Miyakawa, S., `From IPv4 only To "
#~ "v4/v6 Dual Stack "
#~ "`_, IETF72 "
#~ "IAB Technical Plenary, July 2008"
#~ msgstr ""
#~ msgid ""
#~ "Mogul, J. , `The case for "
#~ "persistent-connection HTTP "
#~ "`_. In "
#~ "Proceedings of the Conference on "
#~ "Applications, Technologies, Architectures, and "
#~ "Protocols For Computer Communication "
#~ "(Cambridge, Massachusetts, United States, "
#~ "August 28 - September 01, 1995). "
#~ "D. Oran, Ed. SIGCOMM '95. ACM, New"
#~ " York, NY, 299-313."
#~ msgstr ""
#~ msgid "Moore, R., `Packet switching history`, http://rogerdmoore.ca/PS/"
#~ msgstr ""
#~ msgid ""
#~ "Moy, J., `OSPF: Anatomy of an "
#~ "Internet Routing Protocol "
#~ "`_, Addison "
#~ "Wesley, 1998"
#~ msgstr ""
#~ msgid ""
#~ "Menezes, A., van Oorschot, P. and "
#~ "Vanstone, S. , `Handbook of Applied "
#~ "Cryptography `_ , CRC"
#~ " Press, 2011"
#~ msgstr ""
#~ msgid ""
#~ "Myers, B. A., `A brief history of"
#~ " human-computer interaction technology "
#~ "`_. interactions "
#~ "5, 2 (Mar. 1998), 44-54."
#~ msgstr ""
#~ msgid ""
#~ "Nelson, T. H., `Complex information "
#~ "processing: a file structure for the "
#~ "complex, the changing and the "
#~ "indeterminate `_. "
#~ "In Proceedings of the 1965 20th "
#~ "National Conference (Cleveland, Ohio, United"
#~ " States, August 24 - 26, 1965). "
#~ "L. Winner, Ed. ACM '65. ACM, New"
#~ " York, NY, 84-100."
#~ msgstr ""
#~ msgid ""
#~ "Nielsen, H., Gettys, J., Baird-Smith,"
#~ " A., Prudhommeaux, E., Wium Lie, H.,"
#~ " and Lilley, C. `Network performance "
#~ "effects of HTTP/1.1, CSS1, and PNG "
#~ "`_. SIGCOMM "
#~ "Comput. Commun. Rev. 27, 4 (October "
#~ "1997), 155-166."
#~ msgstr ""
#~ msgid ""
#~ "Paxson, V. , `End-to-end Internet"
#~ " packet dynamics "
#~ "`_. SIGCOMM "
#~ "Comput. Commun. Rev. 27, 4 (Oct. "
#~ "1997), 139-152."
#~ msgstr ""
#~ msgid ""
#~ "Perlman, R., `An algorithm for "
#~ "distributed computation of a spanning "
#~ "tree in an extended LAN "
#~ "`_. SIGCOMM "
#~ "Comput. Commun. Rev. 15, 4 (Sep. "
#~ "1985), 44-53."
#~ msgstr ""
#~ msgid ""
#~ "Perlman, R., `Interconnections : Bridges, "
#~ "routers, switches and internetworking "
#~ "protocols `_, 2nd edition, Addison Wesley,"
#~ " 2000"
#~ msgstr ""
#~ msgid ""
#~ "Perlman, R., `RBridges: Transparent Routing"
#~ " `_, "
#~ "Proc. IEEE Infocom , March 2004."
#~ msgstr ""
#~ msgid ""
#~ "Pouzin, L., `The CYCLADES Network - "
#~ "Present state and development trends "
#~ "`_, Symposium "
#~ "on Computer Networks, 1975 pp 8-13."
#~ msgstr ""
#~ msgid ""
#~ "Rochlis, J. A. and Eichin, M. W.,"
#~ " `With microscope and tweezers: the "
#~ "worm from MIT's perspective "
#~ "`_. Commun. ACM"
#~ " 32, 6 (Jun. 1989), 689-698."
#~ msgstr ""
#~ msgid "Cerf, V., `ASCII format for network interchange`, :rfc:`20`, Oct. 1969"
#~ msgstr ""
#~ msgid "Postel, J., `User Datagram Protocol`, :rfc:`768`, Aug. 1980"
#~ msgstr ""
#~ msgid ""
#~ "Rosen, E., `Vulnerabilities of network "
#~ "control protocols: An example`, :rfc:`789`,"
#~ " July 1981"
#~ msgstr ""
#~ msgid "Postel, J., `Internet Protocol`, :rfc:`791`, Sep. 1981"
#~ msgstr ""
#~ msgid "Postel, J., `Internet Control Message Protocol`, :rfc:`792`, Sep. 1981"
#~ msgstr ""
#~ msgid "Postel, J., `Transmission Control Protocol`, :rfc:`793`, Sept. 1981"
#~ msgstr ""
#~ msgid ""
#~ "Clark, D., `Window and Acknowledgement "
#~ "Strategy in TCP`, :rfc:`813`, July 1982"
#~ msgstr ""
#~ msgid ""
#~ "Su, Z. and Postel, J., `Domain "
#~ "naming convention for Internet user "
#~ "applications`, :rfc:`819`, Aug. 1982"
#~ msgstr ""
#~ msgid "Postel, J., `Simple Mail Transfer Protocol`, :rfc:`821`, Aug. 1982"
#~ msgstr ""
#~ msgid ""
#~ "Crocker, D., `Standard for the format"
#~ " of ARPA Internet text messages, "
#~ ":rfc:`822`, Aug. 1982"
#~ msgstr ""
#~ msgid ""
#~ "Plummer, D., `Ethernet Address Resolution "
#~ "Protocol: Or Converting Network Protocol "
#~ "Addresses to 48.bit Ethernet Address for"
#~ " Transmission on Ethernet Hardware`, "
#~ ":rfc:`826`, Nov. 1982"
#~ msgstr ""
#~ msgid ""
#~ "Postel, J., `TCP maximum segment size"
#~ " and related topics`, :rfc:`879`, Nov. "
#~ "1983"
#~ msgstr ""
#~ msgid ""
#~ "Leffler, S. and Karels, M., `Trailer "
#~ "encapsulations`, :rfc:`893`, April 1984"
#~ msgstr ""
#~ msgid ""
#~ "Hornig, C., `A Standard for the "
#~ "Transmission of IP Datagrams over "
#~ "Ethernet Networks`, :rfc:`894`, April 1984"
#~ msgstr ""
#~ msgid ""
#~ "Nagle, J., `Congestion Control in IP/TCP"
#~ " Internetworks`, :rfc:`896`, Jan. 1984"
#~ msgstr ""
#~ msgid ""
#~ "Harrenstien, K. and Stahl, M. and "
#~ "Feinler, E., `DoD Internet host table"
#~ " specification`, :rfc:`952`, Oct. 1985"
#~ msgstr ""
#~ msgid ""
#~ "Postel, J. and Reynolds, J., `File "
#~ "Transfer Protocol`, :rfc:`959`, Oct. 1985"
#~ msgstr ""
#~ msgid ""
#~ "Partridge, C., `Mail routing and the "
#~ "domain system`, :rfc:`974`, Jan. 1986"
#~ msgstr ""
#~ msgid "Stahl, M., `Domain administrators guide`, :rfc:`1032`, Nov. 1987"
#~ msgstr ""
#~ msgid ""
#~ "Mockapteris, P., `Domain names - "
#~ "implementation and specification`, :rfc:`1035`, "
#~ "Nov. 1987"
#~ msgstr ""
#~ msgid ""
#~ "Postel, J. and Reynolds, J., `Standard"
#~ " for the transmission of IP datagrams"
#~ " over IEEE 802 networks`, :rfc:`1042`, "
#~ "Feb. 1988"
#~ msgstr ""
#~ msgid ""
#~ "Romkey, J., `Nonstandard for transmission "
#~ "of IP datagrams over serial lines: "
#~ "SLIP`, :rfc:`1055`, June 1988"
#~ msgstr ""
#~ msgid ""
#~ "Braden, R., Borman D. and Partridge, "
#~ "C., `Computing the Internet checksum`, "
#~ ":rfc:`1071`, Sep. 1988"
#~ msgstr ""
#~ msgid ""
#~ "Braden, R., `Requirements for Internet "
#~ "Hosts - Communication Layers`, :rfc:`1122`,"
#~ " Oct. 1989"
#~ msgstr ""
#~ msgid ""
#~ "Jacobson, V., `Compressing TCP/IP Headers "
#~ "for Low-Speed Serial Links`, "
#~ ":rfc:`1144`, Feb. 1990"
#~ msgstr ""
#~ msgid ""
#~ "Waitzman, D., `Standard for the "
#~ "transmission of IP datagrams on avian"
#~ " carriers`, :rfc:`1149`, Apr. 1990"
#~ msgstr ""
#~ msgid ""
#~ "Cerf, V. and Mills, K., `Explaining "
#~ "the role of GOSIP`, :rfc:`1169`, Aug."
#~ " 1990"
#~ msgstr ""
#~ msgid "Mogul, J. and Deering, S., `Path MTU discovery`, :rfc:`1191`, Nov. 1990"
#~ msgstr ""
#~ msgid ""
#~ "Callon, R., `Use of OSI IS-IS "
#~ "for routing in TCP/IP and dual "
#~ "environments`, :rfc:`1195`, Dec. 1990"
#~ msgstr ""
#~ msgid "Kantor, B., `BSD Rlogin`, :rfc:`1258`, Sept. 1991"
#~ msgstr ""
#~ msgid "Rivest, R., `The MD5 Message-Digest Algorithm`, :rfc:`1321`, April 1992"
#~ msgstr ""
#~ msgid ""
#~ "Jacobson, V., Braden R. and Borman, "
#~ "D., `TCP Extensions for High "
#~ "Performance`, :rfc:`1323`, May 1992"
#~ msgstr ""
#~ msgid ""
#~ "Callon, R., TCP and UDP with "
#~ "Bigger Addresses (TUBA), `A Simple "
#~ "Proposal for Internet Addressing and "
#~ "Routing`, :rfc:`1347`, June 1992"
#~ msgstr ""
#~ msgid ""
#~ "Rekhter, Y. and Li, T., `An "
#~ "Architecture for IP Address Allocation "
#~ "with CIDR`, :rfc:`1518`, Sept. 1993"
#~ msgstr ""
#~ msgid ""
#~ "Fuller V., Li T., Yu J. and "
#~ "Varadhan, K., `Classless Inter-Domain "
#~ "Routing (CIDR): an Address Assignment "
#~ "and Aggregation Strategy`, :rfc:`1519`, Sept."
#~ " 1993"
#~ msgstr ""
#~ msgid ""
#~ "Wimer, W., `Clarifications and Extensions "
#~ "for the Bootstrap Protocol`, :rfc:`1542`, "
#~ "Oct. 1993"
#~ msgstr ""
#~ msgid ""
#~ "Simpson, W., `The Point-to-Point "
#~ "Protocol (PPP)`, :rfc:`1548`, Dec. 1993"
#~ msgstr ""
#~ msgid ""
#~ "Bradner, S. and Mankin, A., `IP: "
#~ "Next Generation (IPng) White Paper "
#~ "Solicitation`, :rfc:`1550`, Dec. 1993"
#~ msgstr ""
#~ msgid ""
#~ "Piscitello, D., `Use of ISO CLNP "
#~ "in TUBA Environments`, :rfc:`1561`, Dec. "
#~ "1993"
#~ msgstr ""
#~ msgid "Francis, P., `PIP Near-term architecture`, :rfc:`1621`, May 1994"
#~ msgstr ""
#~ msgid ""
#~ "Risjsighani, A., `Computation of the "
#~ "Internet Checksum via Incremental Update`, "
#~ ":rfc:`1624`, May 1994"
#~ msgstr ""
#~ msgid ""
#~ "Egevang K. and Francis, P., `The "
#~ "IP Network Address Translator (NAT)`, "
#~ ":rfc:`1631`, May 1994"
#~ msgstr ""
#~ msgid ""
#~ "Simpson, W., `The Point-to-Point "
#~ "Protocol (PPP)`, :rfc:`1661`, Jul. 1994"
#~ msgstr ""
#~ msgid "Simpson, W., `PPP in HDLC-like Framing`, :rfc:`1662`, July 1994"
#~ msgstr ""
#~ msgid ""
#~ "Hinden, R., `Simple Internet Protocol "
#~ "Plus White Paper`, :rfc:`1710`, Oct. "
#~ "1994"
#~ msgstr ""
#~ msgid ""
#~ "Berners-Lee, T., Masinter, L., and "
#~ "McCahill M., `Uniform Resource Locators "
#~ "(URL)`, :rfc:`1738`, Dec. 1994"
#~ msgstr ""
#~ msgid ""
#~ "Bradner, S. and Mankin, A., `The "
#~ "Recommendation for the IP Next "
#~ "Generation Protocol`, :rfc:`1752`, Jan. 1995"
#~ msgstr ""
#~ msgid ""
#~ "Baker, F., `Requirements for IP Version"
#~ " 4 Routers`, :rfc:`1812`, June 1995"
#~ msgstr ""
#~ msgid ""
#~ "Delgrossi, L., Berger, L., `Internet "
#~ "Stream Protocol Version 2 (ST2) Protocol"
#~ " Specification - Version ST2+`, "
#~ ":rfc:`1819`, Aug. 1995"
#~ msgstr ""
#~ msgid ""
#~ "Schulzrinne H., Casner S., Frederick, R."
#~ " and Jacobson, V., `RTP: A Transport"
#~ " Protocol for Real-Time Applications`, "
#~ ":rfc:`1889`, Jan. 1996"
#~ msgstr ""
#~ msgid ""
#~ "Resnick P., Walker A., `The "
#~ "text/enriched MIME Content-type`, :rfc:`1896`,"
#~ " Feb. 1996"
#~ msgstr ""
#~ msgid ""
#~ "Rekhter Y., Moskowitz B., Karrenberg D.,"
#~ " de Groot G. and Lear, E., "
#~ "`Address Allocation for Private Internets`,"
#~ " :rfc:`1918`, Feb. 1996"
#~ msgstr ""
#~ msgid ""
#~ "Myers, J. and Rose, M., `Post "
#~ "Office Protocol - Version 3`, "
#~ ":rfc:`1939`, May 1996"
#~ msgstr ""
#~ msgid ""
#~ "Berners-Lee, T., Fielding, R. and "
#~ "Frystyk, H., `Hypertext Transfer Protocol "
#~ "-- HTTP/1.0`, :rfc:`1945`, May 1996"
#~ msgstr ""
#~ msgid ""
#~ "Bellovin, S., `Defending Against Sequence "
#~ "Number Attacks`, :rfc:`1948`, May 1996"
#~ msgstr ""
#~ msgid ""
#~ "Deutsch, P., `DEFLATE Compressed Data "
#~ "Format Specification version 1.3`, "
#~ ":rfc:`1951`, May 1996"
#~ msgstr ""
#~ msgid ""
#~ "McCann, J., Deering, S. and Mogul, "
#~ "J., `Path MTU Discovery for IP "
#~ "version 6`, :rfc:`1981`, Aug. 1996"
#~ msgstr ""
#~ msgid "Perkins, C., `IP Encapsulation within IP`, :rfc:`2003`, Oct. 1996"
#~ msgstr ""
#~ msgid ""
#~ "Mathis, M., Mahdavi, J., Floyd, S. "
#~ "and Romanow, A., `TCP Selective "
#~ "Acknowledgment Options`, :rfc:`2018`, Oct. "
#~ "1996"
#~ msgstr ""
#~ msgid ""
#~ "Freed, N. and Borenstein, N., "
#~ "`Multipurpose Internet Mail Extensions (MIME)"
#~ " Part One: Format of Internet Message"
#~ " Bodies`, :rfc:`2045`, Nov. 1996"
#~ msgstr ""
#~ msgid ""
#~ "Freed, N. and Borenstein, N., "
#~ "`Multipurpose Internet Mail Extensions (MIME)"
#~ " Part Two: Media Types`, :rfc:`2046`, "
#~ "Nov. 1996"
#~ msgstr ""
#~ msgid ""
#~ "Hubbard, K. and Kosters, M. and "
#~ "Conrad, D. and Karrenberg, D. and "
#~ "Postel, J., `Internet Registry IP "
#~ "Allocation Guidelines`, :rfc:`2050`, Nov. 1996"
#~ msgstr ""
#~ msgid "Malkin, G. and Minnear, R., `RIPng for IPv6`, :rfc:`2080`, Jan. 1997"
#~ msgstr ""
#~ msgid ""
#~ "Baker, F. and Atkinson, R., `RIP-2 "
#~ "MD5 Authentication`, :rfc:`2082`, Jan. 1997"
#~ msgstr ""
#~ msgid ""
#~ "Droms, R., `Dynamic Host Configuration "
#~ "Protocol`, :rfc:`2131`, March 1997"
#~ msgstr ""
#~ msgid "Touch, J., `TCP Control Block Interdependence`, :rfc:`2140`, April 1997"
#~ msgstr ""
#~ msgid ""
#~ "Laubach, M., Halpern, J., `Classical IP"
#~ " and ARP over ATM`, :rfc:`2225`, "
#~ "April 1998"
#~ msgstr ""
#~ msgid "Moy, J., `OSPF Version 2`, :rfc:`2328`, April 1998"
#~ msgstr ""
#~ msgid ""
#~ "Luciani, J. and Katz, D. and "
#~ "Piscitello, D. and Cole, B. and "
#~ "Doraswamy, N., `NBMA Next Hop Resolution"
#~ " Protocol (NHRP)`, :rfc:`2332`, April 1998"
#~ msgstr ""
#~ msgid ""
#~ "Gross, G. and Kaycee, M. and Li,"
#~ " A. and Malis, A. and Stephens, "
#~ "J., `PPP Over AAL5`, :rfc:`2364`, July"
#~ " 1998"
#~ msgstr ""
#~ msgid ""
#~ "Hoffman, P. and Masinter, L. and "
#~ "Zawinski, J., `The mailto URL scheme`,"
#~ " :rfc:`2368`, July 1998"
#~ msgstr ""
#~ msgid "Malkin, G., `RIP Version 2`, :rfc:`2453`, Nov. 1998"
#~ msgstr ""
#~ msgid ""
#~ "Deering S., Hinden, R., `Internet "
#~ "Protocol, Version 6 (IPv6) Specification`, "
#~ ":rfc:`2460`, Dec. 1998"
#~ msgstr ""
#~ msgid ""
#~ "Crawford, M., `Transmission of IPv6 "
#~ "Packets over Ethernet Networks`, :rfc:`2464`,"
#~ " Dec. 1998"
#~ msgstr ""
#~ msgid ""
#~ "Degermark, M. and Nordgren, B. and "
#~ "Pink, S., `IP Header Compression`, "
#~ ":rfc:`2507`, Feb. 1999"
#~ msgstr ""
#~ msgid ""
#~ "Mamakos, L. and Lidl, K. and "
#~ "Evarts, J. and Carrel, J. and "
#~ "Simone, D. and Wheeler, R., `A "
#~ "Method for Transmitting PPP Over "
#~ "Ethernet (PPPoE)`, :rfc:`2516`, Feb. 1999"
#~ msgstr ""
#~ msgid ""
#~ "Allman, M. and Paxson, V. and "
#~ "Stevens, W., `TCP Congestion Control`, "
#~ ":rfc:`2581`, April 1999"
#~ msgstr ""
#~ msgid ""
#~ "Fielding, R. and Gettys, J. and "
#~ "Mogul, J. and Frystyk, H. and "
#~ "Masinter, L. and Leach, P. and "
#~ "Berners-Lee, T., `Hypertext Transfer "
#~ "Protocol -- HTTP/1.1`, :rfc:`2616`, June "
#~ "1999"
#~ msgstr ""
#~ msgid ""
#~ "Franks, J. and Hallam-Baker, P. "
#~ "and Hostetler, J. and Lawrence, S. "
#~ "and Leach, P. and Luotonen, A. and"
#~ " Stewart, L., `HTTP Authentication: Basic"
#~ " and Digest Access Authentication`, "
#~ ":rfc:`2617`, June 1999"
#~ msgstr ""
#~ msgid ""
#~ "Alaettinoglu, C. and Villamizar, C. and"
#~ " Gerich, E. and Kessens, D. and "
#~ "Meyer, D. and Bates, T. and "
#~ "Karrenberg, D. and Terpstra, M., "
#~ "`Routing Policy Specification Language "
#~ "(RPSL)`, :rfc:`2622`, June 1999"
#~ msgstr ""
#~ msgid ""
#~ "Tsirtsis, G. and Srisuresh, P., `Network"
#~ " Address Translation - Protocol Translation"
#~ " (NAT-PT)`, :rfc:`2766`, Feb. 2000"
#~ msgstr ""
#~ msgid ""
#~ "Connolly, D. and Masinter, L., `The "
#~ "'text/html' Media Type`, :rfc:`2854`, June "
#~ "2000"
#~ msgstr ""
#~ msgid ""
#~ "Kristol, D. and Montulli, L., `HTTP "
#~ "State Management Mechanism`, :rfc:`2965`, Oct."
#~ " 2000"
#~ msgstr ""
#~ msgid ""
#~ "Paxson, V. and Allman, M., `Computing"
#~ " TCP's Retransmission Timer`, :rfc:`2988`, "
#~ "Nov. 2000"
#~ msgstr ""
#~ msgid ""
#~ "Thaler, D. and Hopps, C., `Multipath "
#~ "Issues in Unicast and Multicast Next-"
#~ "Hop Selection`, :rfc:`2991`, Nov. 2000"
#~ msgstr ""
#~ msgid ""
#~ "Retana, A. and White, R. and "
#~ "Fuller, V. and McPherson, D., `Using "
#~ "31-Bit Prefixes on IPv4 Point-to-"
#~ "Point Links`, :rfc:`3021`, Dec. 2000"
#~ msgstr ""
#~ msgid ""
#~ "Srisuresh, P., Egevang, K., `Traditional "
#~ "IP Network Address Translator (Traditional "
#~ "NAT)`, :rfc:`3022`, Jan. 2001"
#~ msgstr ""
#~ msgid ""
#~ "Rosen, E. and Viswanathan, A. and "
#~ "Callon, R., `Multiprotocol Label Switching "
#~ "Architecture`, :rfc:`3031`, Jan. 2001"
#~ msgstr ""
#~ msgid ""
#~ "Ramakrishnan, K. and Floyd, S. and "
#~ "Black, D., `The Addition of Explicit "
#~ "Congestion Notification (ECN) to IP`, "
#~ ":rfc:`3168`, Sept. 2001"
#~ msgstr ""
#~ msgid ""
#~ "Carpenter, B. and Brim, S., "
#~ "`Middleboxes: Taxonomy and Issues`, "
#~ ":rfc:`3234`, Feb. 2002"
#~ msgstr ""
#~ msgid ""
#~ "Senie, D., `Network Address Translator "
#~ "(NAT)-Friendly Application Design Guidelines`, "
#~ ":rfc:`3235`, Jan. 2002"
#~ msgstr ""
#~ msgid ""
#~ "Stone, J. and Stewart, R. and "
#~ "Otis, D., `Stream Control Transmission "
#~ "Protocol (SCTP) Checksum Change`, :rfc:`3309`,"
#~ " Sept. 2002"
#~ msgstr ""
#~ msgid ""
#~ "Droms, R. and Bound, J. and Volz,"
#~ " B. and Lemon, T. and Perkins, "
#~ "C. and Carney, M., `Dynamic Host "
#~ "Configuration Protocol for IPv6 (DHCPv6)`, "
#~ ":rfc:`3315`, July 2003"
#~ msgstr ""
#~ msgid "IANA, `Special-Use IPv4 Addresses`, :rfc:`3330`, Sept. 2002"
#~ msgstr ""
#~ msgid ""
#~ "Floyd, S., `Inappropriate TCP Resets "
#~ "Considered Harmful`, :rfc:`3360`, Aug. 2002"
#~ msgstr ""
#~ msgid ""
#~ "Allman, M. and Floyd, S. and "
#~ "Partridge, C., `Increasing TCP's Initial "
#~ "Window`, :rfc:`3390`, Oct. 2002"
#~ msgstr ""
#~ msgid ""
#~ "Faltstrom, P. and Hoffman, P. and "
#~ "Costello, A., `Internationalizing Domain Names"
#~ " in Applications (IDNA)`, :rfc:`3490`, "
#~ "March 2003"
#~ msgstr ""
#~ msgid ""
#~ "Crispin, M., `Internet Message Access "
#~ "Protocol - Version 4 rev1`, :rfc:`3501`,"
#~ " March 2003"
#~ msgstr ""
#~ msgid ""
#~ "Hinden, R. and Deering, S., `Internet"
#~ " Protocol Version 6 (IPv6) Addressing "
#~ "Architecture`, :rfc:`3513`, April 2003"
#~ msgstr ""
#~ msgid ""
#~ "Thomson, S. and Huitema, C. and "
#~ "Ksinant, V. and Souissi, M., `DNS "
#~ "Extensions to Support IP Version 6`, "
#~ ":rfc:`3596`, October 2003"
#~ msgstr ""
#~ msgid ""
#~ "Aboba, B. and Blunk, L. and "
#~ "Vollbrecht, J. and Carlson, J. and "
#~ "Levkowetz, H., `Extensible Authentication "
#~ "Protocol (EAP)`, :rfc:`3748`, June 2004"
#~ msgstr ""
#~ msgid ""
#~ "Karn, P. and Bormann, C. and "
#~ "Fairhurst, G. and Grossman, D. and "
#~ "Ludwig, R. and Mahdavi, J. and "
#~ "Montenegro, G. and Touch, J. and "
#~ "Wood, L., `Advice for Internet "
#~ "Subnetwork Designers`, :rfc:`3819`, July 2004"
#~ msgstr ""
#~ msgid ""
#~ "Larzon, L-A. and Degermark, M. and "
#~ "Pink, S. and Jonsson, L-E. and "
#~ "Fairhurst, G., `The Lightweight User "
#~ "Datagram Protocol (UDP-Lite)`, :rfc:`3828`,"
#~ " July 2004"
#~ msgstr ""
#~ msgid ""
#~ "Cheshire, S. and Aboba, B. and "
#~ "Guttman, E., `Dynamic Configuration of "
#~ "IPv4 Link-Local Addresses`, :rfc:`3927`, "
#~ "May 2005"
#~ msgstr ""
#~ msgid ""
#~ "Lau, J. and Townsley, M. and "
#~ "Goyret, I., `Layer Two Tunneling "
#~ "Protocol - Version 3 (L2TPv3)`, "
#~ ":rfc:`3931`, March 2005"
#~ msgstr ""
#~ msgid ""
#~ "Arkko, J. and Kempf, J. and Zill,"
#~ " B. and Nikander, P., `SEcure "
#~ "Neighbor Discovery (SEND)`, :rfc:`3971`, March"
#~ " 2005"
#~ msgstr ""
#~ msgid ""
#~ "Aura, T., `Cryptographically Generated "
#~ "Addresses (CGA)`, :rfc:`3972`, March 2005"
#~ msgstr ""
#~ msgid ""
#~ "Berners-Lee, T. and Fielding, R. "
#~ "and Masinter, L., `Uniform Resource "
#~ "Identifier (URI): Generic Syntax`, "
#~ ":rfc:`3986`, January 2005"
#~ msgstr ""
#~ msgid ""
#~ "Arends, R. and Austein, R. and "
#~ "Larson, M. and Massey, D. and "
#~ "Rose, S., `DNS Security Introduction and"
#~ " Requirements`, :rfc:`4033`, March 2005"
#~ msgstr ""
#~ msgid ""
#~ "Hinden, R. and Haberman, B., `Unique "
#~ "Local IPv6 Unicast Addresses`, :rfc:`4193`,"
#~ " Oct. 2005"
#~ msgstr ""
#~ msgid ""
#~ "Ylonen, T. and Lonvick, C., `The "
#~ "Secure Shell (SSH) Protocol Architecture`, "
#~ ":rfc:`4251`, Jan. 2006"
#~ msgstr ""
#~ msgid "Griffin, T. and Huston, G., `BGP Wedgies`, :rfc:`4264`, Nov. 2005"
#~ msgstr ""
#~ msgid ""
#~ "Rekhter, Y. and Li, T. and Hares,"
#~ " S., `A Border Gateway Protocol 4 "
#~ "(BGP-4)`, :rfc:`4271`, Jan. 2006"
#~ msgstr ""
#~ msgid ""
#~ "Hinden, R. and Deering, S., `IP "
#~ "Version 6 Addressing Architecture`, "
#~ ":rfc:`4291`, Feb. 2006"
#~ msgstr ""
#~ msgid ""
#~ "Kent, S. and Seo, K., `Security "
#~ "Architecture for the Internet Protocol`, "
#~ ":rfc:`4301`, Dec. 2005"
#~ msgstr ""
#~ msgid "Kent, S., `IP Authentication Header`, :rfc:`4302`, Dec. 2005"
#~ msgstr ""
#~ msgid ""
#~ "Kent, S., `IP Encapsulating Security "
#~ "Payload (ESP)`, :rfc:`4303`, Dec. 2005"
#~ msgstr ""
#~ msgid ""
#~ "Kohler, E. and Handley, M. and "
#~ "Floyd, S., `Datagram Congestion Control "
#~ "Protocol (DCCP)`, :rfc:`4340`, March 2006"
#~ msgstr ""
#~ msgid ""
#~ "Conta, A. and Deering, S. and "
#~ "Gupta, M., `Internet Control Message "
#~ "Protocol (ICMPv6) for the Internet "
#~ "Protocol Version 6 (IPv6) Specification`, "
#~ ":rfc:`4443`, March 2006"
#~ msgstr ""
#~ msgid ""
#~ "McPherson, D. and Gill, V., `BGP "
#~ "MULTI_EXIT_DISC (MED) Considerations`, :rfc:`4451`,"
#~ " March 2006"
#~ msgstr ""
#~ msgid ""
#~ "Bates, T. and Chen, E. and "
#~ "Chandra, R., `BGP Route Reflection: An"
#~ " Alternative to Full Mesh Internal "
#~ "BGP (IBGP)`, :rfc:`4456`, April 2006"
#~ msgstr ""
#~ msgid ""
#~ "Duke, M. and Braden, R. and Eddy,"
#~ " W. and Blanton, E., `A Roadmap "
#~ "for Transmission Control Protocol (TCP) "
#~ "Specification Documents`, :rfc:`4614`, Oct. "
#~ "2006"
#~ msgstr ""
#~ msgid ""
#~ "Josefsson, S., `The Base16, Base32, and"
#~ " Base64 Data Encodings`, :rfc:`4648`, Oct."
#~ " 2006"
#~ msgstr ""
#~ msgid ""
#~ "Atkinson, R. and Fanto, M., `RIPv2 "
#~ "Cryptographic Authentication`, :rfc:`4822`, Feb. "
#~ "2007"
#~ msgstr ""
#~ msgid ""
#~ "Cerf, V. and Burleigh, S. and "
#~ "Hooke, A. and Torgerson, L. and "
#~ "Durst, R. and Scott, K. and Fall,"
#~ " K. and Weiss, H., `Delay-Tolerant"
#~ " Networking Architecture`, :rfc:`4838`, April "
#~ "2007"
#~ msgstr ""
#~ msgid ""
#~ "Narten, T. and Nordmark, E. and "
#~ "Simpson, W. and Soliman, H.,`Neighbor "
#~ "Discovery for IP version 6 (IPv6)`, "
#~ ":rfc:`4861`, Sept. 2007"
#~ msgstr ""
#~ msgid ""
#~ "Thomson, S. and Narten, T. and "
#~ "Jinmei, T., `IPv6 Stateless Address "
#~ "Autoconfiguration`, :rfc:`4862`, Sept. 2007"
#~ msgstr ""
#~ msgid ""
#~ "Delany, M., `Domain-Based Email "
#~ "Authentication Using Public Keys Advertised"
#~ " in the DNS (DomainKeys)`, :rfc:`4870`, "
#~ "May 2007"
#~ msgstr ""
#~ msgid ""
#~ "Allman, E. and Callas, J. and "
#~ "Delany, M. and Libbey, M. and "
#~ "Fenton, J. and Thomas, M., `DomainKeys"
#~ " Identified Mail (DKIM) Signatures`, "
#~ ":rfc:`4871`, May 2007"
#~ msgstr ""
#~ msgid ""
#~ "Narten, T. and Draves, R. and "
#~ "Krishnan, S., `Privacy Extensions for "
#~ "Stateless Address Autoconfiguration in IPv6`,"
#~ " :rfc:`4941`, Sept. 2007"
#~ msgstr ""
#~ msgid ""
#~ "Montenegro, G. and Kushalnagar, N. and"
#~ " Hui, J. and Culler, D., "
#~ "`Transmission of IPv6 Packets over IEEE"
#~ " 802.15.4 Networks`, :rfc:`4944`, Sept. "
#~ "2007"
#~ msgstr ""
#~ msgid ""
#~ "Klensin, J. and Ko, Y., `Overview "
#~ "and Framework for Internationalized Email`,"
#~ " :rfc:`4952`, July 2007"
#~ msgstr ""
#~ msgid ""
#~ "Touch, J., `Defending TCP Against "
#~ "Spoofing Attacks`, :rfc:`4953`, July 2007"
#~ msgstr ""
#~ msgid ""
#~ "Simeborski, R. and Melnikov, A., `SMTP"
#~ " Service Extension for Authentication`, "
#~ ":rfc:`4954`, July 2007"
#~ msgstr ""
#~ msgid ""
#~ "Heffner, J. and Mathis, M. and "
#~ "Chandler, B., `IPv4 Reassembly Errors at"
#~ " High Data Rates`, :rfc:`4963`, July "
#~ "2007"
#~ msgstr ""
#~ msgid ""
#~ "Aoun, C. and Davies, E., `Reasons "
#~ "to Move the Network Address Translator"
#~ " - Protocol Translator (NAT-PT) to"
#~ " Historic Status`, :rfc:`4966`, July 2007"
#~ msgstr ""
#~ msgid ""
#~ "Eddy, W., `TCP SYN Flooding Attacks "
#~ "and Common Mitigations`, :rfc:`4987`, Aug. "
#~ "2007"
#~ msgstr ""
#~ msgid ""
#~ "Chen, E. and Sangli, S., `Avoid "
#~ "BGP Best Path Transitions from One "
#~ "External to Another`, :rfc:`5004`, Sept. "
#~ "2007"
#~ msgstr ""
#~ msgid ""
#~ "Traina, P. and McPherson, D. and "
#~ "Scudder, J., `Autonomous System Confederations"
#~ " for BGP`, :rfc:`5065`, Aug. 2007"
#~ msgstr ""
#~ msgid ""
#~ "Hutzler, C. and Crocker, D. and "
#~ "Resnick, P. and Allman, E. and "
#~ "Finch, T., `Email Submission Operations: "
#~ "Access and Accountability Requirements`, "
#~ ":rfc:`5068`, Nov. 2007"
#~ msgstr ""
#~ msgid ""
#~ "Varada, S. and Haskins, D. and "
#~ "Allen, E., `IP Version 6 over "
#~ "PPP`, :rfc:`5072`, Sept. 2007"
#~ msgstr ""
#~ msgid ""
#~ "Abley, J. and Savola, P. and "
#~ "Neville-Neil, G., `Deprecation of Type "
#~ "0 Routing Headers in IPv6`, :rfc:`5095`,"
#~ " Dec. 2007"
#~ msgstr ""
#~ msgid "Cheshire, S., `IPv4 Address Conflict Detection`, :rfc:`5227`, July 2008"
#~ msgstr ""
#~ msgid ""
#~ "Crocker, D. and Overell, P., `Augmented"
#~ " BNF for Syntax Specifications: ABNF`, "
#~ ":rfc:`5234`, Jan. 2008"
#~ msgstr ""
#~ msgid "Klensin, J., `Simple Mail Transfer Protocol`, :rfc:`5321`, Oct. 2008"
#~ msgstr ""
#~ msgid "Resnick, P., `Internet Message Format`, :rfc:`5322`, Oct. 2008"
#~ msgstr ""
#~ msgid ""
#~ "Coltun, R. and Ferguson, D. and "
#~ "Moy, J. and Lindem, A., `OSPF for"
#~ " IPv6`, :rfc:`5340`, July 2008"
#~ msgstr ""
#~ msgid "Crocker, D., `Internet Mail Architecture`, :rfc:`5598`, July 2009"
#~ msgstr ""
#~ msgid ""
#~ "Phillips, A. and Davis, M., `Tags "
#~ "for Identifying Languages`, :rfc:`5646`, Sept."
#~ " 2009"
#~ msgstr ""
#~ msgid ""
#~ "Allman, M. and Paxson, V. and "
#~ "Blanton, E., `TCP congestion control`, "
#~ ":rfc:`5681`, Sept. 2009"
#~ msgstr ""
#~ msgid ""
#~ "Cotton, M. and Vegoda, L., `Special "
#~ "Use IPv4 Addresses`, :rfc:`5735`, January "
#~ "2010"
#~ msgstr ""
#~ msgid ""
#~ "Sandlund, K. and Pelletier, G. and "
#~ "Jonsson, L-E., `The RObust Header "
#~ "Compression (ROHC) Framework`, :rfc:`5795`, "
#~ "March 2010"
#~ msgstr ""
#~ msgid ""
#~ "Papadimitriou, D. and Welzl, M. and "
#~ "Scharf, M. and Briscoe, B., `Open "
#~ "Research Issues in Internet Congestion "
#~ "Control`, :rfc:`6077`, February 2011"
#~ msgstr ""
#~ msgid ""
#~ "Duerst, M., Masinter, L. and Zawinski,"
#~ " J., `The 'mailto' URI Scheme` , "
#~ ":rfc:`6068`, October 2010"
#~ msgstr ""
#~ msgid ""
#~ "Baker, F. and Li, X. and Bao, "
#~ "X. and Yin, K., `Framework for "
#~ "IPv4/IPv6 Translation`, :rfc:`6144`, April "
#~ "2011"
#~ msgstr ""
#~ msgid "Barth, A., `HTTP State Management Mechanism`, :rfc:`6265`, April 2011"
#~ msgstr ""
#~ msgid ""
#~ "Gont, F., `Security Assessment of the"
#~ " Internet Protocol Version 4`, :rfc:`6274`,"
#~ " July 2011"
#~ msgstr ""
#~ msgid ""
#~ "Rhodes, B. and Goerzen, J., `Foundations"
#~ " of Python Network Programming: The "
#~ "Comprehensive Guide to Building Network "
#~ "Applications with Python "
#~ "`_, Second "
#~ "Edition, Academic Press, 2004"
#~ msgstr ""
#~ msgid ""
#~ "Ristic, I., `Bulletproof SSL and TLS:"
#~ " Understanding and Deploying SSL/TLS and"
#~ " PKI to Secure Web Servers and "
#~ "Applications `_,"
#~ " Feisty Duck, 2015"
#~ msgstr ""
#~ msgid ""
#~ "Ramakrishnan, K. K. and Jain, R., "
#~ "`A binary feedback scheme for congestion"
#~ " avoidance in computer networks with "
#~ "a connectionless network layer "
#~ "`_. SIGCOMM "
#~ "Comput. Commun. Rev. 25, 1 (Jan. "
#~ "1995), 138-156."
#~ msgstr ""
#~ msgid ""
#~ "Raiciu, C., Iyengar, J., Bonaventure, "
#~ "O., `Recent Advances in Reliable "
#~ "Transport Protocols "
#~ "`_,"
#~ " in H. Haddadi, O. Bonaventure "
#~ "(Eds.), `Recent Advances in Networking "
#~ "`_, (2013), pp. "
#~ "59-106."
#~ msgstr ""
#~ msgid ""
#~ "Rivest, R., Shamir, A. and Adleman, "
#~ "L., `A method for obtaining digital "
#~ "signatures and public-key cryptosystems "
#~ "`_. Commun. ACM"
#~ " 21, 2 (February 1978), 120-126"
#~ msgstr ""
#~ msgid ""
#~ "Roberts, L., `ALOHA packet system with"
#~ " and without slots and capture "
#~ "`_. SIGCOMM "
#~ "Comput. Commun. Rev. 5, 2 (Apr. "
#~ "1975), 28-42."
#~ msgstr ""
#~ msgid ""
#~ "Ross, F., `An overview of FDDI: "
#~ "The fiber distributed data interface "
#~ "`_, IEEE J. "
#~ "Selected Areas in Comm., vol. 7, "
#~ "no. 7, pp. 1043-1051, Sept. 1989"
#~ msgstr ""
#~ msgid ""
#~ "Russell A., `Rough Consensus and Running"
#~ " Code and the Internet-OSI Standards"
#~ " War `_, IEEE"
#~ " Annals of the History of Computing,"
#~ " July-September 2006"
#~ msgstr ""
#~ msgid ""
#~ "Sidhu, G., Andrews, R., Oppenheimer, A.,"
#~ " `Inside AppleTalk "
#~ "`_,"
#~ " Addison-Wesley, 1990"
#~ msgstr ""
#~ msgid ""
#~ "Subramanian, L., Agarwal, S., Rexford, "
#~ "J., Katz, R.. `Characterizing the "
#~ "Internet hierarchy from multiple vantage "
#~ "points `_. "
#~ "In IEEE INFOCOM, 2002"
#~ msgstr ""
#~ msgid ""
#~ "Stone, J., Greenwald, M., Partridge, C.,"
#~ " and Hughes, J., `Performance of "
#~ "checksums and CRC's over real data "
#~ "`_. IEEE/ACM Trans."
#~ " Netw. 6, 5 (Oct. 1998), 529-543."
#~ msgstr ""
#~ msgid ""
#~ "Shoch, J. F. and Hupp, J. A., "
#~ "`Measured performance of an Ethernet "
#~ "local network "
#~ "`_. Commun. ACM"
#~ " 23, 12 (Dec. 1980), 711-721."
#~ msgstr ""
#~ msgid ""
#~ "Senapathi, S., Hernandez, R., `Introduction"
#~ " to TCP Offload Engines "
#~ "`_, "
#~ "March 2004"
#~ msgstr ""
#~ msgid ""
#~ "Stoica, I., Morris, R., Karger, D., "
#~ "Kaashoek, F., and Balakrishnan, H., "
#~ "`Chord: A scalable peer-to-peer "
#~ "lookup service for internet applications "
#~ "`_. In "
#~ "Proceedings of the 2001 conference on"
#~ " Applications, technologies, architectures, and"
#~ " protocols for computer communications "
#~ "(SIGCOMM '01). ACM, New York, NY, "
#~ "USA, 149-160"
#~ msgstr ""
#~ msgid ""
#~ "Semke, J., Mahdavi, J., and Mathis, "
#~ "M., `Automatic TCP buffer tuning "
#~ "`_. SIGCOMM "
#~ "Comput. Commun. Rev. 28, 4 (Oct. "
#~ "1998), 315-323."
#~ msgstr ""
#~ msgid ""
#~ "Stigge, M., Plotz, H., Muller, W., "
#~ "Redlich, J., `Reversing CRC - Theory "
#~ "and Practice `_. Berlin: Humboldt University "
#~ "Berlin. pp. 24."
#~ msgstr ""
#~ msgid ""
#~ "Sridharan, M., Tan, K., Bansal, D., "
#~ "Thaler, D., `Compound TCP: A New "
#~ "TCP Congestion Control for High-Speed"
#~ " and Long Distance Networks "
#~ "`_, Internet draft, work in "
#~ "progress, April 2009"
#~ msgstr ""
#~ msgid ""
#~ "Stewart, R., Tuexen, M., Dong, X., "
#~ "`ECN for Stream Control Transmission "
#~ "Protocol (SCTP) `_, Internet draft, "
#~ "draft-stewart-tsvwg-sctpecn-04, April "
#~ "2013, work in progress"
#~ msgstr ""
#~ msgid ""
#~ "Seifert, R., Edwards, J., `The All-"
#~ "New Switch Book : The complete "
#~ "guide to LAN switching technology "
#~ "`_, Wiley, "
#~ "2008"
#~ msgstr ""
#~ msgid ""
#~ "Selinger, P., `MD5 collision demo`, "
#~ "http://www.mscs.dal.ca/~selinger/md5collision/"
#~ msgstr ""
#~ msgid ""
#~ "Sklower, K. 1989. `Improving the "
#~ "efficiency of the OSI checksum "
#~ "calculation `_. "
#~ "SIGCOMM Comput. Commun. Rev. 19, 5 "
#~ "(Oct. 1989), 32-43."
#~ msgstr ""
#~ msgid ""
#~ "Sarrar, N., Maier, G., Ager, B., "
#~ "Sommer, R. and Uhlig, S., `Investigating"
#~ " IPv6 traffic "
#~ "`_, "
#~ "Passive and Active Measurements, Lecture "
#~ "Notes in Computer Science vol 7192, "
#~ "2012, pp.11-20"
#~ msgstr ""
#~ msgid ""
#~ "Stallings, W., `Protocol Basics: Secure "
#~ "Shell Protocol "
#~ "`_,"
#~ " Internet Protocol Journal, vol 12, n"
#~ " 4, Dec. 2009"
#~ msgstr ""
#~ msgid ""
#~ "Stevens, R., `TCP/IP Illustrated : the"
#~ " Protocols `_,"
#~ " Addison-Wesley, 1994"
#~ msgstr ""
#~ msgid ""
#~ "Stewart, J., `BGP4: Inter-Domain Routing"
#~ " In The Internet "
#~ "`_, Addison-"
#~ "Wesley, 1998"
#~ msgstr ""
#~ msgid ""
#~ "Stoll, C., `Stalking the wily hacker "
#~ "`_, Commun. ACM"
#~ " 31, 5 (May. 1988), 484-497."
#~ msgstr ""
#~ msgid ""
#~ "Shreedhar and G. Varghese. `Efficient "
#~ "fair queueing using deficit round robin"
#~ " `_ SIGCOMM "
#~ "Comput. Commun. Rev. 25, 4 (October "
#~ "1995), 231-242."
#~ msgstr ""
#~ msgid ""
#~ "Tsuchiya, P. F. and Eng, T., "
#~ "`Extending the IP internet through "
#~ "address reuse "
#~ "`_. SIGCOMM "
#~ "Comput. Commun. Rev. 23, 1 (Jan. "
#~ "1993), 16-33."
#~ msgstr ""
#~ msgid ""
#~ "Thomborson, C., `The V.42bis Standard "
#~ "for Data-Compressing Modems "
#~ "`_, "
#~ "IEEE Micro, September/October 1992 (vol. "
#~ "12 no. 5), pp. 41-53"
#~ msgstr ""
#~ msgid ""
#~ "The Unicode Consortium. `The Unicode "
#~ "Standard `_, "
#~ "Version 5.0.0, defined by: The Unicode"
#~ " Standard, Version 5.0 (Boston, MA, "
#~ "Addison-Wesley, 2007"
#~ msgstr ""
#~ msgid ""
#~ "Vasseur, J., Pickavet, M., and "
#~ "Demeester, P., `Network Recovery: Protection"
#~ " and Restoration of Optical, SONET-"
#~ "SDH, IP, and MPLS "
#~ "`_. Morgan "
#~ "Kaufmann Publishers Inc., 2004"
#~ msgstr ""
#~ msgid ""
#~ "Varghese, G., `Network Algorithmics: An "
#~ "Interdisciplinary Approach to Designing Fast"
#~ " Networked Devices "
#~ "`_, Morgan "
#~ "Kaufmann, 2005"
#~ msgstr ""
#~ msgid ""
#~ "Vyncke, E., Paggen, C., `LAN Switch "
#~ "Security: What Hackers Know About Your"
#~ " Switches `_,"
#~ " Cisco Press, 2007"
#~ msgstr ""
#~ msgid ""
#~ "Waserman, M., Baker, F., `IPv6-to-IPv6"
#~ " Network Address Translation (NAT66)`, "
#~ "Internet draft, November 2008, "
#~ "http://tools.ietf.org/html/draft-mrw-behave-nat66-02"
#~ msgstr ""
#~ msgid ""
#~ "Wilson, P., Michaelson, G., Huston, G.,"
#~ " `Redesignation of 240/4 from \"Future "
#~ "Use\" to \"Private Use\"`, Internet "
#~ "draft, September 2008, work in progress,"
#~ " http://tools.ietf.org/html/draft-wilson-class-e-02"
#~ msgstr ""
#~ msgid ""
#~ "White, R., Mc Pherson, D., Srihari, "
#~ "S., `Practical BGP "
#~ "`_, Addison-"
#~ "Wesley, 2004"
#~ msgstr ""
#~ msgid ""
#~ "Watson, R., `Timer-Based Mechanisms in"
#~ " Reliable Transport Protocol Connection "
#~ "Management `_."
#~ " Computer Networks 5: 47-56 (1981)"
#~ msgstr ""
#~ msgid ""
#~ "Wessels, D., Fomenkov, M., `Wow, That's"
#~ " a lot of packets "
#~ "`_, "
#~ "Passive and Active Network Measurement "
#~ "Workshop (PAM), Apr 2003"
#~ msgstr ""
#~ msgid ""
#~ "Williams, R. `A painless guide to "
#~ "CRC error detection algorithms`, August "
#~ "1993, unpublished manuscript, "
#~ "http://www.ross.net/crc/download/crc_v3.txt"
#~ msgstr ""
#~ msgid ""
#~ "Winston, G., `NetBIOS Specification "
#~ "`_, 2003"
#~ msgstr ""
#~ msgid ""
#~ "Wing, D. and Yourtchenko, A., `Happy "
#~ "Eyeballs: Success with Dual-Stack "
#~ "Hosts`, Internet draft, work in "
#~ "progress, July 2011, http://tools.ietf.org/html"
#~ "/draft-ietf-v6ops-happy-eyeballs-03"
#~ msgstr ""
#~ msgid ""
#~ "ITU-T, recommendation X.224, `Information "
#~ "technology - Open Systems Interconnection "
#~ "- Protocol for providing the "
#~ "connection-mode transport service "
#~ "`_, 1995"
#~ msgstr ""
#~ msgid ""
#~ "Xerox, `Xerox Network Systems Architecture "
#~ "`_,"
#~ " XNSG058504, 1985"
#~ msgstr ""
#~ msgid ""
#~ "Ylonen, T., `SSH — Secure Login "
#~ "Connections over the Internet "
#~ "`_,"
#~ " Usenix Security 1996"
#~ msgstr ""
#~ msgid ""
#~ "Zimmermann, H., `OSI Reference Model -"
#~ " The ISO Model of Architecture for"
#~ " Open Systems Interconnection "
#~ "`_, IEEE "
#~ "Transactions on Communications, vol. 28, "
#~ "no. 4, April 1980, pp. 425 - "
#~ "432."
#~ msgstr ""
PK+?)t9 t9 PK H}X 7 cnp3-ebook/index/locale/fr/LC_MESSAGES/exercises/dns.po# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2019 Olivier Bonaventure
# This file is distributed under the same license as the Computer networking : Principles, Protocols and Practice package.
# FIRST AUTHOR , YEAR.
#
msgid ""
msgstr ""
"Project-Id-Version: Computer networking : Principles, Protocols and Practice "
"3\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2021-05-17 09:55+0200\n"
"PO-Revision-Date: 2021-08-27 14:47+0000\n"
"Last-Translator: Anthony Gego \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n > 1;\n"
"X-Generator: Weblate 3.9.1\n"
#: ../../exercises/dns.rst:7
msgid "Application layer"
msgstr ""
#: ../../exercises/dns.rst:11
msgid "This is an unpolished draft of the third edition of this e-book. If you find any error or have suggestions to improve the text, please create an issue via https://github.com/CNP3/ebook/issues?milestone=5 or help us by providing pull requests to close the existing issues."
msgstr ""
#: ../../exercises/dns.rst:15
msgid "The DNS"
msgstr ""
#: ../../exercises/dns.rst:17
msgid "The Domain Name System (DNS) plays a key role in the Internet today as it allows applications to use fully qualified domain names (FQDN) instead of IPv4 or IPv6 addresses. When using the DNS, it is important to remember the role of the different types of DNS records."
msgstr ""
#: ../../exercises/dns.rst:25
msgid "Several software tools can be used to send queries to DNS servers. For this exercise, we use dig_ which is installed on most Unix/Linux systems."
msgstr ""
#: ../../exercises/dns.rst:27
msgid "A typical usage of dig is as follows:"
msgstr ""
#: ../../exercises/dns.rst:33
msgid "where"
msgstr ""
#: ../../exercises/dns.rst:35
msgid "`server` is the IP address or the name of a DNS server or resolver"
msgstr ""
#: ../../exercises/dns.rst:36
msgid "`type` is the type of DNS record that is requested by the query such as `NS` for a nameserver, `A` for an IPv4 address, `AAAA` for an IPv6 address, `MX` for a mail relay, ..."
msgstr ""
#: ../../exercises/dns.rst:37
msgid "`fqdn` is the fully qualified domain name being queried"
msgstr ""
#: ../../exercises/dns.rst:39
msgid "dig_ also contains some additional parameters and flags that are described in the man page. Among these, the `+trace` flag allows to trace all requests that are sent when recursively contacting DNS servers."
msgstr ""
#: ../../exercises/dns.rst:41
msgid "What are the IP addresses of the resolvers that the `dig` implementation you are using relies on [#fdig]_ ?"
msgstr ""
#: ../../exercises/dns.rst:43
msgid "What are the nameservers that are responsible for the `info` top-level domain ? Is it possible to use IPv6 to query them ?"
msgstr ""
#: ../../exercises/dns.rst:45
msgid "What is the IPv6 address that corresponds to `www.computer-networking.info` ? Which type of DNS query does `dig` send to obtain this information ?"
msgstr ""
#: ../../exercises/dns.rst:48
msgid "When run without any parameter, `dig` queries one of the root DNS servers and retrieves the list of the names of all root DNS servers. For technical reasons, there are only 13 different root DNS servers. This information is also available as a text file from http://www.internic.net/zones/named.root. What are the IPv6 addresses of all these servers?"
msgstr ""
#: ../../exercises/dns.rst:50
msgid "Assume now that you are residing in a network where there is no DNS resolver and that you need to perform your query manually starting from the DNS root."
msgstr ""
#: ../../exercises/dns.rst:52
msgid "Use `dig` to send a query to one of these root servers to find the IPv6 address of the DNS server(s) (NS record) responsible for the `org` top-level domain"
msgstr ""
#: ../../exercises/dns.rst:53
msgid "Use `dig` to send a query to one of these DNS servers to find the IP address of the DNS server(s) (NS record) responsible for `root-servers.org`"
msgstr ""
#: ../../exercises/dns.rst:54
msgid "Continue until you find the server responsible for `www.root-servers.org`"
msgstr ""
#: ../../exercises/dns.rst:55
msgid "What is the lifetime associated to this IPv6 address ?"
msgstr ""
#: ../../exercises/dns.rst:57
msgid "Perform the same analysis for a popular website such as `www.google.com`. What is the lifetime associated to the corresponding IPv6 address ? If you perform the same request several times, do you always receive the same answer ? Can you explain why a lifetime is associated to the DNS replies ?"
msgstr ""
#: ../../exercises/dns.rst:59
msgid "Use `dig` to find the mail relays used by the `uclouvain.be` and `student.uclouvain.be` domains. What is the `TTL` of these records ? Can you explain the preferences used by the `MX` records. You can find more information about the MX records in :rfc:`5321`."
msgstr ""
#: ../../exercises/dns.rst:61
msgid "When `dig` is run, the header section in its output indicates the `id` the DNS identifier used to send the query. Does your implementation of `dig` generates random identifiers ?"
msgstr ""
#: ../../exercises/dns.rst:73
msgid "A DNS implementation such as `dig`, and more importantly a name resolver such as bind_ or unbound_, always checks that the received DNS reply contains the same identifier as the DNS request that it sent. Why is this so important ?"
msgstr ""
#: ../../exercises/dns.rst:75
msgid "Imagine an attacker who is able to send forged DNS replies to, for example, associate `www.bigbank.com` to his own IP address. How could he attack a DNS implementation that"
msgstr ""
#: ../../exercises/dns.rst:77
msgid "sends DNS requests containing always the same identifier"
msgstr ""
#: ../../exercises/dns.rst:78
msgid "sends DNS requests containing identifiers that are incremented by one after each request"
msgstr ""
#: ../../exercises/dns.rst:79
msgid "sends DNS requests containing random identifiers"
msgstr ""
#: ../../exercises/dns.rst:81
msgid "The DNS protocol can run over UDP and over TCP. Most DNS servers prefer to use UDP because it consumes fewer resources on the server. However, TCP is useful when a large answer is expected. Compare `time dig +tcp` and `time dig` to query a root DNS server. Is it faster to receive an answer via TCP or via UDP ?"
msgstr ""
#: ../../exercises/dns.rst:84
msgid "Besides `dig`, another way to analyze the DNS is to look at packet traces with tools such as `wireshark `_ or `tcpdump `_ These tools can capture packets in a network and also display and analyze their content. `Wireshark `_ provides a flexible Graphical User Interface that eases the analysis of the captured packets. The three questions below should help you to better understand the important fields of DNS messages."
msgstr ""
#: ../../exercises/dns.rst:93
msgid "The next three questions ask you to go one step further by predicting the values of specific fields in the DNS messages."
msgstr ""
#: ../../exercises/dns.rst:101
msgid "When a client requests the mapping of a domain name into an IP address to its local resolver, the resolver may need to query a large number of nameservers starting from the root nameserver. The three exercises below show packet traces collected while the resolver was resolving the following names: `www.example.com`, `www.google.com` and `www.computer-networking.info`. If you understand how the DNS operates, you should be able to correctly reorder those packet traces."
msgstr ""
#: ../../exercises/dns.rst:112
msgid "Footnotes"
msgstr "Notes de pied de page"
#: ../../exercises/dns.rst:113
msgid "On a Linux machine, the *Description* section of the `dig` man page tells you where `dig` finds the list of nameservers to query."
msgstr ""
#: ../../exercises/dns.rst:115
msgid "You may obtain additional information about the root DNS servers from http://www.root-servers.org"
msgstr ""
PKv7" PK H}X 9 cnp3-ebook/index/locale/fr/LC_MESSAGES/exercises/email.po# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2019 Olivier Bonaventure
# This file is distributed under the same license as the Computer networking : Principles, Protocols and Practice package.
# FIRST AUTHOR , YEAR.
#
msgid ""
msgstr ""
"Project-Id-Version: Computer networking : Principles, Protocols and Practice "
"3\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2021-05-17 09:55+0200\n"
"PO-Revision-Date: 2021-08-27 14:47+0000\n"
"Last-Translator: Anthony Gego \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n > 1;\n"
"X-Generator: Weblate 3.9.1\n"
#: ../../exercises/email.rst:5
msgid "Internet email protocols"
msgstr ""
#: ../../exercises/email.rst:7
msgid "Many Internet protocols are ASCII_-based protocols where the client sends requests as one line of ASCII_ text terminated by `CRLF` and the server replies with one of more lines of ASCII_ text. Using such ASCII_ messages has several advantages compared to protocols that rely on binary encoded messages"
msgstr ""
#: ../../exercises/email.rst:9
msgid "the messages exchanged by the client and the server can be easily understood by a developer or network engineer by simply reading the messages"
msgstr ""
#: ../../exercises/email.rst:10
msgid "it is often easy to write a small prototype that implements a part of the protocol"
msgstr ""
#: ../../exercises/email.rst:11
msgid "it is possible to test a server manually by using telnet"
msgstr ""
#: ../../exercises/email.rst:13
msgid "Telnet is a protocol that allows to obtain a terminal on a remote server. For this, telnet opens a TCP connection with the remote server on port 23. However, most `telnet` implementations allow the user to specify an alternate port as `telnet hosts port` When used with a port number as parameter, `telnet` opens a TCP connection to the remote host on the specified port. `telnet` can thus be used to test any server using an ASCII-based protocol on top of TCP. Note that if you need to stop a running `telnet` session, ``Ctrl-C`` will not work as it will be sent by `telnet` to the remote host over the TCP connection. On many `telnet` implementations you can type ``Ctrl-]`` to freeze the TCP connection and return to the telnet interface."
msgstr ""
#: ../../exercises/email.rst:16
msgid "Use your preferred email tool to send an email message to yourself containing a single line of text. Most email tools have the ability to show the `source` of the message, use this function to look at the message that you sent and the message that you received. Can you find an explanation for all the lines that have been added to your single line email ?"
msgstr ""
#: ../../exercises/email.rst:18
msgid "The TCP protocol supports 65536 different ports numbers. Many of these port numbers have been reserved for some applications. The official repository of the reserved port numbers is maintained by the Internet Assigned Numbers Authority (IANA_) on http://www.iana.org/assignments/port-numbers [#fservices]_. Using this information, what is the default port number for the POP3 protocol ? Does it run on top of UDP or TCP ?"
msgstr ""
#: ../../exercises/email.rst:20
msgid "The Post Office Protocol (POP) is a rather simple protocol described in :rfc:`1939`. POP operates in three phases. The first phase is the authorization phase where the client provides a username and a password. The second phase is the transaction phase where the client can retrieve emails. The last phase is the update phase where the client finalizes the transaction. What are the main POP commands and their parameters ? When a POP server returns an answer, how can you easily determine whether the answer is positive or negative ?"
msgstr ""
#: ../../exercises/email.rst:22
msgid "On smartphones, users often want to avoid downloading large emails over a slow wireless connection. How could a POP client only download emails that are smaller than 5 KBytes ?"
msgstr ""
#: ../../exercises/email.rst:26
msgid "Footnotes"
msgstr "Notes de pied de page"
#: ../../exercises/email.rst:27
msgid "On Unix hosts, a subset of the port assignments is often placed in `/etc/services`."
msgstr ""
PK,h PK H}X > cnp3-ebook/index/locale/fr/LC_MESSAGES/exercises/ex-sharing.po# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2019 Olivier Bonaventure
# This file is distributed under the same license as the Computer networking
# : Principles, Protocols and Practice package.
# FIRST AUTHOR , 2019.
#
msgid ""
msgstr ""
"Project-Id-Version: Computer networking : Principles, Protocols and Practice "
"3\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2019-10-09 12:39+0000\n"
"PO-Revision-Date: 2021-03-04 19:15+0000\n"
"Last-Translator: Philippe D \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n > 1;\n"
"X-Generator: Weblate 3.9.1\n"
"Generated-By: Babel 2.7.0\n"
#: ../../exercises/ex-sharing.rst:6
msgid ""
"This is an unpolished draft of the third edition of this e-book. If you "
"find any error or have suggestions to improve the text, please create an "
"issue via https://github.com/CNP3/ebook/issues?milestone=3 or help us by "
"providing pull requests to close the existing issues."
msgstr ""
"Ceci est une ébauche non révisée de la troisième édition de cet e-book. Si "
"vous trouvez une quelconque erreur ou avez des suggestions pour améliorer ce "
"texte, n'hésitez pas à envoyer une issue via https://github.com/CNP3/ebook/"
"issues?milestone=3 ou aidez-nous en fournissant une pull request afin de "
"clore les issues existantes."
#: ../../exercises/ex-sharing.rst:11
msgid "Sharing resources"
msgstr "Le partage de ressources"
#: ../../exercises/ex-sharing.rst:15
msgid "Medium Access Control"
msgstr ""
#: ../../exercises/ex-sharing.rst:17
msgid ""
"To understand the operation of Medium Access Control algorithms, it is "
"often interesting to use a geometric representation of the transmission "
"of frames on a shared medium. This representation is suitable if the "
"communicating devices are attached to a single cable. Consider a simple "
"scenario with a host connected at one end of a cable. For simplicity, let"
" us consider a cable that has a length of one kilometer. Let us also "
"consider that the propagation delay of the electrical signal is five "
"microseconds per kilometer. The figure below shows the transmission of a "
"2000 bits frame at 100 Mbps by host A on the cable."
msgstr ""
#: ../../exercises/ex-sharing.rst:42
msgid ""
"If the transmitting host is located at another position on the shared "
"medium than one of the edges, then the geometrical pattern that "
"represents the transmission of a frame is slightly different. If the "
"transmitting host is placed in the middle of the cable, then the signal "
"is transmitted in both directions on the cable. The figure below shows "
"the transmission of one 100 bits frame at 100 Mbps by host C on the same "
"cable."
msgstr ""
#: ../../exercises/ex-sharing.rst:66
msgid ""
"In a shared medium, a collision may happen if two hosts transmit at "
"almost the same time as shown in the example below."
msgstr ""
#: ../../exercises/ex-sharing.rst:92
msgid ""
"Consider the following scenario for the ALOHA medium access control "
"algorithm. Three hosts are attached to a one-kilometer long cable and "
"transmit 1000 bits frames at 1 Mbps. Each arrow represents a request to "
"transmit a frame on the corresponding host. Each square represents 250 "
"microseconds in the figure. Represent all the transmitted frames and list"
" the frames that collide."
msgstr ""
#: ../../exercises/ex-sharing.rst:119
msgid ""
"Same question as above, but now consider that the hosts transmit 1000 "
"bits frames at 100 Mbps. The cable has a length of 2 kilometers. C is in "
"the middle of the cable. Each square in the figure below corresponds to "
"10 microseconds."
msgstr ""
#: ../../exercises/ex-sharing.rst:150
msgid ""
"In ALOHA, the hosts rely on acknowledgments to detect whether their frame"
" has been received correctly by the destination. Consider a network "
"running at 100 Mbps where the host exchange 1000 bits frames and "
"acknowledgments of 100 bits. Draw the frames sent by hosts A and B in the"
" figure below. Assume that a square corresponds to 10 microseconds and "
"that the cable has a length of 2 kilometers."
msgstr ""
#: ../../exercises/ex-sharing.rst:175
msgid ""
"Same question as above, but now assume that the retransmission timer of "
"each host is set to 50 microseconds."
msgstr ""
#: ../../exercises/ex-sharing.rst:203
msgid ""
"In practice, hosts transmit variable length frames. Consider a cable "
"having a bandwidth of 100 Mbps and a length of 2 kilometers."
msgstr ""
#: ../../exercises/ex-sharing.rst:231
msgid ""
"With CSMA, hosts need to listen to the communication channel before "
"starting their transmission. Consider again a 2 kilometers long cable "
"where hosts send frames at 100 Mbps. Show in the figure below the correct"
" transmission of frames with CSMA."
msgstr ""
#: ../../exercises/ex-sharing.rst:260
msgid ""
"CSMA/CD does not use acknowledgments but instead assumes that each host "
"can detect collisions by listening while transmitting. Consider a 2 "
"kilometers long cable running at 10 Mbps. Show in the figure below the "
"utilization of the communication channel and the collisions that would "
"occur. For this exercise, do not attempt to retransmit the frames that "
"have collided."
msgstr ""
#: ../../exercises/ex-sharing.rst:290
msgid ""
"Consider again a network that uses CSMA/CD. This time, the bandwidth is "
"set to 1 Gbps and the cable has a length of two kilometers. When a "
"collision occurs, consider that the hosts B and C retransmit immediately "
"while host A waits for the next slot."
msgstr ""
#: ../../exercises/ex-sharing.rst:316
msgid ""
"An important part of the CSMA/CD algorithm is the exponential backoff. To"
" illustrate the operation of this algorithm, let us consider a cable that"
" has a length of one kilometer. The bandwidth of the network is set to 10"
" Mbps. Assume that when a collision occurs, host A always selects the "
"highest possible random delay according to the exponential backoff "
"algorithm while host B always selects the shortest one. In this network, "
"the slot time is equal to the time required to transmit 100 bits. We "
"further assume that a host can detect collision immediately (i.e. as soon"
" as the other frame arrives)."
msgstr ""
#: ../../exercises/ex-sharing.rst:343
msgid "Fairness and congestion control"
msgstr ""
#: ../../exercises/ex-sharing.rst:345
msgid ""
"Consider the network below. Compute the max-min fair allocation for the "
"hosts in this network assuming that nodes `Sx` always send traffic "
"towards node `Dx`. Furthermore, link `R1-R2` has a bandwidth of 10 Mbps "
"while link `R2-R3` has a bandwidth of 20 Mbps."
msgstr ""
#: ../../exercises/ex-sharing.rst:382
msgid ""
"To understand congestion control algorithms, it can also be useful to "
"represent the exchange of packets by using a graphical representation. As"
" a first example, let us consider a very simple network composed of two "
"hosts interconnected through a switch."
msgstr ""
#: ../../exercises/ex-sharing.rst:399
msgid ""
"Suppose now that host A uses a window of three segments and sends these "
"three segments immediately. The segments will be queued in the router "
"before being transmitted on the output link and delivered to their "
"destination. The destination will reply with a short acknowledgment "
"segment. A possible visualization of this exchange of packets is "
"represented in the figure below. We assume for this figure that the "
"router marks the packets to indicate congestion as soon as its buffer is "
"non-empty when its receives a packet on its input link. In the figure, a "
"`(c)` sign is added to each packet to indicate that it has been "
"explicitly marked."
msgstr ""
#: ../../exercises/ex-sharing.rst:432
msgid ""
"In practice, a router is connected to multiple input links. The figure "
"below shows an example with two hosts."
msgstr ""
#: ../../exercises/ex-sharing.rst:491
msgid ""
"In general, the links have a non-zero delay. This is illustrated in the "
"figure below where a delay has been added on the link between `R` and "
"`C`."
msgstr ""
#: ../../exercises/ex-sharing.rst:538 ../../exercises/ex-sharing.rst:613
msgid "Consider the network depicted in the figure below."
msgstr ""
#: ../../exercises/ex-sharing.rst:558
msgid ""
"In this network, compute the minimum round-trip-time between `A` (resp. "
"`B`) and `D`. Perform the computation if the hosts send segments "
"containing 1000 bits."
msgstr ""
#: ../../exercises/ex-sharing.rst:559
msgid ""
"How is the maximum round-trip-time influenced if the buffers of router "
"`R1` store 10 packets ?"
msgstr ""
#: ../../exercises/ex-sharing.rst:560
msgid ""
"If hosts `A` and `B` send to `D` 1000 bits segments and use a sending "
"window of four segments, what is the maximum throughput that they can "
"achieve ?"
msgstr ""
#: ../../exercises/ex-sharing.rst:561
msgid ""
"Assume now that `R1` is using round-robin scheduling instead of a FIFO "
"buffer. One queue is used to store the packets sent by `A` and another "
"for the packets sent by `B`. `A` sends one 1000 bits packet every second "
"while `B` sends packets at 10 Mbps. What is the round-trip-time measured "
"by each of these two hosts if each of the two queues of `R1` can store 5 "
"packets ?"
msgstr ""
#: ../../exercises/ex-sharing.rst:564
msgid ""
"When analyzing the reaction of a network using round-robin schedulers, it"
" is sometimes useful to consider that the packets sent by each source are"
" equivalent to a fluid and that each scheduler acts as a tap. Using this "
"analogy, consider the network below. In this network, all the links are "
"100 Mbps and host `B` is sending packets at 100 Mbps. If A sends at 1, 5,"
" 10, 20, 30, 40, 50, 60, 80 and 100 Mbps, what is the throughput that "
"destination `D` will receive from `A`. Use this data to plot a graph that"
" shows the portion of the traffic sent by host `A` which is received by "
"host `D`."
msgstr ""
#: ../../exercises/ex-sharing.rst:582
msgid "Compute the max-min fair bandwidth allocation in the network below."
msgstr ""
#: ../../exercises/ex-sharing.rst:588
msgid "Simple network topology"
msgstr ""
#: ../../exercises/ex-sharing.rst:591
msgid "Consider the simple network depicted in the figure below."
msgstr ""
#: ../../exercises/ex-sharing.rst:609
msgid ""
"In this network, a 250 Kbps link is used between the routers. The "
"propagation delays in the network are negligible. Host `A` sends 1000 "
"bits long segments so that it takes one msec to transmit one segment on "
"the `A-R1` link. Neglecting the transmission delays for the "
"acknowledgments, what is the minimum round-trip time measured on host `A`"
" with such segments ?"
msgstr ""
#: ../../exercises/ex-sharing.rst:610
msgid ""
"If host `A` uses a window of two segments and needs to transmit five "
"segments of data. How long does the entire transfer lasts ?"
msgstr ""
#: ../../exercises/ex-sharing.rst:611
msgid ""
"Same question as above, but now host `A` uses the simple DECBIT "
"congestion control mechanism and a maximum window size of four segments."
msgstr ""
#: ../../exercises/ex-sharing.rst:630
msgid ""
"Hosts `A` and `B` use the simple congestion control scheme described in "
"the book and router `R1` uses the DECBIT mechanism to mark packets as "
"soon as its buffers contain one packet. Hosts `A` and `B` need to send "
"five segments and start exactly at the same time. How long does each "
"hosts needs to wait to receive the acknowledgment for its fifth segment ?"
msgstr ""
#: ../../exercises/ex-sharing.rst:633
msgid "Discussion questions"
msgstr "Questions de discussion"
#: ../../exercises/ex-sharing.rst:639
msgid ""
"In a deployed CSMA/CD network, would it be possible to increase or "
"decrease the duration of the slotTime ? Justify your answer"
msgstr ""
#: ../../exercises/ex-sharing.rst:641
msgid ""
"Consider a CSMA/CD network that contains hosts that generate frames at a "
"regular rate. When the transmission rate increases, the amount of "
"collisions increases. For a given network load, measured in bits/sec, "
"would the number of collisions be smaller, equal or larger with short "
"frames than with long frames ?"
msgstr ""
#: ../../exercises/ex-sharing.rst:643
msgid ""
"Slotted ALOHA improves the performance of ALOHA by dividing the time in "
"slots. However, this basic idea raises two interested questions. First "
"how would you enforce the duration of these slots ? Second, should a slot"
" include the time to transmit a data frame or the time to transmit a data"
" frame and the corresponding acknowledgment ?"
msgstr ""
#: ../../exercises/ex-sharing.rst:645
msgid ""
"Like ALOHA, CSMA relies on acknowledgments to detect where a frame has "
"been correctly received. When a host senses an idle channel, if should "
"transmit its frame immediately. How should it react if it detects that "
"another host is already transmitting ? Consider two options :"
msgstr ""
#: ../../exercises/ex-sharing.rst:647
msgid ""
"the host continues to listen until the communication channel becomes "
"free. It transmits as soon as the communication channel becomes free."
msgstr ""
#: ../../exercises/ex-sharing.rst:648
msgid ""
"the host stops to listen and waits for a random time before sensing again"
" the communication channel to check whether it is free."
msgstr ""
PKwo4 4 PK H}X 8 cnp3-ebook/index/locale/fr/LC_MESSAGES/exercises/http.po# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2019 Olivier Bonaventure
# This file is distributed under the same license as the Computer networking : Principles, Protocols and Practice package.
# FIRST AUTHOR , YEAR.
#
msgid ""
msgstr ""
"Project-Id-Version: Computer networking : Principles, Protocols and Practice "
"3\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2021-05-17 09:55+0200\n"
"PO-Revision-Date: 2021-08-27 14:47+0000\n"
"Last-Translator: Anthony Gego \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n > 1;\n"
"X-Generator: Weblate 3.9.1\n"
#: ../../exercises/http.rst:6
msgid "The HyperText Transfer Protocol"
msgstr ""
#: ../../exercises/http.rst:8
msgid "An important difference between HTTP/1.0, HTTP/1.1 and HTTP/2.0 is their utilization of the underlying transport connections. Answer the three questions below to confirm that you understand the difference between these versions of the HTTP protocol."
msgstr ""
#: ../../exercises/http.rst:17
msgid "System administrators who are responsible for web servers often want to monitor these servers and check that they are running correctly. As a HTTP server uses TCP on port 80, the simplest solution is to open a TCP connection on port 80 and check that the TCP connection is accepted by the remote host. However, as HTTP/1.x is an ASCII-based protocol, it is also very easy to write a small script that downloads a web page on the server and compares its content with the expected one. Use `telnet` or `ncat` to verify that a web server is running on host `www.computer-networking.info` [#fhttp]_."
msgstr ""
#: ../../exercises/http.rst:19
msgid "Instead of using `telnet` on port 80, it is also possible to use a command-line tool such as curl_. Use curl_ with the `--trace-ascii tracefile` option to store in `tracefile` all the information exchanged by curl_ when accessing the server."
msgstr ""
#: ../../exercises/http.rst:21
msgid "What is the version of HTTP used by your version of curl_ ?"
msgstr ""
#: ../../exercises/http.rst:22
msgid "Can you explain the different headers placed by curl_ in the request ?"
msgstr ""
#: ../../exercises/http.rst:23
msgid "Can you explain the different headers found in the response ?"
msgstr ""
#: ../../exercises/http.rst:25
msgid "HTTP 1.1, specified in :rfc:`2616`, forces the client to include the `Host:` header in all its requests. HTTP 1.0 does not define the `Host:` header, but most implementations support it. By using `telnet` and `curl` retrieve the first page of the https://www.computer-networking.info web server [#fhttps]_ by sending http requests with and without the `Host:` header. Explain the difference between the two."
msgstr ""
#: ../../exercises/http.rst:27
msgid "The headers sent in a HTTP request allow the client to provide additional information to the server. One of these headers is the `Accept-Language` header that allows indicating the preferred language of the client [#flang]_. For example, `curl -HAccept-Language:en http://www.google.be` will send to `http://www.google.be` a HTTP request indicating English (`en`) as the preferred language. Does google provides a different page in French (`fr`) and Walloon (`wa`) ? Same question for `http://www.uclouvain.be` (given the size of the homepage, use ``diff`` to compare the different pages retrieved from `www.uclouvain.be`)."
msgstr ""
#: ../../exercises/http.rst:29
msgid "Compare the size of the http://www.yahoo.com and http://www.google.com web pages by downloading them with curl_."
msgstr ""
#: ../../exercises/http.rst:31
msgid "The `ipvfoo `_ extension on google chrome allows the user to visually detect whether a website is using IPv6 and IPv4, but also to see which web sites have been contacted when rendering a given web page. Some websites are distributed over several dozens of different servers. Can you find one ?"
msgstr ""
#: ../../exercises/http.rst:33
msgid "Some websites are reachable over both IPv4 and IPv6 while others are only reachable over IPv4 [#fv6only]_. You can use the `-6` (resp. `-4`) option to force curl_ to only use IPv6 (resp. IPv4). Verify that `www.computer-networking.info` is reachable over IPv6 and IPv4 and then check whether your university website already supports IPv6."
msgstr ""
#: ../../exercises/http.rst:35
msgid "curl_ supports a huge number of options and parameters that are described in its `man page `_ Some of them allow you to force the utilization of a specific version of HTTP. These include `--http0.9`, `--http1.0`, `--http1.1` and `--http2`. Using the latter, verify whether your favorite website supports HTTP/2.0."
msgstr ""
#: ../../exercises/http.rst:37
msgid "As for the DNS, besides using software tools that implement the HTTP protocols, it can also be useful to analyze packet traces with wireshark_ . The exercises below contain simple packet traces collected with different versions of the HTTP protocol."
msgstr ""
#: ../../exercises/http.rst:50
msgid "Footnotes"
msgstr "Notes de pied de page"
#: ../../exercises/http.rst:51
msgid "The minimum command sent to a HTTP server is `GET / HTTP/1.0` followed by CRLF and a blank line."
msgstr ""
#: ../../exercises/http.rst:53
msgid "This syllabus is now hosted on a web server using HTTPS (port 443) instead of HTTP (port 80)."
msgstr ""
#: ../../exercises/http.rst:55
msgid "The list of available language tags can be found at http://www.iana.org/assignments/language-subtag-registry. Versions in other formats are available at http://www.langtag.net/registries.html. Additional information about the support of multiple languages in Internet protocols may be found in rfc5646_."
msgstr ""
#: ../../exercises/http.rst:57
msgid "There are probably very few websites that only support IPv6 and not IPv4. If you find one, let us know by submitting a pull-request to change this exercise."
msgstr ""
PKNX PK H}X 9 cnp3-ebook/index/locale/fr/LC_MESSAGES/exercises/intro.po# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2019 Olivier Bonaventure
# This file is distributed under the same license as the Computer networking
# : Principles, Protocols and Practice package.
# FIRST AUTHOR , 2019.
#
msgid ""
msgstr ""
"Project-Id-Version: Computer networking : Principles, Protocols and Practice "
"3\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2019-10-09 12:39+0000\n"
"PO-Revision-Date: 2021-02-09 22:35+0000\n"
"Last-Translator: Philippe D \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n > 1;\n"
"X-Generator: Weblate 3.9.1\n"
"Generated-By: Babel 2.7.0\n"
#: ../../exercises/intro.rst:6
msgid "Exercises"
msgstr "Exercices"
#: ../../exercises/intro.rst:8
msgid ""
"This section gathers a series of open questions that have been designed "
"to enable the students to improve their understanding of the topics "
"presented in the e-book. These open questions typically contain a small "
"problem that needs to be solved by the student. They are designed so that"
" they can lead to discussions with teaching assistants."
msgstr ""
"Cette section regroupe une série de questions ouvertes destinées à permettre "
"aux étudiants d'améliorer leur compréhension des sujets abordés dans cet e-"
"book. Ces questions ouvertes contiennent généralement des petits problèmes à "
"résoudre par l'étudiant. Ils sont faits pour encourager la discussion avec "
"les assistants."
#: ../../exercises/intro.rst:10
msgid ""
"Several `Multiple Choice Questions` and simple exercises are included in "
"the main text and supported by the https://inginious.org platform."
msgstr ""
"Plusieurs `questions à choix multiples` et des exercices simples sont inclus "
"dans le texte principal et fournis grâce à la plateforme https://"
"inginious.org ."
#: ../../exercises/intro.rst:12
msgid ""
"A good understanding of the topics covered by this e-book can only be "
"obtained by solving the proposed exercises. Reading the e-book from the "
"first to the last page is not sufficient to get a detailed knowledge of "
"computer networking."
msgstr ""
"Une bonne compréhension des sujets couverts par cet e-book peut être acquise "
"seulement en résolvant les exercices proposés. Lire le livre jusqu'à la "
"dernière ligne n'est pas suffisant pour une compréhension approfondie des "
"réseaux informatiques."
PKbTr$
$
PK H}X 8 cnp3-ebook/index/locale/fr/LC_MESSAGES/exercises/ipv6.po# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2019 Olivier Bonaventure
# This file is distributed under the same license as the Computer networking : Principles, Protocols and Practice package.
# FIRST AUTHOR , YEAR.
#
msgid ""
msgstr ""
"Project-Id-Version: Computer networking : Principles, Protocols and Practice "
"3\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2021-05-17 09:55+0200\n"
"PO-Revision-Date: 2021-08-27 14:47+0000\n"
"Last-Translator: Anthony Gego \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n > 1;\n"
"X-Generator: Weblate 3.9.1\n"
#: ../../exercises/ipv6.rst:6
msgid "IPv6 Networks"
msgstr "Réseaux IPv6"
#: ../../exercises/ipv6.rst:9
msgid "Basic questions on IPv6 Networks"
msgstr ""
#: ../../exercises/ipv6.rst:11
msgid "Before starting to determine the paths that packets will follow in an IPv6 network, it is important to remember how to convert IPv6 addresses in binary numbers."
msgstr ""
#: ../../exercises/ipv6.rst:15
msgid "An IPv6 forwarding table contains a list of IPv6 prefixes with their associated nexthop or outgoing interface. When an IPv6 router receives a packet, it forwards it according to its forwarding table. Note that IPv6 routers forward packets along the *longest match* between the destination address of the packet and the routes in the forwarding table."
msgstr ""
#: ../../exercises/ipv6.rst:20
msgid "Now that you master the basics, you can determine the paths followed by IPv6 packets in simple networks."
msgstr ""
#: ../../exercises/ipv6.rst:31
msgid "Design questions"
msgstr ""
#: ../../exercises/ipv6.rst:33
#: ../../exercises/ipv6.rst:142
msgid "Consider the network shown in the figure below. In this network, the following addresses are used."
msgstr ""
#: ../../exercises/ipv6.rst:35
#: ../../exercises/ipv6.rst:144
#: ../../exercises/ipv6.rst:222
msgid "host ``A`` : ``2001:db8:1341:1::A`` and its default route points to ``2001:db8:1341:1::1``"
msgstr ""
#: ../../exercises/ipv6.rst:36
#: ../../exercises/ipv6.rst:145
#: ../../exercises/ipv6.rst:223
msgid "host ``B`` : ``2001:db8:1341:4::B`` and its default route points to ``2001:db8:1341:4::4``"
msgstr ""
#: ../../exercises/ipv6.rst:38
#: ../../exercises/ipv6.rst:147
#: ../../exercises/ipv6.rst:225
msgid "The routers have one address inside each network :"
msgstr ""
#: ../../exercises/ipv6.rst:40
#: ../../exercises/ipv6.rst:149
msgid "router ``R1`` uses address ``2001:db8:1341:1::1`` on its West interface, address ``2001:db8:1341:12::1`` on its East interface and address ``2001:db8:1341:13::1`` on its South interface"
msgstr ""
#: ../../exercises/ipv6.rst:41
msgid "router ``R2`` uses address ``2001:db8:1341:12::2`` on its West interface, address ``2001:db8:1341:23::2`` on its South-West interface and address ``2001:db8:1341:24::2`` on its South interface."
msgstr ""
#: ../../exercises/ipv6.rst:42
msgid "router ``R3`` uses address ``2001:db8:1341:34::3`` on its East interface, address ``2001:db8:1341:23::3`` on its North-East interface and address ``2001:db8:1341:13::3`` on its North interface"
msgstr ""
#: ../../exercises/ipv6.rst:43
#: ../../exercises/ipv6.rst:152
msgid "router ``R4`` uses address ``2001:db8:1341:34::4`` on its West interface, address ``2001:db8:1341:24::4`` on its North interface and address ``2001:db8:1341:4::4`` on its East interface"
msgstr ""
#: ../../exercises/ipv6.rst:45
msgid "The forwarding paths used in a network depend on the forwarding tables installed in the network nodes. Sometimes, these forwarding tables must be configured manually."
msgstr ""
#: ../../exercises/ipv6.rst:91
msgid "In this network, propose the forwarding tables of ``R2`` and ``R3`` that ensure that hosts ``A`` and ``B`` can exchange packets in both directions."
msgstr ""
#: ../../exercises/ipv6.rst:94
msgid "Consider the same network as in the previous question, but now the forwarding tables of ``R2`` and ``R3`` are configured as shown below :"
msgstr ""
#: ../../exercises/ipv6.rst:139
msgid "In this network, select `all` the rules in the shown forwarding tables that ensure that the packets sent from ``A`` to ``B`` follow the reverse path of the packets sent by ``B`` to ``A``."
msgstr ""
#: ../../exercises/ipv6.rst:150
#: ../../exercises/ipv6.rst:228
msgid "router ``R2`` uses address ``2001:db8:1341:12::2`` on its West interface, and address ``2001:db8:1341:24::2`` on its South interface"
msgstr ""
#: ../../exercises/ipv6.rst:151
#: ../../exercises/ipv6.rst:229
msgid "router ``R3`` uses address ``2001:db8:1341:34::3`` on its East interface and address ``2001:db8:1341:13::3`` on its North interface"
msgstr ""
#: ../../exercises/ipv6.rst:154
msgid "Routers ``R2`` and ``R3`` are buggy in this network. Besides the routes for their local interfaces (not shown in the figure), they only have a default route which is shown in the figure below."
msgstr ""
#: ../../exercises/ipv6.rst:193
msgid "How do you configure the forwarding tables on ``R1`` and ``R4`` so that ``A`` can reach ``B`` and the reverse ?"
msgstr ""
#: ../../exercises/ipv6.rst:195
msgid "Consider a slightly different network than in the previous question."
msgstr ""
#: ../../exercises/ipv6.rst:220
msgid "Assuming that the following IPv6 addresses are used :"
msgstr ""
#: ../../exercises/ipv6.rst:227
msgid "router ``R1`` uses address ``2001:db8:1341:1::1`` on its West interface, address ``2001:db8:1341:12::1`` on its East interface, address ``2001:db8:1341:14::1`` on its South-East interface and address ``2001:db8:1341:13::1`` on its South interface"
msgstr ""
#: ../../exercises/ipv6.rst:230
msgid "router ``R4`` uses address ``2001:db8:1341:34::4`` on its West interface, address ``2001:db8:1341:24::4`` on its North interface, address ``2001:db8:1341:14::4`` on its North-West interface and address ``2001:db8:1341:4::4`` on its East interface"
msgstr ""
#: ../../exercises/ipv6.rst:232
msgid "Can you configure the forwarding tables so that the following paths are used by packets sent by host ``A`` to reach one of the four addresses of router ``R4``?"
msgstr ""
#: ../../exercises/ipv6.rst:290
msgid "Do your forwarding tables impose the path used to reach host ``B`` which is attached to router ``R4`` or do you need to configure an additional entry in these tables ?"
msgstr ""
#: ../../exercises/ipv6.rst:292
msgid "Consider the network below that contains only routers. This network has been configured by a group of students and you must verify whether the configuration is correct. All the IPv6 addresses are part of the same ``/48`` prefix that we name ``p``. The following subnets are defined in this ``/48`` prefix."
msgstr ""
#: ../../exercises/ipv6.rst:294
msgid "``p:12/64`` for the link between ``R1`` and ``R2``. On this subnet, ``R1`` uses address ``p:12::1`` while router ``R2`` uses address ``p:12::2``"
msgstr ""
#: ../../exercises/ipv6.rst:295
msgid "``p:13/64`` for the link between ``R1`` and ``R3``. On this subnet, ``R1`` uses address ``p:13::1`` while router ``R3`` uses address ``p:13::3``"
msgstr ""
#: ../../exercises/ipv6.rst:296
msgid "``p:24/64`` for the link between ``R2`` and ``R4``. On this subnet, ``R2`` uses address ``p:24::2`` while router ``R4`` uses address ``p:24::4``"
msgstr ""
#: ../../exercises/ipv6.rst:297
msgid "..."
msgstr ""
#: ../../exercises/ipv6.rst:330
msgid "The students have configured the following forwarding tables on these six routers."
msgstr ""
#: ../../exercises/ipv6.rst:332
msgid "on router ``R1``"
msgstr ""
#: ../../exercises/ipv6.rst:350
msgid "on router ``R2``"
msgstr ""
#: ../../exercises/ipv6.rst:368
msgid "on router ``R3``"
msgstr ""
#: ../../exercises/ipv6.rst:384
msgid "on router ``R5``"
msgstr ""
#: ../../exercises/ipv6.rst:399
msgid "on router ``R4``"
msgstr ""
#: ../../exercises/ipv6.rst:416
msgid "on router ``R6``"
msgstr ""
#: ../../exercises/ipv6.rst:433
msgid "What do you think about the proposed configuration?"
msgstr ""
#: ../../exercises/ipv6.rst:436
msgid "Sometimes, static routes must be configured on networks to enforce certain paths. Consider the six routers network shown in the figure below."
msgstr ""
#: ../../exercises/ipv6.rst:471
msgid "In this network, we will focus on four IPv6 prefixes :"
msgstr ""
#: ../../exercises/ipv6.rst:473
msgid "``p:0000::/64`` used on the link ``A1-R1``. ``A1`` uses address ``p:0000::A1/64``"
msgstr ""
#: ../../exercises/ipv6.rst:474
msgid "``p:0001::/64`` used on the link ``A2-R3``. ``A2`` uses address ``p:0001::A2/64``"
msgstr ""
#: ../../exercises/ipv6.rst:475
msgid "``p:0002::/64`` used on the link ``B1-R5``. ``B1`` uses address ``p:0002::B1/64``"
msgstr ""
#: ../../exercises/ipv6.rst:476
msgid "``p:0003::/64`` used on the link ``B2-R6``. ``B2`` uses address ``p:0003::B2/64``"
msgstr ""
#: ../../exercises/ipv6.rst:478
msgid "Can you configure the forwarding tables of the six routers to achieve the following network objectives :"
msgstr ""
#: ../../exercises/ipv6.rst:480
msgid "All packets sent by ``B1`` and ``B2`` to ``A1`` and ``A2`` are always forwarded via ``R2`` while all packets from ``A1`` and ``A2`` are always forwarded via ``R4``"
msgstr ""
#: ../../exercises/ipv6.rst:481
msgid "The packets whose destinations are ``A1``, ``A2``, ``B1`` or ``B2`` are never forwarded via router ``R4``"
msgstr ""
#: ../../exercises/ipv6.rst:482
msgid "The packets sent by ``A1`` or ``A2`` towards ``B1`` are always forwarded via ``R2`` while the packets towards ``B2`` are always forwarded via ``R4``."
msgstr ""
#: ../../exercises/ipv6.rst:484
msgid "When creating these forwarding tables, try to minimize the number of entries that you install on each router."
msgstr ""
#: ../../exercises/ipv6.rst:486
msgid "When a network is designed, an important element of the design is the IP address allocation plan. A good allocation plan can provide flexibility and help to reduce the size of the forwarding tables."
msgstr ""
#: ../../exercises/ipv6.rst:517
msgid "Assign IP subnets to all links in this network so that you can reduce the number of entries in the forwarding tables of all routers. Assume that you have received a ``/56`` prefix that you can use as you want. Each subnet containing a host must be allocated a ``/64`` subnet."
msgstr ""
#: ../../exercises/ipv6.rst:527
msgid "Configuring IPv6 Networks"
msgstr ""
#: ../../exercises/ipv6.rst:529
msgid "With the previous exercises, you have learned how to reason about IPv6 networks \"on paper\". Given the availability of IPv6 implementations, it is also possible to carry out experiments in real and virtual labs. Several virtual environments are possible. In this section, we focus on mininet_. mininet_ is an emulation framework developed at Stanford University that leverages the namespaces features of recent Linux kernels. With those namespaces, a single Linux kernel can support a variety of routers and hosts interconnected by virtual links. mininet_ has been used by several universities as an educational tool, but unfortunately it was designed without IPv6 support."
msgstr ""
#: ../../exercises/ipv6.rst:531
msgid "During the last years, `Olivier Tilmans `_ and `Mathieu Jadin `_ have developed the missing piece to enable students to use mininet_ to experiment with IPv6: ipmininet_. ipmininet_ is a python module that provides the classes that are required to automatically configure IPv6 networks with different routing protocols. It is available from PyPi from https://pypi.python.org/ipmininet."
msgstr ""
#: ../../exercises/ipv6.rst:533
msgid "The syntax of IPMininet_ is relatively simple and can be learned by looking at a few examples."
msgstr ""
#: ../../exercises/ipv6.rst:535
msgid "Let us start our exploration of IPv6 routing with a simple network topology that contains two hosts and three routers and uses static routes."
msgstr ""
#: ../../exercises/ipv6.rst:580
msgid "IPMininet_ simplifies the creation of the network topology by providing a simple API. For this, you simply need to declare a class that extends the ``IPTopo`` class."
msgstr ""
#: ../../exercises/ipv6.rst:592
msgid "Then, you need to extend the build method that creates routers and hosts."
msgstr ""
#: ../../exercises/ipv6.rst:607
msgid "Although IPMininet_ can assign prefixes and addresses automatically, we use manually assigned addresses in this example."
msgstr ""
#: ../../exercises/ipv6.rst:609
msgid "We use five /64 IPv6 prefixes in this network topology:"
msgstr ""
#: ../../exercises/ipv6.rst:611
msgid "``2001:db8:1341:1::/64`` on the link between ``a`` and ``r1``"
msgstr ""
#: ../../exercises/ipv6.rst:612
msgid "``2001:db8:1341:12::/64`` on the link between ``r1`` and ``r2``"
msgstr ""
#: ../../exercises/ipv6.rst:613
msgid "``2001:db8:1341:13::/64`` on the link between ``r1`` and ``r3``"
msgstr ""
#: ../../exercises/ipv6.rst:614
msgid "``2001:db8:1341:23::/64`` on the link between ``r2`` and ``r3``"
msgstr ""
#: ../../exercises/ipv6.rst:615
msgid "``2001:db8:1341:1::/64`` on the link between ``b`` and ``r3``"
msgstr ""
#: ../../exercises/ipv6.rst:617
msgid "We can then manually configure the IPv6 addresses of each host/router on each link. Let us start with the links attached to the two hosts."
msgstr ""
#: ../../exercises/ipv6.rst:631
msgid "The same can be done for the three links between the different routers."
msgstr ""
#: ../../exercises/ipv6.rst:648
msgid "With these IP prefixes and the network topology, we can now use IPMininet_ to create the topology and assign the addresses."
msgstr ""
#: ../../exercises/ipv6.rst:656
msgid "We start by creating the objects that correspond to the static routes on the three routers. The second argument of the ``addDaemon`` method is a list of ``StaticRoute`` objects. Each of these objects is created by specifying an IP prefix and a nexthop."
msgstr ""
#: ../../exercises/ipv6.rst:675
msgid "We can now create the hosts and the routers"
msgstr ""
#: ../../exercises/ipv6.rst:682
msgid "With this ``build`` method, we can now launch the network by using the python code below."
msgstr ""
#: ../../exercises/ipv6.rst:694
msgid "The entire script is available from :download:`/exercises/ipmininet_scripts/static-1.py`."
msgstr ""
#: ../../exercises/ipv6.rst:696
msgid "To help students to start using IPMininet, `Mathieu Jadin `_ has created a Vagrant box that launches a Ubuntu virtual machine with all the required software. See https://ipmininet.readthedocs.io/en/latest/install.html for additional information."
msgstr ""
#: ../../exercises/ipv6.rst:698
msgid "Here is a simple example of the utilization of this Vagrant box."
msgstr ""
#: ../../exercises/ipv6.rst:700
msgid "We start the network topology shown above with the ``sudo python script.py`` command. It launches the mininet_ interactive shell that provides several useful commands:"
msgstr ""
#: ../../exercises/ipv6.rst:732
msgid "Some of the standard mininet commands assume the utilisation of IPv4 and do not have a direct IPv6 equivalent. Here are some useful commands."
msgstr ""
#: ../../exercises/ipv6.rst:734
msgid "The ``nodes`` command lists the routers and hosts that have been created in the mininet topology."
msgstr ""
#: ../../exercises/ipv6.rst:743
msgid "The ``links`` command lists the links that have been instantiated and shows that mapping between the named interfaces on each node."
msgstr ""
#: ../../exercises/ipv6.rst:760
msgid "It is possible to execute any of the standard Linux commands to configure the network stack on any of the hosts by prefixing the command with the corresponding host. Remember to always specify ``inet6`` as the address family to retrieve the IPv6 information."
msgstr ""
#: ../../exercises/ipv6.rst:770
msgid "Host ``a`` has two interfaces: the standard loopback interface and a network interface named ``a-eth0`` that is attached to router ``r1``. We can also verify how the IPv6 addresses have been configured:"
msgstr ""
#: ../../exercises/ipv6.rst:784
msgid "On its ``a-eth0`` interface, host ``a`` uses IPv6 address ``2001:db8:1341:1::a/64``. The link local address (``fe80::c44e:26ff:fed9:de6d/64``) will be described in another chapter. Finally, we can check the forwarding table of host ``a``."
msgstr ""
#: ../../exercises/ipv6.rst:794
msgid "There are three routes in this table. The first two correspond to the two prefixes that are used over the ``a-eth0`` interface. These routes are automatically created when an IPv6 address is configured on an interface. The last route is the default route (``::/0``) which points towards ``2001:db8:1341:1::1``, i.e. router ``r1``."
msgstr ""
#: ../../exercises/ipv6.rst:796
msgid "Another useful command is ``xterm`` 'node' that allows to launch a terminal on the specified node. This gives you a interactive shell on any node. You can use it to capture packets with tcpdump_. As an example, let us use :manpage:`traceroute6(8)` to trace the path followed by packets from host ``a`` towards the IPv6 address of host ``b`` i.e. ``2001:db8:1341:3::b``. The output of this command shows that the path passes through routers ``r1``, ``r2`` and ``r3``."
msgstr ""
#: ../../exercises/ipv6.rst:808
msgid "Another interesting mininet_ command is ``pingall`` it allows to check that any host can reach any other host inside the network. It executes a ping from any host to any other host inside the network topology."
msgstr ""
#: ../../exercises/ipv6.rst:819
msgid "When debugging a network, it can be interesting to capture packets using tcpdump_ on specific links to check that they follow the expect. If you use tcpdump_ without any filter, you will capture the packets generated by xterm. To capture packets, you need to specify precise filters that will match the packets of interest. For traceroute6, you need to match the IPv6 packets that contain UDP segments and some ICMPv6 packets. The script below provides a simple filter that you can reuse. It takes one argument: the name of the interface on which tcpdump_ needs to run."
msgstr ""
#: ../../exercises/ipv6.rst:827
msgid "Starting from the :download:`/exercises/ipmininet_scripts/static-1.py` IPMininet_ script, we can explore classical problems when networks are configured with static routes. A first problem is when a router has an incomplete forwarding table. We configure the static routes as shown below. The entire script is available from :download:`/exercises/ipmininet_scripts/static-1-hole.py`."
msgstr ""
#: ../../exercises/ipv6.rst:841
msgid "We first check with ``pingall`` whether the network works correctly."
msgstr ""
#: ../../exercises/ipv6.rst:851
msgid "The problem can be detected by using :manpage:`traceroute6(8)`."
msgstr ""
#: ../../exercises/ipv6.rst:861
msgid "In the output of :manpage:`traceroute6(8)`, a ``!N`` indicates that host ``a`` received from ``2001:db8:1341:12::2``, i.e. router ``r2``, a Network unreachable ICMPv6 message. The forwarding table of ``r2`` confirms the root cause of this problem."
msgstr ""
#: ../../exercises/ipv6.rst:873
msgid "A second problem is when there is a forwarding loop inside the network, i.e. packets sent to a specific destination loop through several routers. With the static routes shown below, router ``r2`` forwards the packets towards ``2001:db8:1341:3::b`` via router ``r1``. The entire script is available from :download:`/exercises/ipmininet_scripts/static-1-loop.py`."
msgstr ""
#: ../../exercises/ipv6.rst:888
msgid "The ``pingall`` command reveals that there is a problem in this network."
msgstr ""
#: ../../exercises/ipv6.rst:898
msgid "We can analyze this configuration problem in more details by using ``traceroute6``. The loop appears clearly."
msgstr ""
#: ../../exercises/ipv6.rst:919
msgid "On host ``b``, the problem is different. The packets that it sends towards host ``a`` do not seem to go beyond router ``r3``."
msgstr ""
#: ../../exercises/ipv6.rst:933
msgid "To debug this problem, let us look at the forwarding table of ``r3``. This router forwards the packets sent to host ``a`` to router ``r1`` that is directly connected to host ``a``."
msgstr ""
#: ../../exercises/ipv6.rst:946
msgid "Unfortunately, when router ``r1`` sends its ICMP HopLimit exceeded message, the destination of this IP packet is ``2001:db8:1341:3::b``. This packet is forward to router ``r2`` that returns the packet back to router ``r1``. The packet loops between the two routers until their HopLimit reaches zero."
msgstr ""
#: ../../exercises/ipv6.rst:965
msgid "IPv6 packets"
msgstr ""
#: ../../exercises/ipv6.rst:967
msgid "To correctly understand the operation of IPv6, it is sometimes important to remember the packet format and how the different fields are used."
msgstr ""
#: ../../exercises/ipv6.rst:971
msgid "The `Next Header` of the IPv6 packet indicates the type of the header that follows the IPv6 packet. IANA_ maintains a list of all the assigned values of this header at https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml"
msgstr ""
#: ../../exercises/ipv6.rst:980
msgid "When an IPv6 router receives a packet that is larger than the Maximum Transmission Unit (MTU) on its outgoing interface, it drops the packet and returns an ICMPv6 message back to the source. Upon reception of this ICMPv6 message, the source will either adjust the size of the packets that it transmits or use IPv6 packet fragmentation. The exercises below show a few examples of the utilization of IPv6 fragmentation."
msgstr ""
#: ../../exercises/ipv6.rst:987
msgid "Network engineers often rely on :manpage:`ping6(8)` to verify the reachability of a remote host or router. :manpage:`ping6(8)` sends ICMPv6 echo request messages and analyzes the received ICMPv6 echo responses. Each echo request message contains an identifier and a sequence number that is returned in the response."
msgstr ""
#: ../../exercises/ipv6.rst:991
msgid "When the :manpage:`ping6(8)` is executed, it sends ICMPv6 echo request messages with increasing sequence numbers."
msgstr ""
#: ../../exercises/ipv6.rst:995
msgid "The :manpage:`traceroute6(8)` software is very useful to debug network problems. It sends a series of UDP segments encapsulated inside IP packets with increasing values of the HopLimit. The first packet has a HotLimit and the first router on the path returns an ICMPv6 HopLimit exceeded message."
msgstr ""
#: ../../exercises/ipv6.rst:999
msgid "When :manpage:`traceroute6(8)` sends UDP segments, it uses the UDP source port as a way to remember the target hop for this specific UDP segment."
msgstr ""
PK4-Y -Y PK H}X 7 cnp3-ebook/index/locale/fr/LC_MESSAGES/exercises/lan.po# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2019 Olivier Bonaventure
# This file is distributed under the same license as the Computer networking : Principles, Protocols and Practice package.
# FIRST AUTHOR , YEAR.
#
msgid ""
msgstr ""
"Project-Id-Version: Computer networking : Principles, Protocols and Practice "
"3\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2021-05-17 09:55+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: Automatically generated\n"
"Language-Team: none\n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../exercises/lan.rst:5
msgid "Local Area Networks: The Spanning Tree Protocol and Virtual LANs"
msgstr ""
#: ../../exercises/lan.rst:18
msgid "Exercises"
msgstr ""
#: ../../exercises/lan.rst:20
msgid "Consider the switched network shown in Fig. 1. What is the spanning tree that will be computed by 802.1d in this network assuming that all links have a unit cost ? Indicate the state of each port."
msgstr ""
#: ../../exercises/lan.rst:26
msgid "Fig. 1. A small network composed of Ethernet switches"
msgstr ""
#: ../../exercises/lan.rst:28
msgid "Consider the switched network shown in Fig. 1. In this network, assume that the LAN between switches S3 and S12 fails. How should the switches update their port/address tables after the link failure ?"
msgstr ""
#: ../../exercises/lan.rst:31
msgid "Consider the switched network shown in the figure below. Compute the Spanning Tree of this network."
msgstr ""
#: ../../exercises/lan.rst:56
msgid "Many enterprise networks are organized with a set of backbone devices interconnected by using a full mesh of links as shown in Fig.2. In this network, what are the benefits and drawbacks of using Ethernet switches and IP routers running OSPF ?"
msgstr ""
#: ../../exercises/lan.rst:62
msgid "Fig. 2. A typical enterprise backbone network"
msgstr ""
#: ../../exercises/lan.rst:64
msgid "In the network depicted in Fig. 3, the host `H0` performs a traceroute toward its peer `H1` (designated by its name) through a network composed of switches and routers. Explain precisely the frames, packets, and segments exchanged since the network was turned on. You may assign addresses if you need to."
msgstr ""
#: ../../exercises/lan.rst:70
msgid "Fig. 3. Host `H0` performs a traceroute towards its peer `H1` through a network composed of switches and routers"
msgstr ""
#: ../../exercises/lan.rst:77
msgid "In the network represented in Fig. 4, can the host `H0` communicate with `H1` and vice-versa? Explain. Add whatever you need in the network to allow them to communicate."
msgstr ""
#: ../../exercises/lan.rst:83
msgid "Fig. 4. Can `H0` and `H1` communicate ?"
msgstr ""
#: ../../exercises/lan.rst:85
msgid "Consider the network depicted in Fig. 5. Both of the hosts `H0` and `H1` have two interfaces: one connected to the switch `S0` and the other one to the switch `S1`. Will the link between `S0` and `S1` ever be used? If so, under which assumptions? Provide a comprehensive answer."
msgstr ""
#: ../../exercises/lan.rst:91
msgid "Fig. 5. Will the link between `S0` and `S1` ever be used?"
msgstr ""
#: ../../exercises/lan.rst:93
msgid "Most commercial Ethernet switches are able to run the Spanning tree protocol independently on each VLAN. What are the benefits of using per-VLAN spanning trees ?"
msgstr ""
#: ../../exercises/lan.rst:115
msgid "Testing the Spanning Tree with IPMininet"
msgstr ""
#: ../../exercises/lan.rst:117
msgid "IPMininet_ can also be used to configure the Spanning Tree protocol on Linux hosts that act as Ethernet switches. Let us consider the simple Ethernet network shown in the figure below."
msgstr ""
#: ../../exercises/lan.rst:140
msgid "This network can be launched with the IPMininet_ script shown below. The entire script is available from :download:`/exercises/ipmininet_scripts/stp.py`."
msgstr ""
#: ../../exercises/lan.rst:193
msgid "The ``addSwitch`` method creates an Ethernet switch. It assigns a random MAC address to each switch and we can configure it with a priority that is used in the high order bits of the switch identifier. We add one IP address to each switch so that we can connect to them on mininet_. In practice, IPMininet_ configures the :manpage:`brtcl(8)` software that implements the Spanning Tree protocol on Linux. We can then create the links, configure their cost if required and launch tcpdump_ to capture the Ethernet frames that contain the messages of the Spanning Tree protocol."
msgstr ""
#: ../../exercises/lan.rst:195
msgid "The network contains five nodes and six links."
msgstr ""
#: ../../exercises/lan.rst:211
msgid "By using :manpage:`brtcl(8)`, we can easily observe the state of the Spanning Tree protocol on the different switches. Let us start with ``s3``, i.e. the root of the Spanning Tree."
msgstr ""
#: ../../exercises/lan.rst:246
msgid "The first part of the output of the :manpage:`brctl(8)` command shows the state of the Spanning Tree software on the switch. The identifier of this switch is ``0003.f63545ab5f79`` and the root switch is itself. There is no root port on this switch since it is the root. The path cost is the cost of the path to reach the root switch, i.e. 0 on the root. Then the switch reports the different timers."
msgstr ""
#: ../../exercises/lan.rst:248
msgid "The second part of the output provides the state of each switch port. Port ``s3-eth1`` is active and forwards data frames (state is set to `forwarding`). This port is a `designated` port. The cost of ``1`` is the cost associated to this interface. The same information is found for port ``s3-eth2``."
msgstr ""
#: ../../exercises/lan.rst:250
msgid "The state of switch ``s9`` is different. The output of :manpage:`brctl(8)` indicates that the root identifier is ``0003.f63545ab5f79`` which is at a distance of ``1`` from switch ``s9``. The root port on ``s9`` is port `1`, i.e. ``s9-eth1``. Two of the ports of this switch forward data packets, the root port and the ``s9-eth3`` which is a designated port. The ``s9-eth2`` port is a blocked port."
msgstr ""
#: ../../exercises/lan.rst:293
msgid ":manpage:`brctl(8)` also maintains a MAC address table that contains the Ethernet addresses that have been learned on each switch port."
msgstr ""
#: ../../exercises/lan.rst:310
msgid "Thanks to the traces collected by tcpdump_, we can easily analyze the messages exchanged by the switches. Here is the fist message sent by switch ``s3``."
msgstr ""
PKh4 PK H}X ; cnp3-ebook/index/locale/fr/LC_MESSAGES/exercises/network.po# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2019 Olivier Bonaventure
# This file is distributed under the same license as the Computer networking
# : Principles, Protocols and Practice package.
# FIRST AUTHOR , 2019.
#
msgid ""
msgstr ""
"Project-Id-Version: Computer networking : Principles, Protocols and Practice "
"3\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2019-10-09 12:39+0000\n"
"PO-Revision-Date: 2021-05-15 11:49+0000\n"
"Last-Translator: Philippe D \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n > 1;\n"
"X-Generator: Weblate 3.9.1\n"
"Generated-By: Babel 2.7.0\n"
#: ../../exercises/network.rst:8
msgid ""
"This is an unpolished draft of the third edition of this e-book. If you "
"find any error or have suggestions to improve the text, please create an "
"issue via https://github.com/CNP3/ebook/issues?milestone=2 or help us by "
"providing pull requests to close the existing issues."
msgstr ""
"Ceci est un brouillon non peaufiné de la troisième édition de cet e-book. Si "
"vous avez trouvé une erreur ou avez des suggestions pour améliorer le texte, "
"merci de créer une *issue* via https://github.com/CNP3/ebook/"
"issues?milestone=2 ou de nous aider en ouvrant des *pull requests* pour "
"fermer les *issues* existantes."
#: ../../exercises/network.rst:12
msgid "Network : Open questions"
msgstr "Réseaux : Questions ouvertes"
#: ../../exercises/network.rst:14
msgid ""
"In your daily life, you also use hierarchical and flat address spaces. "
"Can you provide examples of these two types of addresses and discuss the "
"benefits of using a hierarchical or flat addressing space in this "
"particular context ?"
msgstr ""
"Dans la vie de tous les jours, vous utilisez également des adresses "
"hiérarchiques et des adresses plates. Pouvez-vous donner des exemples pour "
"chacun de ces deux types et discuter des avantages d'utiliser l'un ou "
"l'autre dans ces contextes particuliers ?"
#: ../../exercises/network.rst:16
msgid ""
"The network below uses port forwarding with flat addresses. The network "
"boots and all hosts start one after the other. Explain at each step how "
"the packets are forwarded and how the port forwarding tables of the "
"network nodes are modified. Host `C` sends a packet to host `B`. Some "
"time later, host `A` sends a packet to host `C`. Finally, host `B` sends "
"a packet to host `A`."
msgstr ""
"Le réseau ci-dessous utilise du port forwarding avec des adresses plates. Le "
"réseau démarre et tous les hôtes se lancent l'un après l'autre. Expliquez à "
"chaque étape comment les paquets sont transférés et comment les port "
"forwarding table des noeuds du réseau sont modifiées. L'hôte `C` envoie un "
"paquet à l'hôte `B`. Quelques temps après, l'hôte `A` envoie un paquet à "
"l'hôte `C`. Enfin, l'hôte `B` envoie un paquet à l'hôte `A`."
#: ../../exercises/network.rst:42
msgid ""
"Same question as above, but the network is modified as shown in the "
"figure below."
msgstr ""
"Même question qu'au-dessus, mais cette fois-ci le réseau est modifié comme "
"illustré dans la figure ci-dessous."
#: ../../exercises/network.rst:67
msgid ""
"Routing protocols used in data networks only use positive link weights. "
"What would happen with a distance vector routing protocol in the network "
"below that contains a negative link weight ?"
msgstr ""
"Les protocoles de routage utilisés dans les réseaux de données utilisent "
"uniquement des poids de lien positifs. Que se passerait-il avec un protocole "
"de routage à vecteur de distance dans le réseau ci-dessous qui contient un "
"poids de lien négatif ?"
#: ../../exercises/network.rst:86
msgid ""
"When a network specialist designs a network, one of the problems that he "
"needs to solve is to set the metrics the links in his network. In the "
"USA, the Abilene network interconnects most of the research labs and "
"universities. The figure below shows the topology of this network in "
"2009."
msgstr ""
"Lorsqu'un spécialiste des réseaux conçoit un réseau, l'un des problèmes "
"qu'il doit résoudre est de définir la métrique des liens de son réseau. Aux "
"États-Unis, le réseau Abilene interconnecte la plupart des laboratoires de "
"recherche et des universités. La figure ci-dessous montre la topologie de ce "
"réseau en 2009."
#: ../../exercises/network.rst:92
msgid "The Abilene network"
msgstr "Le réseau Abilene"
#: ../../exercises/network.rst:94
msgid ""
"In this network, assume that all the link weights are set to 1. What is "
"the paths followed by a packet sent by the router located in `Los "
"Angeles` to reach :"
msgstr ""
"Dans ce réseau, considérez que tous les poids des liens sont égaux à 1. Quel "
"est le chemin emprunté par un paquet envoyé par le routeur situé à `Los "
"Angeles` vers :"
#: ../../exercises/network.rst:96
msgid "the router located in `New York`"
msgstr "le routeur situé à `New York`"
#: ../../exercises/network.rst:97
msgid "the router located in `Washington` ?"
msgstr "le routeur situé à `Washington` ?"
#: ../../exercises/network.rst:99
msgid ""
"Is it possible to configure the link metrics so that the packets sent by "
"the router located in `Los Angeles` to the routers located in "
"respectively `New York` and `Washington` do not follow the same path ?"
msgstr ""
"Est-il possible de configurer les valeurs des liaisons de sorte à ce que les "
"paquets envoyés par le routeur situé à `Los Angeles` aux routeurs situés "
"respectivement à `New York` et `Washington` ne suivent pas le même chemin ?"
#: ../../exercises/network.rst:101
msgid ""
"Is it possible to configure the link weights so that the packets sent by "
"the router located in `Los Angeles` to router located in `New York` "
"follow one path while the packets sent by the router located in `New "
"York` to the router located in `Los Angeles` follow a completely "
"different path ?"
msgstr ""
"Est-il possible de configurer les poids des liens de sorte que les paquets "
"envoyés par le routeur situé à `Los Angeles` vers le routeur situé à `New "
"York` suivent un chemin alors que les paquets envoyés par le routeur situé à "
"`New York` vers le routeur situé à `Los Angeles` suivent un chemin "
"complètement différent ?"
#: ../../exercises/network.rst:103
msgid ""
"Assume that the routers located in `Denver` and `Kansas City` need to "
"exchange lots of packets. Can you configure the link metrics such that "
"the link between these two routers does not carry any packet sent by "
"another router in the network ?"
msgstr ""
"Considérez que les routeurs à `Denver` et `Kansas City` doivent échanger "
"beaucoup de paquets. Pouvez-vous configurer les valeurs des liaisons de "
"sorte à ce que le chemin entre ces deux routeurs ne transporte aucun autre "
"paquet envoyé par d'autres routeurs dans le réseau ?"
#: ../../exercises/network.rst:105
msgid ""
"In the five nodes network shown below, can you configure the link metrics"
" so that the packets sent by router `E` to router `A` use link `B->A` "
"while the packets sent by router `B` use links `B->D` and `D->A`?"
msgstr ""
"Dans le réseau de cinq noeuds ci-dessous, pouvez-vous configurer les valeurs "
"des liaisons de sorte à ce que les paquets envoyés par le routeur `E` au "
"routeur `A` utilisent le chemin `B->A` alors que les paquets envoyés par le "
"routeur `B` utilisent les chemins `B->D` et `D->A` ?"
#: ../../exercises/network.rst:129
msgid ""
"In the five nodes network shown above, can you configure the link weights"
" so that the packets sent by router `E` (resp. `F`) follow the `E->B->A` "
"path (resp. `F->D->B->A`) ?"
msgstr ""
"Dans le réseau à cinq nœuds présenté ci-dessus, pouvez-vous configurer les "
"poids des liens de façon à ce que les paquets envoyés par le routeur `E` ("
"resp. `F`) suivent le chemin `E->B->A` (resp. `F->D->B->A`) ?"
#: ../../exercises/network.rst:132 ../../exercises/network.rst:154
#: ../../exercises/network.rst:184 ../../exercises/network.rst:216
msgid "Consider the network shown in the figure below."
msgstr "Considérons à présent le réseau dans la figure ci-dessous."
#: ../../exercises/network.rst:152
msgid ""
"Assuming that the network uses source routing, what are the possible "
"paths from `R1` to `R4` ?"
msgstr ""
"En considérant que le réseau utilise du source routing, quels sont les "
"chemins possible de `R1` à `R4` ?"
#: ../../exercises/network.rst:176
msgid ""
"The network operator uses would like to have the following paths in this "
"network :"
msgstr ""
"L'opérateur du réseau souhaite avoir les chemins suivants dans ce réseau :"
#: ../../exercises/network.rst:178
msgid "`R3->R2->R4->R5` and `R1->R2->R5`"
msgstr "`R3->R2->R4->R5` et `R1->R2->R5`"
#: ../../exercises/network.rst:180
msgid ""
"Is it possible to achieve these paths and if so what are the required "
"forwarding tables ?"
msgstr ""
"Est-il possible de construire ces chemins ? Si oui, à quoi ressemblent les "
"tables de forwarding ?"
#: ../../exercises/network.rst:182 ../../exercises/network.rst:214
msgid "Same question with virtual circuits."
msgstr "Même question avec les circuits virtuels."
#: ../../exercises/network.rst:208 ../../exercises/network.rst:238
msgid "The network operator would like to use the following paths :"
msgstr "L'opérateur réseau souhaite utiliser les chemins suivants :"
#: ../../exercises/network.rst:210
msgid "`R1->R2->R4` and `R3->R2->R5->R4`"
msgstr "`R1->R2->R4` et `R3->R2->R5->R4`"
#: ../../exercises/network.rst:212 ../../exercises/network.rst:242
msgid ""
"Are these paths possible with link-state or distance vector routing ? If "
"yes, how do configure the link weights. If no, explain your answer."
msgstr ""
"Ces chemins sont-ils possibles avec un routage link-state ou à vecteur de "
"distance ? Si oui, comment configurer les poids des liens ? Si non, "
"expliquez votre réponse."
#: ../../exercises/network.rst:240
msgid "`R1->R5->R4` and `R3->R2->R4`"
msgstr "`R1->R5->R4` et`R3->R2->R4`"
#: ../../exercises/network.rst:247
msgid "Network: Discussion questions"
msgstr "Réseau : Questions de discussion"
#: ../../exercises/network.rst:250
msgid ""
"The network below uses port forwarding tables. It has been running for "
"several hours and all hosts have exchanged packets. What is the content "
"of the port forwarding tables ?"
msgstr ""
"Le réseau ci-dessous utilise port forwarding tables. Il fonctionne depuis "
"plusieurs heures et tous les hôtes ont échangé des paquets. Quel est le "
"contenu des forwarding table ?"
#: ../../exercises/network.rst:273
msgid ""
"At this point, a new link is added between `R1` and `R3`. What happens "
"for the forwarding of packets ?"
msgstr ""
"A ce moment, un nouveau lien est ajouté entre `R1` et `R3`. Que se passe-t-"
"il pour le transfert des paquets ?"
#: ../../exercises/network.rst:276
msgid ""
"The network below uses port forwarding tables. What happens if host `A` "
"moves by removing its link with `R1` and replacing it with a link with "
"`R3`? How should networks using port forwarding deal with such mobile "
"hosts ?"
msgstr ""
"Le réseau ci-dessous utilise des port forwarding table. Que se passe-t-il si "
"l'hôte `A` se déplace en supprimant son lien avec `R1` et en le remplaçant "
"par un lien avec `R3` ? Comment les réseaux utilisant le port forwarding "
"doivent-ils traiter de tels hôtes mobiles ?"
#: ../../exercises/network.rst:299
msgid ""
"Some hosts need to be multihomed, i.e. attached to two different network "
"nodes as shown in the figure below."
msgstr ""
"Certains hôtes doivent être multihomed, c'est-à-dire rattachés à deux nœuds "
"de réseau différents, comme le montre la figure ci-dessous."
#: ../../exercises/network.rst:323
msgid "Would this network work correctly with port-forwarding tables if :"
msgstr ""
"Ce réseau fonctionnerait-il correctement avec les port forwarding table si :"
#: ../../exercises/network.rst:325
msgid "Host `A` uses the same flat address for both links."
msgstr "L'hôte `A` utilise la même adresse plate pour les deux liens."
#: ../../exercises/network.rst:326
msgid "Host `A` uses a different flat address on each of its links"
msgstr ""
"L'hôte \"A\" utilise une adresse plate différente sur chacun de ses liens"
#: ../../exercises/network.rst:328
msgid ""
"What are the advantages and drawbacks of flat addresses versus "
"hierarchical addresses ?"
msgstr ""
"Quels sont les avantages et les inconvénients des adresses plates par "
"rapport aux adresses hiérarchiques ?"
#: ../../exercises/network.rst:332
msgid ""
"Let us now consider the transient problems that mainly happen when the "
"network topology changes. For this, consider the network topology shown "
"in the figure below and assume that all routers use a distance vector "
"protocol that uses split horizon."
msgstr ""
"Considérons maintenant les problèmes transitoires qui se produisent "
"principalement lorsque la topologie du réseau change. Pour cela, considérons "
"la topologie du réseau présentée dans la figure ci-dessous et supposons que "
"tous les routeurs utilisent un protocole de vecteur de distance qui utilise "
"le split horizon."
#: ../../exercises/network.rst:356
msgid ""
"If you compute the routing tables of all routers in this network, you "
"would obtain a table such as the table below :"
msgstr ""
"Si vous calculez les tables de routage de tous les routeurs de ce réseau, "
"vous obtiendrez un tableau tel que le tableau ci-dessous :"
#: ../../exercises/network.rst:360
msgid "Destination"
msgstr "Destination"
#: ../../exercises/network.rst:360
msgid "Routes on A"
msgstr "Routes sur A"
#: ../../exercises/network.rst:360
msgid "Routes on B"
msgstr "Routes sur B"
#: ../../exercises/network.rst:360
msgid "Routes on C"
msgstr "Routes sur C"
#: ../../exercises/network.rst:360
msgid "Routes on D"
msgstr "Routes sur D"
#: ../../exercises/network.rst:360
msgid "Routes on E"
msgstr "Routes sur E"
#: ../../exercises/network.rst:363
msgid "A"
msgstr "A"
#: ../../exercises/network.rst:363 ../../exercises/network.rst:364
#: ../../exercises/network.rst:365 ../../exercises/network.rst:366
#: ../../exercises/network.rst:367
msgid "0"
msgstr "0"
#: ../../exercises/network.rst:363
msgid "1 via A"
msgstr "1 via A"
#: ../../exercises/network.rst:363 ../../exercises/network.rst:365
msgid "2 via B"
msgstr "2 via B"
#: ../../exercises/network.rst:363 ../../exercises/network.rst:367
msgid "3 via C"
msgstr "3 via C"
#: ../../exercises/network.rst:363
msgid "4 via D"
msgstr "4 via D"
#: ../../exercises/network.rst:364
msgid "B"
msgstr "B"
#: ../../exercises/network.rst:364
msgid "1 via B"
msgstr "1 via B"
#: ../../exercises/network.rst:364 ../../exercises/network.rst:366
msgid "2 via C"
msgstr "2 via C"
#: ../../exercises/network.rst:364
msgid "3 via D"
msgstr "3 via D"
#: ../../exercises/network.rst:365
msgid "C"
msgstr "C"
#: ../../exercises/network.rst:365
msgid "1 via C"
msgstr "1 via C"
#: ../../exercises/network.rst:365 ../../exercises/network.rst:367
msgid "2 via D"
msgstr "2 via D"
#: ../../exercises/network.rst:366
msgid "D"
msgstr "D"
#: ../../exercises/network.rst:366
msgid "3 via B"
msgstr "3 via B"
#: ../../exercises/network.rst:366
msgid "1 via D"
msgstr "1 via D"
#: ../../exercises/network.rst:367
msgid "E"
msgstr "E"
#: ../../exercises/network.rst:367
msgid "4 via B"
msgstr "4 via B"
#: ../../exercises/network.rst:367
msgid "1 via E"
msgstr "1 via E"
#: ../../exercises/network.rst:370
msgid ""
"Distance vector protocols can operate in two different modes : `periodic "
"updates` and `triggered updates`. `Periodic updates` is the default mode "
"for a distance vector protocol. For example, each router could advertise "
"its distance vector every thirty seconds. With the `triggered updates` a "
"router sends its distance vector when its routing table changes (and "
"periodically when there are no changes)."
msgstr ""
"Les protocoles de vecteur de distance peuvent fonctionner selon deux modes "
"différents : les mises à jour périodiques et les mises à jour déclenchées. "
"Les mises à jour périodiques sont le mode par défaut d'un protocole de "
"vecteur de distance. Par exemple, chaque routeur pourrait annoncer son "
"vecteur de distance toutes les trente secondes. Avec les `mises à jour "
"déclenchées`, un routeur envoie son vecteur de distance lorsque sa table de "
"routage change (et périodiquement lorsqu'il n'y a pas de changement)."
#: ../../exercises/network.rst:372
msgid ""
"Consider a distance vector protocol using split horizon and `periodic "
"updates`. Assume that the link `B-C` fails. `B` and `C` update their "
"local routing table but they will only advertise it at the end of their "
"period. Select one ordering for the `periodic updates` and every time a "
"router sends its distance vector, indicate the vector sent to each "
"neighbor and update the table above. How many periods are required to "
"allow the network to converge to a stable state ?"
msgstr ""
"Considérons un protocole de vecteur de distance utilisant un split horizon "
"et des \"mises à jour périodiques\". Supposons que le lien `B-C` tombe en "
"panne. `B` et `C` mettent à jour leur table de routage locale mais ils ne "
"l'annonceront qu'à la fin de leur période. Choisissez un ordre pour les `"
"mises à jour périodiques` et chaque fois qu'un routeur envoie son vecteur de "
"distance, indiquez le vecteur envoyé à chaque voisin et mettez à jour la "
"table ci-dessus. Combien de périodes sont nécessaires pour permettre au "
"réseau de converger vers un état stable ?"
#: ../../exercises/network.rst:374
msgid ""
"Consider the same distance vector protocol, but now with `triggered "
"updates`. When link `B-C` fails, assume that `B` updates its routing "
"table immediately and sends its distance vector to `A` and `D`. Assume "
"that both `A` and `D` process the received distance vector and that `A` "
"sends its own distance vector, ... Indicate all the distance vectors that"
" are exchanged and update the table above each time a distance vector is "
"sent by a router (and received by other routers) until all routers have "
"learned a new route to each destination. How many distance vector "
"messages must be exchanged until the network converges to a stable state "
"?"
msgstr ""
"Considérons le même protocole de vecteur de distance, mais maintenant avec "
"des \"mises à jour déclenchées\". Lorsque la liaison `B-C` tombe en panne, "
"supposons que `B` mette immédiatement à jour sa table de routage et envoie "
"son vecteur de distance à `A` et `D`. Supposons que `A` et `D` traitent tous "
"deux le vecteur de distance reçu et que `A` envoie son propre vecteur de "
"distance, ... Indiquez tous les vecteurs de distance qui sont échangés et "
"mettez à jour le tableau ci-dessus chaque fois qu'un vecteur de distance est "
"envoyé par un routeur (et reçu par d'autres routeurs) jusqu'à ce que tous "
"les routeurs aient appris une nouvelle route vers chaque destination. "
"Combien de messages de vecteur de distance doivent être échangés jusqu'à ce "
"que le réseau converge vers un état stable ?"
#: ../../exercises/network.rst:376
msgid ""
"Consider again the network shown above. After some time, link state "
"routing converges and all routers compute the same routing tables as "
"above."
msgstr ""
"Considérons à nouveau le réseau illustré ci-dessus. Après un certain temps, "
"le routage link-state converge et tous les routeurs calculent les mêmes "
"tables de routage que ci-dessus."
#: ../../exercises/network.rst:378
msgid ""
"An important difference between OSPF and RIP is that OSPF routers flood "
"link state packets that allow the other routers to recompute their own "
"routing tables while RIP routers exchange distance vectors. Consider that"
" link `B-C` fails and that router `B` is the first to detect the failure."
" At this point, `B` cannot reach anymore `C`, `D` and `E`. `C` cannot "
"reach `B` and `A` anymore."
msgstr ""
"Une différence importante entre OSPF et RIP est que les routeurs OSPF "
"envoient des paquets link-state qui permettent aux autres routeurs de "
"recalculer leurs propres tables de routage alors que les routeurs RIP "
"échangent des vecteurs de distance. Imaginons que le lien `B-C` tombe en "
"panne et que le routeur `B` soit le premier à détecter la panne. À ce moment-"
"là, `B` ne peut plus atteindre `C`, `D` et `E`. `C` ne peut plus atteindre "
"`B` et `A`."
#: ../../exercises/network.rst:380
msgid ""
"Router `B` will flood its updated link state packet through the entire "
"network and all routers will recompute their forwarding table. Upon "
"reception of a link state packet, routers usually first flood the "
"received link-state packet and then recompute their forwarding table. "
"Assume that `B` is the first to recompute its forwarding table, followed "
"by `D`, `A`, `C` and finally `E`."
msgstr ""
"Le routeur `B` flood son paquet link-state mis à jour à travers le réseau "
"entier et tous les routeurs recompileront leur forwarding table. À la "
"réception d'un paquet link-state, les routeurs commencent généralement par "
"flood le paquet link-state reçu, puis recalculent leur forwarding table. "
"Supposons que `B` soit le premier à recompiler sa forwarding table, suivi de "
"`D`, `A`, `C` et enfin `E`."
#: ../../exercises/network.rst:382
msgid ""
"After each update of a forwarding table, verify which pairs of routers "
"are able to exchange packets. Provide your answer using a table similar "
"to the one shown above."
msgstr ""
"Après chaque mise à jour d'une table de transfert, vérifiez quelles paires "
"de routeurs sont capables d'échanger des paquets. Fournissez votre réponse à "
"l'aide d'un tableau similaire à celui présenté ci-dessus."
PKќV V PK H}X ? cnp3-ebook/index/locale/fr/LC_MESSAGES/exercises/reliability.po# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2019 Olivier Bonaventure
# This file is distributed under the same license as the Computer networking
# : Principles, Protocols and Practice package.
# FIRST AUTHOR , 2019.
#
msgid ""
msgstr ""
"Project-Id-Version: Computer networking : Principles, Protocols and Practice "
"3\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2019-10-09 12:39+0000\n"
"PO-Revision-Date: 2021-03-04 19:15+0000\n"
"Last-Translator: Philippe D \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n > 1;\n"
"X-Generator: Weblate 3.9.1\n"
"Generated-By: Babel 2.7.0\n"
#: ../../exercises/reliability.rst:7
msgid "Reliable transfer"
msgstr "Transfert fiable"
#: ../../exercises/reliability.rst:11
msgid "Open questions"
msgstr "Questions ouvertes"
#: ../../exercises/reliability.rst:13
msgid ""
"Consider a `b` bits per second link between two hosts that has a "
"propagation delay of `t` seconds. Derive a formula that computes the time"
" elapsed between the transmission of the first bit of a `d` bytes segment"
" from a sending host and the reception of the last bit of this segment on"
" the receiving host."
msgstr ""
"Soit un câble entre deux hôtes ayant un débit de `b` bits par second et un "
"délai de propagation de `t` secondes. Établissez une formule qui calcule le "
"temps écoulé entre la transmission du premier bit d'un segment de `d` bytes "
"à partir de l'hôte émetteur et la réception du dernier bit de ce segment par "
"l'hôte récepteur."
#: ../../exercises/reliability.rst:16
msgid ""
"Transmission links have sometimes different upstream and downstream "
"bandwidths. A typical example are access networks that use ADSL "
"(Asymmetric Digital Subscriber Lines). Consider two hosts connected via "
"an ADSL link having an upstream bandwidth of 1 Mbps and a downstream "
"bandwidth of 50 Mbps. The propagation delay between the two hosts is 10 "
"milliseconds. What is the maximum throughput, expressed in frames/second,"
" that the alternating bit protocol can obtain on this link if each data "
"frame has a length of 125 bytes and acknowledgments are 25 bytes long. "
"Same question if the protocol is modified to support 1500 bytes long data"
" frames."
msgstr ""
#: ../../exercises/reliability.rst:19
msgid ""
"How would you set the duration of the retransmission timer in the "
"alternating bit protocol ?"
msgstr ""
"Comment fixeriez-vous le délai du timer de retransmission dans le protocole "
"du bit alterné ?"
#: ../../exercises/reliability.rst:22
msgid ""
"A version of the Alternating Bit Protocol supporting variable length "
"frames uses a header that contains the following fields :"
msgstr ""
"Une version du protocole du bit alterné à frame de longueur variable utilise "
"une entête qui contient les champs suivants :"
#: ../../exercises/reliability.rst:24
msgid "a `number` (0 or 1)"
msgstr "un `nombre` (0 ou 1)"
#: ../../exercises/reliability.rst:25
msgid "a `length` field that indicates the length of the data"
msgstr "un champ `length` (taille) qui indique la taille des données"
#: ../../exercises/reliability.rst:26
msgid "a Cyclic Redundancy Check (`CRC`)"
msgstr "un contrôle de redondance cyclique (`CRC`)"
#: ../../exercises/reliability.rst:28
msgid ""
"To speedup the transmission of the frames, a student proposes to compute "
"the CRC over the data part of the segment but not over the header. What "
"do you think of this proposed solution ?"
msgstr ""
"Pour accélérer la transmission des frames, un étudiant propose de calculer "
"le CRC à partir du segment de données et non à partir de l'entête. Que "
"pensez-vous de la solution proposée ?"
#: ../../exercises/reliability.rst:30
msgid ""
"Derive a mathematical expression that provides the `goodput`, i.e. the "
"amount of payload bytes that have been transmitted during a period of "
"time, achieved by the Alternating Bit Protocol assuming that :"
msgstr ""
"Obtenez une expression mathématique pour le `goodput`, c'est-à-dire la "
"quantité de bytes pouvant être transmis pendant une période de temps donnée, "
"issu du protocole du bit alterné en considérant que :"
#: ../../exercises/reliability.rst:32
msgid "Each frame contains `D` bytes of data and `c` bytes of control information"
msgstr ""
"Chaque frame contient `D` bytes de donnée et `c` bytes d'information de "
"contrôle"
#: ../../exercises/reliability.rst:33
msgid "Each acknowledgment contains `c` bytes of control information"
msgstr "Chaque acknowledgment contient `c` bytes de information de contrôle"
#: ../../exercises/reliability.rst:34
msgid ""
"The bandwidth of the two directions of the link is set to `B` bits per "
"second"
msgstr ""
"La bande passante dans les deux directions du câble est de `B` bits par "
"seconde"
#: ../../exercises/reliability.rst:35
msgid "The delay between the two hosts is `s` seconds in both directions"
msgstr "Le délai entre deux hôtes est de `s` secondes dans les deux sens"
#: ../../exercises/reliability.rst:36
msgid "there are no transmission errors"
msgstr "il n'y a pas d'erreur de transmission"
#: ../../exercises/reliability.rst:38
msgid ""
"Consider a go-back-n sender and a go-back receiver that are directly "
"connected with a 10 Mbps link that has a propagation delay of 100 "
"milliseconds. Assume that the retransmission timer is set to three "
"seconds. If the window has a length of 4 segments, draw a time-sequence "
"diagram showing the transmission of 10 segments (each segment contains "
"10000 bits):"
msgstr ""
#: ../../exercises/reliability.rst:40
msgid "when there are no losses"
msgstr "dans le cas où il n'y a pas de pertes"
#: ../../exercises/reliability.rst:41
msgid "when the third and seventh segments are lost"
msgstr "lorsque la troisième et septième frame sont perdues"
#: ../../exercises/reliability.rst:42
msgid "when every second acknowledgment is discarded due to transmission errors"
msgstr ""
"lorsqu'un acknowledgment sur deux est ignoré à cause des erreurs de "
"transmission"
#: ../../exercises/reliability.rst:44
msgid ""
"Same question when using selective repeat instead of go-back-n. Note that"
" the answer is not necessarily the same."
msgstr ""
"Même question en utilisant du selective repeat à la place du go-back-n. "
"Remarquez que la réponse n'est pas nécessairement la même."
#: ../../exercises/reliability.rst:50
msgid "Practice"
msgstr "Exercices"
#: ../../exercises/reliability.rst:52
msgid ""
"Reliable protocols depend on error detection algorithms to detect "
"transmission errors. The following questions will reinforce your "
"understanding of these algorithms."
msgstr ""
"Les protocoles fiables dépendent d'algorithmes de détection des erreurs de "
"transmission. Les questions suivantes vont vous permettre d'approfondir "
"votre compréhension de ces algorithmes."
#: ../../exercises/reliability.rst:54
msgid ""
"Reliable protocols rely on different types of checksums to verify whether"
" frames have been affected by transmission errors. The most frequently "
"used checksums are :"
msgstr ""
"Les protocoles fiables reposent sur différents types de checksums afin de "
"vérifier si des erreurs de transmission ont affecté les frames. Les "
"checksums les plus fréquemment utilisés sont :"
#: ../../exercises/reliability.rst:56
msgid ""
"the Internet checksum used by UDP, TCP and other Internet protocols which"
" is defined in :rfc:`1071` and implemented in various libraries."
msgstr ""
#: ../../exercises/reliability.rst:57
msgid ""
"the 16 bits or the 32 bits Cyclical Redundancy Checks (CRC) that are "
"often used on disks, in zip archives and in datalink layer protocols. See"
" http://rosettacode.org/wiki/CRC-32 for CRC-32 implementations in various"
" languages."
msgstr ""
#: ../../exercises/reliability.rst:58
#, python-format
msgid ""
"the Fletcher checksum [Fletcher1982]_, see "
"https://en.wikipedia.org/wiki/Fletcher%27s_checksum for implementation "
"details"
msgstr ""
"le Fletcher checksum [Fletcher1982]_, voir https://en.wikipedia.org/wiki/"
"Fletcher%27s_checksum pour les détails de son implémentation"
#: ../../exercises/reliability.rst:60
msgid ""
"By using your knowledge of the Internet checksum, can you find a "
"transmission error that will not be detected by this checksum ?"
msgstr ""
"A l'aide de vos connaissances sur l'Internet checksum, pouvez-vous trouver "
"une erreur de transmission qui ne sera pas détectée par le checksum ?"
#: ../../exercises/reliability.rst:62
msgid ""
"The Cyclic Redundancy Checks (CRCs) are efficient error detection codes "
"that are able to detect :"
msgstr ""
"Les contrôles de redondance cyclique (CRC) sont des outils efficaces de "
"détection d'erreurs pouvant détecter :"
#: ../../exercises/reliability.rst:64
msgid "all errors that affect an odd number of bits"
msgstr "toutes les erreurs affectant un nombre impair de bits"
#: ../../exercises/reliability.rst:65
msgid ""
"all errors that affect a sequence of bits which is shorter than the "
"length of the CRC"
msgstr ""
"toutes les errors affectant une séquence de bits plus courte que la longueur "
"du CRC"
#: ../../exercises/reliability.rst:67
msgid ""
"Implement a small software that computes the CRC-32 for a text file. "
"Then, modify the contents of the file to change an even number of bits or"
" an odd number of bits inside the file. When modifying the file, remember"
" that an ASCII file is composed of 8 bits characters that are encoded by "
"using the ASCII table that you can find at : "
"http://en.wikipedia.org/wiki/ASCII . You can also write a small program "
"that produces binary files that are a small variation of each other."
msgstr ""
#: ../../exercises/reliability.rst:69
msgid ""
"Checksums and CRCs should not be confused with secure hash functions such"
" as MD5 defined in :rfc:`1321` or SHA-1 described in :rfc:`4634`. Secure "
"hash functions are used to ensure that files or sometimes "
"packets/segments have not been modified. Secure hash functions aim at "
"detecting malicious changes while checksums and CRCs only detect random "
"transmission errors. Use the `shasum "
"`_ or `md5sum "
"`_ programs on Linux to perform the "
"same tests as above."
msgstr ""
#: ../../exercises/reliability.rst:74
msgid "Discussion questions"
msgstr "Questions de discussion"
#: ../../exercises/reliability.rst:77
msgid ""
"Consider two high-end servers connected back-to-back by using a 10 Gbps "
"interface. If the delay between the two servers is one millisecond, what "
"is the throughput that can be achieved by a reliable protocol that is "
"using 10,000 bits frames and a window of"
msgstr ""
#: ../../exercises/reliability.rst:79
msgid "one frame"
msgstr "une frame"
#: ../../exercises/reliability.rst:80
msgid "ten frames"
msgstr "dix frames"
#: ../../exercises/reliability.rst:81
msgid "hundred frames"
msgstr "cent frames"
#: ../../exercises/reliability.rst:83
msgid ""
"Is it possible for a go-back-n receiver to inter-operate with a "
"selective-repeat sender ? Justify your answer."
msgstr ""
"Est-il possible pour un récepteur go-back-n de fonctionner avec un émetteur "
"selective-repeat ? Justifiez."
#: ../../exercises/reliability.rst:85
msgid ""
"Is it possible for a selective-repeat receiver to inter-operate with a "
"go-back-n sender ? Justify your answer."
msgstr ""
"Est-il possible pour un récepteur selective-repeat de fonctionner avec un "
"émetteur go-back-n ? Justifiez."
#: ../../exercises/reliability.rst:89
msgid ""
"A go-back-n receiver has sent :math:`2^n` data segments. All the segments"
" have been received correctly and in-order by the receiver, but all the "
"returned acknowledgments have been lost. Show by using a time sequence "
"diagram (e.g. by considering a window of four segments) what happens in "
"this case. Can you fix the problem on the go-back-n sender ?"
msgstr ""
#: ../../exercises/reliability.rst:91
msgid ""
"Same question as above, but assume now that both the sender and the "
"receiver implement selective repeat. Note that the answer can be "
"different from the above question."
msgstr ""
PKۦ
0 0 PK H}X D cnp3-ebook/index/locale/fr/LC_MESSAGES/exercises/routing-policies.po# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2019 Olivier Bonaventure
# This file is distributed under the same license as the Computer networking : Principles, Protocols and Practice package.
# FIRST AUTHOR , YEAR.
#
msgid ""
msgstr ""
"Project-Id-Version: Computer networking : Principles, Protocols and Practice "
"3\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2021-05-17 09:55+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: Automatically generated\n"
"Language-Team: none\n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../exercises/routing-policies.rst:5
msgid "Inter-domain routing"
msgstr ""
#: ../../exercises/routing-policies.rst:9
msgid "Exercises"
msgstr ""
#: ../../exercises/routing-policies.rst:24
msgid "Consider the interdomain topology shown in the figure below."
msgstr ""
#: ../../exercises/routing-policies.rst:56
msgid "In this network, what are the paths :"
msgstr ""
#: ../../exercises/routing-policies.rst:58
msgid "from `AS1` to `AS4`"
msgstr ""
#: ../../exercises/routing-policies.rst:59
msgid "from `AS4` to `AS2`"
msgstr ""
#: ../../exercises/routing-policies.rst:60
msgid "from `AS4` to `AS1`"
msgstr ""
#: ../../exercises/routing-policies.rst:63
#: ../../exercises/routing-policies.rst:96
msgid "Consider the interdomain topology shown in the figure below. Assuming, that `AS1` advertises prefix ``2001:db8:1::/48``, `AS2` prefix ``2001:db8:2::/48``, ... compute the routing tables of the different ASes."
msgstr ""
#: ../../exercises/routing-policies.rst:93
msgid "Are all ASes capable of reaching all the other ASes in this simple Internet ?"
msgstr ""
#: ../../exercises/routing-policies.rst:128
msgid "In this internet, some ASes cannot reach all other ASes. Can you fix the problem by adding one shared-cost peering link or one customer-provider peering link ?"
msgstr ""
#: ../../exercises/routing-policies.rst:133
msgid "Consider the network below in which a stub domain, `AS456`, is connected to two providers `AS123` and `AS789`. `AS456` advertises its prefix to both its providers. On the other hand, `AS123` advertises ``2001:db8:dead::/48`` while `AS789` advertises ``2001:db8:beef::/48`` and ``2001:db8:dead:cafe::/63``. Via which provider will the packets destined to ``2001:db8:dead:cafe::1`` will be received by `AS456` ?"
msgstr ""
#: ../../exercises/routing-policies.rst:141
msgid "Should `AS123` change its configuration ?"
msgstr ""
#: ../../exercises/routing-policies.rst:143
msgid "Consider that the AS stub (`AS456`) shown in the figure below decides to advertise two ``/48`` prefixes instead of its allocated ``/47`` prefix."
msgstr ""
#: ../../exercises/routing-policies.rst:151
msgid "Via which provider does `AS456` receive the packets destined to ``2001:db8:caff::bb`` and ``2001:db8:cafe::aa`` ?"
msgstr ""
#: ../../exercises/routing-policies.rst:153
msgid "How is the reachability of these addresses affected when link `R1`-`R3` fails ?"
msgstr ""
#: ../../exercises/routing-policies.rst:155
msgid "Propose a configuration on R1 that achieves the same objective as the one shown in the figure but also preserves the reachability of all IP addresses inside `AS456` if one of `AS456`'s interdomain links fails."
msgstr ""
#: ../../exercises/routing-policies.rst:157
msgid "Consider the network shown below. In this network, the metric of each link is set to `1` except link `A-B` whose metric is set to `4` in both directions. In this network, there are two paths with the same cost between `D` and `C`. Old routers would randomly select one of these equal cost paths and install it in their forwarding table. Recent routers are able to use up to `N` equal cost paths towards the same destination."
msgstr ""
#: ../../exercises/routing-policies.rst:163
msgid "A simple network"
msgstr ""
#: ../../exercises/routing-policies.rst:165
msgid "On recent routers, a lookup in the forwarding table for a destination address returns a set of outgoing interfaces. How would you design an algorithm that selects the outgoing interface used for each packet, knowing that to avoid reordering, all segments of a given TCP connection should follow the same path ?"
msgstr ""
#: ../../exercises/routing-policies.rst:167
msgid "A ``traceroute6`` towards ``ipv6.google.com`` provides the following output :"
msgstr ""
#: ../../exercises/routing-policies.rst:191
msgid "Can you explain why at the eighth, ninth and tenth hopes several IPv6 addresses are reported in the ``traceroute6`` output ?"
msgstr ""
#: ../../exercises/routing-policies.rst:193
msgid "`Section 3.3 `_ of :rfc:`4443` explains two different reasons why an IPv6 enabled device could generate an ICMPv6 Time Exceeded message. Explain when a router could generate such a message with ``Code==0`` and when a host could generate such a message with ``Code==1``."
msgstr ""
#: ../../exercises/routing-policies.rst:195
msgid "`Section 3.1 `_ of :rfc:`4443` seven different Codes for the ICMPv6 Destination Unreachable Message. Under which circumstances would a router generate such an ICMPv6 message with :"
msgstr ""
#: ../../exercises/routing-policies.rst:197
msgid "``Code==0``"
msgstr ""
#: ../../exercises/routing-policies.rst:213
msgid "An ICMPv6 error message includes in its message body the beginning of the IPv6 packet that triggered this error. How many bytes of the original packet must be returned to allow the host to recover the original source and destination addresses and source and destination ports of the packet that caused the error ?"
msgstr ""
PK%wT T PK H}X E cnp3-ebook/index/locale/fr/LC_MESSAGES/exercises/routing-protocols.po# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2019 Olivier Bonaventure
# This file is distributed under the same license as the Computer networking : Principles, Protocols and Practice package.
# FIRST AUTHOR , YEAR.
#
msgid ""
msgstr ""
"Project-Id-Version: Computer networking : Principles, Protocols and Practice "
"3\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2021-05-17 09:55+0200\n"
"PO-Revision-Date: 2021-08-27 14:47+0000\n"
"Last-Translator: Anthony Gego \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n > 1;\n"
"X-Generator: Weblate 3.9.1\n"
#: ../../exercises/routing-protocols.rst:7
msgid "Exploring routing protocols"
msgstr "Découverte des protocoles de routage"
#: ../../exercises/routing-protocols.rst:9
msgid "Routing protocols play a key role in the Internet since they ensure that all the routers have valid routing tables. In this section, we use IPMininet_ to explore how intradomain and interdomain routing protocols work in practice. IPMininet_ adds an abstraction layer above the actual configuration of the FRRouting daemons that implement these routing protocols."
msgstr ""
#: ../../exercises/routing-protocols.rst:13
msgid "Exploring OSPF"
msgstr ""
#: ../../exercises/routing-protocols.rst:15
msgid "We first use IPMininet_ to explore the operation of OSPFv3, the version of OSPF that supports IPv6. We create a simple network with three routers and two hosts as shown in the figure below."
msgstr ""
#: ../../exercises/routing-protocols.rst:80
msgid "The code is very simple as by default IPMininet_ enables OSPF on routers. We introduce two specific parameters. First, the interface that connects a router to a host is flagged as a passive interface (``igp_passive=True``). This indicates to the router that there are no other routers attached to this interface and that it should not send or accept OSPF Hello messages on this interface. The second configuration parameter is that we set the IGP cost on each link."
msgstr ""
#: ../../exercises/routing-protocols.rst:83
msgid "We use this mininet_ topology to collect packet traces that show the packets that OSPF routers exchange. For this, we add the following ``post_build`` method that IPMininet_ starts after having constructed the network and before launching the daemons. It simply starts tcpdump_ on each router to collect the first 100 OSPF packets that they send/receive."
msgstr ""
#: ../../exercises/routing-protocols.rst:94
msgid "Finally, we can start the IPMininet_ topology and launch the daemons. The entire script is available from :download:`/exercises/ipmininet_scripts/ospf6.py`."
msgstr ""
#: ../../exercises/routing-protocols.rst:106
msgid "The script starts the routers and hosts."
msgstr ""
#: ../../exercises/routing-protocols.rst:120
msgid "We can easily verify that the paths used to forward packets are the expected ones according to the configured IGP weights."
msgstr ""
#: ../../exercises/routing-protocols.rst:135
msgid "We can also connect to the OSPFv3 daemon running on the routers to observe its state. For this, we use the ``noecho r1 telnet localhost ospf6d`` command."
msgstr ""
#: ../../exercises/routing-protocols.rst:152
msgid "The password to access this daemon is `zebra`. It supports various commands that are described in the `FRRouting documentation `_ We briefly illustrate some of them below."
msgstr ""
#: ../../exercises/routing-protocols.rst:175
msgid "The ``show ipv6 ospf6`` command reports the general state of the OSPFv3 daemon. The ``show ipv6 ospf6 neighbor`` command reports the state of the connected neighbors."
msgstr ""
#: ../../exercises/routing-protocols.rst:186
msgid "In its output, we see that ``r1`` is attached to two different routers. Finally, the ``show ipv6 ospf6 database`` returns the full OSPFv3 database with all the link state information that was distributed by OSPFv3."
msgstr ""
#: ../../exercises/routing-protocols.rst:239
msgid "We can also use the packet traces that were collected by tcpdump_ to observe the packets that the OSPFv3 daemons exchange. OSPFv3 is a more complex protocol that the basic link state protocol that we have described in this book, but you should be able to understand some of these packets. The packet traces are available as :download:`/exercises/traces/ospf6-r1-trace.pcap`, :download:`/exercises/traces/ospf6-r2-trace.pcap` and :download:`/exercises/traces/ospf6-r3-trace.pcap`. Here are a few interesting packets collected on router ``r1``."
msgstr ""
#: ../../exercises/routing-protocols.rst:241
msgid "The first packet that this router received his a Hello packet that was sent by router ``r2``. There are several interesting points to note about this packet. First, its source address is the link-local address (``fe80::68bc:b4ff:fe19:42b7``) of router ``r2`` on this interface. The destination address of the packet is reserved IPv6 multicast address for OSPFv3, i.e. ``ff02::5``. The Hop Limit of the packet is set to 1 and OSFPv3 uses a next header of type 89."
msgstr ""
#: ../../exercises/routing-protocols.rst:245
msgid "The Hello packet contains some parameters such as the `Hello interval` that is set to 1 second. This interval is the delay between the transmission of successive Hello packets. Since the `Router Dead Interval` is set to 3 seconds, the router will consider the link as down if it does not receive Hello packets during a period of 3 seconds. The second packet of the trace is sent by router ``r1``."
msgstr ""
#: ../../exercises/routing-protocols.rst:249
msgid "We can then observe the Database description packet that is sent by routers to announce the state of their OSPFv3 database. The details of this packet are beyond the scope of this simple exercise."
msgstr ""
#: ../../exercises/routing-protocols.rst:253
msgid "This packet is updated when new information is added in the router's OSPFv3 database. A few seconds router, this router sends another Database description packet that announces more information."
msgstr ""
#: ../../exercises/routing-protocols.rst:257
msgid "Router ``r2`` reacts to this updated Database description packet by requesting the link state information that it does not already know. For this, it sends a `LS Request` packet."
msgstr ""
#: ../../exercises/routing-protocols.rst:261
msgid "The requested information is sent in a `LS Update` packet shortly after that."
msgstr ""
#: ../../exercises/routing-protocols.rst:265
msgid "OSPFv3 also includes `LS Acknowledge` packets that acknowledge the correct reception of link state information."
msgstr ""
#: ../../exercises/routing-protocols.rst:269
msgid "A more detailed discussion of the packets that routing protocols exchange may be found in [Goralski2009]_."
msgstr ""
#: ../../exercises/routing-protocols.rst:272
msgid "Exploring RIP"
msgstr ""
#: ../../exercises/routing-protocols.rst:274
msgid "IPMininet_ can also be used to perform experiments with RIP. A simple script that uses RIPng is provided below."
msgstr ""
#: ../../exercises/routing-protocols.rst:336
msgid "As RIP messages are exchanged using UDP on port 521, we filter this port in the tcpdump_ trace. RIPng distributes the routes and our two hosts can exchange packets. The entire script is available from :download:`/exercises/ipmininet_scripts/ripng.py`."
msgstr ""
#: ../../exercises/routing-protocols.rst:357
msgid "We can observe the RIPng messages that are exchanged over the network. :rfc:`2080` defines two types of RIPng messages:"
msgstr ""
#: ../../exercises/routing-protocols.rst:359
msgid "the requests"
msgstr ""
#: ../../exercises/routing-protocols.rst:360
msgid "the responses that contain the router's routing table"
msgstr ""
#: ../../exercises/routing-protocols.rst:362
msgid "When a router starts, it sends a request message. This is illustrated in the figure below with the first message sent by router ``r2``. This message is sent inside an IPv6 packet whose source address is the link-local address of the router and the destination address is ``ff02::9`` which is the reserved multicast address for RIPng."
msgstr ""
#: ../../exercises/routing-protocols.rst:366
msgid "Router ``r2`` receives a similar request from ``fe80::481a:48ff:fed7:292e`` and replies by sending its routing table in a response message. Note that this message is sent to the link-local address of the requesting router."
msgstr ""
#: ../../exercises/routing-protocols.rst:370
msgid "Later, router ``r2`` will regularly transmit its distance vector inside an unsolicited response message that is sent towards the IPv7 multicast address ``ff02::9``."
msgstr ""
#: ../../exercises/routing-protocols.rst:374
msgid "The packet traces collected on the three routers of this example are available from :download:`/exercises/traces/ripng-r1-trace.pcap`, :download:`/exercises/traces/ripng-r2-trace.pcap` and :download:`/exercises/traces/ripng-r3-trace.pcap`."
msgstr ""
#: ../../exercises/routing-protocols.rst:378
msgid "Exploring BGP"
msgstr ""
#: ../../exercises/routing-protocols.rst:380
msgid "To explore the configuration of BGP, let us consider a network that contains three ASes: ``AS1``, ``AS2`` and ``AS3``. To simplify the tests, we identify one host inside each of these ASes."
msgstr ""
#: ../../exercises/routing-protocols.rst:434
msgid "As in the previous examples, we create the routers and associate one IPv6 prefix to each AS:"
msgstr ""
#: ../../exercises/routing-protocols.rst:436
msgid "``AS1`` is assigned ``2001:cafe:1::/48``"
msgstr ""
#: ../../exercises/routing-protocols.rst:437
msgid "``AS2`` is assigned ``2001:cafe:2::/48``"
msgstr ""
#: ../../exercises/routing-protocols.rst:438
msgid "``AS3`` is assigned ``2001:cafe:3::/48``"
msgstr ""
#: ../../exercises/routing-protocols.rst:454
msgid "The `addDaemon` method adds a BGP daemon on each router and configures it to advertise the IPv6 prefix allocated to this AS. We then create all the links and manually assign one IPv6 subnet to each link and one IPv6 address to each interface. For the interdomain links, we use an IPv6 prefix that belongs to one of the attached ASes."
msgstr ""
#: ../../exercises/routing-protocols.rst:491
msgid "The last step is to specify to which AS each router belongs and to configure the eBGP sessions and their routing policies. IPMininet_ abstracts most of the complexity of the configuration of these policies by supporting two policies"
msgstr ""
#: ../../exercises/routing-protocols.rst:510
msgid "The script ends by launching the full topology. The entire script is available from :download:`/exercises/ipmininet_scripts/ebgp-simple.py`."
msgstr ""
#: ../../exercises/routing-protocols.rst:512
msgid "We can now run this simple network."
msgstr ""
#: ../../exercises/routing-protocols.rst:518
msgid "If you launch the script and immediately type ``ping6all`` to check the connectivity, you might obtained the following result."
msgstr ""
#: ../../exercises/routing-protocols.rst:529
msgid "Remember that BGP is a distributed protocol and that it takes some time to launch the daemons and exchange the messages. After some time, the same command will confirm that everything works as expected."
msgstr ""
#: ../../exercises/routing-protocols.rst:540
msgid "We can also use :manpage:`traceroute6(8)` to check the path followed by the packets. Before doing that, think about the configuration of the BGP routing policies and try to predict the output of :manpage:`traceroute6(8)`. This is a good exercise to check your understanding of BGP."
msgstr ""
#: ../../exercises/routing-protocols.rst:542
msgid "We have configured the following addresses on the hosts."
msgstr ""
#: ../../exercises/routing-protocols.rst:559
msgid "We can now explore the routes in this small Internet. Host ``h1`` can reach directly host ``h3``."
msgstr ""
#: ../../exercises/routing-protocols.rst:569
msgid "Note that the path preferred by ``AS3`` to reach ``AS1`` is different."
msgstr ""
#: ../../exercises/routing-protocols.rst:581
msgid "The same applies for the paths between ``h1`` and ``h2``"
msgstr ""
#: ../../exercises/routing-protocols.rst:598
msgid "Besides :manpage:`ping6(8)` and :manpage:`traceroute6(8)`, it is also useful to interact with the BGP daemon that runs on each of our routers. This is done by connecting on the Command Line Interface of the BGP router using telnet."
msgstr ""
#: ../../exercises/routing-protocols.rst:619
msgid "The password for the BGP daemon is `zebra`. The `noecho` command indicates that mininet_ does not need to echo the characters that you type. You then enter the Quagga VTY that enables you to type commands. The `help` commands gives you some information about the available commands as well as `?`."
msgstr ""
#: ../../exercises/routing-protocols.rst:649
msgid "In these exercises, we mainly consider the ``show`` that extracts information from the BGP daemon. We type `show bgp` and press the `tabulation` key to see the available commands in the `show bgp`."
msgstr ""
#: ../../exercises/routing-protocols.rst:663
msgid "A useful command to start is `show bgp summary` which provides a summary of the state of the BGP daemon."
msgstr ""
#: ../../exercises/routing-protocols.rst:685
msgid "This router (`as1`) has two BGP neighbors: ``2001:cafe:1:12::2`` and ``2001:cafe:1:13::3``. Both BGP sessions are established using the current version of the protocol (version 4). About 50 messages were sent/received over each session. These messages are mainly the BGP Keepalive messages that are exchanged every 30 seconds. The last column indicates that two prefixes were received over each session. We can see more details about these two eBGP sessions with the `show bgp neighbors` command."
msgstr ""
#: ../../exercises/routing-protocols.rst:812
msgid "We can now observe the BGP-Loc-RIB of the router with the ``show bgp ipv6 command`` command."
msgstr ""
#: ../../exercises/routing-protocols.rst:838
msgid "It is interesting to look at the output of this command in details. Router `as1` has routes for three different IPv6 prefixes. The first prefix is its own prefix, ``2001:cafe:1::/48``. It has no nexthop since this prefix is originated by the router. Then, `as1` has received two paths for ``2001:cafe:2::/48``. In the BGP Loc-RIB, the `>` character indicates the best route according to the BGP decision process. ``2001:cafe:2::/48`` was learned over two different BGP sessions:"
msgstr ""
#: ../../exercises/routing-protocols.rst:840
msgid "the eBGP session with ``fe80::3c81:2eff:fe19:465d`` with an AS-Path of ``AS3:AS2`` (see last column)"
msgstr ""
#: ../../exercises/routing-protocols.rst:841
msgid "the eBGP session with ``fe80::c001:dcff:fe49:a512`` with an AS-Path of ``AS2`` (see last column)"
msgstr ""
#: ../../exercises/routing-protocols.rst:843
msgid "The first of these two routes is preferred as indicated by the `>` character because it has a higher ``local-preference` (150) than the second one (100). For prefix ``2001:cafe:3::/48``, the route learned via ``fe80::3c81:2eff:fe19:465d`` is also preferred for the same reason."
msgstr ""
#: ../../exercises/routing-protocols.rst:845
msgid "IPMininet_ also allows to explore the dynamics of BGP by looking at the packets that the routers exchange. For this, we slightly modify the example above and add delays to the interdomain links as follows."
msgstr ""
#: ../../exercises/routing-protocols.rst:854
msgid "We also add a ``post_build`` method to launch tcpdump_ and capture the BGP packets exchanged by the routers. A BGP session runs over a TCP connection. Let us examine a few of the BGP messages exchanged on the BGP session between ``AS1`` and ``AS2``. The traces collected on the three routers are available from :download:`/exercises/traces/bgp-as1-trace.pcap`, :download:`/exercises/traces/bgp-as2-trace.pcap` and :download:`/exercises/traces/bgp-as2-trace.pcap`."
msgstr ""
#: ../../exercises/routing-protocols.rst:856
msgid "The BGP session starts with a TCP three-way handshake. Once the session has been established, both BGP daemons send an ``OPEN`` message describing their capabilities and the BGP extensions that it supports. The details of these extensions go beyond the scope of this book. However, it is important to note that the ``OPEN`` message contains the ``AS`` number of the router that sends the message and its identifier as a 32 bits IPv4 address. This router identifier uniquely identifies the router. The last mandatory parameter of the ``OPEN`` message is the `Hold Time`, i.e. the maximum delay between two successive messages over this BGP session. A BGP router should send ``KEEPALIVE`` messages every one third of the `Hold Time` to keep the session up."
msgstr ""
#: ../../exercises/routing-protocols.rst:861
msgid "The ``UPDATE`` message can be used to withdraw and advertise routes. The packet below is sent by ``AS2`` to advertise its route towards `2001:cafe:2::/48` on the BGP session with ``AS1``."
msgstr ""
#: ../../exercises/routing-protocols.rst:866
msgid "Another interesting utilization of IPMininet_ is to explore how routers react to link failures. We start from the same network as with the previous example and disable the link between ``AS2`` and ``AS3``. For this, we log on one of the two routers and issue the following commands."
msgstr ""
#: ../../exercises/routing-protocols.rst:898
msgid "We first connect to the BGP daemon on router `as2`. In addition to the `show` commands that have been described earlier, the router also supports privileged commands that can change its configuration. Before executing these commands, we must enter the privileged mode with the `enable` command. On production routers, this command requires a password to verify the credentials of the network administrator. The `#` prompt indicates that we are allowed to execute privileged commands. We first check the state of the BGP sessions with the `show bgp summary` commands. There are two BGP sessions configured on this router."
msgstr ""
#: ../../exercises/routing-protocols.rst:900
msgid "We can now disable one of the BGP sessions on router `as2` as follows."
msgstr ""
#: ../../exercises/routing-protocols.rst:911
msgid "We start indicate that we will use the terminal to change the router configuration with `configure terminal`. We then enter the BGP part of the configuration with `router bgp 2` (`2` is the AS number of `as2`). Then we use the `neighbor 2001:cafe:2:23::3 shutdown` that takes as parameter the IP address of the peer of the session that we want to stop. We then leave the BGP part of the configuration (first `exit`) and the configuration menu (second `exit` command). At this point, the BGP session between ``AS2`` and ``AS3`` is down."
msgstr ""
#: ../../exercises/routing-protocols.rst:930
msgid "Without a BGP session between ``AS2`` and ``AS3``, there are reachability problems in this simple Internet."
msgstr ""
#: ../../exercises/routing-protocols.rst:941
msgid "We can fix them by enabling again the BGP session with the `no neighbor 2001:cafe:2:23::3 shutdown` command."
msgstr ""
#: ../../exercises/routing-protocols.rst:989
msgid "Exercises"
msgstr ""
#: ../../exercises/routing-protocols.rst:991
msgid "We can use IPMininet_ to prepare some networks with problems that need to be analyzed and corrected."
msgstr ""
#: ../../exercises/routing-protocols.rst:993
msgid "Our first example is a small Internet with 5 ASes. A subset of the script that configures this network is shown below. There is one host attached to each AS and this host has the same number as its AS. The entire script is available from :download:`/exercises/ipmininet_scripts/ebgp-bug.py`."
msgstr ""
#: ../../exercises/routing-protocols.rst:1016
msgid "When this network is launched, `ping6all` reports connectivity problems. Hosts `h1` and `h4` cannot exchange packets. Can you fix the problem by changing the routing policy used on only one interdomain link ? Justify your answer"
msgstr ""
#: ../../exercises/routing-protocols.rst:1029
msgid "Another interesting utilization IPMininet_ is to explore the impact of a link failure. We start from a small variant of the above topology."
msgstr ""
#: ../../exercises/routing-protocols.rst:1052
msgid "When this network starts, all hosts can reach all other hosts."
msgstr ""
#: ../../exercises/routing-protocols.rst:1066
msgid "Draw the network and try to predict how it will react to a shutdown of any of the customer-provider links ?"
msgstr ""
#: ../../exercises/routing-protocols.rst:1068
msgid "What are the BGP messages that will be exchanged when the link between ``AS1`` and ``AS2`` fails ? How does this affect the reachability of the different hosts ?"
msgstr ""
#: ../../exercises/routing-protocols.rst:1098
msgid "What are the BGP messages that will be exchanged when the link between ``AS1`` and ``AS3`` fails ? How does this affect the reachability of the different hosts ?"
msgstr ""
#: ../../exercises/routing-protocols.rst:1128
msgid "What are the BGP messages that will be exchanged when the link between ``AS1`` and ``AS5`` fails ? How does this affect the reachability of the different hosts ?"
msgstr ""
#: ../../exercises/routing-protocols.rst:1158
msgid "What are the BGP messages that will be exchanged when the link between ``AS3`` and ``AS4`` fails ? How does this affect the reachability of the different hosts ?"
msgstr ""
#: ../../exercises/routing-protocols.rst:1190
msgid "Let us now consider another example. The network contains nine ASes with one host per AS. Assuming that ``AS9`` announces prefix `p9` and that ``AS2`` announces prefix `p2`."
msgstr ""
#: ../../exercises/routing-protocols.rst:1228
msgid "What is the Loc-RIB of ``AS6`` for prefix `p9` ? Indicate which is the best route towards this prefix."
msgstr ""
#: ../../exercises/routing-protocols.rst:1230
msgid "What is the Loc-RIB of ``AS9`` for prefix `p2` ? Indicate which is the best route towards this prefix."
msgstr ""
#: ../../exercises/routing-protocols.rst:1232
msgid "The network below contains nine ASes with one host per AS. Assuming that ``AS1`` announces prefix `p1` and that ``AS2`` announces prefix `p2`."
msgstr ""
#: ../../exercises/routing-protocols.rst:1265
msgid "What is the Loc-RIB of ``AS6`` for prefix `p1` ? Indicate which is the best route towards this prefix."
msgstr ""
#: ../../exercises/routing-protocols.rst:1267
msgid "What is the Loc-RIB of ``AS8`` for prefix `p2` ? Indicate which is the best route towards this prefix."
msgstr ""
#: ../../exercises/routing-protocols.rst:1272
msgid "Let us now consider another example, also implemented using an IPMininet_ script. The network contains eight ASes with one host per AS. This small Internet is shown below and the script is available from :download:`/exercises/ipmininet_scripts/ebgp-bug-3.py`."
msgstr ""
#: ../../exercises/routing-protocols.rst:1312
msgid "The network does not provide a full connectivity. The hosts attached to ``AS5`` cannot ping the hosts attached to ``AS8``."
msgstr ""
#: ../../exercises/routing-protocols.rst:1327
msgid "What is the path that packets follow from a host attached to ``AS1`` to a host attached to ``AS8`` ?"
msgstr ""
#: ../../exercises/routing-protocols.rst:1339
msgid "What is the path that packets follow from a host attached to ``AS8`` to a host attached to ``AS1`` ?"
msgstr ""
#: ../../exercises/routing-protocols.rst:1351
msgid "What is the path that packets follow from a host attached to ``AS8`` to a host attached to ``AS2`` ?"
msgstr ""
#: ../../exercises/routing-protocols.rst:1364
msgid "What is the path that packets follow from a host attached to ``AS2`` to a host attached to ``AS7`` ?"
msgstr ""
#: ../../exercises/routing-protocols.rst:1375
msgid "We now disable the interdomain link between ``AS3`` and ``AS4``. What are the hosts that ``AS1``, ``AS5`` and ``AS6`` are still able to ping ?"
msgstr ""
PKPIi^ i^ PK H}X ; cnp3-ebook/index/locale/fr/LC_MESSAGES/exercises/sockets.po# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2019 Olivier Bonaventure
# This file is distributed under the same license as the Computer networking
# : Principles, Protocols and Practice package.
# FIRST AUTHOR , 2019.
#
msgid ""
msgstr ""
"Project-Id-Version: Computer networking : Principles, Protocols and Practice "
"3\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2019-10-09 12:39+0000\n"
"PO-Revision-Date: 2021-08-27 14:47+0000\n"
"Last-Translator: Anthony Gego \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n > 1;\n"
"X-Generator: Weblate 3.9.1\n"
"Generated-By: Babel 2.7.0\n"
#: ../../exercises/sockets.rst:4
msgid "Using sockets for inter-process communication"
msgstr "Utilisation de sockets pour la communication interprocessus"
#: ../../exercises/sockets.rst:7
msgid ""
"Popular operating systems allow to isolate different programs by "
"executing them in separate `processes`. A :term:`socket` is a tool "
"provided by the operating system that allows two separated processes to "
"communicate with each other. A socket takes the form of a file descriptor"
" and can be seen as a communication pipe through which the communicating "
"processes can exchange arbitrary information. In order to receive a "
"message, a process must be attached to a specific :term:`address` that "
"the peer can use to reach it."
msgstr ""
"Les systèmes d'exploitation courants permettent d'isoler différents "
"programmes en les exécutant dans des `processus` distincts. Un :term:`socket`"
" est un outil fourni par le système d'exploitation qui permet à deux "
"processus séparés de communiquer entre eux. Un socket prend la forme d'un "
"descripteur de fichier et peut être considéré comme un tuyau de "
"communication par lequel les processus communicants peuvent échanger des "
"informations arbitraires. Pour recevoir un message, un processus doit être "
"attaché à une :term:`adresse` spécifique que l'homologue peut utiliser pour "
"l'atteindre."
#: ../../exercises/sockets.rst:52
msgid ""
"The socket is a powerful abstraction as it allows processes to "
"communicate even if they are located on different computers. In this "
"specific cases, the inter-processes communication will go through a "
"network."
msgstr ""
"Le socket est une abstraction puissante car il permet aux processus de "
"communiquer même s'ils sont situés sur des ordinateurs différents. Dans ce "
"cas précis, la communication inter-processus passe par un réseau."
#: ../../exercises/sockets.rst:98
msgid ""
"Networked applications were usually implemented by using the "
":term:`socket` :term:`API`. This API was designed when TCP/IP was first "
"implemented in the `Unix BSD`_ operating system [Sechrest]_ [LFJLMT]_, "
"and has served as the model for many APIs between applications and the "
"networking stack in an operating system. Although the socket API is very "
"popular, other APIs have also been developed. For example, the STREAMS "
"API has been added to several Unix System V variants [Rago1993]_. The "
"socket API is supported by most programming languages and several "
"textbooks have been devoted to it. Users of the C language can consult "
"[DC2009]_, [Stevens1998]_, [SFR2004]_ or [Kerrisk2010]_. The Java "
"implementation of the socket API is described in [CD2008]_ and in the "
"`Java tutorial "
"`_."
" In this section, we will use the C socket API to illustrate the key "
"concepts."
msgstr ""
"Les applications en réseau sont généralement mises en œuvre à l'aide de "
"l'interface :term:`socket` :term:`API`. Cette API a été conçue lorsque TCP/"
"IP a été implémenté pour la première fois dans le système d'exploitation `"
"Unix BSD`_ [Sechrest]_ [LFJLMT]_, et a servi de modèle pour de nombreuses "
"API entre les applications et la pile réseau dans un système d'exploitation. "
"Bien que l'API socket soit très populaire, d'autres API ont également été "
"développées. Par exemple, l'API STREAMS a été ajoutée à plusieurs variantes "
"d'Unix System V [Rago1993]_. L'API socket est supportée par la plupart des "
"langages de programmation et plusieurs manuels lui ont été consacrés. Les "
"utilisateurs du langage C peuvent consulter [DC2009]_, [Stevens1998]_, "
"[SFR2004]_ ou [Kerrisk2010]_. L'implémentation Java de l'API socket est "
"décrite dans [CD2008]_ et dans le `tutoriel Java `_. Dans cette section, nous "
"utiliserons l'API socket C pour illustrer les concepts clés."
#: ../../exercises/sockets.rst:100
msgid ""
"The socket API is quite low-level and should be used only when you need a"
" complete control of the network access. If your application simply "
"needs, for instance, to retrieve data from a web server, there are much "
"simpler and higher-level APIs."
msgstr ""
"L'API socket est de très bas niveau et ne doit être utilisée que lorsque "
"vous avez besoin d'un contrôle complet de l'accès au réseau. Si votre "
"application a simplement besoin, par exemple, d'extraire des données d'un "
"serveur web, il existe des API beaucoup plus simples et de plus haut niveau."
#: ../../exercises/sockets.rst:102
msgid ""
"A detailed discussion of the socket API is outside the scope of this "
"section and the references cited above provide a detailed discussion of "
"all the details of the socket API. As a starting point, it is "
"interesting to compare the socket API with the service primitives that we"
" have discussed in the previous chapter. Let us first consider the "
"connectionless service that consists of the following two primitives :"
msgstr ""
"Une discussion détaillée de l'API de socket sort du cadre de cette section "
"et les références citées ci-dessus fournissent une discussion détaillée de "
"tous les détails de l'API de socket. Pour commencer, il est intéressant de "
"comparer l'API socket avec les primitives de service que nous avons abordées "
"dans le chapitre précédent. Considérons d'abord le service sans connexion "
"qui se compose des deux primitives suivantes :"
#: ../../exercises/sockets.rst:104
msgid ""
"`DATA.request(destination,message)` is used to send a message to a "
"specified destination. In this socket API, this corresponds to the "
"``send`` method."
msgstr ""
"`DATA.request(destination,message)` est utilisé pour envoyer un message à "
"une destination spécifiée. Dans cette API socket, cela correspond à la "
"méthode ``send``."
#: ../../exercises/sockets.rst:105
msgid ""
"`DATA.indication(message)` is issued by the transport service to deliver "
"a message to the application. In the socket API, this corresponds to the "
"return of the ``recv`` method that is called by the application."
msgstr ""
"`DATA.indication(message)` est émis par le service de transport pour "
"délivrer un message à l'application. Dans l'API socket, cela correspond au "
"retour de la méthode ``recv`` qui est appelée par l'application."
#: ../../exercises/sockets.rst:107
msgid ""
"The `DATA` primitives are exchanged through a service access point. In "
"the socket API, the equivalent to the service access point is the "
"`socket`. A `socket` is a data structure which is maintained by the "
"networking stack and is used by the application every time it needs to "
"send or receive data through the networking stack."
msgstr ""
"Les primitives `DATA` sont échangées via un point d'accès au service. Dans "
"l'API socket, l'équivalent du point d'accès au service est le `socket`. Une "
"`socket` est une structure de données qui est maintenue par la pile réseau "
"et qui est utilisée par l'application à chaque fois qu'elle doit envoyer ou "
"recevoir des données à travers la pile réseau."
#: ../../exercises/sockets.rst:110
msgid "Sending data to a peer using a socket"
msgstr "Envoi de données à un pair à l'aide d'une socket"
#: ../../exercises/sockets.rst:112
msgid ""
"In order to reach a peer, a process must know its :term:`address`. An "
"address is a value that identifies a peer in a given network. There "
"exists many different kinds of address families. For example, some of "
"them allow to reach a peer using the file system on the computer. Some "
"others allow to reach a remote peer using a network. The socket API "
"provides generic functions: the peer address is taken as a ``struct "
"sockaddr *``, which can point to any family of address. This is partly "
"why sockets are a powerful abstraction."
msgstr ""
"Afin d'atteindre un pair, un processus doit connaître son :term:`adresse`. "
"Une adresse est une valeur qui identifie un pair dans un réseau donné. Il "
"existe de nombreux types de familles d'adresses différentes. Par exemple, "
"certaines d'entre elles permettent d'atteindre un pair en utilisant le "
"système de fichiers de l'ordinateur. D'autres permettent d'atteindre un pair "
"distant en utilisant un réseau. L'API socket fournit des fonctions "
"génériques : l'adresse du pair est prise comme une ``struct sockaddr *``, "
"qui peut pointer vers n'importe quelle famille d'adresse. C'est en partie "
"pour cela que les sockets sont une abstraction puissante."
#: ../../exercises/sockets.rst:114
msgid ""
"The ``sendto`` system call allows to send data to a peer identified by "
"its socket address through a given socket."
msgstr ""
"L'appel système ``sendto`` permet d'envoyer des données à un pair identifié "
"par son adresse de socket via un socket donné."
#: ../../exercises/sockets.rst:120
msgid ""
"The first argument is the file descriptor of the socket that we use to "
"perform the communication. ``buf`` is a buffer of length ``len`` "
"containing the bytes to send to the peer. The usage of ``flags`` argument"
" is out of the scope of this section and can be set to 0. ``dest_addr`` "
"is the socket address of the destination to which we want to send the "
"bytes, its length is passed using the ``addrlen`` argument."
msgstr ""
"Le premier argument est le descripteur de fichier de la socket que nous "
"utilisons pour effectuer la communication. ``buf`` est un tampon de longueur "
"``len`` contenant les octets à envoyer à l'homologue. L'utilisation de "
"l'argument ``flags`` est hors de portée de cette section et peut être mis à "
"0. ``dest_addr`` est l'adresse de la socket de destination à laquelle nous "
"voulons envoyer les octets, sa longueur est passée en utilisant l'argument "
"``addrlen`'."
#: ../../exercises/sockets.rst:122
msgid ""
"In the following example, a C program is sending the bytes ``'h'``, "
"``'e'``, ``'l'``, ``'l'`` and ``'o'`` to a remote process located at "
"address ``peer_addr``, using the already created socket ``sock``."
msgstr ""
"Dans l'exemple suivant, un programme C envoie les octets ``'h'``, ``'e'``, "
"``'l'``, ``'l'`` et ``'o'`` à un processus distant situé à l'adresse "
"``peer_addr``, en utilisant la socket ``sock`` déjà créée."
#: ../../exercises/sockets.rst:135
msgid ""
"As the ``sendto`` function is generic, this function will work correctly "
"independently from the fact that the peer's address is defined as a path "
"on the computer filesystem or a network address."
msgstr ""
"Comme la fonction ``sendto`` est générique, cette fonction fonctionnera "
"correctement indépendamment du fait que l'adresse de l'homologue soit "
"définie comme un chemin sur le système de fichiers de l'ordinateur ou une "
"adresse réseau."
#: ../../exercises/sockets.rst:139
msgid "Receiving data from a peer using a socket"
msgstr "Recevoir des données d'un pair en utilisant un socket"
#: ../../exercises/sockets.rst:141
msgid ""
"Operating systems allow to assign an address to a socket using the "
"``bind`` system call. This is useful when you want to receive messages "
"from another program to which you announced your socket address. Once the"
" address is assigned to the socket, the program can receive data from "
"others using system calls such as ``recv`` and ``read``. Note that we can"
" use the ``read`` system call as the operating system provides a socket "
"as a file descriptor."
msgstr ""
"Les systèmes d'exploitation permettent d'assigner une adresse à une socket "
"en utilisant l'appel système ``bind``. Ceci est utile lorsque vous voulez "
"recevoir des messages d'un autre programme auquel vous avez annoncé "
"l'adresse de votre socket. Une fois l'adresse assignée à la socket, le "
"programme peut recevoir des données d'autres programmes en utilisant des "
"appels système tels que ``recv`` et ``read``. Notez que nous pouvons "
"utiliser l'appel système ``read`` car le système d'exploitation fournit un "
"socket comme descripteur de fichier."
#: ../../exercises/sockets.rst:144
msgid ""
"The following program binds its socket to a given socket address and then"
" waits for receiving new bytes, using the already created socket "
"``sock``."
msgstr ""
"Le programme suivant lie son socket à une adresse de socket donnée et attend "
"ensuite de recevoir de nouveaux octets, en utilisant le socket ``sock`` déjà "
"créé."
#: ../../exercises/sockets.rst:173
msgid ""
"Depending on the socket address family, the operating system might "
"implicitly assign an address to an unbound socket upon a call to "
"``write``, ``send`` or ``sendto``. While this is a useful behavior, "
"describing it precisely is out of the scope of this section."
msgstr ""
"En fonction de la famille d'adresse de la socket, le système d'exploitation "
"peut implicitement assigner une adresse à un socket non liée lors d'un appel "
"à ``write``, ``send`` ou ``sendto``. Bien que ce comportement soit utile, sa "
"description précise n'entre pas dans le cadre de cette section."
#: ../../exercises/sockets.rst:175
msgid ""
"Using this code, the program will read and print an arbitrary message "
"received from an arbitrary peer who knows the program's socket address. "
"If we want to know the address of the peer that sent us the message, we "
"can use the ``recvfrom`` system call. This is what a modified version of "
"``bind_and_receive_from_peer`` is doing below."
msgstr ""
"En utilisant ce code, le programme lira et imprimera un message arbitraire "
"reçu d'un homologue arbitraire qui connaît l'adresse de socket du programme. "
"Si nous voulons connaître l'adresse de l'homologue qui nous a envoyé le "
"message, nous pouvons utiliser l'appel système ``recvfrom``. C'est ce que "
"fait une version modifiée de ``bind_and_receive_from_peer`` ci-dessous."
#: ../../exercises/sockets.rst:213
msgid ""
"This function is now using the ``recvfrom`` system call that will also "
"provide the address of the peer who sent the message. As addresses are "
"generic and can have different sizes, ``recvfrom`` also tells us the size"
" of the address that it has written."
msgstr ""
"Cette fonction utilise maintenant l'appel système ``recvfrom`` qui fournira "
"également l'adresse du pair qui a envoyé le message. Comme les adresses sont "
"génériques et peuvent avoir différentes tailles, ``recvfrom`` nous indique "
"également la taille de l'adresse qu'il a écrite."
#: ../../exercises/sockets.rst:216
msgid "``connect``: connecting a socket to a remote address"
msgstr "``connect``:connecter un socket à une adresse distante"
#: ../../exercises/sockets.rst:218
msgid ""
"Operating systems allow to link a socket to a remote address so that "
"every information sent through the socket will only be sent to this "
"remote address, and the socket will only receive messages sent by this "
"remote address. This can be done using the ``connect`` system call below."
msgstr ""
"Les systèmes d'exploitation permettent de lier un socket à une adresse "
"distante de sorte que toute information envoyée par la socket ne sera "
"envoyée qu'à cette adresse distante, et la socket ne recevra que les "
"messages envoyés par cette adresse distante. Ceci peut être fait en "
"utilisant l'appel système ``connect`` ci-dessous."
#: ../../exercises/sockets.rst:224
msgid ""
"This system call will assign the socket ``sockfd`` to the ``addr`` remote"
" socket address. The process can then use the ``send`` and ``write`` "
"system calls that do not to specify the destination socket address. "
"Furthermore, the calls to ``recv`` and ``read`` will only deliver "
"messages sent by this remote address. This is useful when we only care "
"about the other peer messages."
msgstr ""
"Cet appel système va assigner la socket ``sockfd`` à l'adresse de socket "
"distante ``addr``. Le processus peut alors utiliser les appels système "
"``send`` et ``write`` qui ne spécifient pas l'adresse de la socket de "
"destination. De plus, les appels à ``recv`` et ``read`` ne délivreront que "
"les messages envoyés par cette adresse distante. Ceci est utile lorsque l'on "
"ne s'intéresse qu'aux messages des autres pairs."
#: ../../exercises/sockets.rst:227
msgid ""
"The following program connects a socket to a remote address, sends a "
"message and waits for a reply."
msgstr ""
"Le programme suivant connecte un socket à une adresse distante, envoie un "
"message et attend une réponse."
#: ../../exercises/sockets.rst:259
msgid "Creating a new socket to communicate through a network"
msgstr "Création d'une nouvelle socket pour communiquer via un réseau"
#: ../../exercises/sockets.rst:261
msgid ""
"Until now, we learned how to use sockets that were already created. When "
"writing a whole program, you will have to create you own sockets and "
"choose the concrete technology that it will use to communicate with "
"others. In this section, we will create new sockets and allow a program "
"to communicate with processes located on another computer using a "
"network. The most recent standardized technology used to communicate "
"through a network is the :term:`IPv6` network protocol. In the IPv6 "
"protocol, hosts are identified using *IPv6 addresses*. Modern operating "
"systems allow IPv6 network communications between programs to be done "
"using the socket API, just as we did in the previous sections."
msgstr ""
"Jusqu'à présent, nous avons appris à utiliser des sockets déjà créés. "
"Lorsque vous écrirez un programme complet, vous devrez créer vos propres "
"sockets et choisir la technologie concrète qu'il utilisera pour communiquer "
"avec les autres. Dans cette section, nous allons créer de nouveaux sockets "
"et permettre à un programme de communiquer avec des processus situés sur un "
"autre ordinateur en utilisant un réseau. La technologie standardisée la plus "
"récente utilisée pour communiquer via un réseau est le protocole réseau "
":term:`IPv6`. Dans le protocole IPv6, les hôtes sont identifiés à l'aide "
"d'adresses *IPv6*. Les systèmes d'exploitation modernes permettent d'établir "
"des communications réseau IPv6 entre programmes à l'aide de l'API socket, "
"comme nous l'avons fait dans les sections précédentes."
#: ../../exercises/sockets.rst:264
msgid "A program can use the ``socket`` system call to create a new socket."
msgstr ""
"Un programme peut utiliser l'appel système ``socket`` pour créer un nouveau "
"socket."
#: ../../exercises/sockets.rst:270
msgid ""
"The ``domain`` parameter specifies the address family that we will use to"
" concretely perform the communication. For an IPv6 socket, the ``domain``"
" parameter will be set to the value ``AF_INET6``, telling the operating "
"system that we plan to communicate using IPv6 addresses. The ``type`` "
"parameter specifies the communication guarantees that we need. For now, "
"we will use the type ``SOCK_DGRAM`` which allows us to send *unreliable "
"messages*. This means that each data that we send at each call of "
"``sendto`` will either be completely received or not received at all. The"
" last parameter will be set to ``0``. The following line creates a "
"socket, telling the operating system that we want to communicate using "
"IPv6 addresses and that we want to send unreliable messages."
msgstr ""
"Le paramètre ``domain`` spécifie la famille d'adresses que nous allons "
"utiliser pour réaliser concrètement la communication. Pour une socket IPv6, "
"le paramètre ``domain`` prendra la valeur ``AF_INET6``, indiquant au système "
"d'exploitation que nous prévoyons de communiquer en utilisant des adresses "
"IPv6. Le paramètre ``type`` spécifie les garanties de communication dont "
"nous avons besoin. Pour l'instant, nous allons utiliser le type "
"``SOCK_DGRAM`` qui nous permet d'envoyer des *messages non fiables*. Cela "
"signifie que chaque donnée que nous envoyons à chaque appel de ``sendto`` "
"sera soit complètement reçue, soit pas du tout reçue. Le dernier paramètre "
"sera fixé à \"0\". La ligne suivante crée un socket, indiquant au système "
"d'exploitation que nous voulons communiquer en utilisant des adresses IPv6 "
"et que nous voulons envoyer des messages non fiables."
#: ../../exercises/sockets.rst:280
msgid "Sending a message to a remote peer using its IPv6 address"
msgstr "Envoi d'un message à un homologue distant en utilisant son adresse IPv6"
#: ../../exercises/sockets.rst:284
msgid ""
"Now that we created an IPv6 socket, we can use it to reach another "
"program if we know its IPv6 address. IPv6 addresses have a human-readable"
" format that can be represented as a string of characters. The details of"
" IPv6 addresses are out of scope of this section but here are some "
"examples :"
msgstr ""
"Maintenant que nous avons créé un socket IPv6, nous pouvons l'utiliser pour "
"atteindre un autre programme si nous connaissons son adresse IPv6. Les "
"adresses IPv6 ont un format lisible par l'homme qui peut être représenté par "
"une chaîne de caractères. Les détails des adresses IPv6 sont hors de portée "
"de cette section mais voici quelques exemples :"
#: ../../exercises/sockets.rst:283
msgid ""
"The ``::1`` IPv6 address identifies the computer on which the current "
"program is running."
msgstr ""
"L'adresse IPv6 ``::1`` identifie l'ordinateur sur lequel le programme tourne."
#: ../../exercises/sockets.rst:284
msgid ""
"The ``2001:6a8:308f:9:0:82ff:fe68:e520`` IPv6 address identifies the "
"computer serving the ``https://beta.computer-networking.info`` website."
msgstr ""
"L'adresse IPv6 ``2001:6a8:308f:9:0:82ff:fe68:e520`` identifie l'ordinateur "
"qui dessert le site ``https://beta.computer-networking.info``."
#: ../../exercises/sockets.rst:288
msgid ""
"An IPv6 address often identifies a computer and not a program running on "
"the computer. In order to identify a specific program running on a "
"specific computer, we use a *port number* in addition to the IPv6 "
"address. A program using an IPv6 socket is this identified using :"
msgstr ""
"Une adresse IPv6 identifie souvent un ordinateur et non pas un programme "
"exécuté sur cet ordinateur. Afin d'identifier un programme spécifique "
"fonctionnant sur un ordinateur spécifique, nous utilisons un *numéro de port*"
" en plus de l'adresse IPv6. Un programme utilisant un socket IPv6 est ainsi "
"identifié par :"
#: ../../exercises/sockets.rst:287
msgid "The IPv6 address of the computer"
msgstr "L'adresse IPv6 de l'ordinateur"
#: ../../exercises/sockets.rst:288
msgid "The port number identifying the program running on the computer"
msgstr "Le port du programme qui tourne sur l'ordinateur"
#: ../../exercises/sockets.rst:290
msgid ""
"A program can use the ``struct sockaddr_in6`` to represent IPv6 socket "
"addresses. The following program creates a ``struct sockaddr_in6`` that "
"identifies the program that reserved the port number ``55555`` on the "
"computer identified by the ``::1`` IPv6 address."
msgstr ""
"Un programme peut utiliser la structure sockaddr_in6 pour représenter les "
"adresses de socket IPv6. Le programme suivant crée une ``struct "
"sockaddr_in6`` qui identifie le programme ayant réservé le numéro de port "
"``55555`` sur l'ordinateur identifié par l'adresse IPv6 ``::1``."
#: ../../exercises/sockets.rst:301
msgid ""
"Now, we have built everything we need to send a message to the remote "
"program. The ``create_socket_and_send_message`` function below assembles "
"all the building blocks we created until now in order to send the message"
" ``\"hello\"`` to the program running on port ``55555`` on the computer "
"identified by the ``::1`` IPv6 address."
msgstr ""
"Maintenant, nous avons construit tout ce dont nous avons besoin pour envoyer "
"un message au programme distant. La fonction "
"``create_socket_and_send_message`` ci-dessous assemble toutes les briques "
"que nous avons créées jusqu'à présent afin d'envoyer le message ``hello\"`` "
"au programme tournant sur le port ``55555`` sur l'ordinateur identifié par "
"l'adresse IPv6 ``::1``."
#: ../../exercises/sockets.rst:322
msgid ""
"Note that we can reuse our ``send_hello_to_peer`` function without any "
"modification as we wrote it to handle any kind of sockets, including "
"sockets using the IPv6 network protocol."
msgstr ""
"Notez que nous pouvons réutiliser notre fonction ``send_hello_to_peer`` sans "
"aucune modification puisque nous l'avons écrite pour gérer tout type de "
"sockets, y compris les sockets utilisant le protocole réseau IPv6."
#: ../../exercises/sockets.rst:326
msgid "Endianness: exchanging integers between different computers"
msgstr "Endianness : échange d'entiers entre différents ordinateurs"
#: ../../exercises/sockets.rst:328
msgid ""
"Besides character strings, some applications also need to exchange 16 "
"bits and 32 bits fields such as integers. A naive solution would have "
"been to send the 16- or 32-bits field as it is encoded in the host's "
"memory. Unfortunately, there are different methods to store 16- or "
"32-bits fields in memory. Some CPUs store the most significant byte of a "
"16-bits field in the first address of the field while others store the "
"least significant byte at this location. When networked applications "
"running on different CPUs exchange 16 bits fields, there are two "
"possibilities to transfer them over the transport service :"
msgstr ""
"Outre les chaînes de caractères, certaines applications doivent également "
"échanger des champs de 16 et 32 bits tels que des entiers. Une solution "
"naïve aurait été d'envoyer le champ de 16 ou 32 bits tel qu'il est codé dans "
"la mémoire de l'hôte. Malheureusement, il existe différentes méthodes pour "
"stocker les champs de 16 ou 32 bits en mémoire. Certains processeurs "
"stockent l'octet le plus significatif d'un champ de 16 bits dans la première "
"adresse du champ, tandis que d'autres stockent l'octet le moins significatif "
"à cet endroit. Lorsque des applications en réseau fonctionnant sur des "
"unités centrales différentes échangent des champs de 16 bits, il existe deux "
"possibilités pour les transférer via le service de transport :"
#: ../../exercises/sockets.rst:330
msgid "send the most significant byte followed by the least significant byte"
msgstr ""
"envoyer l'octet le plus significatif suivi de l'octet le moins significatif"
#: ../../exercises/sockets.rst:331
msgid "send the least significant byte followed by the most significant byte"
msgstr ""
"envoyer l'octet le moins significatif suivi de l'octet le plus significatif"
#: ../../exercises/sockets.rst:333
msgid ""
"The first possibility was named `big-endian` in a note written by Cohen "
"[Cohen1980]_ while the second was named `little-endian`. Vendors of CPUs "
"that used `big-endian` in memory insisted on using `big-endian` encoding "
"in networked applications while vendors of CPUs that used `little-endian`"
" recommended the opposite. Several studies were written on the relative "
"merits of each type of encoding, but the discussion became almost a "
"religious issue [Cohen1980]_. Eventually, the Internet chose the `big-"
"endian` encoding, i.e. multi-byte fields are always transmitted by "
"sending the most significant byte first, :rfc:`791` refers to this "
"encoding as the :term:`network-byte order`. Most libraries [#fhtonl]_ "
"used to write networked applications contain functions to convert multi-"
"byte fields from memory to the network byte order and vice versa."
msgstr ""
"La première possibilité a été nommée `big-endian` dans une note écrite par "
"Cohen [Cohen1980]_ tandis que la seconde a été nommée `little-endian`. Les "
"vendeurs de processeurs qui utilisaient le `big-endian` en mémoire "
"insistaient pour utiliser le codage `big-endian` dans les applications en "
"réseau alors que les vendeurs de processeurs qui utilisaient le `little-"
"endian` recommandaient le contraire. Plusieurs études ont été écrites sur "
"les mérites relatifs de chaque type de codage, mais la discussion est "
"devenue presque une question religieuse [Cohen1980]_. Finalement, Internet a "
"choisi le codage `big-endian`, c'est-à-dire que les champs à plusieurs "
"octets sont toujours transmis en envoyant l'octet le plus significatif en "
"premier, :rfc:`791` se réfère à ce codage comme le :term:`network-byte order`"
". La plupart des bibliothèques [#fhtonl]_ utilisées pour écrire des "
"applications en réseau contiennent des fonctions permettant de convertir les "
"champs multi-octets de la mémoire à l'ordre des octets du réseau et vice-"
"versa."
#: ../../exercises/sockets.rst:335
msgid ""
"Besides 16 and 32 bit words, some applications need to exchange data "
"structures containing bit fields of various lengths. For example, a "
"message may be composed of a 16 bits field followed by eight, one bit "
"flags, a 24 bits field and two 8 bits bytes. Internet protocol "
"specifications will define such a message by using a representation such "
"as the one below. In this representation, each line corresponds to 32 "
"bits and the vertical lines are used to delineate fields. The numbers "
"above the lines indicate the bit positions in the 32-bits word, with the "
"high order bit at position `0`."
msgstr ""
"Outre les mots de 16 et 32 bits, certaines applications doivent échanger des "
"structures de données contenant des champs de bits de différentes longueurs. "
"Par exemple, un message peut être composé d'un champ de 16 bits suivi de "
"huit drapeaux d'un bit, d'un champ de 24 bits et de deux octets de 8 bits. "
"Les spécifications du protocole Internet définiront un tel message en "
"utilisant une représentation telle que celle qui suit. Dans cette "
"représentation, chaque ligne correspond à 32 bits et les lignes verticales "
"sont utilisées pour délimiter les champs. Les chiffres au-dessus des lignes "
"indiquent la position des bits dans le mot de 32 bits, le bit de poids fort "
"étant en position \"0\"."
#: ../../exercises/sockets.rst:341
msgid "Message format"
msgstr "Format du message"
#: ../../exercises/sockets.rst:343
msgid ""
"The message mentioned above will be transmitted starting from the upper "
"32-bits word in network byte order. The first field is encoded in 16 "
"bits. It is followed by eight one bit flags (`A-H`), a 24 bits field "
"whose high order byte is shown in the first line and the two low order "
"bytes appear in the second line followed by two one byte fields. This "
"ASCII representation is frequently used when defining binary protocols. "
"We will use it for all the binary protocols that are discussed in this "
"book."
msgstr ""
"Le message mentionné ci-dessus sera transmis en commençant par le mot "
"supérieur de 32 bits dans l'ordre des octets du réseau. Le premier champ est "
"codé sur 16 bits. Il est suivi de huit drapeaux d'un bit (`A-H`), d'un champ "
"de 24 bits dont l'octet de poids fort figure sur la première ligne et les "
"deux octets de poids faible apparaissent sur la deuxième ligne, suivis de "
"deux champs d'un octet. Cette représentation ASCII est fréquemment utilisée "
"lors de la définition de protocoles binaires. Nous l'utiliserons pour tous "
"les protocoles binaires abordés dans ce livre."
#: ../../exercises/sockets.rst:346
msgid "Exercises"
msgstr "Exercices"
#: ../../exercises/sockets.rst:348
msgid "Here are some exercises that will help you to learn how to use sockets."
msgstr ""
"Voici quelques exercices qui vous permettront d'apprendre à utiliser les "
"sockets."
#: ../../exercises/sockets.rst:364
msgid "Footnotes"
msgstr "Notes de pied de page"
#: ../../exercises/sockets.rst:365
msgid ""
"For example, the ``htonl(3)`` (resp. ``ntohl(3)``) function the standard "
"C library converts a 32-bits unsigned integer from the byte order used by"
" the CPU to the network byte order (resp. from the network byte order to "
"the CPU byte order). Similar functions exist in other programming "
"languages."
msgstr ""
"Par exemple, la fonction ``htonl(3)`` (resp. ``ntohl(3)``) de la "
"bibliothèque C standard convertit un entier non signé de 32 bits de l'ordre "
"des octets utilisé par le CPU à l'ordre des octets du réseau (resp. de "
"l'ordre des octets du réseau à l'ordre des octets du CPU). Des fonctions "
"similaires existent dans d'autres langages de programmation."
PKRD PK H}X 9 cnp3-ebook/index/locale/fr/LC_MESSAGES/exercises/tcp-2.po# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2019 Olivier Bonaventure
# This file is distributed under the same license as the Computer networking : Principles, Protocols and Practice package.
# FIRST AUTHOR , YEAR.
#
msgid ""
msgstr ""
"Project-Id-Version: Computer networking : Principles, Protocols and Practice "
"3\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2021-05-17 09:55+0200\n"
"PO-Revision-Date: 2021-08-27 14:47+0000\n"
"Last-Translator: Anthony Gego \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n > 1;\n"
"X-Generator: Weblate 3.9.1\n"
#: ../../exercises/tcp-2.rst:8
msgid "A closer look at TCP"
msgstr ""
#: ../../exercises/tcp-2.rst:10
msgid "In this series of exercises, you will explore in more details the operation of TCP and its congestion control scheme. TCP is a very important protocol in today's Internet since most applications use it to exchange data. We first look at TCP in more details by injecting segments in the Linux TCP stack and analyze how the stack reacts. Then we study the TCP congestion control scheme."
msgstr ""
#: ../../exercises/tcp-2.rst:14
msgid "Injecting segments in the Linux TCP stack"
msgstr ""
#: ../../exercises/tcp-2.rst:16
msgid "Packet capture tools like tcpdump_ and Wireshark_ are very useful to observe the segments that transport protocols exchange. TCP is a complex protocol that has evolved a lot since its first specification :rfc:`793`. TCP includes a large number of heuristics that influence the reaction of a TCP implementation to various types of events. A TCP implementation interacts with the application through the ``socket`` API."
msgstr ""
#: ../../exercises/tcp-2.rst:18
msgid "packetdrill_ is a TCP test suite that was designed to develop unit tests to verify the correct operation of a TCP implementation. A more detailed description of packetdrill_ may be found in [CCB+2013]_. packetdrill_ uses a syntax which is a mix between the C language and the tcpdump_ syntax. To understand the operation of packetdrill_, we first discuss several examples. The TCP implementation in the Linux kernel supports all the recent TCP extensions to improve its performance. For pedagogical reasons, we disable [#fsysctl]_ most of these extensions to use a simple TCP stack. packetdrill_ can be easily installed on recent Linux kernels [#finstall]_."
msgstr ""
#: ../../exercises/tcp-2.rst:20
msgid "Let us start with a very simple example that uses packetdrill_ to open a TCP connection on a server running on the Linux kernel. A packetdrill_ script is a sequence of lines that are executed one after the other. There are three main types of lines in a packetdrill_ script."
msgstr ""
#: ../../exercises/tcp-2.rst:22
msgid "packetdrill_ executes a system call and verifies its return value"
msgstr ""
#: ../../exercises/tcp-2.rst:23
msgid "packetdrill_ injects [#ftcpdump_pdrill]_ a packet in the instrumented Linux kernel as if it were received from the network"
msgstr ""
#: ../../exercises/tcp-2.rst:24
msgid "packetdrill_ compares a packet transmitted by the instrumented Linux kernel with the packet that the script expects"
msgstr ""
#: ../../exercises/tcp-2.rst:26
msgid "For our first packetdrill_ script, we aim at reproducing the simple connection shown in the figure below."
msgstr ""
#: ../../exercises/tcp-2.rst:57
msgid "Let us start with the execution of a system call. A simple example is shown below."
msgstr ""
#: ../../exercises/tcp-2.rst:63
msgid "The ``0`` indicates that the system call must be issued immediately. packetdrill_ then executes the system call and verifies that it returns ``3```. If yes, the processing continues. Otherwise the script stops and indicates an error."
msgstr ""
#: ../../exercises/tcp-2.rst:65
msgid "For this first example, we program packetdrill_ to inject the segments that a client would send. The first step is thus to prepare a :manpage:`socket` that can be used to accept this connection. This socket can be created by using the four system calls below."
msgstr ""
#: ../../exercises/tcp-2.rst:80
msgid "At this point, the socket is ready to accept incoming TCP connections. packetdrill_ needs to inject a TCP segment in the instrumented Linux stack. This can be done with the line below."
msgstr ""
#: ../../exercises/tcp-2.rst:86
msgid "Each line of a packetdrill_ script starts with a `timing` parameter that indicates at what time the event specified on this line should happen. packetdrill_ supports absolute and relative timings. An absolute timing is simply a number that indicates the delay in seconds between the start of the script and the event. A relative timing is indicated by using ``+`` followed by a number. This number is then the delay in seconds between the previous event and the current line. Additional information may be found in [CCB+2013]_."
msgstr ""
#: ../../exercises/tcp-2.rst:88
msgid "The description of TCP packets in packetdrill_ uses a syntax that is very close to the tcpdump_ one. The ``+0`` timing indicates that the line is executed immediately after the previous event. The ``<`` sign indicates that packetdrill_ injects a TCP segment and the ``S`` character indicates that the ``SYN`` flag must be set. Like tcpdump_, packetdrill_ uses sequence numbers that are relative to initial sequence number. The three numbers that follow are the sequence number of the first byte of the payload of the segment (``0``), the sequence number of the last byte of the payload of the segment (``0`` after the semi-column) and the length of the payload (``0`` between brackets) of the ``SYN`` segment. This segment does not contain a valid acknowledgment but advertises a window of 1000 bytes. All ``SYN`` segments must also include the ``MSS`` option. In this case, we set the MSS to 1000 bytes. The next line of the packetdrill_ script verifies the reply sent by the instrumented Linux kernel."
msgstr ""
#: ../../exercises/tcp-2.rst:95
msgid "This TCP segment is sent immediately by the stack. The ``SYN`` flag is set and the dot next to the ``S`` character indicates that the ACK flag is also set. The SYN+ACK segment does not contain any data but its acknowledgment number is set to 1 (relative to the initial sequence number). For outgoing packets, packetdrill_ does not verify the value of the advertised window. In this line, it also accepts any TCP options (``<...>``)."
msgstr ""
#: ../../exercises/tcp-2.rst:98
msgid "The third segment of the three-way handshake is sent by packetdrill_ after a delay of 0.1 seconds. The connection is now established and the accept system call will succeed."
msgstr ""
#: ../../exercises/tcp-2.rst:105
msgid "The :manpage:`accept` system call returns a new file descriptor, in this case value ``4``. At this point, packetdrill_ can write data on the socket or inject packets."
msgstr ""
#: ../../exercises/tcp-2.rst:113
msgid "packetdrill_ writes 10 bytes of data through the :manpage:`write` system call. The stack immediately sends these 10 bytes inside a segment whose ``Push`` flag is set [#fpush]_. The payload starts at sequence number ``1`` and ends at sequence number ``10``. packetdrill_ replies by injecting an acknowledgment for the entire data after 100 milliseconds."
msgstr ""
#: ../../exercises/tcp-2.rst:115
msgid "packetdrill_ can also inject data that will be read by the stack as shown by the lines below."
msgstr ""
#: ../../exercises/tcp-2.rst:123
msgid "In the example above, packetdrill_ injects a segment containing two bytes. This segment is acknowledged and after that the :manpage:`read` system call succeeds and reads the available data with a buffer of 1000 bytes. It returns the amount of read bytes, i.e. ``2``."
msgstr ""
#: ../../exercises/tcp-2.rst:125
msgid "We can now close the connection gracefully. Let us first issue inject a segment with the ``FIN`` flag set."
msgstr ""
#: ../../exercises/tcp-2.rst:133
msgid "packetdrill_ injects the ``FIN`` segment and the instrumented kernel returns an acknowledgment. If packetdrill_ issues the :manpage:`close` system call, the kernel will send a ``FIN`` segment to terminate the connection. packetdrill_ injects an acknowledgment to confirm the end of the connection."
msgstr ""
#: ../../exercises/tcp-2.rst:142
msgid "The complete packetdrill_ script is available from :download:`/exercises/packetdrill_scripts/connect.pkt`."
msgstr ""
#: ../../exercises/tcp-2.rst:145
msgid "Another interesting features of packetdrill_ is that it is possible to inspect the state maintained by the Linux kernel for the underlying connection using the ``TCP_INFO`` socket option. This makes it possible to retrieve the value of some variables of the TCP control block."
msgstr ""
#: ../../exercises/tcp-2.rst:147
msgid "Let us first explore how a TCP connection can be established. In the previous script, we have injected the segments that a client would send to a server. We can also use the Linux stack as a client and inject the segments that a server would return. Such a client process would first create its :manpage:`socket`` and then issue the :manpage:`connect` system call. At this point, the stack sends a ``SYN`` segment. To simplify the scripts, we have configured the stack to use a ``MSS`` of 1000 bytes and disabled the TCP extensions (the details of this configuration may be found at the beginning of the script). The server replies with a ``SYN+ACK`` and the stack sends acknowledges it to finish the three-way-handshake."
msgstr ""
#: ../../exercises/tcp-2.rst:165
msgid "The ``tcpi_state`` variable used in this script is returned by ``TCP_INFO`` [#ftcpinfo]_. It tracks the state of the TCP connection according to TCP's finite state machine [#fstates]_. This script is available from :download:`/exercises/packetdrill_scripts/client.pkt`."
msgstr ""
#: ../../exercises/tcp-2.rst:167
msgid "Another example is the simultaneous establishment of a TCP connection. The TCP stack sends a ``SYN`` and receives a ``SYN`` in response instead of a ``SYN+ACK``. It then acknowledges the received ``SYN`` and retransmits its own ``SYN``. The connection becomes established upon reception of the fourth segment. This script is available from :download:`/exercises/packetdrill_scripts/dual.pkt`."
msgstr ""
#: ../../exercises/tcp-2.rst:191
msgid "Another usage of packetdrill_ is to explore how a TCP connection ends. The scripts below show how a TCP stack closes a TCP connection. The first example shows a local host that connects to a remote host and then closes the connection. The remote host acknowledges the ``FIN`` and later closes its direction of data transfer. This script is available from :download:`/exercises/packetdrill_scripts/local-close.pkt`."
msgstr ""
#: ../../exercises/tcp-2.rst:213
msgid "As for the establishment of a connection, it is also possible for the two communicating hosts to close the connection at the same time. This is shown in the example below where the remote host sends its own ``FIN`` when acknowledging the first one. This script is available from :download:`/exercises/packetdrill_scripts/local-close2.pkt`."
msgstr ""
#: ../../exercises/tcp-2.rst:234
msgid "A third scenario for the termination of a TCP connection is that the remote hosts sends its ``FIN`` first. This script is available from :download:`/exercises/packetdrill_scripts/remote-close.pkt`."
msgstr ""
#: ../../exercises/tcp-2.rst:259
msgid "Another very interesting utilization of packetdrill_ is to explore how a TCP stack reacts to acknowledgments that would correspond to lost or reordered segments. For this analysis, we configure a very large initial congestion window to ensure that the connection does not start with a slow-start."
msgstr ""
#: ../../exercises/tcp-2.rst:261
msgid "Let us first use packetdrill_ to explore the evolution of the TCP retransmission timeout. The value of this timeout is set based on the measured round-trip-time and its variance. When the retransmission timer expires, TCP doubles the retransmission timer. This exponential backoff mechanism is important to ensure that TCP slowdowns during very severe congestion periods. We use the ``tcpi_rto`` variable from ``TCP_INFO`` to track the evolution of the retransmission timer. This script is available from :download:`/exercises/packetdrill_scripts/rto.pkt`."
msgstr ""
#: ../../exercises/tcp-2.rst:293
msgid "We can use a similar code to demonstrate that the TCP stack performs a fast retransmit after having received three duplicate acknowledgments. This script is available from :download:`/exercises/packetdrill_scripts/frr.pkt`."
msgstr ""
#: ../../exercises/tcp-2.rst:326
msgid "A TCP stack uses both the fast retransmit technique and retransmission timers. A retransmission timer can fire after a fast retransmit when several segments are lost. The example below shows a loss of two consecutive segments. This script is available from :download:`/exercises/packetdrill_scripts/frr-rto.pkt`."
msgstr ""
#: ../../exercises/tcp-2.rst:364
msgid "More complex scenarios can be written. The script below demonstrates how the TCP stack behaves when three segments are lost. This script is available from :download:`/exercises/packetdrill_scripts/frr-rto2.pkt`."
msgstr ""
#: ../../exercises/tcp-2.rst:411
msgid "The examples above have demonstrated how TCP retransmits lost segments. However, they did not consider the interactions with the congestion control scheme since the use a large initial congestion window. We now set the initial congestion window to two MSS-sized segments and use the ``tcpi_snd_cwnd`` and ``tcpi_snd_ssthresh`` variables from ``TCP_INFO`` to explore the evolution of the TCP congestion control scheme. Our first script looks at the evolution of the congestion window during a slow-start when there are no losses. This script is available from :download:`/exercises/packetdrill_scripts/slow-start.pkt`."
msgstr ""
#: ../../exercises/tcp-2.rst:459
msgid "Some TCP clients use delayed acknowledgments and send a TCP acknowledgment after after second in-sequence segment. This behavior is illustrated in the script below. This script is available from :download:`/exercises/packetdrill_scripts/slow-start-delayed.pkt`."
msgstr ""
#: ../../exercises/tcp-2.rst:502
msgid "We can now explore how TCP's retransmission techniques interact with the congestion control scheme. The Linux TCP code that combines these two techniques contains several heuristics to improve their performance. We start with a transfer of 8KBytes where the penultimate segment is not received by the remote host. In this case, TCP does not receive enough acknowledgments to trigger the fast retransmit and it must wait for the expiration of the retransmission timer. This script is available from :download:`/exercises/packetdrill_scripts/slow-start-rto2.pkt`."
msgstr ""
#: ../../exercises/tcp-2.rst:546
msgid "Another interesting scenario is when the loss happens early in the data transfer. This is shown in the script below where the second segment is lost. We observe that by triggering transmissions of unacknowledged data, the :rfc:`3042` rule speeds up the recovery since a fast retransmit happens. This script is available from :download:`/exercises/packetdrill_scripts/slow-start-frr2.pkt`."
msgstr ""
#: ../../exercises/tcp-2.rst:593
msgid "Our last scenario is when the first segment sent is lost. In this case, two round-trip-times are required to retransmit the missing segment and recover from the loss. This script is available from :download:`/exercises/packetdrill_scripts/slow-start-frr3.pkt`."
msgstr ""
#: ../../exercises/tcp-2.rst:637
msgid "Open questions"
msgstr ""
#: ../../exercises/tcp-2.rst:639
msgid "Unless otherwise noted, we assume for the questions in this section that the following conditions hold."
msgstr ""
#: ../../exercises/tcp-2.rst:641
msgid "the sender/receiver performs a single :manpage:`send(3)` of `x` bytes"
msgstr ""
#: ../../exercises/tcp-2.rst:642
msgid "the round-trip-time is fixed and does not change during the lifetime of the TCP connection. We assume a fixed value of 100 milliseconds for the round-trip-time and a fixed value of 200 milliseconds for the retransmission timer."
msgstr ""
#: ../../exercises/tcp-2.rst:643
msgid "the delay required to transmit a single TCP segment containing MSS bytes is small and set to 1 milliseconds, independently of the MSS size"
msgstr ""
#: ../../exercises/tcp-2.rst:644
msgid "the transmission delay for a TCP acknowledgment is negligible"
msgstr ""
#: ../../exercises/tcp-2.rst:645
msgid "the initial value of the congestion window is one MSS-sized segment"
msgstr ""
#: ../../exercises/tcp-2.rst:646
msgid "the value of the duplicate acknowledgment threshold is fixed and set to 3"
msgstr ""
#: ../../exercises/tcp-2.rst:647
msgid "TCP always acknowledges each received segment"
msgstr ""
#: ../../exercises/tcp-2.rst:649
msgid "To understand the operation of the TCP congestion control, it is often useful to write time-sequence diagrams for different scenarios. The example below shows the operation of the TCP congestion control scheme in a very simple scenario. The initial congestion window (``cwnd``) is set to 1000 bytes and the receive window (``rwin``) advertised by the receiver (supposed constant for the entire connection) is set to 2000 bytes. The slow-start threshold (``ssthresh``) is set to 64000 bytes."
msgstr ""
#: ../../exercises/tcp-2.rst:684
msgid "Can you explain why the sender only sends one segment first and then two successive segments (the delay between the two segments on the figure is due to graphical reasons) ?"
msgstr ""
#: ../../exercises/tcp-2.rst:686
msgid "Can you explain why the congestion window is increased after the reception of the first acknowledgment ?"
msgstr ""
#: ../../exercises/tcp-2.rst:688
msgid "How long does it take for the sender to deliver 3 KBytes to the receiver ?"
msgstr ""
#: ../../exercises/tcp-2.rst:691
msgid "Same question as above but now with a small variation. Recent TCP implementations use a large initial value for the congestion window. Draw the time-sequence diagram that corresponds to an initial value of 10000 bytes for this congestion window."
msgstr ""
#: ../../exercises/tcp-2.rst:715
msgid "Same question as the first one, but consider that the MSS on the sender is set to 500 bytes. How does this modification affect the entire delay ?"
msgstr ""
#: ../../exercises/tcp-2.rst:738
msgid "Assuming that there are no losses and that there is no congestion in the network. If the sender writes `x` bytes on a newly established TCP connection, derive a formula that computes the minimum time required to deliver all these `x` bytes to the receiver. For the derivation of this formula, assume that `x` is a multiple of the maximum segment size and that the receive window and the slow-start threshold are larger than `x`."
msgstr ""
#: ../../exercises/tcp-2.rst:740
msgid "In question 1, we assumed that the receiver acknowledged every segment received from the sender. In practice, many deployed TCP implementations use delayed acknowledgments. Assuming a delayed acknowledgment timer of 50 milliseconds, modify the time-sequence diagram below to reflect the impact of these delayed acknowledgment. Does their usage decreases or increased the transmission delay ?"
msgstr ""
#: ../../exercises/tcp-2.rst:775
msgid "Let us now explore the impact of congestion on the slow-start and congestion avoidance mechanisms. Consider the scenario below. For graphical reasons, it is not possible anymore to show information about the segments on the graph, but you can easily infer them."
msgstr ""
#: ../../exercises/tcp-2.rst:832
msgid "Redraw the same figure assuming that the second segment that was delivered by the sender in the figure experienced congestion. In a network that uses Explicit Congestion Notification, this segment would be marked by routers and the receiver would return the congestion mark in the corresponding acknowledgment."
msgstr ""
#: ../../exercises/tcp-2.rst:834
msgid "Same question, but assume now that the fourth segment delivered by the sender experienced congestion (but was not discarded)."
msgstr ""
#: ../../exercises/tcp-2.rst:837
msgid "A TCP connection has been active for some time and has reached a congestion window of 4000 bytes. Four segments are sent, but the second (shown in red in the figure) is corrupted. Complete the time-sequence diagram."
msgstr ""
#: ../../exercises/tcp-2.rst:871
msgid "Footnotes"
msgstr "Notes de pied de page"
#: ../../exercises/tcp-2.rst:876
msgid "On Linux, most of the parameters to tune the TCP stack are accessible via :manpage:`sysctl`. These parameters are briefly described in https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.txt and in the :manpage:`tcp` manpage. Each script sets some of these configuration variables."
msgstr ""
#: ../../exercises/tcp-2.rst:883
msgid "packetdrill_ requires root privileges since it inject raw IP packets. The easiest way to install it is to use a virtualbox image with a Linux kernel 4.x or 5.x. You can clone its git repository from https://github.com/google/packetdrill and follow the instructions in https://github.com/google/packetdrill/tree/master/gtests/net/packetdrill. The packetdrill_ scripts used in this section are available from https://github.com/cnp3/ebook/tree/master/exercises/packetdrill_scripts"
msgstr ""
#: ../../exercises/tcp-2.rst:885
msgid "By default, packetdrill_ uses port 8080 when creating TCP segments. You can thus capture the packets injected by packetdrill_ and the responses from the stack by using ``tcpdump -i any -n port 8080``"
msgstr ""
#: ../../exercises/tcp-2.rst:887
msgid "The `Push` flag is one of the TCP flags defined in :rfc:`793`. TCP stacks usually set this flag when transmitting a segment that empties the send buffer. This is the reason why we observe this push flag in our example."
msgstr ""
#: ../../exercises/tcp-2.rst:889
msgid "The variables that are included in TCP_INFO are defined in https://github.com/torvalds/linux/blob/master/include/uapi/linux/tcp.h"
msgstr ""
#: ../../exercises/tcp-2.rst:891
msgid "These states are defined in https://github.com/torvalds/linux/blob/master/include/net/tcp_states.h"
msgstr ""
PKyW W PK H}X 7 cnp3-ebook/index/locale/fr/LC_MESSAGES/exercises/tcp.po# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2019 Olivier Bonaventure
# This file is distributed under the same license as the Computer networking : Principles, Protocols and Practice package.
# FIRST AUTHOR , YEAR.
#
msgid ""
msgstr ""
"Project-Id-Version: Computer networking : Principles, Protocols and Practice "
"3\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2021-05-17 09:55+0200\n"
"PO-Revision-Date: 2021-08-27 14:47+0000\n"
"Last-Translator: Anthony Gego \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n > 1;\n"
"X-Generator: Weblate 3.9.1\n"
#: ../../exercises/tcp.rst:6
msgid "TCP basics"
msgstr ""
#: ../../exercises/tcp.rst:9
msgid "TCP is one of the key protocols in today's Internet. A TCP connection always starts with a three-way handshake. The exercises below should help you to improve your understandings of this first phase of a TCP connection."
msgstr ""
#: ../../exercises/tcp.rst:25
msgid "Once the connection is established, the client and the server can exchange data and acknowledgments."
msgstr ""
#: ../../exercises/tcp.rst:37
msgid "A connection ends with the transmission of segments that include the `FIN` flag that marks the end of the data transfer."
msgstr ""
#: ../../exercises/tcp.rst:43
msgid "TCP can be extended by using options that are negotiated during the three-way handshake."
msgstr ""
#: ../../exercises/tcp.rst:52
msgid "With your knowledge of TCP, you should now be able to reorder all the segments exchanged over a TCP connection."
msgstr ""
#: ../../exercises/tcp.rst:63
msgid "Footnotes"
msgstr "Notes de pied de page"
PKx' ' PK H}X 7 cnp3-ebook/index/locale/fr/LC_MESSAGES/exercises/tls.po# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2019 Olivier Bonaventure
# This file is distributed under the same license as the Computer networking : Principles, Protocols and Practice package.
# FIRST AUTHOR , YEAR.
#
msgid ""
msgstr ""
"Project-Id-Version: Computer networking : Principles, Protocols and Practice "
"3\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2021-05-17 09:55+0200\n"
"PO-Revision-Date: 2021-08-27 14:47+0000\n"
"Last-Translator: Anthony Gego \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n > 1;\n"
"X-Generator: Weblate 3.9.1\n"
#: ../../exercises/tls.rst:6
msgid "TLS and ssh"
msgstr "TLS et SSH"
#: ../../exercises/tls.rst:8
msgid "One of the first motivations for the deployment of wide area networks such as the Internet was to enable researchers to connect to distant servers. For many years, these connections were carried out by using a simple application layer protocol such as telnet over a TCP connection. With telnet, all the characters typed by the user are sent in cleartext over the TCP connection. This implies that if someone is able to capture the packets transmitted over the network, he/she can collect sensitive information such as user names or passwords."
msgstr ""
#: ../../exercises/tls.rst:15
msgid "Fortunately, telnet is rarely used without TLS these days and system administrators usually prefer to deploy more secure protocols such as ``ssh``."
msgstr ""
#: ../../exercises/tls.rst:24
msgid "The Transport Layer Security (TLS) protocol is now used by a wide range of applications, even if the most popular one is HTTPS. In the exercises below, you will analyze some of the features of TLS by looking at the packets that are exchanged over a TLS session."
msgstr ""
#: ../../exercises/tls.rst:41
msgid "Footnotes"
msgstr "Notes de pied de page"
PK <> PK H}X 9 cnp3-ebook/index/locale/fr/LC_MESSAGES/exercises/trace.po# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2019 Olivier Bonaventure
# This file is distributed under the same license as the Computer networking : Principles, Protocols and Practice package.
# FIRST AUTHOR , YEAR.
#
msgid ""
msgstr ""
"Project-Id-Version: Computer networking : Principles, Protocols and Practice "
"3\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2021-05-17 09:55+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: Automatically generated\n"
"Language-Team: none\n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../exercises/trace.rst:6
msgid "Analyzing packet traces"
msgstr ""
#: ../../exercises/trace.rst:8
msgid "When debugging networking problems or to figure out performance problems, it is sometimes useful to capture the segments that are exchanged between two hosts and to analyze them."
msgstr ""
#: ../../exercises/trace.rst:10
msgid "Several packet trace analysis tools are available, either as commercial or open-source tools. These tools are able to capture all the packets exchanged on a link. Of course, capturing packets require administrator privileges. They can also analyze the content of the captured packets and display information about them. The captured packets can be stored in a file for offline analysis."
msgstr ""
#: ../../exercises/trace.rst:12
msgid "tcpdump_ is probably one of the most well known packet capture software. It is able to both capture packets and display their content. tcpdump_ is a text-based tool that can display the value of the most important fields of the captured packets. Additional information about tcpdump_ may be found in :manpage:`tcpdump(1)`."
msgstr ""
#: ../../exercises/trace.rst:15
msgid "As an illustration, let us use tcpdump_ to analyze the packets exchanged while executing the following command on a Linux host:"
msgstr ""
#: ../../exercises/trace.rst:28
msgid "The ``-6`` parameter passed to curl_ forces the utilization of IPv6. curl_ returns an HTML page that indicates that https must be used instead of http to access this web site."
msgstr ""
#: ../../exercises/trace.rst:35
msgid "A first solution to analyze this trace is to use tcpdump_ on the command line. The `-n` disables the reverse DNS lookups that tcpdump_ does by default for all IP addresses. The `-r` argument is the name of the file contained the captured packets. The trace starts with the DNS request. This request was sent over IPv4 which is the default on this host. tcpdump_ indicates the query and the response returned by the local DNS resolver."
msgstr ""
#: ../../exercises/trace.rst:45
msgid "The following three lines of the tcpdump_ output correspond to TCP's three-way handshake. There are several interesting points to note in this output. First, ``Flags [S]`` indicates that the `SYN` flag was set in the first and second segments. In this first segment, tcpdump_ indicates the initial sequence number (``2681184541``). In the second segment, tcpdump_ indicates both the initial sequence number (``3804204915``) and the acknowledgment number (``2681184542``). Both segments contain TCP options. Starting in the third segment, tcpdump_ shows relative sequence numbers. Thus, the acknowledgment that you observe in the third segment is an acknowledgment for the `SYN` returned by the server."
msgstr ""
#: ../../exercises/trace.rst:59
msgid "The two lines above correspond to the request sent by the client and the acknowledgment returned by the server. Note that the first byte sent by the client has `1` as relative sequence number. In this example, the HTTP request has a total length of 92 bytes. This request is immediately acknowledged by the server."
msgstr ""
#: ../../exercises/trace.rst:62
msgid "The server then sends its response, which fits inside a single segment. The client acknowledges the reception of this segment."
msgstr ""
#: ../../exercises/trace.rst:71
msgid "The TCP connection is then closed by exchanging three segments, the first two having the `FIN` flag set."
msgstr ""
#: ../../exercises/trace.rst:79
msgid "tcpdump_ can provide more detailed information about the packets by using the `-v` or `-vv` option."
msgstr ""
#: ../../exercises/trace.rst:82
msgid "wireshark_ is more recent than tcpdump_. It evolved from the ethereal packet trace analysis software. It can be used as a text tool like tcpdump_. For a TCP connection, wireshark_ can provide almost the same output as tcpdump_. The main advantage of wireshark_ is that it also includes a graphical user interface that allows performing various types of analysis on a packet trace."
msgstr ""
#: ../../exercises/trace.rst:88
msgid "Wireshark : default window"
msgstr ""
#: ../../exercises/trace.rst:94
msgid "The wireshark_ window is divided in three parts. The top part of the window is a summary of the first packets from the trace. By clicking on one of the lines, you can show the detailed content of this packet in the middle part of the window. The middle of the window allows you to inspect all the fields of the captured packet. The bottom part of the window is the hexadecimal representation of the packet, with the field selected in the middle window being highlighted."
msgstr ""
#: ../../exercises/trace.rst:96
msgid "wireshark_ is very good at displaying packets, but it also contains several analysis tools that can be very useful. The first tool is `Follow TCP stream`. It is part of the `Analyze` menu and allows you to reassemble and display all the payload exchanged during a TCP connection. This tool can be useful if you need to analyze for example the commands exchanged during an HTTP or SMTP session."
msgstr ""
#: ../../exercises/trace.rst:98
msgid "The second tool is the flow graph that is part of the `Statistics` menu. It provides a time sequence diagram of the packets exchanged with some comments about the packet contents. See below for an example."
msgstr ""
#: ../../exercises/trace.rst:104
msgid "Wireshark : flow graph"
msgstr ""
#: ../../exercises/trace.rst:107
msgid "Use wireshark to analyze the packet traces described earlier :download:`traces/simple-trace.pcap`."
msgstr ""
#: ../../exercises/trace.rst:109
msgid "When analyzing packet traces with wireshark_, it is often very useful to use `Display filters` that only show the packets that match some specific criteria. There filters are described in several online documents:"
msgstr ""
#: ../../exercises/trace.rst:111
msgid "the `wireshark wiki ` page on `Display filters `_"
msgstr ""
#: ../../exercises/trace.rst:112
msgid "a nice `list of Wireshark Display Filters `_ by Robert Allen"
msgstr ""
#: ../../exercises/trace.rst:114
msgid "You can now use your understanding of wireshark_ and tcpdump_ to analyze a 2-minutes long packet trace."
msgstr ""
PKf$I I PK H}X = cnp3-ebook/index/locale/fr/LC_MESSAGES/exercises/transport.po# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2019 Olivier Bonaventure
# This file is distributed under the same license as the Computer networking
# : Principles, Protocols and Practice package.
# FIRST AUTHOR , 2019.
#
msgid ""
msgstr ""
"Project-Id-Version: Computer networking : Principles, Protocols and Practice "
"3\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2019-10-09 12:39+0000\n"
"PO-Revision-Date: 2021-08-27 14:47+0000\n"
"Last-Translator: Anthony Gego \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n > 1;\n"
"X-Generator: Weblate 3.9.1\n"
"Generated-By: Babel 2.7.0\n"
#: ../../exercises/transport.rst:7
msgid "Serving applications"
msgstr "Servir des applications"
#: ../../exercises/transport.rst:10
msgid ""
"This is an unpolished draft of the third edition of this e-book. If you "
"find any error or have suggestions to improve the text, please create an "
"issue via https://github.com/CNP3/ebook/issues?milestone=3 or help us by "
"providing pull requests to close the existing issues."
msgstr ""
"Ceci est une ébauche non révisée de la troisième édition de cet e-book. Si "
"vous trouvez une quelconque erreur ou avez des suggestions pour améliorer ce "
"texte, n'hésitez pas à envoyer une issue via https://github.com/CNP3/ebook/"
"issues?milestone=3 ou aidez-nous en fournissant une pull request afin de "
"clore les issues existantes."
#: ../../exercises/transport.rst:14
msgid "Open questions"
msgstr "Questions ouvertes"
#: ../../exercises/transport.rst:16
msgid ""
"Which mechanisms that should be included in a transport protocol that "
"provides an unreliable connectionless transport service that can detect "
"transmission errors but not correct them ?"
msgstr ""
"Quels mécanismes devraient être inclus dans un protocole de transport "
"fournissant un transport service connectionless non fiable pouvant détecter "
"les erreurs de transmission mais sans les corriger ?"
#: ../../exercises/transport.rst:18
msgid ""
"A reliable connection oriented transport places a 32 bits sequence number"
" inside the segment header to number the segments. This sequence number "
"is incremented for each data segment. The connection starts as shown in "
"the figure below :"
msgstr ""
"Un transport fiable via connexion place un numéro de séquence de 32 bits à "
"l'intérieur d'un segment header afin d'énumérer les segments. Ce numéro de "
"séquence est incrémenté pour chaque segment data. La connexion commence "
"comme montré dans la figure ci-dessous :"
#: ../../exercises/transport.rst:38
msgid ""
"Continue the connection so that `Host B` sends `Hello` as data and `Host "
"A` replies by sending `Pleased to meet you`. After having received the "
"response, `Host B` closes the connection gracefully and `Host A` does the"
" same. Discuss on the state that needs to be maintained inside each host."
msgstr ""
"Continuez la connexion pour que l'`Hôte B` envoie comme donnée `Hello` et "
"que l'`Hôte A` réponde en envoyant `Pleased to meet you`. Après avoir reçu "
"la réponse, l'`Hôte B` termine la connexion gracefully et l'`Hôte A` fait de "
"même. Discutez de l'état qui doit être maintenu pour chaque hôte."
#: ../../exercises/transport.rst:40
msgid ""
"A transport connection that provides a message-mode service has been "
"active for some time and all data has been exchanged and acknowledged in "
"both directions. As in the exercise above, the sequence number is "
"incremented after the transmission of each segment. At this time, `Host "
"A` sends two DATA segments as shown in the figure below."
msgstr ""
"Une liaison de transport qui fournit un service message-mode est active "
"depuis un certain temps et toutes les données ont été échangées et "
"accréditées dans les deux directions. Comme dans l'exercice avant, le numéro "
"de séquence est incrémenté après la transmission de chaque segment. Cette "
"fois-ci, l'`Hôte A` envoie deux segments DATA comme illustré dans la figure "
"ci-dessous."
#: ../../exercises/transport.rst:57
msgid ""
"What are the acknowledgments sent by `Host B`. How does `Host A` react "
"and how does it terminate the connection ?"
msgstr ""
"Quels sont les acknowledgments envoyés par l'`Hôte B`. Comment réagit l'`"
"Hôte A` et comment termine-t-il la connexion ?"
#: ../../exercises/transport.rst:60
msgid ""
"Consider a reliable connection-oriented transport protocol that provides "
"the bytestream service. In this transport protocol, the sequence number "
"that is placed inside each DATA segment reflects the position of the "
"bytes in the bytestream. Considering the connection shown below, provide "
"the DATA segments that are sent by `Host A` in response to the "
"`DATA.request`, assuming that one segment is sent for each "
"`DATA.request`."
msgstr ""
"Considérez un protocole de transport par connexion qui fournit un service "
"bytestream. Dans ce protocole, le numéro de séquence placé à l'intérieur de "
"chaque segment DATA reflète la position des bytes dans le bytestream. En "
"considérant la connexion illustrée ci-dessous, établissez les segments DATA "
"qui sont envoyés par l'`Hôte A` en réponse au `Data.request`, en considérant "
"qu'un segment est envoyé pour chaque `Data.request`."
#: ../../exercises/transport.rst:86
msgid ""
"Same question as above, but consider now that the transport protocol "
"tries to send large DATA segments whenever possible. For this exercise, "
"we consider that a DATA segment can contain up to 8 bytes of data in the "
"payload. Do not forget to show the acknowledgments in your answer."
msgstr ""
"Même question qu'avant, en considérant cette fois-ci que le protocole de "
"transport tente d'envoyer de larges segments DATA dès que possible. Pour cet "
"exercice, nous considérons que le segment DATA peut contenir jusqu'à 8 bytes "
"de données dans le payload. N'oubliez pas d'inclure les acknowledgments dans "
"votre réponse."
#: ../../exercises/transport.rst:88
msgid ""
"Consider a transport protocol that provides a reliable connection-"
"oriented bytestream service. You observe the segments sent by a host that"
" uses this protocol. Does the time-sequence diagram below reflects a "
"valid implementation of this protocol ? Justify your answer."
msgstr ""
"Considérez un protocole de transport qui fournit un service bytestream par "
"connexion. Vous observez les segments envoyés par un hôte qui utilise ce "
"protocole. Est-ce que le diagramme de séquence ci-dessous reflète une "
"implémentation valide de ce protocole ? Justifiez votre réponse."
#: ../../exercises/transport.rst:105
msgid ""
"In the above example, the two `DATA` segments were lost before arriving "
"at the destination. Discuss the following scenario and explain how the "
"receiver should react to the reception of the last `DATA` segment."
msgstr ""
"Dans l'exemple ci-dessus, les deux segments `DATA` ont été perdus avant "
"d'arriver à destination. Discutez du scénario suivant et expliquer comment "
"le receiver devrait réagir lors de la réception du dernier segment `DATA`."
#: ../../exercises/transport.rst:122
msgid ""
"A network layer service guarantees that a packet will never live during "
"more than 100 seconds inside the network. Consider a reliable connection-"
"oriented transport protocol that places a 32 bits sequence number inside "
"each segment. What is the maximum rate (in segments per second) at which "
"is should sent data segments to prevent having two segments with the same"
" sequence number inside the network ?"
msgstr ""
"Un service de la couche réseau garantit qu'un paquet ne transitera pas plus "
"de 100 secondes dans le réseau. Considérez un protocole de transport fiable "
"par connexion qui place un numéro de séquence de 32 bits à l'intérieur de "
"chaque segment. Quel est le taux maximum (en segments par seconde) auquel "
"les segments de données devraient être envoyées pour éviter d'avoir deux "
"segments avec le même numéro de séquence à l'intérieur du réseau ?"
#: ../../exercises/transport.rst:126
msgid "Practice"
msgstr "Exercices"
#: ../../exercises/transport.rst:128
msgid ""
"Amazon provides the `S3 storage service `_ "
"where companies and researchers can store lots of information and perform"
" computations on the stored information. Amazon allows users to send "
"files through the Internet, but also by sending hard-disks. Assume that a"
" 1 Terabyte hard-disk can be delivered within 24 hours to Amazon by "
"courier service. What is the minimum bandwidth required to match the "
"bandwidth of this courier service ?"
msgstr ""
"Amazon fournit le `S3 storage service ‹https://s3.amazonaws.com/›`_ où les "
"entreprises et les chercheurs peuvent stocker beaucoup d'information et "
"effectuer des calculs sur l'information stockée. Amazon permet aux "
"utilisateurs d'envoyer des fichiers via Internet, mais également en envoyant "
"des disques durs. En considérant qu'un disque dur de 1 Terabyte peut être "
"livré en 24 heures à Amazon par service postal. Quelle serait la bande "
"passante minimale requise pour égaler le service postal ?"
#: ../../exercises/transport.rst:135
msgid "Discussion questions"
msgstr "Questions de discussion"
#: ../../exercises/transport.rst:137
msgid ""
"In the transport layer, the receive window advertised by a receiver can "
"vary during the lifetime of the connection. What are the causes for these"
" variations ?"
msgstr ""
"Dans la couche de transport, la fenêtre de réception envoyée par un receiver "
"peut varier tout au long de la durée de la connexion. Quels sont les causes "
"de ces variations ?"
#: ../../exercises/transport.rst:139
msgid ""
"A reliable connection-oriented protocol can provide a message-mode "
"service or a byte stream service. Which of the following usages of the "
"sequence numbers is the best suited for each of these services ?"
msgstr ""
"Un protocole fiable par connexion peut fournir un service message-mode ou un "
"service bytestream. Quels usages des numéros de séquence convient le mieux "
"pour chacun de ces services ?"
#: ../../exercises/transport.rst:141
msgid ""
"DATA segments contain a sequence number that is incremented for each byte"
" transmitted"
msgstr ""
"Les segments DATA contiennent des numéros de séquence qui sont incrémentés "
"pour chaque byte transmis"
#: ../../exercises/transport.rst:142
msgid ""
"DATA segments contain a sequence number that is incremented for each DATA"
" segment transmitted"
msgstr ""
"Les segments DATA contiennent des numéros de séquence qui sont incrémentés "
"pour chaque segment DATA transmis"
#: ../../exercises/transport.rst:144
msgid ""
"Some transport protocols use 32 bits sequence numbers while others use 64"
" bits sequence number. What are the advantages and drawbacks of each "
"approach ?"
msgstr ""
"Certains protocoles de transport utilisent des numéros de séquence sur 32 "
"bits alors que d'autres utilisent des numéros de séquence sur 64 bits. Quels "
"sont les avantages les inconvénients de chaque approche ?"
#: ../../exercises/transport.rst:146
msgid ""
"Consider a transport protocol that provides the bytestream service and "
"uses 32 bits sequence number to represent the position of the first byte "
"of the payload of DATA segments in the bytestream. How would you modify "
"this protocol so that it can provide a message-mode service ? Consider "
"first short messages that always fit inside a single segment. In a second"
" step, discuss how you could support messages of unlimited size."
msgstr ""
"Considérez un protocole de transport qui fournit un service bytestream et "
"utilise des numéros de séquence sur 32 bits afin de représenter la position "
"du premier byte du payload des segments DATA dans le bytestream. Quels "
"changements apporteriez-vous au protocole de sorte à ce qu'il puisse fournir "
"un service message-mode ? Considérez d'abord l'envoi de messages courts qui "
"ne dépassent pas la taille d'un seul segment. Dans un second temps, discutez "
"de comment vous feriez pour pouvoir gérer des messages de taille illimitée."
#: ../../exercises/transport.rst:148
msgid "What is piggybacking and what are the benefits of this technique ?"
msgstr ""
"Qu'est-ce que le piggybacking et quels sont les avantages de cette technique "
"?"
#: ../../exercises/transport.rst:155
msgid "Footnotes"
msgstr "Notes de pied de page"
PK- 1 1 PK H}X 2 cnp3-ebook/index/locale/fr/LC_MESSAGES/glossary.po# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2019 Olivier Bonaventure
# This file is distributed under the same license as the Computer networking
# : Principles, Protocols and Practice package.
# FIRST AUTHOR , 2019.
#
msgid ""
msgstr ""
"Project-Id-Version: Computer networking : Principles, Protocols and Practice "
"3\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2019-10-09 12:39+0000\n"
"PO-Revision-Date: 2022-06-15 20:11+0000\n"
"Last-Translator: Thomas ANTOINE \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n > 1;\n"
"X-Generator: Weblate 3.9.1\n"
"Generated-By: Babel 2.7.0\n"
#: ../../glossary.rst:8
msgid "Glossary"
msgstr "Glossaire"
#: ../../glossary.rst:322
msgid "address"
msgstr "Adresse"
#: ../../glossary.rst:324
msgid ""
"A string of bits that identifies a network interface in the network layer"
" or the datalink layer. Most addresses have a fixed length, e.g. 32 bits "
"for :term:`IPv4`, 128 bits for :term:`IPv6` or 48 bits for "
":term:`Ethernet` and other related Local Area Networks."
msgstr ""
"Une chaîne de bits qui identifie une interface réseau dans la couche réseau "
"ou dans la couche de liaison des données. La plupart des adresses ont une "
"taille fixe, par exemple 32 bits pour :term:`IPv4`, 128 bits pour "
":term:`IPv6` or 48 bits pour :term:`Ethernet` et d'autres réseaux locaux."
#: ../../glossary.rst:183
msgid "AIMD"
msgstr "AIMD"
#: ../../glossary.rst:185
msgid ""
"Additive Increase, Multiplicative Decrease. A rate adaption algorithm "
"used notably by TCP where a host additively increases its transmission "
"rate when the network is not congested and multiplicatively decreases "
"when congested is detected."
msgstr ""
#: ../../glossary.rst:15
msgid "anycast"
msgstr "anycast"
#: ../../glossary.rst:17
msgid ""
"a transmission mode where an information is sent from one source to `one`"
" receiver that belongs to a specified group"
msgstr ""
#: ../../glossary.rst:117
msgid "API"
msgstr "API"
#: ../../glossary.rst:119
msgid "Application Programming Interface"
msgstr ""
#: ../../glossary.rst:268
msgid "ARP"
msgstr ""
#: ../../glossary.rst:270
msgid ""
"The Address Resolution Protocol is a protocol used by IPv4 devices to "
"obtain the datalink layer address that corresponds to an IPv4 address on "
"the local area network. ARP is defined in :rfc:`826`"
msgstr ""
#: ../../glossary.rst:48
msgid "ARPANET"
msgstr ""
#: ../../glossary.rst:50
msgid ""
"The Advanced Research Project Agency (ARPA) Network is a network that was"
" built by network scientists in USA with funding from the ARPA of the US "
"Ministry of Defense. ARPANET is considered as the grandfather of today's "
"Internet."
msgstr ""
#: ../../glossary.rst:12
msgid "ascii"
msgstr "ascii"
#: ../../glossary.rst:14
msgid ""
"The American Standard Code for Information Interchange (ASCII) is a "
"character-encoding scheme that defines a binary representation for "
"characters. The ASCII table contains both printable characters and "
"control characters. ASCII characters were encoded in 7 bits and only "
"contained the characters required to write text in English. Other "
"character sets such as Unicode have been developed later to support all "
"written languages."
msgstr ""
#: ../../glossary.rst:99
msgid "ASN.1"
msgstr ""
#: ../../glossary.rst:101
msgid ""
"The Abstract Syntax Notation One (ASN.1) was designed by ISO and ITU-T. "
"It is a standard and flexible notation that can be used to describe data "
"structures for representing, encoding, transmitting, and decoding data "
"between applications. It was designed to be used in the Presentation "
"layer of the OSI reference model but is now used in other protocols such "
"as :term:`SNMP`."
msgstr ""
#: ../../glossary.rst:226
msgid "ATM"
msgstr ""
#: ../../glossary.rst:228
msgid "Asynchronous Transfer Mode"
msgstr ""
#: ../../glossary.rst:156
msgid "BGP"
msgstr ""
#: ../../glossary.rst:158
msgid ""
"The Border Gateway Protocol is the interdomain routing protocol used in "
"the global Internet."
msgstr ""
#: ../../glossary.rst:235
msgid "BNF"
msgstr ""
#: ../../glossary.rst:237
msgid ""
"A Backus-Naur Form (BNF) is a formal way to describe a language by using "
"syntactic and lexical rules. BNFs are frequently used to define "
"programming languages, but also to define the messages exchanged between "
"networked applications. :rfc:`5234` explains how a BNF must be written to"
" specify an Internet protocol."
msgstr ""
#: ../../glossary.rst:24
msgid "broadcast"
msgstr ""
#: ../../glossary.rst:26
msgid ""
"a transmission mode where is same information is sent to all nodes in the"
" network"
msgstr ""
#: ../../glossary.rst:129
msgid "CIDR"
msgstr ""
#: ../../glossary.rst:131
msgid ""
"Classless Inter Domain Routing is the current address allocation "
"architecture for IP version 4. It was defined in :rfc:`1518` and "
":rfc:`4632`."
msgstr ""
#: ../../glossary.rst:283
msgid "dial-up line"
msgstr ""
#: ../../glossary.rst:285
msgid ""
"A synonym for a regular telephone line, i.e. a line that can be used to "
"dial any telephone number."
msgstr ""
#: ../../glossary.rst:54 ../../glossary.rst:211 ../../glossary.rst:232
msgid "DNS"
msgstr ""
#: ../../glossary.rst:56
msgid ""
"The Domain Name System is a distributed database that allows to map names"
" on IP addresses."
msgstr ""
#: ../../glossary.rst:213
msgid "The Domain Name System is defined in :rfc:`1035`"
msgstr ""
#: ../../glossary.rst:234
msgid ""
"The Domain Name System is a distributed database that can be queried by "
"hosts to map names onto IP addresses"
msgstr ""
#: ../../glossary.rst:171
msgid "eBGP"
msgstr ""
#: ../../glossary.rst:173
msgid ""
"An eBGP session is a BGP session between two directly connected routers "
"that belong to two different Autonomous Systems. Also called an external "
"BGP session."
msgstr ""
#: ../../glossary.rst:150
msgid "EGP"
msgstr ""
#: ../../glossary.rst:152
msgid "Exterior Gateway Protocol. Synonym of interdomain routing protocol"
msgstr ""
#: ../../glossary.rst:159
msgid "EIGRP"
msgstr ""
#: ../../glossary.rst:161
msgid ""
"The Enhanced Interior Gateway Routing Protocol (EIGRP) is a proprietary "
"intradomain routing protocol that is often used in enterprise networks. "
"EIGRP uses the DUAL algorithm described in [Garcia1993]_."
msgstr ""
#: ../../glossary.rst:325
msgid "Ethernet"
msgstr ""
#: ../../glossary.rst:327
msgid "The most widely used LAN technology."
msgstr ""
#: ../../glossary.rst:319
msgid "file transfer"
msgstr ""
#: ../../glossary.rst:321
msgid ""
"A service that enables a user to send or receive a file from a distant "
"server over the network. The File Transfer Protocol :term:`FTP` was a "
"popular service. It has now been replaced by HTTP/HTTPs or more secure "
"protocols such as the `SSH File Transfer Protocol "
"`_."
msgstr ""
#: ../../glossary.rst:63
msgid "frame"
msgstr ""
#: ../../glossary.rst:65
msgid "a frame is the unit of information transfer in the datalink layer"
msgstr ""
#: ../../glossary.rst:229
msgid "Frame-Relay"
msgstr ""
#: ../../glossary.rst:231
msgid ""
"A wide area networking technology using virtual circuits that is "
"deployed by telecom operators."
msgstr ""
#: ../../glossary.rst:102
msgid "ftp"
msgstr ""
#: ../../glossary.rst:104
msgid ""
"The File Transfer Protocol defined in :rfc:`959` has been the `de facto` "
"protocol to exchange files over the Internet before the widespread "
"adoption of HTTP :rfc:`2616`."
msgstr ""
#: ../../glossary.rst:198
msgid "FTP"
msgstr ""
#: ../../glossary.rst:200
msgid "The File Transfer Protocol is defined in :rfc:`959`"
msgstr ""
#: ../../glossary.rst:313
msgid "hosts.txt"
msgstr ""
#: ../../glossary.rst:315
msgid ""
"The original file containing the list of all Internet hosts. This file "
"has been deprecated, but Unix variants still maintain a local "
"``/etc/hosts`` containing mappings between names and IP addresses. See "
"http://man7.org/linux/man-pages/man5/hosts.5.html for a description of "
"the format of this file on Linux."
msgstr ""
#: ../../glossary.rst:262
msgid "HTML"
msgstr ""
#: ../../glossary.rst:264
msgid ""
"The HyperText Markup Language specifies the structure and the syntax of "
"the documents that are exchanged on the world wide web. HTML is "
"maintained by the `HTML working group `_ of "
"the :term:`W3C`"
msgstr ""
#: ../../glossary.rst:186
msgid "HTTP"
msgstr ""
#: ../../glossary.rst:188
msgid "The HyperText Transport Protocol is defined in :rfc:`2616`"
msgstr ""
#: ../../glossary.rst:180
msgid "hub"
msgstr ""
#: ../../glossary.rst:182
msgid "A relay operating in the physical layer."
msgstr ""
#: ../../glossary.rst:132
msgid "IANA"
msgstr ""
#: ../../glossary.rst:134
msgid ""
"The Internet Assigned Numbers Authority (IANA) is responsible for the "
"coordination of the DNS Root, IP addressing, and other Internet protocol "
"resources"
msgstr ""
#: ../../glossary.rst:168
msgid "iBGP"
msgstr ""
#: ../../glossary.rst:170
msgid ""
"An iBGP session is a BGP between two routers belonging to the same "
"Autonomous System. Also called an internal BGP session."
msgstr ""
#: ../../glossary.rst:241
msgid "ICANN"
msgstr ""
#: ../../glossary.rst:243
msgid ""
"The Internet Corporation for Assigned Names and Numbers (ICANN) "
"coordinates the allocation of domain names, IP addresses and AS numbers "
"as well protocol parameters. It also coordinates the operation and the "
"evolution of the DNS root name servers."
msgstr ""
#: ../../glossary.rst:42
msgid "IETF"
msgstr ""
#: ../../glossary.rst:44
msgid ""
"The Internet Engineering Task Force is a non-profit organization that "
"develops the standards for the protocols used in the Internet. The IETF "
"mainly covers the transport and network layers. Several application layer"
" protocols are also standardized within the IETF. The work in the IETF is"
" organized in working groups. Most of the work is performed by exchanging"
" emails and there are three IETF meetings every year. Participation is "
"open to anyone. See https://www.ietf.org"
msgstr ""
#: ../../glossary.rst:147
msgid "IGP"
msgstr ""
#: ../../glossary.rst:149
msgid "Interior Gateway Protocol. Synonym of intradomain routing protocol"
msgstr ""
#: ../../glossary.rst:162
msgid "IGRP"
msgstr ""
#: ../../glossary.rst:164
msgid ""
"The Interior Gateway Routing Protocol (IGRP) is a proprietary intradomain"
" routing protocol that uses distance vector. IGRP supports multiple "
"metrics for each route but has been replaced by :term:`EIGRP`"
msgstr ""
#: ../../glossary.rst:195 ../../glossary.rst:259
msgid "IMAP"
msgstr ""
#: ../../glossary.rst:197
msgid "The Internet Message Access Protocol is defined in :rfc:`3501`"
msgstr ""
#: ../../glossary.rst:261
msgid ""
"The Internet Message Access Protocol (IMAP), defined in :rfc:`3501`, is "
"an application-level protocol that allows a client to access and "
"manipulate the emails stored on a server. With IMAP, the email messages "
"remain on the server and are not downloaded on the client."
msgstr ""
#: ../../glossary.rst:69
msgid "Internet"
msgstr ""
#: ../../glossary.rst:71
msgid ""
"a public internet, i.e. a network composed of different networks that are"
" running :term:`IPv4` or :term:`IPv6`"
msgstr ""
#: ../../glossary.rst:72
msgid "internet"
msgstr ""
#: ../../glossary.rst:74
msgid ""
"an internet is an internetwork, i.e. a network composed of different "
"networks. The :term:`Internet`, with a capital `I` corresponds to the "
"global network that we use today, but other internetworks have been used "
"in the path."
msgstr ""
#: ../../glossary.rst:304
msgid "inverse query"
msgstr ""
#: ../../glossary.rst:306
msgid ""
"For DNS servers and resolvers, an inverse query is a query for the domain"
" name that corresponds to a given IP address."
msgstr ""
#: ../../glossary.rst:75
msgid "IP"
msgstr ""
#: ../../glossary.rst:77
msgid ""
"Internet Protocol is the generic term for the network layer protocol in "
"the TCP/IP protocol suite. IP version 4 is widely used but IP version 6 "
"is being deployed globally."
msgstr ""
#: ../../glossary.rst:78
msgid "IPv4"
msgstr ""
#: ../../glossary.rst:80
msgid ""
"is the version 4 of the Internet Protocol, the connectionless network "
"layer protocol used in most of the Internet today. IPv4 addresses are "
"encoded as a 32 bits field."
msgstr ""
#: ../../glossary.rst:81
msgid "IPv6"
msgstr ""
#: ../../glossary.rst:83
msgid ""
"is the version 6 of the Internet Protocol, the connectionless network "
"layer protocol which is intended to replace IPv4. IP version 6 addresses "
"are encoded as a 128 bits field."
msgstr ""
#: ../../glossary.rst:144
msgid "IS-IS"
msgstr ""
#: ../../glossary.rst:146
msgid ""
"Intermediate System- Intermediate System. A link-state intradomain "
"routing that was initially defined for the ISO CLNP protocol but was "
"extended to support IP v4 and IP v6. IS-IS is often used in ISP networks."
" It is defined in [ISO10589]_"
msgstr ""
#: ../../glossary.rst:105
msgid "ISN"
msgstr ""
#: ../../glossary.rst:107
msgid ""
"The Initial Sequence Number of a TCP connection is the sequence number "
"chosen by the client ( resp. server) that is placed in the `SYN` (resp. "
"`SYN+ACK`) segment during the establishment of the TCP connection."
msgstr ""
#: ../../glossary.rst:36 ../../glossary.rst:271
msgid "ISO"
msgstr ""
#: ../../glossary.rst:38
msgid ""
"The International Standardization Organization is an agency of the United"
" Nations that is based in Geneva and develop standards on various topics."
" Within ISO, country representatives vote to approve or reject standards."
" Most of the work on the development of ISO standards is done in expert "
"working groups. Additional information about ISO may be obtained from "
"https://www.iso.org"
msgstr ""
#: ../../glossary.rst:273
msgid "The International Standardization Organization"
msgstr ""
#: ../../glossary.rst:289
msgid "ISO-3166"
msgstr ""
#: ../../glossary.rst:291
msgid ""
"An :term:`ISO` standard that defines codes to represent countries and "
"their subdivisions. See http://www.iso.org/iso/country_codes.htm"
msgstr ""
#: ../../glossary.rst:295
msgid "ISP"
msgstr ""
#: ../../glossary.rst:297
msgid ""
"An Internet Service Provider, i.e. a network that provides Internet "
"access to its clients."
msgstr ""
#: ../../glossary.rst:39
msgid "ITU"
msgstr ""
#: ../../glossary.rst:41
msgid ""
"The International Telecommunication Union is a United Nation's agency "
"whose purpose is to develop standards for the telecommunication industry."
" It was initially created to standardize the basic telephone system but "
"expanded later towards data networks. The work within ITU is mainly done "
"by network specialists from the telecommunication industry (operators and"
" vendors). See https://www.itu.int for more information"
msgstr ""
#: ../../glossary.rst:153
msgid "IXP"
msgstr ""
#: ../../glossary.rst:155
msgid ""
"Internet eXchange Point. A location where routers belonging to different "
"domains are attached to the same Local Area Network to establish peering "
"sessions and exchange packets. See http://www.euro-ix.net/ or "
"https://en.wikipedia.org/wiki/List_of_Internet_exchange_points_by_size "
"for a partial list of IXPs."
msgstr ""
#: ../../glossary.rst:27
msgid "LAN"
msgstr ""
#: ../../glossary.rst:29
msgid "Local Area Network"
msgstr ""
#: ../../glossary.rst:286
msgid "leased line"
msgstr ""
#: ../../glossary.rst:288
msgid "A telephone line that is permanently available between two endpoints."
msgstr ""
#: ../../glossary.rst:30
msgid "MAN"
msgstr ""
#: ../../glossary.rst:32
msgid "Metropolitan Area Network"
msgstr ""
#: ../../glossary.rst:253
msgid "MIME"
msgstr ""
#: ../../glossary.rst:255
msgid ""
"The Multipurpose Internet Mail Extensions (MIME) defined in :rfc:`2045` "
"are a set of extensions to the format of email messages that allow to use"
" non-ASCII characters inside mail messages. A MIME message can be "
"composed of several different parts each having a different format."
msgstr ""
#: ../../glossary.rst:277
msgid "MIME document"
msgstr ""
#: ../../glossary.rst:279
msgid "A MIME document is a document, encoded by using the :term:`MIME` format."
msgstr ""
#: ../../glossary.rst:274
msgid "minicomputer"
msgstr ""
#: ../../glossary.rst:276
msgid ""
"A minicomputer is a multi-user system that was typically used in the "
"1960s/1970s to serve departments. See the corresponding Wikipedia article"
" for additional information : https://en.wikipedia.org/wiki/Minicomputer"
msgstr ""
#: ../../glossary.rst:280
msgid "modem"
msgstr ""
#: ../../glossary.rst:282
msgid ""
"A modem (modulator-demodulator) is a device that encodes (resp. decodes) "
"digital information by modulating (resp. demodulating) an analog signal. "
"Modems are frequently used to transmit digital information over telephone"
" lines and radio links. See https://en.wikipedia.org/wiki/Modem for a "
"survey of various types of modems"
msgstr ""
#: ../../glossary.rst:123
msgid "MSS"
msgstr ""
#: ../../glossary.rst:125
msgid ""
"A TCP option used by a TCP entity in SYN segments to indicate the Maximum"
" Segment Size that it is able to receive."
msgstr ""
#: ../../glossary.rst:21
msgid "multicast"
msgstr ""
#: ../../glossary.rst:23
msgid ""
"a transmission mode where an information is sent efficiently to `all` the"
" receivers that belong to a given group"
msgstr ""
#: ../../glossary.rst:250
msgid "nameserver"
msgstr ""
#: ../../glossary.rst:252
msgid ""
"A server that implements the DNS protocol and can answer queries for "
"names inside its own domain."
msgstr ""
#: ../../glossary.rst:165
msgid "NAT"
msgstr ""
#: ../../glossary.rst:167
msgid "A Network Address Translator is a middlebox that translates IP packets."
msgstr ""
#: ../../glossary.rst:310
msgid "NBMA"
msgstr ""
#: ../../glossary.rst:312
msgid ""
"A Non Broadcast Mode Multiple Access Network is a subnetwork that "
"supports multiple hosts/routers but does not provide an efficient way of "
"sending broadcast frames to all devices attached to the subnetwork. ATM "
"subnetworks are an example of NBMA networks."
msgstr ""
#: ../../glossary.rst:298
msgid "network-byte order"
msgstr ""
#: ../../glossary.rst:300
msgid ""
"Internet protocol allow to transport sequences of bytes. These sequences "
"of bytes are sufficient to carry ASCII characters. The network-byte order"
" refers to the Big-Endian encoding for 16 and 32 bits integer. See "
"https://en.wikipedia.org/wiki/Endianness"
msgstr ""
#: ../../glossary.rst:217
msgid "NFS"
msgstr ""
#: ../../glossary.rst:219
msgid "The Network File System is defined in :rfc:`1094`"
msgstr ""
#: ../../glossary.rst:220
msgid "NTP"
msgstr ""
#: ../../glossary.rst:222
msgid "The Network Time Protocol is defined in :rfc:`1305`"
msgstr ""
#: ../../glossary.rst:93
msgid "OSI"
msgstr ""
#: ../../glossary.rst:95
msgid ""
"Open Systems Interconnection. A set of networking standards developed by "
":term:`ISO` including the 7 layers OSI reference model."
msgstr ""
#: ../../glossary.rst:141
msgid "OSPF"
msgstr "OSPF"
#: ../../glossary.rst:143
msgid ""
"Open Shortest Path First. A link-state intradomain routing protocol that"
" is often used in enterprise and ISP networks. OSPF is defined in and "
":rfc:`2328` and :rfc:`5340`"
msgstr ""
#: ../../glossary.rst:57
msgid "packet"
msgstr ""
#: ../../glossary.rst:59
msgid "a packet is the unit of information transfer in the network layer"
msgstr ""
#: ../../glossary.rst:51
msgid "PBL"
msgstr ""
#: ../../glossary.rst:53
msgid "Problem-based learning is a teaching approach that relies on problems."
msgstr ""
#: ../../glossary.rst:192 ../../glossary.rst:256
msgid "POP"
msgstr ""
#: ../../glossary.rst:194
msgid "The Post Office Protocol is defined in :rfc:`1939`"
msgstr ""
#: ../../glossary.rst:258
msgid ""
"The Post Office Protocol (POP), defined :rfc:`1939`, is an application-"
"level protocol that allows a client to download email messages stored on "
"a server."
msgstr ""
#: ../../glossary.rst:316
msgid "remote login"
msgstr ""
#: ../../glossary.rst:318
msgid ""
"A service that enables a user to connect to a distant server over the "
"network. Telnet, defined in :rfc:`854` and the BSD rlogin services "
"defined in :rfc:`1282` were popular in the past. They have been "
"deprecated for security reasons and are now replaced by :term:`ssh`."
msgstr ""
#: ../../glossary.rst:247
msgid "resolver"
msgstr ""
#: ../../glossary.rst:249
msgid ""
"A server that implements the DNS protocol and can resolve queries. A "
"resolver usually serves a set of clients (e.g. all hosts in campus or all"
" clients of a given ISP). It sends DNS queries to nameservers everywhere "
"on behalf of its clients and stores the received answers in its cache. A "
"resolver must know the IP addresses of the root nameservers."
msgstr ""
#: ../../glossary.rst:138
msgid "RIP"
msgstr "RIP"
#: ../../glossary.rst:140
msgid ""
"Routing Information Protocol. An intradomain routing protocol based on "
"distance vectors that is sometimes used in enterprise networks. RIP is "
"defined in :rfc:`2453`."
msgstr ""
#: ../../glossary.rst:135
msgid "RIR"
msgstr ""
#: ../../glossary.rst:137
msgid ""
"Regional Internet Registry. An organization that manages IP addresses and"
" AS numbers on behalf of :term:`IANA`."
msgstr ""
#: ../../glossary.rst:244
msgid "root nameserver"
msgstr ""
#: ../../glossary.rst:246
msgid ""
"A name server that is responsible for the root of the domain names "
"hierarchy. There are currently a dozen root nameservers and each DNS "
"resolver See http://www.root-servers.org/ for more information about the "
"operation of these root servers."
msgstr ""
#: ../../glossary.rst:126
msgid "round-trip-time"
msgstr ""
#: ../../glossary.rst:128
msgid ""
"The round-trip-time (RTT) is the delay between the transmission of a "
"segment and the reception of the corresponding acknowledgment in a "
"transport protocol."
msgstr ""
#: ../../glossary.rst:174
msgid "router"
msgstr ""
#: ../../glossary.rst:176
msgid "A relay operating in the network layer."
msgstr ""
#: ../../glossary.rst:214
msgid "RPC"
msgstr ""
#: ../../glossary.rst:216
msgid ""
"Several types of remote procedure calls have been defined. The RPC "
"mechanism defined in :rfc:`5531` is used by applications such as NFS"
msgstr ""
#: ../../glossary.rst:66
msgid "SDU (Service Data Unit)"
msgstr ""
#: ../../glossary.rst:68
msgid ""
"a Service Data Unit is the unit information transferred between "
"applications"
msgstr ""
#: ../../glossary.rst:60
msgid "segment"
msgstr ""
#: ../../glossary.rst:62
msgid "a segment is the unit of information transfer in the transport layer"
msgstr ""
#: ../../glossary.rst:189
msgid "SMTP"
msgstr ""
#: ../../glossary.rst:191
msgid "The Simple Mail Transfer Protocol is defined in :rfc:`821`"
msgstr ""
#: ../../glossary.rst:96
msgid "SNMP"
msgstr ""
#: ../../glossary.rst:98
msgid ""
"The Simple Network Management Protocol is a management protocol defined "
"for TCP/IP networks."
msgstr ""
#: ../../glossary.rst:120
msgid "socket"
msgstr ""
#: ../../glossary.rst:122
msgid ""
"A low-level API originally defined on Berkeley Unix to allow programmers "
"to develop clients and servers."
msgstr ""
#: ../../glossary.rst:108
msgid "spoofed packet"
msgstr ""
#: ../../glossary.rst:110
msgid ""
"A packet is said to be spoofed when the sender of the packet has used as "
"source address a different address than its own."
msgstr ""
#: ../../glossary.rst:201
msgid "SSH"
msgstr ""
#: ../../glossary.rst:203
msgid "The Secure Shell (SSH) Transport Layer Protocol is defined in :rfc:`4253`"
msgstr ""
#: ../../glossary.rst:301
msgid "standard query"
msgstr ""
#: ../../glossary.rst:303
msgid ""
"For DNS servers and resolvers, a standard query is a query for a `A` or a"
" `AAAA` record. Such a query typically returns an IP address."
msgstr ""
#: ../../glossary.rst:177
msgid "switch"
msgstr ""
#: ../../glossary.rst:179
msgid "A relay operating in the datalink layer."
msgstr ""
#: ../../glossary.rst:111
msgid "SYN cookie"
msgstr ""
#: ../../glossary.rst:113
msgid ""
"The SYN cookies is a technique used to compute the initial sequence "
"number (ISN)"
msgstr ""
#: ../../glossary.rst:114
msgid "TCB"
msgstr ""
#: ../../glossary.rst:116
msgid ""
"The Transmission Control Block is the set of variables that are "
"maintained for each established TCP connection by a TCP implementation."
msgstr ""
#: ../../glossary.rst:87
msgid "TCP"
msgstr ""
#: ../../glossary.rst:89
msgid ""
"The Transmission Control Protocol is a protocol of the transport layer in"
" the TCP/IP protocol suite that provides a reliable bytestream "
"connection-oriented service on top of IP"
msgstr ""
#: ../../glossary.rst:84
msgid "TCP/IP"
msgstr ""
#: ../../glossary.rst:86
msgid "refers to the :term:`TCP` and :term:`IP` protocols"
msgstr ""
#: ../../glossary.rst:204
msgid "telnet"
msgstr ""
#: ../../glossary.rst:206
msgid "The telnet protocol is defined in :rfc:`854`"
msgstr ""
#: ../../glossary.rst:238
msgid "TLD"
msgstr ""
#: ../../glossary.rst:240
msgid ""
"A Top-level domain name. There are two types of TLDs. The ccTLD are the "
"TLD that correspond to a two letters :term:`ISO-3166` country code. The "
"gTLD are the generic TLDs that are not assigned to a country."
msgstr ""
#: ../../glossary.rst:307
msgid "TLS"
msgstr ""
#: ../../glossary.rst:309
msgid ""
"Transport Layer Security, defined in :rfc:`5246` is a cryptographic "
"protocol that is used to provide communication security for Internet "
"applications. This protocol is used on top of the transport service but a"
" detailed description is outside the scope of this book."
msgstr ""
#: ../../glossary.rst:90
msgid "UDP"
msgstr ""
#: ../../glossary.rst:92
msgid ""
"User Datagram Protocol is a protocol of the transport layer in the TCP/IP"
" protocol suite that provides an unreliable connectionless service that "
"includes a mechanism to detect corruption"
msgstr ""
#: ../../glossary.rst:18
msgid "unicast"
msgstr ""
#: ../../glossary.rst:20
msgid ""
"a transmission mode where an information is sent from one source to one "
"recipient"
msgstr ""
#: ../../glossary.rst:292
msgid "vnc"
msgstr ""
#: ../../glossary.rst:294
msgid ""
"A networked application that allows to remotely access a computer's "
"Graphical User Interface. See "
"https://en.wikipedia.org/wiki/Virtual_Network_Computing"
msgstr ""
#: ../../glossary.rst:45
msgid "W3C"
msgstr ""
#: ../../glossary.rst:47
msgid ""
"The world wide web consortium was created to standardize the protocols "
"and mechanisms used in the world wide web. It is thus focused on a subset"
" of the application layer. See https://www.w3.org"
msgstr ""
#: ../../glossary.rst:33
msgid "WAN"
msgstr ""
#: ../../glossary.rst:35
msgid "Wide Area Network"
msgstr ""
#: ../../glossary.rst:223
msgid "X.25"
msgstr ""
#: ../../glossary.rst:225
msgid ""
"A wide area networking technology using virtual circuits that was "
"deployed by telecommunication operators."
msgstr ""
#: ../../glossary.rst:207
msgid "X11"
msgstr ""
#: ../../glossary.rst:209
msgid "The XWindow system and the associated protocols are defined in [SG1990]_"
msgstr ""
#: ../../glossary.rst:265
msgid "XML"
msgstr ""
#: ../../glossary.rst:267
msgid ""
"The eXtensible Markup Language (XML) is a flexible text format derived "
"from SGML. It was originally designed for the electronic publishing "
"industry but is now used by a wide variety of applications that need to "
"exchange structured data. The XML specifications are maintained by "
"`several working groups `_ of the :term:`W3C`"
msgstr ""
#~ msgid ""
#~ "Classless Inter Domain Routing is the"
#~ " current address allocation architecture "
#~ "for IPv4. It was defined in "
#~ ":rfc:`1518` and :rfc:`4632`."
#~ msgstr ""
#~ msgid ""
#~ "The File Transfer Protocol defined in"
#~ " :rfc:`959` has been the de facto "
#~ "protocol to exchange files over the "
#~ "Internet before the widespread adoption "
#~ "of HTTP :rfc:`2616`"
#~ msgstr ""
#~ msgid ""
#~ "A file that initially contained the "
#~ "list of all Internet hosts with "
#~ "their IPv4 address. As the network "
#~ "grew, this file was replaced by "
#~ "the DNS, but each host still "
#~ "maintains a small hosts.txt file that"
#~ " can be used when DNS is not"
#~ " available."
#~ msgstr ""
#~ msgid ""
#~ "The HyperText Markup Language specifies "
#~ "the structure and the syntax of "
#~ "the documents that are exchanged on "
#~ "the world wide web. HTML is "
#~ "maintained by the `HTML working group"
#~ " `_ of the "
#~ ":term:`W3C`"
#~ msgstr ""
#~ msgid ""
#~ "The Internet Engineering Task Force is"
#~ " a non-profit organisation that "
#~ "develops the standards for the protocols"
#~ " used in the Internet. The IETF "
#~ "mainly covers the transport and network"
#~ " layers. Several application layer "
#~ "protocols are also standardised within "
#~ "the IETF. The work in the IETF "
#~ "is organised in working groups. Most "
#~ "of the work is performed by "
#~ "exchanging emails and there are three"
#~ " IETF meetings every year. Participation"
#~ " is open to anyone. See "
#~ "http://www.ietf.org"
#~ msgstr ""
#~ msgid ""
#~ "an internet is an internetwork, i.e. "
#~ "a network composed of different "
#~ "networks. The :term:`Internet` is a very"
#~ " popular internetwork, but other internets"
#~ " have been used in the path."
#~ msgstr ""
#~ msgid ""
#~ "Internet Protocol is the generic term"
#~ " for the network layer protocol in"
#~ " the TCP/IP protocol suite. :term:`IPv4`"
#~ " is widely used today and "
#~ ":term:`IPv6` is expected to replace "
#~ ":term:`IPv4`"
#~ msgstr ""
#~ msgid ""
#~ "is the version 6 of the Internet"
#~ " Protocol, the connectionless network layer"
#~ " protocol which is intended to "
#~ "replace :term:`IPv4` . IPv6 addresses "
#~ "are encoded as a 128 bits field."
#~ msgstr ""
#~ msgid ""
#~ "Intermediate System- Intermediate System. A"
#~ " link-state intradomain routing that "
#~ "was initially defined for the ISO "
#~ "CLNP protocol but was extended to "
#~ "support IPv4 and IPv6. IS-IS is"
#~ " often used in ISP networks. It "
#~ "is defined in [ISO10589]_"
#~ msgstr ""
#~ msgid ""
#~ "The International Standardization Organisation "
#~ "is an agency of the United Nations"
#~ " that is based in Geneva and "
#~ "develop standards on various topics. "
#~ "Within ISO, country representatives vote "
#~ "to approve or reject standards. Most "
#~ "of the work on the development of"
#~ " ISO standards is done in expert "
#~ "working groups. Additional information about"
#~ " ISO may be obtained from "
#~ "http://www.iso.int"
#~ msgstr ""
#~ msgid "The International Standardization Organisation"
#~ msgstr ""
#~ msgid ""
#~ "The International Telecommunication Union is"
#~ " a United Nation's agency whose "
#~ "purpose is to develop standards for "
#~ "the telecommunication industry. It was "
#~ "initially created to standardise the "
#~ "basic telephone system but expanded "
#~ "later towards data networks. The work"
#~ " within ITU is mainly done by "
#~ "network specialists from the telecommunication"
#~ " industry (operators and vendors). See "
#~ "http://www.itu.int for more information"
#~ msgstr ""
#~ msgid ""
#~ "Internet eXchange Point. A location "
#~ "where routers belonging to different "
#~ "domains are attached to the same "
#~ "Local Area Network to establish peering"
#~ " sessions and exchange packets. See "
#~ "http://www.euro-ix.net/ or "
#~ "http://en.wikipedia.org/wiki/List_of_Internet_exchange_points_by_size"
#~ " for a partial list of IXPs."
#~ msgstr ""
#~ msgid ""
#~ "A minicomputer is a multi-user "
#~ "system that was typically used in "
#~ "the 1960s/1970s to serve departments. "
#~ "See the corresponding wikipedia article "
#~ "for additional information : "
#~ "http://en.wikipedia.org/wiki/Minicomputer"
#~ msgstr ""
#~ msgid ""
#~ "A modem (modulator-demodulator) is a "
#~ "device that encodes (resp. decodes) "
#~ "digital information by modulating (resp. "
#~ "demodulating) an analog signal. Modems "
#~ "are frequently used to transmit digital"
#~ " information over telephone lines and "
#~ "radio links. See http://en.wikipedia.org/wiki/Modem"
#~ " for a survey of various types "
#~ "of modems"
#~ msgstr ""
#~ msgid ""
#~ "Internet protocol allow to transport "
#~ "sequences of bytes. These sequences of"
#~ " bytes are sufficient to carry ASCII"
#~ " characters. The network-byte order "
#~ "refers to the Big-Endian encoding "
#~ "for 16 and 32 bits integer. See"
#~ " http://en.wikipedia.org/wiki/Endianness"
#~ msgstr ""
#~ msgid ""
#~ "Regional Internet Registry. An organisation"
#~ " that manages IP addresses and AS "
#~ "numbers on behalf of :term:`IANA`."
#~ msgstr ""
#~ msgid ""
#~ "The round-trip-time (RTT) is the"
#~ " delay between the transmission of a"
#~ " segment and the reception of the "
#~ "corresponding acknowledgement in a transport"
#~ " protocol."
#~ msgstr ""
#~ msgid ""
#~ "A networked application that allows to"
#~ " remotely access a computer's Graphical "
#~ "User Interface. See "
#~ "http://en.wikipedia.org/wiki/Virtual_Network_Computing"
#~ msgstr ""
#~ msgid ""
#~ "The world wide web consortium was "
#~ "created to standardise the protocols and"
#~ " mechanisms used in the global www."
#~ " It is thus focused on a subset"
#~ " of the application layer. See "
#~ "http://www.w3c.org"
#~ msgstr ""
#~ msgid ""
#~ "A wide area networking technology using"
#~ " virtual circuits that was deployed "
#~ "by telecom operators."
#~ msgstr ""
#~ msgid ""
#~ "The eXtensible Markup Language (XML) is"
#~ " a flexible text format derived from"
#~ " SGML. It was originally designed for"
#~ " the electronic publishing industry but "
#~ "is now used by a wide variety "
#~ "of applications that need to exchange"
#~ " structured data. The XML specifications"
#~ " are maintained by `several working "
#~ "groups `_ of the "
#~ ":term:`W3C`"
#~ msgstr ""
PKcƤ PK H}X / cnp3-ebook/index/locale/fr/LC_MESSAGES/index.po# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2019 Olivier Bonaventure
# This file is distributed under the same license as the Computer networking
# : Principles, Protocols and Practice package.
# FIRST AUTHOR , 2019.
#
msgid ""
msgstr ""
"Project-Id-Version: Computer networking : Principles, Protocols and Practice "
"3\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2019-10-09 12:39+0000\n"
"PO-Revision-Date: 2019-10-14 09:05+0000\n"
"Last-Translator: Anthony Gego \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n > 1;\n"
"X-Generator: Weblate 3.8\n"
"Generated-By: Babel 2.7.0\n"
#: ../../index.rst:7
msgid "Computer Networking : Principles, Protocols and Practice, third edition"
msgstr ""
"Réseaux informatiques: Principes, Protocoles et Pratique, troisième édition"
#: ../../index.rst:17
msgid ""
"This is an unpolished draft of the third edition of this ebook. If you "
"find any error or have suggestions to improve the text, please create an "
"issue via https://github.com/CNP3/ebook/issues/new"
msgstr ""
"Ceci est un brouillon non peaufiné de la troisième édition de cet ebook. Si "
"vous avez trouvé une erreur o avez une suggestion pour améliorer le texte, "
"merci de créer un *issue* via https://github.com/CNP3/ebook/issues/new"
#: ../../index.rst:19
msgid ""
"The development of this edition of the textbook is carried out on "
"`https://github.com/CNP3/ebook `_"
msgstr ""
"Le développement de cette édition du livre a lieu ici: `https://github.com/"
"CNP3/ebook `_"
#: ../../index.rst:21
msgid ""
"The source code of the entire textbook is written in `reStructuredText "
"`_ and uses several `sphinx "
"`_ features. You can browse these sources from "
"`github `_"
msgstr ""
"Le code source du livre entier est écrit en `reStructuredText "
"`_ et repose sur plusieurs "
"fonctionnalités de `sphinx