<?xml version="1.0" encoding="UTF-8"?>
<xliff xmlns="urn:oasis:names:tc:xliff:document:1.1" version="1.1">
  <file original="NoName" source-language="en" datatype="plaintext" target-language="en">
    <body>
      <trans-unit xml:space="preserve" approved="no" id="edb36438cc06fead" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">7</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5ee108cebb050297" weblate-flags="read-only">
        <source>Applications</source>
        <target state="translated">Applications</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">10</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9ea017ea75612a25" weblate-flags="read-only">
        <source>There are two important models used to organize a networked application. The first and oldest model is the client-server model. In this model, a server provides services to clients that exchange information with it. This model is highly asymmetrical: clients send requests and servers perform actions and return responses. It is illustrated in the figure below.</source>
        <target state="translated">There are two important models used to organize a networked application. The first and oldest model is the client-server model. In this model, a server provides services to clients that exchange information with it. This model is highly asymmetrical: clients send requests and servers perform actions and return responses. It is illustrated in the figure below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">12</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2ffd5d2bc750f7a5" weblate-flags="read-only">
        <source>The client-server model was the first model to be used to develop networked applications. This model comes naturally from the mainframes and minicomputers that were the only networked computers used until the 1980s. A minicomputer_ is a multi-user system that is used by tens or more users at the same time. Each user interacts with the minicomputer by using a terminal. Such a terminal was mainly a screen, a keyboard and a cable directly connected to the minicomputer.</source>
        <target state="translated">The client-server model was the first model to be used to develop networked applications. This model comes naturally from the mainframes and minicomputers that were the only networked computers used until the 1980s. A minicomputer_ is a multi-user system that is used by tens or more users at the same time. Each user interacts with the minicomputer by using a terminal. Such a terminal was mainly a screen, a keyboard and a cable directly connected to the minicomputer.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">36</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f4a63a537f48e572" weblate-flags="read-only">
        <source>There are various types of servers as well as various types of clients. A web server provides information in response to the query sent by its clients. A print server prints documents sent as queries by the client. An email server forwards towards their recipient the email messages sent as queries while a music server delivers the music requested by the client. From the viewpoint of the application developer, the client and the server applications directly exchange messages (the horizontal arrows labeled `Queries` and `Responses` in the above figure), but in practice these messages are exchanged thanks to the underlying layers (the vertical arrows in the above figure). In this chapter, we focus on these horizontal exchanges of messages.</source>
        <target state="translated">There are various types of servers as well as various types of clients. A web server provides information in response to the query sent by its clients. A print server prints documents sent as queries by the client. An email server forwards towards their recipient the email messages sent as queries while a music server delivers the music requested by the client. From the viewpoint of the application developer, the client and the server applications directly exchange messages (the horizontal arrows labeled `Queries` and `Responses` in the above figure), but in practice these messages are exchanged thanks to the underlying layers (the vertical arrows in the above figure). In this chapter, we focus on these horizontal exchanges of messages.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">38</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="70f28bb71a24752b" weblate-flags="read-only">
        <source>Networked applications do not exchange random messages. In order to ensure that the server is able to understand the queries sent by a client, and also that the client is able to understand the responses sent by the server, they must both agree on a set of syntactical and semantic rules. These rules define the format of the messages exchanged as well as their ordering. This set of rules is called an application-level `protocol`.</source>
        <target state="translated">Networked applications do not exchange random messages. In order to ensure that the server is able to understand the queries sent by a client, and also that the client is able to understand the responses sent by the server, they must both agree on a set of syntactical and semantic rules. These rules define the format of the messages exchanged as well as their ordering. This set of rules is called an application-level `protocol`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">40</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6f3da8a8fd262b4c" weblate-flags="read-only">
        <source>An `application-level protocol` is similar to a structured conversation between humans. Assume that Alice wants to know the current time but does not have a watch. If Bob passes close by, the following conversation could take place :</source>
        <target state="translated">An `application-level protocol` is similar to a structured conversation between humans. Assume that Alice wants to know the current time but does not have a watch. If Bob passes close by, the following conversation could take place :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">42</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4a31d37d5747d49e" weblate-flags="read-only">
        <source>Alice : `Hello`</source>
        <target state="translated">Alice : `Hello`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">44</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6cff97a96dfaf0e4" weblate-flags="read-only">
        <source>Bob : `Hello`</source>
        <target state="translated">Bob : `Hello`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">45</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8300857ea2427f4a" weblate-flags="read-only">
        <source>Alice : `What time is it ?`</source>
        <target state="translated">Alice : `What time is it ?`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">46</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c2755313e8e98695" weblate-flags="read-only">
        <source>Bob : `11:55`</source>
        <target state="translated">Bob : `11:55`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">47</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b7d7cc3d82029d42" weblate-flags="read-only">
        <source>Alice : `Thank you`</source>
        <target state="translated">Alice : `Thank you`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">48</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="dde25f8af9f722bc" weblate-flags="read-only">
        <source>Bob : `You're welcome`</source>
        <target state="translated">Bob : `You're welcome`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">49</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="dae0d739e2f6c655" weblate-flags="read-only">
        <source>Such a conversation succeeds if both Alice and Bob speak the same language. If Alice meets Tchang who only speaks Chinese, she won't be able to ask him the current time. A conversation between humans can be more complex. For example, assume that Bob is a security guard whose duty is to only allow trusted secret agents to enter a meeting room. If all agents know a secret password, the conversation between Bob and Trudy could be as follows :</source>
        <target state="translated">Such a conversation succeeds if both Alice and Bob speak the same language. If Alice meets Tchang who only speaks Chinese, she won't be able to ask him the current time. A conversation between humans can be more complex. For example, assume that Bob is a security guard whose duty is to only allow trusted secret agents to enter a meeting room. If all agents know a secret password, the conversation between Bob and Trudy could be as follows :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">56</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f480daadd4ffb716" weblate-flags="read-only">
        <source>Bob : `What is the secret password ?`</source>
        <target state="translated">Bob : `What is the secret password ?`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">58</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">64</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d8a68b4da991859c" weblate-flags="read-only">
        <source>Trudy : `1234`</source>
        <target state="translated">Trudy : `1234`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">59</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ab48e4345d34f275" weblate-flags="read-only">
        <source>Bob : `This is the correct password, you're welcome`</source>
        <target state="translated">Bob : `This is the correct password, you're welcome`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">60</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2f5076789b77ee5b" weblate-flags="read-only">
        <source>If Alice wants to enter the meeting room but does not know the password, her conversation could be as follows :</source>
        <target state="translated">If Alice wants to enter the meeting room but does not know the password, her conversation could be as follows :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">62</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="493f780eb3a6987f" weblate-flags="read-only">
        <source>Alice : `3.1415`</source>
        <target state="translated">Alice : `3.1415`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">65</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8e8b64bc09ae044d" weblate-flags="read-only">
        <source>Bob : `This is not the correct password.`</source>
        <target state="translated">Bob : `This is not the correct password.`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">66</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="40d5769badb62c5b" weblate-flags="read-only">
        <source>Human conversations can be very formal, e.g. when soldiers communicate with their hierarchy, or informal such as when friends discuss. Computers that communicate are more akin to soldiers and require well-defined rules to ensure a successful exchange of information.  There are two types of rules that define how information can be exchanged between computers :</source>
        <target state="translated">Human conversations can be very formal, e.g. when soldiers communicate with their hierarchy, or informal such as when friends discuss. Computers that communicate are more akin to soldiers and require well-defined rules to ensure a successful exchange of information.  There are two types of rules that define how information can be exchanged between computers :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">68</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0aff3eb522075c29" weblate-flags="read-only">
        <source>Syntactical rules that precisely define the format of the messages that are exchanged. As computers only process bits, the syntactical rules specify how information is encoded as bit strings.</source>
        <target state="translated">Syntactical rules that precisely define the format of the messages that are exchanged. As computers only process bits, the syntactical rules specify how information is encoded as bit strings.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">70</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ee8b22f5776fadb1" weblate-flags="read-only">
        <source>Organization of the information flow. For many applications, the flow of information must be structured and there are precedence relationships between the different types of information. In the time example above, Alice must greet Bob before asking for the current time. Alice would not ask for the current time first and greet Bob afterwards. Such precedence relationships exist in networked applications as well. For example, a server must receive a username and a valid password before accepting more complex commands from its clients.</source>
        <target state="translated">Organization of the information flow. For many applications, the flow of information must be structured and there are precedence relationships between the different types of information. In the time example above, Alice must greet Bob before asking for the current time. Alice would not ask for the current time first and greet Bob afterwards. Such precedence relationships exist in networked applications as well. For example, a server must receive a username and a valid password before accepting more complex commands from its clients.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">71</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d86cb7f312e71c53" weblate-flags="read-only">
        <source>Let us first discuss the syntactical rules. We will later explain how the information flow can be organized by analyzing real networked applications.</source>
        <target state="translated">Let us first discuss the syntactical rules. We will later explain how the information flow can be organized by analyzing real networked applications.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">73</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8d7a360b974dac06" weblate-flags="read-only">
        <source>Application-layer protocols exchange two types of messages. Some protocols such as those used to support electronic mail exchange messages expressed as strings or lines of characters. As the transport layer allows hosts to exchange bytes, they need to agree on a common representation of the characters. The first and simplest method to encode characters is to use the :term:`ASCII` table. :rfc:`20` provides the ASCII table that is used by many protocols on the Internet. For example, the table defines the following binary representations :</source>
        <target state="translated">Application-layer protocols exchange two types of messages. Some protocols such as those used to support electronic mail exchange messages expressed as strings or lines of characters. As the transport layer allows hosts to exchange bytes, they need to agree on a common representation of the characters. The first and simplest method to encode characters is to use the :term:`ASCII` table. :rfc:`20` provides the ASCII table that is used by many protocols on the Internet. For example, the table defines the following binary representations :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">75</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b39741787036e401" weblate-flags="read-only">
        <source>`A` : `1000011b`</source>
        <target state="translated">`A` : `1000011b`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">77</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e108ddb368651cf9" weblate-flags="read-only">
        <source>`0` : `0110000b`</source>
        <target state="translated">`0` : `0110000b`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">78</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7f4ddc4b99f96ea9" weblate-flags="read-only">
        <source>`z` : `1111010b`</source>
        <target state="translated">`z` : `1111010b`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">79</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="90d896c2ae06fce9" weblate-flags="read-only">
        <source>`@` : `1000000b`</source>
        <target state="translated">`@` : `1000000b`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">80</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="fa502a70340959ed" weblate-flags="read-only">
        <source>`space` : `0100000b`</source>
        <target state="translated">`space` : `0100000b`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">81</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="06e4340b15651091" weblate-flags="read-only">
        <source>In addition, the :term:`ASCII` table also defines several non-printable or control characters. These characters were designed to allow an application to control a printer or a terminal. These control characters include `CR` and `LF`, that are used to terminate a line, and the `Bell` character which causes the terminal to emit a sound.</source>
        <target state="translated">In addition, the :term:`ASCII` table also defines several non-printable or control characters. These characters were designed to allow an application to control a printer or a terminal. These control characters include `CR` and `LF`, that are used to terminate a line, and the `Bell` character which causes the terminal to emit a sound.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">83</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="eadd4e95fd3d5e1f" weblate-flags="read-only">
        <source>`carriage return` (`CR`) : `0001101b`</source>
        <target state="translated">`carriage return` (`CR`) : `0001101b`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">85</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0b177a9df6b4cc1c" weblate-flags="read-only">
        <source>`line feed` (`LF`) : `0001010b`</source>
        <target state="translated">`line feed` (`LF`) : `0001010b`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">86</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4e0b872815440175" weblate-flags="read-only">
        <source>`Bell`: `0000111b`</source>
        <target state="translated">`Bell`: `0000111b`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">87</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="235de64c29c76ed7" weblate-flags="read-only">
        <source>The :term:`ASCII` characters are encoded as a seven bits field, but transmitted as an eight-bits byte whose high order bit is usually set to `0`. Bytes are always transmitted starting from the high order or most significant bit.</source>
        <target state="translated">The :term:`ASCII` characters are encoded as a seven bits field, but transmitted as an eight-bits byte whose high order bit is usually set to `0`. Bytes are always transmitted starting from the high order or most significant bit.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">89</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4e05a92a8a3f67cb" weblate-flags="read-only">
        <source>Most applications exchange strings that are composed of fixed or variable numbers of characters. A common solution to define the character strings that are acceptable is to define them as a grammar using a Backus-Naur Form (:term:`BNF`) such as the Augmented BNF defined in :rfc:`5234`. A BNF is a set of production rules that generate all valid character strings. For example, consider a networked application that uses two commands, where the user can supply a username and a password. The BNF for this application could be defined as shown in the figure below.</source>
        <target state="translated">Most applications exchange strings that are composed of fixed or variable numbers of characters. A common solution to define the character strings that are acceptable is to define them as a grammar using a Backus-Naur Form (:term:`BNF`) such as the Augmented BNF defined in :rfc:`5234`. A BNF is a set of production rules that generate all valid character strings. For example, consider a networked application that uses two commands, where the user can supply a username and a password. The BNF for this application could be defined as shown in the figure below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">91</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d4d8f7cc86e3d656" weblate-flags="read-only">
        <source>A simple BNF specification</source>
        <target state="translated">A simple BNF specification</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">97</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b8cfaec21be68d58" weblate-flags="read-only">
        <source>The example above defines several terminals and two commands : `usercommand` and `passwordcommand`. The `ALPHA` terminal contains all letters in upper and lower case. In the `ALPHA` rule, `%x41` corresponds to ASCII character code 41 in hexadecimal, i.e. capital `A`.  The `CR` and `LF` terminals correspond to the carriage return and linefeed control characters. The `CRLF` rule concatenates these two terminals to match the standard end of line termination. The `DIGIT` terminal contains all digits. The `SP` terminal corresponds to the white space characters. The `usercommand` is composed of two strings separated by white space. In the ABNF rules that define the messages used by Internet applications, the commands are case-insensitive. The rule `"user"` corresponds to all possible cases of the letters that compose the word between brackets, e.g. `user`, `uSeR`, `USER`, `usER`, ... A `username` contains at least one letter and up to 8 letters. User names are case-sensitive as they are not defined as a string between brackets. The `password` rule indicates that a password starts with a letter and can contain any number of letters or digits. The white space and the control characters cannot appear in a `password` defined by the above rule.</source>
        <target state="translated">The example above defines several terminals and two commands : `usercommand` and `passwordcommand`. The `ALPHA` terminal contains all letters in upper and lower case. In the `ALPHA` rule, `%x41` corresponds to ASCII character code 41 in hexadecimal, i.e. capital `A`.  The `CR` and `LF` terminals correspond to the carriage return and linefeed control characters. The `CRLF` rule concatenates these two terminals to match the standard end of line termination. The `DIGIT` terminal contains all digits. The `SP` terminal corresponds to the white space characters. The `usercommand` is composed of two strings separated by white space. In the ABNF rules that define the messages used by Internet applications, the commands are case-insensitive. The rule `"user"` corresponds to all possible cases of the letters that compose the word between brackets, e.g. `user`, `uSeR`, `USER`, `usER`, ... A `username` contains at least one letter and up to 8 letters. User names are case-sensitive as they are not defined as a string between brackets. The `password` rule indicates that a password starts with a letter and can contain any number of letters or digits. The white space and the control characters cannot appear in a `password` defined by the above rule.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">99</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4a75b8c23510b4b2" weblate-flags="read-only">
        <source>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 :</source>
        <target state="translated">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 :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">101</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9fdb15f53e21d8a2" weblate-flags="read-only">
        <source>send the most significant byte followed by the least significant byte</source>
        <target state="translated">send the most significant byte followed by the least significant byte</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">103</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="aad38db36c1ba7a7" weblate-flags="read-only">
        <source>send the least significant byte followed by the most significant byte</source>
        <target state="translated">send the least significant byte followed by the most significant byte</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">104</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="538694314486c122" weblate-flags="read-only">
        <source>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 the reverse.</source>
        <target state="translated">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 the reverse.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">106</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8075c4f87ad9450b" weblate-flags="read-only">
        <source>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`.</source>
        <target state="translated">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`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">108</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="fe731472fbfd92c3" weblate-flags="read-only">
        <source>Message format</source>
        <target state="translated">Message format</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">114</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4b8bf19a4231e8b1" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">116</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="80b71d1dbba8e64b" weblate-flags="read-only">
        <source>The peer-to-peer model emerged during the last ten years as another possible architecture for networked applications. In the traditional client-server model, hosts act either as servers or as clients and a server serves a large number of clients. In the peer-to-peer model, all hosts act as both servers and clients and they play both roles. The peer-to-peer model has been used to develop various networked applications, ranging from Internet telephony to file sharing or Internet-wide filesystems. A detailed description of peer-to-peer applications may be found in [BYL2008]_. Surveys of peer-to-peer protocols and applications may be found in [AS2004]_ and [LCP2005]_.</source>
        <target state="translated">The peer-to-peer model emerged during the last ten years as another possible architecture for networked applications. In the traditional client-server model, hosts act either as servers or as clients and a server serves a large number of clients. In the peer-to-peer model, all hosts act as both servers and clients and they play both roles. The peer-to-peer model has been used to develop various networked applications, ranging from Internet telephony to file sharing or Internet-wide filesystems. A detailed description of peer-to-peer applications may be found in [BYL2008]_. Surveys of peer-to-peer protocols and applications may be found in [AS2004]_ and [LCP2005]_.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">120</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f61b55e08b59c13c" weblate-flags="read-only">
        <source>The transport layer</source>
        <target state="translated">The transport layer</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">124</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">552</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="74c022f79198c3c4" weblate-flags="read-only">
        <source>A network is always designed and built to enable applications running on hosts to exchange information. In a previous chapter, we have explained the principles of the `network layer` that enables hosts connected to different types of datalink layers to exchange information through routers. These routers act as relays in the network layer and ensure the delivery of packets between any pair of hosts attached to the network.</source>
        <target state="translated">A network is always designed and built to enable applications running on hosts to exchange information. In a previous chapter, we have explained the principles of the `network layer` that enables hosts connected to different types of datalink layers to exchange information through routers. These routers act as relays in the network layer and ensure the delivery of packets between any pair of hosts attached to the network.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">126</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a0ecf1fb376c0d2c" weblate-flags="read-only">
        <source>The network layer ensures the delivery of packets on a hop-by-hop basis through intermediate nodes. As such, it provides a service to the upper layer. In practice, this layer is usually the `transport layer` that improves the service provided by the `network layer` to make it usable by applications.</source>
        <target state="translated">The network layer ensures the delivery of packets on a hop-by-hop basis through intermediate nodes. As such, it provides a service to the upper layer. In practice, this layer is usually the `transport layer` that improves the service provided by the `network layer` to make it usable by applications.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">130</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="30e05f3af5b82c1d" weblate-flags="read-only">
        <source>Most networks use a datagram organization and provide a simple service which is called the `connectionless service`.</source>
        <target state="translated">Most networks use a datagram organization and provide a simple service which is called the `connectionless service`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">158</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="bdeaf54486877176" weblate-flags="read-only">
        <source>The figure below provides a representation of the connectionless service as a `time-sequence diagram`. The user on the left, having address `S`, issues a `Data.request` primitive containing Service Data Unit (SDU) `M` that must be delivered by the service provider to destination `D`. The dashed line between the two primitives indicates that the `Data.indication` primitive that is delivered to the user on the right corresponds to the `Data.request` primitive sent by the user on the left.</source>
        <target state="translated">The figure below provides a representation of the connectionless service as a `time-sequence diagram`. The user on the left, having address `S`, issues a `Data.request` primitive containing Service Data Unit (SDU) `M` that must be delivered by the service provider to destination `D`. The dashed line between the two primitives indicates that the `Data.indication` primitive that is delivered to the user on the right corresponds to the `Data.request` primitive sent by the user on the left.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">160</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b4945d11f7f00661" weblate-flags="read-only">
        <source>There are several possible implementations of the connectionless service. Before studying these realizations, it is useful to discuss the possible characteristics of the connectionless service. A `reliable connectionless service` is a service where the service provider guarantees that all SDUs submitted in `Data.requests` by a user will eventually be delivered to their destination. Such a service would be very useful for users, but guaranteeing perfect delivery is difficult in practice. For this reason, network layers usually support an `unreliable connectionless service`.</source>
        <target state="translated">There are several possible implementations of the connectionless service. Before studying these realizations, it is useful to discuss the possible characteristics of the connectionless service. A `reliable connectionless service` is a service where the service provider guarantees that all SDUs submitted in `Data.requests` by a user will eventually be delivered to their destination. Such a service would be very useful for users, but guaranteeing perfect delivery is difficult in practice. For this reason, network layers usually support an `unreliable connectionless service`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">179</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b8a92dd88a5f6a6e" weblate-flags="read-only">
        <source>An `unreliable connectionless` service may suffer from various types of problems compared to a `reliable connectionless service`. First of all, an `unreliable connectionless service` does not guarantee the delivery of all SDUs. This can be expressed graphically by using the time-sequence diagram below.</source>
        <target state="translated">An `unreliable connectionless` service may suffer from various types of problems compared to a `reliable connectionless service`. First of all, an `unreliable connectionless service` does not guarantee the delivery of all SDUs. This can be expressed graphically by using the time-sequence diagram below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">181</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3436b105688c7bfe" weblate-flags="read-only">
        <source>In practice, an `unreliable connectionless service` will usually deliver a large fraction of the SDUs. However, since the delivery of SDUs is not guaranteed, the user must be able to recover from the loss of any SDU.</source>
        <target state="translated">In practice, an `unreliable connectionless service` will usually deliver a large fraction of the SDUs. However, since the delivery of SDUs is not guaranteed, the user must be able to recover from the loss of any SDU.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">198</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f3d546bbaea0546b" weblate-flags="read-only">
        <source>A second imperfection that may affect an `unreliable connectionless service` is that it may duplicate SDUs. Some packets may be duplicated in a network and be delivered twice to their destination. This is illustrated by the time-sequence diagram below.</source>
        <target state="translated">A second imperfection that may affect an `unreliable connectionless service` is that it may duplicate SDUs. Some packets may be duplicated in a network and be delivered twice to their destination. This is illustrated by the time-sequence diagram below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">200</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6e8e757483519aec" weblate-flags="read-only">
        <source>Finally, some unreliable connectionless service providers may deliver to a destination a different SDU than the one that was supplied in the `Data.request`. This is illustrated in the figure below.</source>
        <target state="translated">Finally, some unreliable connectionless service providers may deliver to a destination a different SDU than the one that was supplied in the `Data.request`. This is illustrated in the figure below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">218</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e25c0a3fc022c216" weblate-flags="read-only">
        <source>As the transport layer is built on top of the network layer, it is important to know the key features of the network layer service. In this book, we only consider the `connectionless network layer service` which is the most widespread. Its main characteristics are :</source>
        <target state="translated">As the transport layer is built on top of the network layer, it is important to know the key features of the network layer service. In this book, we only consider the `connectionless network layer service` which is the most widespread. Its main characteristics are :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">234</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="38383378dc2f5d9e" weblate-flags="read-only">
        <source>the `connectionless network layer service` can only transfer SDUs of *limited size*</source>
        <target state="translated">the `connectionless network layer service` can only transfer SDUs of *limited size*</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">236</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="cbde6d4f1a8e4573" weblate-flags="read-only">
        <source>the `connectionless network layer service` may discard SDUs</source>
        <target state="translated">the `connectionless network layer service` may discard SDUs</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">237</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="582ad13d2e228060" weblate-flags="read-only">
        <source>the `connectionless network layer service` may corrupt SDUs</source>
        <target state="translated">the `connectionless network layer service` may corrupt SDUs</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">238</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b998b073660f203f" weblate-flags="read-only">
        <source>the `connectionless network layer service` may delay, reorder or even duplicate SDUs</source>
        <target state="translated">the `connectionless network layer service` may delay, reorder or even duplicate SDUs</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">239</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b5f05cb47f4fd3db" weblate-flags="read-only">
        <source>These imperfections of the `connectionless network layer service` are caused by the operations of the `network layer`. This `layer` is able to deliver packets to their intended destination, but it cannot guarantee their delivery. The main cause of packet losses and errors are the buffers used on the network nodes. If the buffers of one of these nodes becomes full, all arriving packets must be discarded. This situation frequently happens in practice [#fqueuesize]_. Transmission errors can also affect packet transmissions on links where reliable transmission techniques are not enabled or because of errors in the buffers of the network nodes.</source>
        <target state="translated">These imperfections of the `connectionless network layer service` are caused by the operations of the `network layer`. This `layer` is able to deliver packets to their intended destination, but it cannot guarantee their delivery. The main cause of packet losses and errors are the buffers used on the network nodes. If the buffers of one of these nodes becomes full, all arriving packets must be discarded. This situation frequently happens in practice [#fqueuesize]_. Transmission errors can also affect packet transmissions on links where reliable transmission techniques are not enabled or because of errors in the buffers of the network nodes.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">242</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a0045e95c12e73bd" weblate-flags="read-only">
        <source>Transport layer services</source>
        <target state="translated">Transport layer services</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">246</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9bdf85f63acf54ca" weblate-flags="read-only">
        <source>When two applications need to communicate, they need to structure their exchange of information. Structuring this exchange of information requires solving two different problems. The first problem is how to represent the information being exchanged knowing that the two applications may be running on hosts that use different operating systems, different processors and have different conventions to store information. This requires a common syntax to transfer the information between the two applications. For this chapter, let us assume that this syntax exists and that the two applications simply need to exchange bytes. We will discuss later how more complex data can be encoded as sequences of bytes to be exchanged. The second problem is how to organize the interactions between the application and the underlying network. From the application's viewpoint, the `network` will appear as the `transport layer` service. This `transport layer` can provide three types of services to the applications :</source>
        <target state="translated">When two applications need to communicate, they need to structure their exchange of information. Structuring this exchange of information requires solving two different problems. The first problem is how to represent the information being exchanged knowing that the two applications may be running on hosts that use different operating systems, different processors and have different conventions to store information. This requires a common syntax to transfer the information between the two applications. For this chapter, let us assume that this syntax exists and that the two applications simply need to exchange bytes. We will discuss later how more complex data can be encoded as sequences of bytes to be exchanged. The second problem is how to organize the interactions between the application and the underlying network. From the application's viewpoint, the `network` will appear as the `transport layer` service. This `transport layer` can provide three types of services to the applications :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">248</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c4c45192c4625b38" weblate-flags="read-only">
        <source>the `connectionless service`</source>
        <target state="translated">the `connectionless service`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">250</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d4f425ebec43eae4" weblate-flags="read-only">
        <source>the `connection oriented service`</source>
        <target state="translated">the `connection oriented service`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">251</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4e32a5cebc5c9048" weblate-flags="read-only">
        <source>the `request-response service`</source>
        <target state="translated">the `request-response service`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">252</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="344a73b73d52c775" weblate-flags="read-only">
        <source>The connectionless service</source>
        <target state="translated">The connectionless service</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">255</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7b89c395b7afd046" weblate-flags="read-only">
        <source>The `connectionless service` that we have described earlier is frequently used by users who need to exchange small SDUs. It can be easily built on top of the connectionless network layer service that we have described earlier. Users needing to either send or receive several different and potentially large SDUs, or who need structured exchanges often prefer the `connection-oriented service`.</source>
        <target state="translated">The `connectionless service` that we have described earlier is frequently used by users who need to exchange small SDUs. It can be easily built on top of the connectionless network layer service that we have described earlier. Users needing to either send or receive several different and potentially large SDUs, or who need structured exchanges often prefer the `connection-oriented service`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">257</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="13ef4cdeb557e40e" weblate-flags="read-only">
        <source>The connection-oriented service</source>
        <target state="translated">The connection-oriented service</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">260</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="adda46ec0d15a03f" weblate-flags="read-only">
        <source>An invocation of the `connection-oriented service` is divided into three phases. The first phase is the establishment of a `connection`. A `connection` is a temporary association between two users through a service provider. Several connections may exist at the same time between any pair of users. Once established, the connection is used to transfer SDUs. `Connections` usually provide one bidirectional stream supporting the exchange of SDUs between the two users that are associated through the `connection`. This stream is used to transfer data during the second phase of the connection called the `data transfer` phase. The third phase is the termination of the connection. Once the users have finished exchanging SDUs, they request the service provider to terminate the connection. As we will see later, there are also some cases where the service provider may need to terminate a connection itself.</source>
        <target state="translated">An invocation of the `connection-oriented service` is divided into three phases. The first phase is the establishment of a `connection`. A `connection` is a temporary association between two users through a service provider. Several connections may exist at the same time between any pair of users. Once established, the connection is used to transfer SDUs. `Connections` usually provide one bidirectional stream supporting the exchange of SDUs between the two users that are associated through the `connection`. This stream is used to transfer data during the second phase of the connection called the `data transfer` phase. The third phase is the termination of the connection. Once the users have finished exchanging SDUs, they request the service provider to terminate the connection. As we will see later, there are also some cases where the service provider may need to terminate a connection itself.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">264</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="afaa4d332cae5b3e" weblate-flags="read-only">
        <source>The establishment of a connection can be modeled by using four primitives : `Connect.request`, `Connect.indication`, `Connect.response` and `Connect.confirm`. The `Connect.request` primitive is used to request the establishment of a connection. The main parameter of this primitive is the `address` of the destination user. The service provider delivers a `Connect.indication` primitive to inform the destination user of the connection attempt. If it accepts to establish a connection, it responds with a `Connect.response` primitive. At this point, the connection is considered to be established and the destination user can start sending SDUs over the connection. The service provider processes the `Connect.response` and will deliver a `Connect.confirm` to the user who initiated the connection. The delivery of this primitive terminates the connection establishment phase. At this point, the connection is considered to be open and both users can send SDUs. A successful connection establishment is illustrated below.</source>
        <target state="translated">The establishment of a connection can be modeled by using four primitives : `Connect.request`, `Connect.indication`, `Connect.response` and `Connect.confirm`. The `Connect.request` primitive is used to request the establishment of a connection. The main parameter of this primitive is the `address` of the destination user. The service provider delivers a `Connect.indication` primitive to inform the destination user of the connection attempt. If it accepts to establish a connection, it responds with a `Connect.response` primitive. At this point, the connection is considered to be established and the destination user can start sending SDUs over the connection. The service provider processes the `Connect.response` and will deliver a `Connect.confirm` to the user who initiated the connection. The delivery of this primitive terminates the connection establishment phase. At this point, the connection is considered to be open and both users can send SDUs. A successful connection establishment is illustrated below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">267</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e6d9256e2f93fe67" weblate-flags="read-only">
        <source>The example above shows a successful connection establishment. However, in practice not all connections are successfully established. One reason is that the destination user may not agree, for policy or performance reasons, to establish a connection with the initiating user at this time. In this case, the destination user responds to the `Connect.indication` primitive by a `Disconnect.request` primitive that contains a parameter to indicate why the connection has been refused. The service provider will then deliver a `Disconnect.indication` primitive to inform the initiating user.</source>
        <target state="translated">The example above shows a successful connection establishment. However, in practice not all connections are successfully established. One reason is that the destination user may not agree, for policy or performance reasons, to establish a connection with the initiating user at this time. In this case, the destination user responds to the `Connect.indication` primitive by a `Disconnect.request` primitive that contains a parameter to indicate why the connection has been refused. The service provider will then deliver a `Disconnect.indication` primitive to inform the initiating user.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">288</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a20b5166365ca782" weblate-flags="read-only">
        <source>A second reason is when the service provider is unable to reach the destination user. This might happen because the destination user is not currently attached to the network or due to congestion. In these cases, the service provider responds to the `Connect.request` with a `Disconnect.indication` primitive whose `reason` parameter contains additional information about the failure of the connection.</source>
        <target state="translated">A second reason is when the service provider is unable to reach the destination user. This might happen because the destination user is not currently attached to the network or due to congestion. In these cases, the service provider responds to the `Connect.request` with a `Disconnect.indication` primitive whose `reason` parameter contains additional information about the failure of the connection.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">309</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="13ce66241ff003f3" weblate-flags="read-only">
        <source>Once the connection has been established, the service provider supplies two data streams to the communicating users. The first data stream can be used by the initiating user to send SDUs. The second data stream allows the responding user to send SDUs to the initiating user. The data streams can be organized in different ways. A first organization is the `message-mode` transfer. With the `message-mode` transfer, the service provider guarantees that one and only one `Data.indication` will be delivered to the endpoint of the data stream for each `Data.request` primitive issued by the other endpoint. The `message-mode` transfer is illustrated in the figure below. The main advantage of the `message-transfer` mode is that the recipient receives exactly the SDUs that were sent by the other user. If each SDU contains a command, the receiving user can process each command as soon as it receives a SDU.</source>
        <target state="translated">Once the connection has been established, the service provider supplies two data streams to the communicating users. The first data stream can be used by the initiating user to send SDUs. The second data stream allows the responding user to send SDUs to the initiating user. The data streams can be organized in different ways. A first organization is the `message-mode` transfer. With the `message-mode` transfer, the service provider guarantees that one and only one `Data.indication` will be delivered to the endpoint of the data stream for each `Data.request` primitive issued by the other endpoint. The `message-mode` transfer is illustrated in the figure below. The main advantage of the `message-transfer` mode is that the recipient receives exactly the SDUs that were sent by the other user. If each SDU contains a command, the receiving user can process each command as soon as it receives a SDU.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">329</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="87d2e1134a040f00" weblate-flags="read-only">
        <source>Unfortunately, the `message-mode` transfer is not widely used on the Internet. On the Internet, the most popular connection-oriented service transfers SDUs in `stream-mode`. With the `stream-mode`, the service provider supplies a byte stream that links the two communicating users. The sending user sends bytes by using `Data.request` primitives that contain sequences of bytes as SDUs. The service provider delivers SDUs containing consecutive bytes to the receiving user by using `Data.indication` primitives. The service provider ensures that all the bytes sent at one end of the stream are delivered correctly in the same order at the other endpoint. However, the service provider does not attempt to preserve the boundaries of the SDUs. There is no relation enforced by the service provider between the number of `Data.request` and the number of `Data.indication` primitives. The `stream-mode` is illustrated in the figure below. In practice, a consequence of the utilization of the `stream-mode` is that if the users want to exchange structured SDUs, they will need to provide the mechanisms that allow the receiving user to separate successive SDUs in the byte stream that it receives. Application layer protocols often use specific delimiters such as the end of line character to delineate SDUs in a bytestream.</source>
        <target state="translated">Unfortunately, the `message-mode` transfer is not widely used on the Internet. On the Internet, the most popular connection-oriented service transfers SDUs in `stream-mode`. With the `stream-mode`, the service provider supplies a byte stream that links the two communicating users. The sending user sends bytes by using `Data.request` primitives that contain sequences of bytes as SDUs. The service provider delivers SDUs containing consecutive bytes to the receiving user by using `Data.indication` primitives. The service provider ensures that all the bytes sent at one end of the stream are delivered correctly in the same order at the other endpoint. However, the service provider does not attempt to preserve the boundaries of the SDUs. There is no relation enforced by the service provider between the number of `Data.request` and the number of `Data.indication` primitives. The `stream-mode` is illustrated in the figure below. In practice, a consequence of the utilization of the `stream-mode` is that if the users want to exchange structured SDUs, they will need to provide the mechanisms that allow the receiving user to separate successive SDUs in the byte stream that it receives. Application layer protocols often use specific delimiters such as the end of line character to delineate SDUs in a bytestream.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">364</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9aac5e66cae3c7b2" weblate-flags="read-only">
        <source>The third phase of a connection is its release. As a connection involves three parties (two users and one service provider), any of them can request the termination of the connection. Usually, connections are terminated upon request of one user once the data transfer is finished. However, sometimes the service provider may be forced to terminate a connection. This can be due to lack of resources inside the service provider or because one of the users is not reachable anymore through the network. In this case, the service provider will issue `Disconnect.indication` primitives to both users. These primitives will contain, as parameter, some information about the reason for the termination of the connection. Unfortunately, as illustrated in the figure below, when a service provider is forced to terminate a connection it cannot guarantee that all SDUs sent by each user have been delivered to the other user. This connection release is said to be abrupt as it can cause losses of data.</source>
        <target state="translated">The third phase of a connection is its release. As a connection involves three parties (two users and one service provider), any of them can request the termination of the connection. Usually, connections are terminated upon request of one user once the data transfer is finished. However, sometimes the service provider may be forced to terminate a connection. This can be due to lack of resources inside the service provider or because one of the users is not reachable anymore through the network. In this case, the service provider will issue `Disconnect.indication` primitives to both users. These primitives will contain, as parameter, some information about the reason for the termination of the connection. Unfortunately, as illustrated in the figure below, when a service provider is forced to terminate a connection it cannot guarantee that all SDUs sent by each user have been delivered to the other user. This connection release is said to be abrupt as it can cause losses of data.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">403</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6b1a6cdb9d91f025" weblate-flags="read-only">
        <source>An abrupt connection release can also be triggered by one of the users. If a user needs, for any reason, to terminate a connection quickly, it can issue a `Disconnect.request` primitive and to request an abrupt release. The service provider will process the request, stop the two data streams and deliver the `Disconnect.indication` primitive to the remote user as soon as possible. As illustrated in the figure below, this abrupt connection release may cause losses of SDUs.</source>
        <target state="translated">An abrupt connection release can also be triggered by one of the users. If a user needs, for any reason, to terminate a connection quickly, it can issue a `Disconnect.request` primitive and to request an abrupt release. The service provider will process the request, stop the two data streams and deliver the `Disconnect.indication` primitive to the remote user as soon as possible. As illustrated in the figure below, this abrupt connection release may cause losses of SDUs.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">435</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="01f5e9acfda3b1dc" weblate-flags="read-only">
        <source>To ensure a reliable delivery of the SDUs sent by each user over a connection, we need to consider the two streams that compose a connection as independent. A user should be able to release the stream that it uses to send SDUs once it has sent all the SDUs that it planned to send over this connection, but still continue to receive SDUs over the opposite stream. This `graceful` connection release is usually performed as shown in the figure below. One user issues a `Disconnect.request` primitive to its provider once it has issued all its `Data.request` primitives. The service provider will wait until all `Data.indication` primitives have been delivered to the receiving user before issuing the `Disconnnect.indication` primitive. This primitive informs the receiving user that it will no longer receive SDUs over this connection, but it is still able to issue `Data.request` primitives on the stream in the opposite direction. Once the user has issued all of its `Data.request` primitives, it issues a `Disconnnect.request` primitive to request the termination of the remaining stream. The service provider will process the request and deliver the corresponding `Disconnect.indication` to the other user once it has delivered all the pending `Data.indication` primitives. At this point, all data has been delivered, the two streams have been released successfully and the connection is completely closed.</source>
        <target state="translated">To ensure a reliable delivery of the SDUs sent by each user over a connection, we need to consider the two streams that compose a connection as independent. A user should be able to release the stream that it uses to send SDUs once it has sent all the SDUs that it planned to send over this connection, but still continue to receive SDUs over the opposite stream. This `graceful` connection release is usually performed as shown in the figure below. One user issues a `Disconnect.request` primitive to its provider once it has issued all its `Data.request` primitives. The service provider will wait until all `Data.indication` primitives have been delivered to the receiving user before issuing the `Disconnnect.indication` primitive. This primitive informs the receiving user that it will no longer receive SDUs over this connection, but it is still able to issue `Data.request` primitives on the stream in the opposite direction. Once the user has issued all of its `Data.request` primitives, it issues a `Disconnnect.request` primitive to request the termination of the remaining stream. The service provider will process the request and deliver the corresponding `Disconnect.indication` to the other user once it has delivered all the pending `Data.indication` primitives. At this point, all data has been delivered, the two streams have been released successfully and the connection is completely closed.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">473</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d30f504120e1fd17" weblate-flags="read-only">
        <source>Reliability of the connection-oriented service</source>
        <target state="translated">Reliability of the connection-oriented service</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">513</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c9c2712188e4c981" weblate-flags="read-only">
        <source>An important point to note about the connection-oriented service is its reliability. A `connection-oriented` service can only guarantee the correct delivery of all SDUs provided that the connection has been released gracefully. This implies that while the connection is active, there is no guarantee for the actual delivery of the SDUs exchanged as the connection may need to be abruptly released at any time.</source>
        <target state="translated">An important point to note about the connection-oriented service is its reliability. A `connection-oriented` service can only guarantee the correct delivery of all SDUs provided that the connection has been released gracefully. This implies that while the connection is active, there is no guarantee for the actual delivery of the SDUs exchanged as the connection may need to be abruptly released at any time.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">515</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4aa917fa943f2c2d" weblate-flags="read-only">
        <source>The request-response service</source>
        <target state="translated">The request-response service</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">520</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2698b5dcf5daab43" weblate-flags="read-only">
        <source>The `request-response service` is a compromise between the `connectionless service` and the `connection-oriented service`. Many applications need to send a small amount of data and receive a small amount of information back. This is similar to procedure calls in programming languages. A call to a procedure takes a few arguments and returns a simple answer. In a network, it is sometimes useful to execute a procedure on a different host and receive the result of the computation. Executing a procedure on another host is often called Remote Procedure Call. It is possible to use the `connectionless service` for this application. However, since this service is usually unreliable, this would force the application to deal with any type of error that could occur. Using the `connection oriented service` is another alternative. This service ensures the reliable delivery of the data, but a connection must be created before the beginning of the data transfer. This overhead can be important for applications that only exchange a small amount of data.</source>
        <target state="translated">The `request-response service` is a compromise between the `connectionless service` and the `connection-oriented service`. Many applications need to send a small amount of data and receive a small amount of information back. This is similar to procedure calls in programming languages. A call to a procedure takes a few arguments and returns a simple answer. In a network, it is sometimes useful to execute a procedure on a different host and receive the result of the computation. Executing a procedure on another host is often called Remote Procedure Call. It is possible to use the `connectionless service` for this application. However, since this service is usually unreliable, this would force the application to deal with any type of error that could occur. Using the `connection oriented service` is another alternative. This service ensures the reliable delivery of the data, but a connection must be created before the beginning of the data transfer. This overhead can be important for applications that only exchange a small amount of data.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">524</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="60458a45f20d36af" weblate-flags="read-only">
        <source>The `request-response service` allows to efficiently exchange small amounts of information in a request and associate it with the corresponding response. This service can be depicted by using the time-sequence diagram below.</source>
        <target state="translated">The `request-response service` allows to efficiently exchange small amounts of information in a request and associate it with the corresponding response. This service can be depicted by using the time-sequence diagram below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">526</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="68e4717abf6508dd" weblate-flags="read-only">
        <source>Services and layers</source>
        <target state="translated">Services and layers</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">545</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4d1b238f8a445dae" weblate-flags="read-only">
        <source>In the previous sections, we have described services that are provided by the transport layer. However, it is important to note that the notion of service is more general than in the transport layer. As explained earlier, the network layer also provides a service, which in most networks is an unreliable connectionless service. There are network layers that provide a connection-oriented service. Similarly, the datalink layer also provides services. Some datalink layers will provide a connectionless service. This will be the case in Local Area Networks for examples. Other datalink layers, e.g. in public networks, provide a connection oriented service.</source>
        <target state="translated">In the previous sections, we have described services that are provided by the transport layer. However, it is important to note that the notion of service is more general than in the transport layer. As explained earlier, the network layer also provides a service, which in most networks is an unreliable connectionless service. There are network layers that provide a connection-oriented service. Similarly, the datalink layer also provides services. Some datalink layers will provide a connectionless service. This will be the case in Local Area Networks for examples. Other datalink layers, e.g. in public networks, provide a connection oriented service.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">547</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b25d8ea927680679" weblate-flags="read-only">
        <source>The transport layer entity interacts with both a user in the application layer and the network layer. It improves the network layer service to make it usable by applications. From the application's viewpoint, the main limitations of the network layer service come from its unreliable service:</source>
        <target state="translated">The transport layer entity interacts with both a user in the application layer and the network layer. It improves the network layer service to make it usable by applications. From the application's viewpoint, the main limitations of the network layer service come from its unreliable service:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">554</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8d132fd761b5b98e" weblate-flags="read-only">
        <source>the network layer may corrupt data;</source>
        <target state="translated">the network layer may corrupt data;</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">556</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="243136cf29156b86" weblate-flags="read-only">
        <source>the network layer may loose data;</source>
        <target state="translated">the network layer may loose data;</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">557</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c2f8e70dfef02fe9" weblate-flags="read-only">
        <source>the network layer may not deliver data in-order;</source>
        <target state="translated">the network layer may not deliver data in-order;</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">558</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="eff975b781f43291" weblate-flags="read-only">
        <source>the network layer has an upper bound on maximum length of the data;</source>
        <target state="translated">the network layer has an upper bound on maximum length of the data;</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">559</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7f167d4ea20785b5" weblate-flags="read-only">
        <source>the network layer may duplicate data.</source>
        <target state="translated">the network layer may duplicate data.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">560</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="366c4d0da2fe1051" weblate-flags="read-only">
        <source>To deal with these issues, the transport layer includes several mechanisms that depend on the service that it provides. It interacts with both the applications and the underlying network layer.</source>
        <target state="translated">To deal with these issues, the transport layer includes several mechanisms that depend on the service that it provides. It interacts with both the applications and the underlying network layer.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">562</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5988144e8d0f06f2" weblate-flags="read-only">
        <source>Interactions between the transport layer, its user, and its network layer provider</source>
        <target state="translated">Interactions between the transport layer, its user, and its network layer provider</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">568</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="67e221487272356c" weblate-flags="read-only">
        <source>We have already described in the datalink layers mechanisms to deal with data losses and transmission errors. These techniques are also used in the transport layer.</source>
        <target state="translated">We have already described in the datalink layers mechanisms to deal with data losses and transmission errors. These techniques are also used in the transport layer.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">570</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f1993385e237646a" weblate-flags="read-only">
        <source>Connectionless transport</source>
        <target state="translated">Connectionless transport</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">574</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4280258ad3ee8ef2" weblate-flags="read-only">
        <source>The simplest service that can be provided in the transport layer is the connectionless transport service. Compared to the connectionless network layer service, this transport service includes two additional features :</source>
        <target state="translated">The simplest service that can be provided in the transport layer is the connectionless transport service. Compared to the connectionless network layer service, this transport service includes two additional features :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">576</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b5d0c535af954d2e" weblate-flags="read-only">
        <source>an `error detection` mechanism that allows detecting corrupted data</source>
        <target state="translated">an `error detection` mechanism that allows detecting corrupted data</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">578</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a9c36cf6a693567b" weblate-flags="read-only">
        <source>a `multiplexing technique` that enables several applications running on one host to exchange information with another host</source>
        <target state="translated">a `multiplexing technique` that enables several applications running on one host to exchange information with another host</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">579</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8a9bc6cd91911a27" weblate-flags="read-only">
        <source>To exchange data, the transport protocol encapsulates the SDU produced by its user inside a `segment`. The `segment` is the unit of transfer of information in the transport layer. Transport layer entities always exchange segments. When a transport layer entity creates a segment, this segment is encapsulated by the network layer into a packet which contains the segment as its payload and a network header. The packet is then encapsulated in a frame to be transmitted in the datalink layer.</source>
        <target state="translated">To exchange data, the transport protocol encapsulates the SDU produced by its user inside a `segment`. The `segment` is the unit of transfer of information in the transport layer. Transport layer entities always exchange segments. When a transport layer entity creates a segment, this segment is encapsulated by the network layer into a packet which contains the segment as its payload and a network header. The packet is then encapsulated in a frame to be transmitted in the datalink layer.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">583</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2b7e95e22760165c" weblate-flags="read-only">
        <source>A `segment` also contains control information, usually stored inside a `header` and the payload that comes from the application. To detect transmission errors, transport protocols rely on checksums or CRCs like the datalink layer protocols.</source>
        <target state="translated">A `segment` also contains control information, usually stored inside a `header` and the payload that comes from the application. To detect transmission errors, transport protocols rely on checksums or CRCs like the datalink layer protocols.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">611</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6206feb10164006d" weblate-flags="read-only">
        <source>Compared to the connectionless network layer service, the transport layer service allows several applications running on a host to exchange SDUs with several other applications running on remote hosts. Let us consider two hosts, e.g. a client and a server. The network layer service allows the client to send information to the server, but if an application running on the client wants to contact a particular application running on the server, then an additional addressing mechanism is required. The network layer address identifies a host, but it is not sufficient to differentiate the applications running on a host. `Port numbers` provides this additional addressing. When a server application is launched on a host, it registers a `port number`. This `port number` will be used by the clients to contact the server process.</source>
        <target state="translated">Compared to the connectionless network layer service, the transport layer service allows several applications running on a host to exchange SDUs with several other applications running on remote hosts. Let us consider two hosts, e.g. a client and a server. The network layer service allows the client to send information to the server, but if an application running on the client wants to contact a particular application running on the server, then an additional addressing mechanism is required. The network layer address identifies a host, but it is not sufficient to differentiate the applications running on a host. `Port numbers` provides this additional addressing. When a server application is launched on a host, it registers a `port number`. This `port number` will be used by the clients to contact the server process.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">613</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4c58a19f9732fc7b" weblate-flags="read-only">
        <source>The figure below shows a typical usage of port numbers. The client process uses port number `1234` while the server process uses port number `5678`. When the client sends a request, it is identified as originating from port number `1234` on the client host and destined to port number `5678` on the server host. When the server process replies to this request, the server's transport layer returns the reply as originating from port  `5678` on the server host and destined to port `1234` on the client host.</source>
        <target state="translated">The figure below shows a typical usage of port numbers. The client process uses port number `1234` while the server process uses port number `5678`. When the client sends a request, it is identified as originating from port number `1234` on the client host and destined to port number `5678` on the server host. When the server process replies to this request, the server's transport layer returns the reply as originating from port  `5678` on the server host and destined to port `1234` on the client host.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">615</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8bb8b563e08faa1c" weblate-flags="read-only">
        <source>To support the connection-oriented service, the transport layer needs to include several mechanisms to enrich the connectionless network-layer service. We discuss these mechanisms in the following sections.</source>
        <target state="translated">To support the connection-oriented service, the transport layer needs to include several mechanisms to enrich the connectionless network-layer service. We discuss these mechanisms in the following sections.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">634</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2e9e5804b8bc092c" weblate-flags="read-only">
        <source>Connection establishment</source>
        <target state="translated">Connection establishment</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">638</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f47f2d5033524979" weblate-flags="read-only">
        <source>Like the connectionless service, the connection-oriented service allows several applications running on a given host to exchange data with other hosts. The port numbers described above for the connectionless service are also used by the connection-oriented service to multiplex several applications. Similarly, connection-oriented protocols use checksums/CRCs to detect transmission errors and discard segments containing an invalid checksum/CRC.</source>
        <target state="translated">Like the connectionless service, the connection-oriented service allows several applications running on a given host to exchange data with other hosts. The port numbers described above for the connectionless service are also used by the connection-oriented service to multiplex several applications. Similarly, connection-oriented protocols use checksums/CRCs to detect transmission errors and discard segments containing an invalid checksum/CRC.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">640</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1f509ee4130e196e" weblate-flags="read-only">
        <source>An important difference between the connectionless service and the connection-oriented one is that the transport entities in the latter maintain some state during lifetime of the connection. This state is created when a connection is established and is removed when it is released.</source>
        <target state="translated">An important difference between the connectionless service and the connection-oriented one is that the transport entities in the latter maintain some state during lifetime of the connection. This state is created when a connection is established and is removed when it is released.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">642</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7454627bd3985614" weblate-flags="read-only">
        <source>The simplest approach to establish a transport connection would be to define two special control segments : `CR` (Connection Request) and `CA` (Connection Acknowledgment). The `CR` segment is sent by the transport entity that wishes to initiate a connection. If the remote entity wishes to accept the connection, it replies by sending a `CA` segment. The `CR` and `CA` segments contain `port numbers` that allow identifying the communicating applications. The transport connection is considered to be established once the `CA` segment has been received. At that point, data segments can be sent in both directions.</source>
        <target state="translated">The simplest approach to establish a transport connection would be to define two special control segments : `CR` (Connection Request) and `CA` (Connection Acknowledgment). The `CR` segment is sent by the transport entity that wishes to initiate a connection. If the remote entity wishes to accept the connection, it replies by sending a `CA` segment. The `CR` and `CA` segments contain `port numbers` that allow identifying the communicating applications. The transport connection is considered to be established once the `CA` segment has been received. At that point, data segments can be sent in both directions.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">644</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="74ea6a04dfceb095" weblate-flags="read-only">
        <source>Unfortunately, this scheme is not sufficient given the unreliable network layer. Since the network layer is imperfect, the `CR` or `CA` segments can be lost, delayed, or suffer from transmission errors. To deal with these problems, the control segments must be protected by a CRC or a checksum to detect transmission errors. Furthermore, since the `CA` segment acknowledges the reception of the `CR` segment, the `CR` segment can be protected using a retransmission timer.</source>
        <target state="translated">Unfortunately, this scheme is not sufficient given the unreliable network layer. Since the network layer is imperfect, the `CR` or `CA` segments can be lost, delayed, or suffer from transmission errors. To deal with these problems, the control segments must be protected by a CRC or a checksum to detect transmission errors. Furthermore, since the `CA` segment acknowledges the reception of the `CR` segment, the `CR` segment can be protected using a retransmission timer.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">669</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9561e1687c6b144c" weblate-flags="read-only">
        <source>Unfortunately, this scheme is not sufficient to ensure the reliability of the transport service. Consider for example a short-lived transport connection where a single, but important transfer (e.g. money transfer from a bank account) is sent. Such a short-lived connection starts with a `CR` segment acknowledged by a `CA` segment, then the data segment is sent, acknowledged and the connection terminates. Unfortunately, as the network layer service is unreliable, delays combined to retransmissions may lead to the situation depicted in the figure below, where a delayed `CR` and data segments from a former connection are accepted by the receiving entity as valid segments, and the corresponding data is delivered to the user. Duplicating SDUs is not acceptable, and the transport protocol must solve this problem.</source>
        <target state="translated">Unfortunately, this scheme is not sufficient to ensure the reliability of the transport service. Consider for example a short-lived transport connection where a single, but important transfer (e.g. money transfer from a bank account) is sent. Such a short-lived connection starts with a `CR` segment acknowledged by a `CA` segment, then the data segment is sent, acknowledged and the connection terminates. Unfortunately, as the network layer service is unreliable, delays combined to retransmissions may lead to the situation depicted in the figure below, where a delayed `CR` and data segments from a former connection are accepted by the receiving entity as valid segments, and the corresponding data is delivered to the user. Duplicating SDUs is not acceptable, and the transport protocol must solve this problem.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">671</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="cb78b752b2666027" weblate-flags="read-only">
        <source>To avoid these duplicates, transport protocols require the network layer to bound the `Maximum Segment Lifetime (MSL)`. The organization of the network must guarantee that no segment remains in the network for longer than `MSL` seconds. For example, on today's Internet, `MSL` is expected to be 2 minutes. To avoid duplicate transport connections, transport protocol entities must be able to safely distinguish between a duplicate `CR` segment and a new `CR` segment, without forcing each transport entity to remember all the transport connections that it has established in the past.</source>
        <target state="translated">To avoid these duplicates, transport protocols require the network layer to bound the `Maximum Segment Lifetime (MSL)`. The organization of the network must guarantee that no segment remains in the network for longer than `MSL` seconds. For example, on today's Internet, `MSL` is expected to be 2 minutes. To avoid duplicate transport connections, transport protocol entities must be able to safely distinguish between a duplicate `CR` segment and a new `CR` segment, without forcing each transport entity to remember all the transport connections that it has established in the past.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">711</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2f34b033bbe8ebb1" weblate-flags="read-only">
        <source>A classical solution to avoid remembering the previous transport connections to detect duplicates is to use a clock inside each transport entity. This `transport clock` has the following characteristics :</source>
        <target state="translated">A classical solution to avoid remembering the previous transport connections to detect duplicates is to use a clock inside each transport entity. This `transport clock` has the following characteristics :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">713</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3ed8f2c68496b6e5" weblate-flags="read-only">
        <source>the `transport clock` is implemented as a `k` bits counter and its clock cycle is such that :math:`2^k \times cycle &gt;&gt; MSL`. Furthermore, the `transport clock` counter is incremented every clock cycle and after each connection establishment. This clock is illustrated in the figure below.</source>
        <target state="translated">the `transport clock` is implemented as a `k` bits counter and its clock cycle is such that :math:`2^k \times cycle &gt;&gt; MSL`. Furthermore, the `transport clock` counter is incremented every clock cycle and after each connection establishment. This clock is illustrated in the figure below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">715</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="176d03678748d04c" weblate-flags="read-only">
        <source>the `transport clock` must continue to be incremented even if the transport entity stops or reboots</source>
        <target state="translated">the `transport clock` must continue to be incremented even if the transport entity stops or reboots</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">716</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a0d689573fc1a4a4" weblate-flags="read-only">
        <source>Transport clock</source>
        <target state="translated">Transport clock</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">722</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4a8c92cf64abf398" weblate-flags="read-only">
        <source>It should be noted that `transport clocks` do not need and usually are not synchronized to the real-time clock. Precisely synchronizing real-time clocks is an interesting problem, but it is outside the scope of this document. See [Mills2006]_ for a detailed discussion on synchronizing the real-time clock.</source>
        <target state="translated">It should be noted that `transport clocks` do not need and usually are not synchronized to the real-time clock. Precisely synchronizing real-time clocks is an interesting problem, but it is outside the scope of this document. See [Mills2006]_ for a detailed discussion on synchronizing the real-time clock.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">725</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a6a65b761d0d2056" weblate-flags="read-only">
        <source>This `transport clock` can now be combined with an exchange of three segments, called the `three way handshake`, to detect duplicates. This `three way handshake` occurs as follows :</source>
        <target state="translated">This `transport clock` can now be combined with an exchange of three segments, called the `three way handshake`, to detect duplicates. This `three way handshake` occurs as follows :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">727</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ac8036665ac45803" weblate-flags="read-only">
        <source>The initiating transport entity sends a `CR` segment. This segment requests the establishment of a transport connection. It contains a port number (not shown in the figure) and a sequence number (`seq=x` in the figure below) whose value is extracted from the `transport clock`. The transmission of the `CR` segment is protected by a retransmission timer.</source>
        <target state="translated">The initiating transport entity sends a `CR` segment. This segment requests the establishment of a transport connection. It contains a port number (not shown in the figure) and a sequence number (`seq=x` in the figure below) whose value is extracted from the `transport clock`. The transmission of the `CR` segment is protected by a retransmission timer.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">729</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b6a5daa21a0dfe53" weblate-flags="read-only">
        <source>The remote transport entity processes the `CR` segment and creates state for the connection attempt. At this stage, the remote entity does not yet know whether this is a new connection attempt or a duplicate segment. It returns a `CA` segment that contains an acknowledgment number to confirm the reception of the `CR` segment (`ack=x` in the figure below) and a sequence number (`seq=y` in the figure below) whose value is extracted from its transport clock. At this stage, the connection is not yet established.</source>
        <target state="translated">The remote transport entity processes the `CR` segment and creates state for the connection attempt. At this stage, the remote entity does not yet know whether this is a new connection attempt or a duplicate segment. It returns a `CA` segment that contains an acknowledgment number to confirm the reception of the `CR` segment (`ack=x` in the figure below) and a sequence number (`seq=y` in the figure below) whose value is extracted from its transport clock. At this stage, the connection is not yet established.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">731</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="61650340142dbccb" weblate-flags="read-only">
        <source>The initiating entity receives the `CA` segment. The acknowledgment number of this segment confirms that the remote entity has correctly received the `CR` segment. The transport connection is considered to be established by the initiating entity and the numbering of the data segments starts at sequence number `x`. Before sending data segments, the initiating entity must acknowledge the received `CA` segments by sending another `CA` segment.</source>
        <target state="translated">The initiating entity receives the `CA` segment. The acknowledgment number of this segment confirms that the remote entity has correctly received the `CR` segment. The transport connection is considered to be established by the initiating entity and the numbering of the data segments starts at sequence number `x`. Before sending data segments, the initiating entity must acknowledge the received `CA` segments by sending another `CA` segment.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">733</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ff9fb5bfcaf05d26" weblate-flags="read-only">
        <source>The remote entity considers the transport connection to be established after having received the segment that acknowledges its `CA` segment. The numbering of the data segments sent by the remote entity starts at sequence number `y`.</source>
        <target state="translated">The remote entity considers the transport connection to be established after having received the segment that acknowledges its `CA` segment. The numbering of the data segments sent by the remote entity starts at sequence number `y`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">735</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="54a68525e1f7de7f" weblate-flags="read-only">
        <source>The three way handshake is illustrated in the figure below.</source>
        <target state="translated">The three way handshake is illustrated in the figure below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">737</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a02196afd924d26a" weblate-flags="read-only">
        <source>Three-way handshake</source>
        <target state="translated">Three-way handshake</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">743</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5d0eb815f1669059" weblate-flags="read-only">
        <source>Thanks to the three way handshake, transport entities avoid duplicate transport connections. This is illustrated by considering the three scenarios below.</source>
        <target state="translated">Thanks to the three way handshake, transport entities avoid duplicate transport connections. This is illustrated by considering the three scenarios below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">745</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8b41a61dd2115ac8" weblate-flags="read-only">
        <source>The first scenario is when the remote entity receives an old `CR` segment. It considers this `CR` segment as a connection establishment attempt and replies by sending a `CA` segment. However, the initiating host cannot match the received `CA` segment with a previous connection attempt. It sends a control segment (`REJECT` in the figure below) to cancel the spurious connection attempt. The remote entity cancels the connection attempt upon reception of this control segment.</source>
        <target state="translated">The first scenario is when the remote entity receives an old `CR` segment. It considers this `CR` segment as a connection establishment attempt and replies by sending a `CA` segment. However, the initiating host cannot match the received `CA` segment with a previous connection attempt. It sends a control segment (`REJECT` in the figure below) to cancel the spurious connection attempt. The remote entity cancels the connection attempt upon reception of this control segment.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">747</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="431c303c934c8c9c" weblate-flags="read-only">
        <source>Three-way handshake : recovery from a duplicate `CR`</source>
        <target state="translated">Three-way handshake : recovery from a duplicate `CR`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">753</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b2f2b08276e98930" weblate-flags="read-only">
        <source>A second scenario is when the initiating entity sends a `CR` segment that does not reach the remote entity and receives a duplicate `CA` segment from a previous connection attempt. This duplicate `CA` segment cannot contain a valid acknowledgment for the `CR` segment as the sequence number of the `CR` segment was extracted from the transport clock of the initiating entity. The `CA` segment is thus rejected and the `CR` segment is retransmitted upon expiration of the retransmission timer.</source>
        <target state="translated">A second scenario is when the initiating entity sends a `CR` segment that does not reach the remote entity and receives a duplicate `CA` segment from a previous connection attempt. This duplicate `CA` segment cannot contain a valid acknowledgment for the `CR` segment as the sequence number of the `CR` segment was extracted from the transport clock of the initiating entity. The `CA` segment is thus rejected and the `CR` segment is retransmitted upon expiration of the retransmission timer.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">755</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3587080ecc1e9c20" weblate-flags="read-only">
        <source>Three-way handshake : recovery from a duplicate `CA`</source>
        <target state="translated">Three-way handshake : recovery from a duplicate `CA`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">762</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2b3dfd1ced10a273" weblate-flags="read-only">
        <source>The last scenario is less likely, but it is important to consider it as well. The remote entity receives an old `CR` segment. It notes the connection attempt and acknowledges it by sending a `CA` segment. The initiating entity does not have a matching connection attempt and replies by sending a `REJECT`. Unfortunately, this segment never reaches the remote entity. Instead, the remote entity receives a retransmission of an older `CA` segment that contains the same sequence number as the first `CR` segment. This `CA` segment cannot be accepted by the remote entity as a confirmation of the transport connection as its acknowledgment number cannot have the same value as the sequence number of the first `CA` segment.</source>
        <target state="translated">The last scenario is less likely, but it is important to consider it as well. The remote entity receives an old `CR` segment. It notes the connection attempt and acknowledges it by sending a `CA` segment. The initiating entity does not have a matching connection attempt and replies by sending a `REJECT`. Unfortunately, this segment never reaches the remote entity. Instead, the remote entity receives a retransmission of an older `CA` segment that contains the same sequence number as the first `CR` segment. This `CA` segment cannot be accepted by the remote entity as a confirmation of the transport connection as its acknowledgment number cannot have the same value as the sequence number of the first `CA` segment.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">764</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c45f0a9d3b21737f" weblate-flags="read-only">
        <source>Three-way handshake : recovery from duplicates `CR` and `CA`</source>
        <target state="translated">Three-way handshake : recovery from duplicates `CR` and `CA`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">770</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="15cd77899370a833" weblate-flags="read-only">
        <source>Data transfer</source>
        <target state="translated">Data transfer</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">774</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d6a00e1524c5921d" weblate-flags="read-only">
        <source>Now that the transport connection has been established, it can be used to transfer data. To ensure a reliable delivery of the data, the transport protocol will include sliding windows, retransmission timers and `go-back-n` or `selective repeat`. However, we cannot simply reuse the techniques from the datalink because a transport protocol needs to deal with more types of errors than a reliable protocol in datalink layer. The first difference between the two layers is the transport layer must face with more variable delays. In the datalink layer, when two hosts are connected by a link, the transmission delay or the round-trip-time over the link is almost fixed. In a network that can span the globe, the delays and the round-trip-times can vary significantly on a per packet basis. This variability can be caused by two factors. First, packets sent through a network do not necessarily follow the same path to reach their destination. Second, some packets may be queued in the buffers of routers when the load is high and these queuing delays can lead to increased end-to-end delays. A second difference between the datalink layer and the transport layer is that a network does not always deliver packets in sequence. This implies that packets may be reordered by the network. Furthermore, the network may sometimes duplicate packets. The last issue that needs to be dealt with in the transport layer is the transmission of large SDUs. In the datalink layer, reliable protocols transmit small frames. Applications could generate SDUs that are much larger than the maximum size of a packet in the network layer. The transport layer needs to include mechanisms to fragment and reassemble these large SDUs.</source>
        <target state="translated">Now that the transport connection has been established, it can be used to transfer data. To ensure a reliable delivery of the data, the transport protocol will include sliding windows, retransmission timers and `go-back-n` or `selective repeat`. However, we cannot simply reuse the techniques from the datalink because a transport protocol needs to deal with more types of errors than a reliable protocol in datalink layer. The first difference between the two layers is the transport layer must face with more variable delays. In the datalink layer, when two hosts are connected by a link, the transmission delay or the round-trip-time over the link is almost fixed. In a network that can span the globe, the delays and the round-trip-times can vary significantly on a per packet basis. This variability can be caused by two factors. First, packets sent through a network do not necessarily follow the same path to reach their destination. Second, some packets may be queued in the buffers of routers when the load is high and these queuing delays can lead to increased end-to-end delays. A second difference between the datalink layer and the transport layer is that a network does not always deliver packets in sequence. This implies that packets may be reordered by the network. Furthermore, the network may sometimes duplicate packets. The last issue that needs to be dealt with in the transport layer is the transmission of large SDUs. In the datalink layer, reliable protocols transmit small frames. Applications could generate SDUs that are much larger than the maximum size of a packet in the network layer. The transport layer needs to include mechanisms to fragment and reassemble these large SDUs.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">776</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3fb600b4b11ba0e2" weblate-flags="read-only">
        <source>To deal with all these characteristics of the network layer, we need to adapt the techniques that we have introduced in the datalink layer.</source>
        <target state="translated">To deal with all these characteristics of the network layer, we need to adapt the techniques that we have introduced in the datalink layer.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">778</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6f425fe4cb167a0d" weblate-flags="read-only">
        <source>The first point which is common between the two layers is that both use CRCs or checksums to detect transmission errors. Each segment contains a CRC/checksum which is computed over the entire segment (header and payload) by the sender and inserted in the header. The receiver recomputes the CRC/checksum for each received segment and discards all segments with an invalid CRC.</source>
        <target state="translated">The first point which is common between the two layers is that both use CRCs or checksums to detect transmission errors. Each segment contains a CRC/checksum which is computed over the entire segment (header and payload) by the sender and inserted in the header. The receiver recomputes the CRC/checksum for each received segment and discards all segments with an invalid CRC.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">780</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="dace73f3d3e64c5d" weblate-flags="read-only">
        <source>Reliable transport protocols also use sequence numbers and acknowledgment numbers. While reliable protocols in the datalink layer use one sequence number per frame, reliable transport protocols consider all the data transmitted as a stream of bytes. In these protocols, the sequence number placed in the segment header corresponds to the position of the first byte of the payload in the bytestream. This sequence number allows detecting losses but also enables the receiver to reorder the out-of-sequence segments. This is illustrated in the figure below.</source>
        <target state="translated">Reliable transport protocols also use sequence numbers and acknowledgment numbers. While reliable protocols in the datalink layer use one sequence number per frame, reliable transport protocols consider all the data transmitted as a stream of bytes. In these protocols, the sequence number placed in the segment header corresponds to the position of the first byte of the payload in the bytestream. This sequence number allows detecting losses but also enables the receiver to reorder the out-of-sequence segments. This is illustrated in the figure below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">782</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="57e87dbaab8e0f62" weblate-flags="read-only">
        <source>Using sequence numbers to count bytes has also one advantage when the transport layer needs to fragment SDUs in several segments. The figure below shows the fragmentation of a large SDU in two segments. Upon reception of the segments, the receiver will use the sequence numbers to correctly reorder the data.</source>
        <target state="translated">Using sequence numbers to count bytes has also one advantage when the transport layer needs to fragment SDUs in several segments. The figure below shows the fragmentation of a large SDU in two segments. Upon reception of the segments, the receiver will use the sequence numbers to correctly reorder the data.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">801</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="10262d6fcf8691fd" weblate-flags="read-only">
        <source>Compared to reliable protocols in the datalink layer, reliable transport protocols encode their sequence numbers using more bits. 32 bits and 64 bits sequence numbers are frequent in the transport layer while some datalink layer protocols encode their sequence numbers in an 8 bits field. This large sequence number space is motivated by two reasons. First, since the sequence number is incremented for each transmitted byte, a single segment may consume one or several thousands of sequence numbers. Second, a reliable transport protocol must be able to detect delayed segments. This can only be done if the number of bytes transmitted during the MSL period is smaller than the sequence number space. Otherwise, there is a risk of accepting duplicate segments.</source>
        <target state="translated">Compared to reliable protocols in the datalink layer, reliable transport protocols encode their sequence numbers using more bits. 32 bits and 64 bits sequence numbers are frequent in the transport layer while some datalink layer protocols encode their sequence numbers in an 8 bits field. This large sequence number space is motivated by two reasons. First, since the sequence number is incremented for each transmitted byte, a single segment may consume one or several thousands of sequence numbers. Second, a reliable transport protocol must be able to detect delayed segments. This can only be done if the number of bytes transmitted during the MSL period is smaller than the sequence number space. Otherwise, there is a risk of accepting duplicate segments.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">818</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3885c64a29cde145" weblate-flags="read-only">
        <source>`Go-back-n` and `selective repeat` can be used in the transport layer as in the datalink layer. Since the network layer does not guarantee an in-order delivery of the packets, a transport entity should always store the segments that it receives out-of-sequence. For this reason, most transport protocols will opt for some form of selective repeat mechanism.</source>
        <target state="translated">`Go-back-n` and `selective repeat` can be used in the transport layer as in the datalink layer. Since the network layer does not guarantee an in-order delivery of the packets, a transport entity should always store the segments that it receives out-of-sequence. For this reason, most transport protocols will opt for some form of selective repeat mechanism.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">820</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="69cbfd1475fc0280" weblate-flags="read-only">
        <source>In the datalink layer, the sliding window has usually a fixed size which depends on the amount of buffers allocated to the datalink layer entity. Such a datalink layer entity usually serves one or a few network layer entities. In the transport layer, the situation is different. A single transport layer entity serves a large and varying number of application processes. Each transport layer entity manages a pool of buffers that needs to be shared between all these processes. Transport entity are usually implemented inside the operating system kernel and shares memory with other parts of the system. Furthermore, a transport layer entity must support several (possibly hundreds or thousands) of transport connections at the same time. This implies that the memory which can be used to support the sending or the receiving buffer of a transport connection may change during the lifetime of the connection [#fautotune]_ . Thus, a transport protocol must allow the sender and the receiver to adjust their window sizes.</source>
        <target state="translated">In the datalink layer, the sliding window has usually a fixed size which depends on the amount of buffers allocated to the datalink layer entity. Such a datalink layer entity usually serves one or a few network layer entities. In the transport layer, the situation is different. A single transport layer entity serves a large and varying number of application processes. Each transport layer entity manages a pool of buffers that needs to be shared between all these processes. Transport entity are usually implemented inside the operating system kernel and shares memory with other parts of the system. Furthermore, a transport layer entity must support several (possibly hundreds or thousands) of transport connections at the same time. This implies that the memory which can be used to support the sending or the receiving buffer of a transport connection may change during the lifetime of the connection [#fautotune]_ . Thus, a transport protocol must allow the sender and the receiver to adjust their window sizes.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">822</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3e86b7825e4ed46c" weblate-flags="read-only">
        <source>To deal with this issue, transport protocols allow the receiver to advertise the current size of its receiving window in all the acknowledgments that it sends. The receiving window advertised by the receiver bounds the size of the sending buffer used by the sender. In practice, the sender maintains two state variables : `swin`, the size of its sending window (that may be adjusted by the system) and `rwin`, the size of the receiving window advertised by the receiver. At any time, the number of unacknowledged segments cannot be larger than :math:`\min(swin,rwin)` [#facklost]_ . The utilization of dynamic windows is illustrated in the figure below.</source>
        <target state="translated">To deal with this issue, transport protocols allow the receiver to advertise the current size of its receiving window in all the acknowledgments that it sends. The receiving window advertised by the receiver bounds the size of the sending buffer used by the sender. In practice, the sender maintains two state variables : `swin`, the size of its sending window (that may be adjusted by the system) and `rwin`, the size of the receiving window advertised by the receiver. At any time, the number of unacknowledged segments cannot be larger than :math:`\min(swin,rwin)` [#facklost]_ . The utilization of dynamic windows is illustrated in the figure below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">824</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="562028e6bf3ee12d" weblate-flags="read-only">
        <source>Dynamic receiving window</source>
        <target state="translated">Dynamic receiving window</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">830</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ae74c50f9fe0ad51" weblate-flags="read-only">
        <source>The receiver may adjust its advertised receive window based on its current memory consumption, but also to limit the bandwidth used by the sender. In practice, the receive buffer can also shrink as the application may not able to process the received data quickly enough. In this case, the receive buffer may be completely full and the advertised receive window may shrink to `0`. When the sender receives an acknowledgment with a receive window set to `0`, it is blocked until it receives an acknowledgment with a positive receive window. Unfortunately, as shown in the figure below, the loss of this acknowledgment could cause a deadlock as the sender waits for an acknowledgment while the receiver is waiting for a data segment.</source>
        <target state="translated">The receiver may adjust its advertised receive window based on its current memory consumption, but also to limit the bandwidth used by the sender. In practice, the receive buffer can also shrink as the application may not able to process the received data quickly enough. In this case, the receive buffer may be completely full and the advertised receive window may shrink to `0`. When the sender receives an acknowledgment with a receive window set to `0`, it is blocked until it receives an acknowledgment with a positive receive window. Unfortunately, as shown in the figure below, the loss of this acknowledgment could cause a deadlock as the sender waits for an acknowledgment while the receiver is waiting for a data segment.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">832</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="17b4da4c52a6c7d7" weblate-flags="read-only">
        <source>Risk of deadlock with dynamic windows</source>
        <target state="translated">Risk of deadlock with dynamic windows</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">838</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e00feb6a3b73b6fa" weblate-flags="read-only">
        <source>To solve this problem, transport protocols rely on a special timer : the `persistence timer`. This timer is started by the sender whenever it receives an acknowledgment advertising a receive window set to `0`. When the timer expires, the sender retransmits an old segment in order to force the receiver to send a new acknowledgment, and hence send the current receive window size.</source>
        <target state="translated">To solve this problem, transport protocols rely on a special timer : the `persistence timer`. This timer is started by the sender whenever it receives an acknowledgment advertising a receive window set to `0`. When the timer expires, the sender retransmits an old segment in order to force the receiver to send a new acknowledgment, and hence send the current receive window size.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">843</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4783961f12ab5b80" weblate-flags="read-only">
        <source>To conclude our description of the basic mechanisms found in transport protocols, we still need to discuss the impact of segments arriving in the wrong order. If two consecutive segments are reordered, the receiver relies on their sequence numbers to reorder them in its receive buffer. Unfortunately, as transport protocols reuse the same sequence number for different segments, if a segment is delayed for a prolonged period of time, it might still be accepted by the receiver. This is illustrated in the figure below where segment `D(1,b)` is delayed.</source>
        <target state="translated">To conclude our description of the basic mechanisms found in transport protocols, we still need to discuss the impact of segments arriving in the wrong order. If two consecutive segments are reordered, the receiver relies on their sequence numbers to reorder them in its receive buffer. Unfortunately, as transport protocols reuse the same sequence number for different segments, if a segment is delayed for a prolonged period of time, it might still be accepted by the receiver. This is illustrated in the figure below where segment `D(1,b)` is delayed.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">845</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1c2affd8cade7645" weblate-flags="read-only">
        <source>Ambiguities caused by excessive delays</source>
        <target state="translated">Ambiguities caused by excessive delays</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">852</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="71fcce189c811807" weblate-flags="read-only">
        <source>To deal with this problem, transport protocols combine two solutions. First, they use 32 bits or more to encode the sequence number in the segment header. This increases the overhead, but also increases the delay between the transmission of two different segments having the same sequence number. Second, transport protocols require the network layer to enforce a `Maximum Segment Lifetime (MSL)`. The network layer must ensure that no packet remains in the network for more than MSL seconds. In the Internet the MSL is assumed [#fmsl]_ to be 2 minutes :rfc:`793`. Note that this limits the maximum bandwidth of a transport protocol. If it uses `n` bits to encode its sequence numbers, then it cannot send more than :math:`2^n` segments every MSL seconds.</source>
        <target state="translated">To deal with this problem, transport protocols combine two solutions. First, they use 32 bits or more to encode the sequence number in the segment header. This increases the overhead, but also increases the delay between the transmission of two different segments having the same sequence number. Second, transport protocols require the network layer to enforce a `Maximum Segment Lifetime (MSL)`. The network layer must ensure that no packet remains in the network for more than MSL seconds. In the Internet the MSL is assumed [#fmsl]_ to be 2 minutes :rfc:`793`. Note that this limits the maximum bandwidth of a transport protocol. If it uses `n` bits to encode its sequence numbers, then it cannot send more than :math:`2^n` segments every MSL seconds.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">856</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="66a2c90b751d376e" weblate-flags="read-only">
        <source>Connection release</source>
        <target state="translated">Connection release</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">860</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b809832a0b530cca" weblate-flags="read-only">
        <source>When we discussed the connection-oriented service, we mentioned that there are two types of connection releases : `abrupt release` and `graceful release`.</source>
        <target state="translated">When we discussed the connection-oriented service, we mentioned that there are two types of connection releases : `abrupt release` and `graceful release`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">864</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d2f363a6ad172bd2" weblate-flags="read-only">
        <source>The first solution to release a transport connection is to define a new control segment (e.g. the `DR` segment for Disconnection Request) and consider the connection to be released once this segment has been sent or received. This is illustrated in the figure below.</source>
        <target state="translated">The first solution to release a transport connection is to define a new control segment (e.g. the `DR` segment for Disconnection Request) and consider the connection to be released once this segment has been sent or received. This is illustrated in the figure below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">866</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c8db135c113f235f" weblate-flags="read-only">
        <source>Abrupt connection release</source>
        <target state="translated">Abrupt connection release</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">873</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5719f9a775a3ed01" weblate-flags="read-only">
        <source>As the entity that sends the `DR` segment cannot know whether the other entity has already sent all its data on the connection, SDUs can be lost during such an `abrupt connection release`.</source>
        <target state="translated">As the entity that sends the `DR` segment cannot know whether the other entity has already sent all its data on the connection, SDUs can be lost during such an `abrupt connection release`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">875</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e180e71d041e1754" weblate-flags="read-only">
        <source>The second method to release a transport connection is to release independently the two directions of data transfer. Once a user of the transport service has sent all its SDUs, it performs a `DISCONNECT.req` for its direction of data transfer. The transport entity sends a control segment to request the release of the connection *after* the delivery of all previous SDUs to the remote user. This is usually done by placing in the `DR` the next sequence number and by delivering the `DISCONNECT.ind` only after all previous `DATA.ind`. The remote entity confirms the reception of the `DR` segment and the release of the corresponding direction of data transfer by returning an acknowledgment. This is illustrated in the figure below.</source>
        <target state="translated">The second method to release a transport connection is to release independently the two directions of data transfer. Once a user of the transport service has sent all its SDUs, it performs a `DISCONNECT.req` for its direction of data transfer. The transport entity sends a control segment to request the release of the connection *after* the delivery of all previous SDUs to the remote user. This is usually done by placing in the `DR` the next sequence number and by delivering the `DISCONNECT.ind` only after all previous `DATA.ind`. The remote entity confirms the reception of the `DR` segment and the release of the corresponding direction of data transfer by returning an acknowledgment. This is illustrated in the figure below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">879</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="78278d8b1e809aa5" weblate-flags="read-only">
        <source>Graceful connection release</source>
        <target state="translated">Graceful connection release</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">885</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c463aea6549199a2" weblate-flags="read-only">
        <source>Footnotes</source>
        <target state="translated">Footnotes</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">890</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d08c348785a78bf4" weblate-flags="read-only">
        <source>For example, the :manpage:`htonl(3)` (resp. :manpage:`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.</source>
        <target state="translated">For example, the :manpage:`htonl(3)` (resp. :manpage:`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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">891</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3ddb41cd29529650" weblate-flags="read-only">
        <source>In the application layer, most servers are implemented as processes. The network and transport layer on the other hand are usually implemented inside the operating system and the amount of memory that they can use is limited by the amount of memory allocated to the entire kernel.</source>
        <target state="translated">In the application layer, most servers are implemented as processes. The network and transport layer on the other hand are usually implemented inside the operating system and the amount of memory that they can use is limited by the amount of memory allocated to the entire kernel.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">893</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="37b854899436afe7" weblate-flags="read-only">
        <source>For a discussion on how the sending buffer can change, see e.g. [SMM1998]_</source>
        <target state="translated">For a discussion on how the sending buffer can change, see e.g. [SMM1998]_</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">895</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b7f900f1c97f8800" weblate-flags="read-only">
        <source>Note that if the receive window shrinks, it might happen that the sender has already sent a segment that is not anymore inside its window. This segment will be discarded by the receiver and the sender will retransmit it later.</source>
        <target state="translated">Note that if the receive window shrinks, it might happen that the sender has already sent a segment that is not anymore inside its window. This segment will be discarded by the receiver and the sender will retransmit it later.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">897</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d1c3a4569ac0335f" weblate-flags="read-only">
        <source>In reality, the Internet does not strictly enforce this MSL. However, it is reasonable to expect that most packets on the Internet will not remain in the network during more than 2 minutes. There are a few exceptions to this rule, such as :rfc:`1149` whose implementation is described in http://www.blug.linux.no/rfc1149/ but there are few real links supporting :rfc:`1149` in the Internet.</source>
        <target state="translated">In reality, the Internet does not strictly enforce this MSL. However, it is reasonable to expect that most packets on the Internet will not remain in the network during more than 2 minutes. There are a few exceptions to this rule, such as :rfc:`1149` whose implementation is described in http://www.blug.linux.no/rfc1149/ but there are few real links supporting :rfc:`1149` in the Internet.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/transport.rst</context>
          <context context-type="linenumber">899</context>
        </context-group>
      </trans-unit>
    </body>
  </file>
</xliff>
