<?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="fr">
    <body>
      <trans-unit xml:space="preserve" approved="no" id="056e029045bd1427">
        <source>Connecting two hosts</source>
        <target state="translated">Connexion entre deux hôtes</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">8</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="97a264c8a10fe94b">
        <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=1 or help us by providing pull requests to close the existing issues.</source>
        <target state="translated">Ceci est un brouillon non peaufiné de la troisième édition de cet e-book. Si vous avez trouvé une erreur ou avez des suggestions pour améliorer le texte, merci de créer une *issue* via https://github.com/CNP3/ebook/issues?milestone=1 ou de nous aider en ouvrant des *pull requests* pour fermer les *issues* existantes.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">14</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="42a66419cedc5b69">
        <source>The first step when building a network, even a worldwide network such as the Internet, is to connect two hosts together. This is illustrated in the figure below.</source>
        <target state="translated">La première étape lorsque l'on construit un réseau, même dans le cas d'un réseau mondial tel qu'Internet, est de connecter deux hôtes ensemble. Ceci est illustré par la figure ci-dessous.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">17</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a89abee31f36f813">
        <source>To enable the two hosts to exchange information, they need to be linked together by some kind of physical media. Computer networks have used various types of physical media to exchange information, notably :</source>
        <target state="translated">Pour permettre à deux hôtes d'échanger de l'information, il est nécessaire de les lier ensemble au moyen d'un support physique quelconque. Les réseaux informatiques utilisent divers types de supports physiques pour échanger de l'information, notamment :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">31</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="90e4ec854b3fa9e3">
        <source>`electrical cable`. Information can be transmitted over different types of electrical cables. The most common ones are the twisted pairs (that are used in the telephone network, but also in enterprise networks) and the coaxial cables (that are still used in cable TV networks, but are no longer used in enterprise networks). Some networking technologies operate over the classical electrical cable.</source>
        <target state="translated">des `câbles électriques`. Les informations peuvent être transmises à travers différents types de câbles électriques. Les plus courants sont les paires torsadées (qui sont utilisées pour le réseau téléphonique, mais aussi dans les réseaux d'entreprise) et les câbles coaxiaux (qui sont toujours utilisés pour les réseaux de télévision câblée, mais qui ne sont plus utilisés dans les réseaux d'entreprise). Plusieurs technologies de réseau fonctionnent au moyen d'un câble électrique classique.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">33</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="62894cc47d66ab95">
        <source>`wireless`. In this case, a radio signal is used to encode the information exchanged between the communicating devices. Many types of modulation techniques are used to send information over a wireless channel and there is lot of innovation in this field with new techniques appearing every year. While most wireless networks rely on radio signals, some use a laser that sends light pulses to a remote detector. These optical techniques allow to create point-to-point links while radio-based techniques can be used to build networks containing devices spread over a small geographical area.</source>
        <target state="translated">le `sans fil`. Dans ce cas, un signal radio est utilisé pour encoder les informations échangées entre les deux appareils qui communiquent. Plusieurs types de modulations sont utilisées pour envoyer de l'information sur un canal sans-fil et ce domaine témoigne de beaucoup d'innovations avec de nouvelles techniques faisant leur apparition chaque année. Alors que la plupart des réseaux sans-fils reposent sur un signal radio, quelques uns utilisent un laser pour envoyer des pulsations de lumières à un détecteur à distance. Ces technologies optiques permettent de créer des liaisons point à point tandis que les technologies reposant sur un signal radio permettent de construire des réseaux avec des appareils dispersés au sein d'une petite zone géographique.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">35</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="253a12125f09a240">
        <source>The physical layer</source>
        <target state="translated">La couche physique</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">39</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6544ba38e1b03f2e">
        <source>Bit rate</source>
        <target state="translated">Débit</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">44</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">49</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d28a37d381c321c5">
        <source>Bits per second</source>
        <target state="translated">Bits par seconde</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">49</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f438a34f5e5c2659">
        <source>1 Kbps</source>
        <target state="translated">1 Kbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">51</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="acd60575922ed818">
        <source>:math:`10^3`</source>
        <target state="translated">:math:`10^3`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">51</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="30623f7a59f71552">
        <source>1 Mbps</source>
        <target state="translated">1 Mbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">52</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5d1707ec74553605">
        <source>:math:`10^6`</source>
        <target state="translated">:math:`10^6`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">52</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6eaaf97d666f9119">
        <source>1 Gbps</source>
        <target state="translated">1 Gbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">53</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e88e6e161443146d">
        <source>:math:`10^9`</source>
        <target state="translated">:math:`10^9`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">53</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="75b29a3ecf1b4b52">
        <source>1 Tbps</source>
        <target state="translated">1 Tbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">54</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2b4212296773ad7d">
        <source>:math:`10^{12}`</source>
        <target state="translated">:math:`10^{12}`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">54</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e6e0c7754f513265">
        <source>To understand some of the principles behind the physical transmission of information, let us consider the simple case of an electrical wire that is used to transmit bits. Assume that the two communicating hosts want to transmit one thousand bits per second. To transmit these bits, the two hosts can agree on the following rules :</source>
        <target state="translated">Pour comprendre les principes de la transmission physique d'information, considérons le cas d'un fil électrique qui est utilisé pour transmettre des bits. Supposons que les deux hôtes qui communiquent veulent transmettre un millier de bits par seconde. Pour transmettre ces bits, les deux hôtes peuvent se mettre d'accord sur les règles suivantes :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">59</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="74f263d5917359f1">
        <source>On the sender side :</source>
        <target state="translated">Du côté de l'émetteur :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">63</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e32ee478425548dd">
        <source>set the voltage on the electrical wire at ``+5V`` during one millisecond to transmit a bit set to `1`</source>
        <target state="translated">mettre la tension sur le fil électeique à ``+5V`` pendant une milliseconde pour transmettre un bit mis à `1`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">62</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="20fb9cdaacf12deb">
        <source>set the voltage on the electrical wire at ``-5V`` during one millisecond to transmit a bit set to `0`</source>
        <target state="translated">mettre la tension sur le fil électrique à ``-5V`` pendant une milliseconde pour transmettre un bit mis à `0`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">63</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9de006cf6bf01adf">
        <source>On the receiver side :</source>
        <target state="translated">Du côté du récepteur :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">66</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="058a4c985925b993">
        <source>every millisecond, record the voltage applied on the electrical wire. If the voltage is set to ``+5V``, record the reception of bit `1`. Otherwise, record the reception of bit `0`</source>
        <target state="translated">chaque milliseconde, enregistrer la tension appliquée sur le fil électrique. Si la tension est de ``+5V``, enregistrer le bit reçu comme étant `1`. Sinon, enregistrer le bit reçu comme étant `0`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">66</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5f762d5e164a12e8">
        <source>This transmission scheme has been used in some early networks. We use it as a basis to understand how hosts communicate.  From a Computer Science viewpoint, dealing with voltages is unusual. Computer scientists frequently rely on models that enable them to reason about the issues that they face without having to consider all implementation details. The physical transmission scheme described above can be represented by using a `time-sequence diagram`.</source>
        <target state="translated">Ce procédé de transmission a été utilisé pour quelques-uns des tout premiers réseaux. Nous l'utilisons comme base pour comprendre comment deux hôtes communiquent. Pour un informaticien, travailler avec des tensions est inhabituel. Les informaticiens reposent plutôt sur des modèles qui leur permettent de raisonner aux problèmes auxquels ils font face sans avoir à prendre en compte tous les détails d'implémentation. Le procédé de transmission physique décrit ci-dessus peut être représenté en utilisant un `diagramme de séquence`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">70</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9efe98ea25bdabfb">
        <source>With the above transmission scheme, a bit is transmitted by setting the voltage on the electrical cable to a specific value during some period of time. We have seen that due to electromagnetic interference, the voltage measured by the receiver can differ from the voltage set by the transmitter. This is the main cause of transmission errors. However, this is not the only type of problem that can occur. Besides defining the voltages for bits `0` and `1`, the above transmission scheme also specifies the duration of each bit. If one million bits are sent every second, then each bit lasts 1 microsecond. On each host, the transmission (resp. the reception) of each bit is triggered by a local clock having a 1 MHz frequency. These clocks are the second source of problems when transmitting bits over a wire. Although the two clocks have the same specification, they run on different hosts, possibly at a different temperature and with a different source of energy. In practice, it is possible that the two clocks do not operate at exactly the same frequency. Assume that the clock of the transmitting host operates at exactly 1000000 Hz while the receiving clock operates at 999999 Hz. This is a very small difference between the two clocks. However, when using the clock to transmit bits, this difference is important. With its 1000000 Hz clock, the transmitting host will generate one million bits during a period of one second. During the same period, the receiving host will sense the wire 999999 times and thus will receive one bit less than the bits originally transmitted. This small difference in clock frequencies implies that bits can "disappear" during their transmission on an electrical cable. This is illustrated in the figure below.</source>
        <target state="translated">Avec le schéma de transmission ci-dessus, un bit est transmis en fixant la tension sur un câble électrique à une valeur spécifique durant un laps de temps donné. Nous avons vu qu'en raison des interférences électromagnétiques, la tension mesurée par le récepteur peut être différente de celle définie par l'émetteur. C'est la cause principale des erreurs de transmission. Cependant, ce n'est pas l'unique type de problème qui peut survenir. En plus de définir tes tensions spécifiques pour les bits `0` et `1`, le schéma ci-dessus définit aussi la durée de chaque bit. Si un million de bits sont envoyés chaque seconde, alors chaque bit a une durée de 1 microseconde. Sur chaque hôte, la transmission (resp. la réception) de chaque bit est déclenchée par une horloge locale ayant une fréquence de 1 MHz. Ces horloges constituent la deuxième source de problèmes lors de la transmission de bits par câble. Bien que les deux horloges aient les mêmes caractéristiques, elles tournent sur des hôtes différents, potentiellement à des températures différentes et des sources d'énergie différentes. En pratique, il est possible que les deux horloges ne soient pas précisément synchronisées sur la même fréquence. Considérons que l'horloge de l'émetteur tourne à précisément 1000000 Hz alors que l'horloge du récepteur tourne à 999999 Hz. Une différence minime entre les deux horloges, pourtant, cette différence est importante lorsque l'on utilise l'une ou l'autre horloge pour transmettre un bit. Dans le cas de l'horloge à 1 MHz, il y aura un million de bits générés durant une période de une seconde alors que pour la même durée, le récepteur ne détectera le signal sur le câble que 999999 fois et recevra un bit de moins que ce qui a été transmis initialement. Cette légère différence de fréquence implique la disparition potentielle de certains bits durant leur transmission sur un câble électrique. Ce phénomène est illustré sur la figure ci-dessous.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">106</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e4930e7a67740b3a">
        <source>A similar reasoning applies when the clock of the sending host is slower than the clock of the receiving host. In this case, the receiver will sense more bits than the bits that have been transmitted by the sender. This is illustrated in the figure below where the second bit received on the right was not transmitted by the left host.</source>
        <target state="translated">Un raisonnement similaire s'applique lorsque la fréquence d'horloge de l'hôte émetteur est plus basse que celle de l'hôte récepteur. Dans ce cas, le récepteur va mesurer plus de bits que ce qui n'a été transmis par l'émetteur. La figure ci-dessous illustre ce phénomène. Le second bit reçu à droite n'a pas été transmis par l'hôte de gauche.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">128</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5b52e19382952f4f">
        <source>the `Physical layer service` may change, e.g. due to electromagnetic interference, the value of a bit being transmitted</source>
        <target state="translated">le `service de la couche physique` peut changer, c'est le cas notamment lors d'interférences électromagnétiques où la valeur d'un bit transmis peut être altérée</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">152</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e956e7a0cd95bb4d">
        <source>the `Physical layer service` may deliver `more` bits to the receiver than the bits sent by the sender</source>
        <target state="translated">le `service de la couche physique` peut délivrer `plus` de bits au récepteur que l'émetteur n'en a réellement envoyé</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">153</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="efc818bfdaab5f42">
        <source>the `Physical layer service` may deliver `fewer` bits to the receiver than the bits sent by the sender</source>
        <target state="translated">le `service de la couche physique` peut délivrer `moins` de bits au récepteur que ce qui a été envoyé par l'émetteur</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">154</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5b566fb2ec048644">
        <source>Many other types of encodings have been defined to transmit information over an electrical cable. All physical layers are able to send and receive physical symbols that represent values `0` and `1`. However, for various reasons that are outside the scope of this chapter, several physical layers exchange other physical symbols as well. For example, the Manchester encoding used in several physical layers can send four different symbols. The Manchester encoding is a differential encoding scheme in which time is divided into fixed-length periods. Each period is divided in two halves and two different voltage levels can  be applied. To send a symbol, the sender must set one of these two voltage levels during each half period. To send a `1` (resp. `0`), the sender must set a high (resp. low) voltage during the first half of the period and a low (resp. high) voltage during the second half. This encoding ensures that there will be a transition at the middle of each period and allows the receiver to synchronize its clock to the sender's clock. Apart from the encodings for `0` and `1`, the Manchester encoding also supports two additional symbols : `InvH` and `InvB`  where the same voltage level is used for the two half periods. By definition, these two symbols cannot appear inside a frame which is only composed of `0` and `1`. Some technologies use these special symbols as markers for the beginning or end of frames.</source>
        <target state="translated">De nombreux autres types de codages ont été définis pour transmettre des informations sur un câble électrique. Toutes les couches physiques sont capables d'envoyer et de recevoir des symboles physiques qui représentent les valeurs `0` et `1`. Cependant, pour diverses raisons qui sortent du cadre de ce chapitre, plusieurs couches physiques échangent également d'autres symboles physiques. Par exemple, le codage Manchester utilisé dans plusieurs couches physiques peut envoyer quatre symboles différents. Le codage Manchester est un schéma de codage différentiel dans lequel le temps est divisé en périodes de longueur fixe. Chaque période est divisée en deux moitiés et deux niveaux de tension différents peuvent être appliqués. Pour envoyer un symbole, l'expéditeur doit définir l'un de ces deux niveaux de tension pendant chaque demi-période. Pour envoyer un `1` (resp. `0`), l'expéditeur doit définir une tension élevée (resp. faible) pendant la première moitié de la période et une tension faible (resp. élevée) pendant la seconde moitié. Ce codage garantit qu'il y aura une transition au milieu de chaque période et permet au récepteur de synchroniser son horloge avec celle de l'émetteur. Outre les codages pour `0` et `1`, le codage Manchester supporte également deux symboles supplémentaires : `InvH` et `InvB` où le même niveau de tension est utilisé pour les deux demi-périodes. Par définition, ces deux symboles ne peuvent pas apparaître à l'intérieur d'une trame qui n'est composée que de `0` et `1`. Certaines technologies utilisent ces symboles spéciaux comme marqueurs de début ou de fin de trame.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">160</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="df7c834f1aa32604">
        <source>Manchester encoding</source>
        <target state="translated">Le codage Manchester</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">167</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ceee3826cc4e5c82">
        <source>All the functions related to the physical transmission or information through a wire (or a wireless link) are usually known as the `physical layer`. The physical layer allows thus two or more entities that are directly attached to the same transmission medium to exchange bits. Being able to exchange bits is important as virtually any information can be encoded as a sequence of bits. Electrical engineers are used to processing streams of bits, but computer scientists usually prefer to deal with higher level concepts. A similar issue arises with file storage. Storage devices such as hard-disks also store streams of bits. There are hardware devices that process the bit stream produced by a hard-disk, but computer scientists have designed filesystems to allow applications to easily access such storage devices. These filesystems are typically divided into several layers as well. Hard-disks store sectors of 512 bytes or more. Unix filesystems group sectors in larger blocks that can contain data or `inodes` representing the structure of the filesystem. Finally, applications manipulate files and directories that are translated in blocks, sectors and eventually bits by the operating system.</source>
        <target state="translated">Toutes les fonctions liées à la transmission physique ou à l'information transmise à travers un câble (ou une connexion sans fil) sont regroupées sous l'appellation `couche physique`. La couche physique permet ainsi à deux entités ou plus qui sont directement reliées par un même moyen de transmission d'échanger des bits. Pouvoir échanger des bits est fondamental puisque pratiquement n'importe quelle information peut être encodée comme une séquence de bits. Les ingénieurs électriciens sont habitués à traiter des flux de bits mais les informaticiens préfèrent habituellement faire usage de concepts plus haut niveau. Un problème similaire se pose quant aux systèmes de fichiers. Les périphériques de stockage tels que les disques durs stockent également des flux de bits. Il y a des périphériques matériels qui traitent directement le flux de bit produit par le disque dur mais les informaticiens ont conçu des systèmes de fichiers destinés à permettre aux applications d'accéder facilement à ces périphériques de stockage. Ces systèmes de fichiers sont généralement également divisés en plusieurs couches. Les disques durs stockent des secteurs de 512 bytes ou plus. Les systèmes de fichiers Unix regroupent les secteurs par blocs plus larges pouvant contenir des données ou `inodes` représentant la structure du système de fichiers. Enfin, les applications manipulent des fichiers et répertoires qui sont traduits en blocs, secteurs et enfin en bits par le système d'exploitation.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">180</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7246f29ca52554df">
        <source>Computer networks use a similar approach. Each layer provides a service that is built above the underlying layer and is closer to the needs of the applications. The datalink layer builds upon the service provided by the physical layer. We will see that it also contains several functions.</source>
        <target state="translated">Les réseaux informatiques utilisent une approche similaire. Chaque couche fournit un service construit sur la couche en-dessous et est plus proche des besoins des applications. La couche de liaison de données est construite à partir du service fourni par la couche physique. Nous allons voir qu'elle contient aussi plusieurs fonctions.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">184</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="eb647155d40d487f">
        <source>The datalink layer</source>
        <target state="translated">La couche de liaison de données</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">188</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="813f31e90d8d0a0c">
        <source>To enable the transmission/reception of frames, the first problem to be solved is how to encode a frame as a sequence of bits, so that the receiver can easily recover the received frame despite the limitations of the physical layer.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">194</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="f1c8c69eb4a6e7dd">
        <source>If the physical layer were perfect, the problem would be very simple. We would simply need to define how to encode each frame as a sequence of consecutive bits. The receiver would then easily be able to extract the frames from the received bits. Unfortunately, the imperfections of the physical layer make this framing problem slightly more complex. Several solutions have been proposed and are used in practice in different network technologies.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">199</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="26a910f58e32d3c7">
        <source>Framing</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">202</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="d9bae1eb052edf01">
        <source>The `framing` problem can be defined as : "`How does a sender encode frames so that the receiver can efficiently extract them from the stream of bits that it receives from the physical layer`".</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">204</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="f5fe707de39c11b3">
        <source>A first solution to this problem is to require the physical layer to remain idle for some time after the transmission of each frame. These idle periods can be detected by the receiver and serve as a marker to delineate frame boundaries. Unfortunately, this solution is not acceptable for two reasons. First, some physical layers cannot remain idle and always need to transmit bits. Second, inserting an idle period between frames decreases the maximum bit rate that can be achieved.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">206</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="3b501a9171e07c12">
        <source>Bit rate and bandwidth</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">208</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="b184f6ddbad07dd2">
        <source>Bit rate and bandwidth are often used to characterize the transmission capacity of the physical service. The original definition of `bandwidth &lt;https://www.merriam-webster.com/dictionary/bandwidth&gt;`_, as listed in the `Webster dictionary &lt;https://www.merriam-webster.com/dictionary&gt;`_ is `a range of radio frequencies which is occupied by a modulated carrier wave, which is assigned to a service, or over which a device can operate`. This definition corresponds to the characteristics of a given transmission medium or receiver. For example, the human ear is able to decode sounds in roughly the 0-20 KHz frequency range. By extension, bandwidth is also used to represent the capacity of a communication system in bits per second. For example, a Gigabit Ethernet link is theoretically capable of transporting one billion bits per second.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">210</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="800e724480be967a">
        <source>Given that multi-symbol encodings cannot be used by all physical layers, a generic solution which can be used with any physical layer that is able to transmit and receive only bits `0` and `1` is required. This generic solution is called `stuffing` and two variants exist : `bit stuffing` and `character stuffing`. To enable a receiver to easily delineate the frame boundaries, these two techniques reserve special bit strings as frame boundary markers and encode the frames so that these special bit strings do not appear inside the frames.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">215</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="6b983114ee10ca0c">
        <source>`Bit stuffing` reserves the `01111110` bit string as the frame boundary marker and ensures that there will never be six consecutive `1` symbols transmitted by the physical layer inside a frame. With bit stuffing, a frame is sent as follows. First, the sender transmits the marker, i.e. `01111110`. Then, it sends all the bits of the frame and inserts an additional bit set to `0` after each sequence of five consecutive `1` bits. This ensures that the sent frame never contains a sequence of six consecutive bits set to `1`. As a consequence, the marker pattern cannot appear inside the frame sent. The marker is also sent to mark the end of the frame. The receiver performs the opposite to decode a received frame. It first detects the beginning of the frame thanks to the `01111110` marker. Then, it processes the received bits and counts the number of consecutive bits set to `1`. If a `0` follows five consecutive bits set to `1`, this bit is removed since it was inserted by the sender. If a `1` follows five consecutive bits sets to `1`, it indicates a marker if it is followed by a bit set to `0`. The table below illustrates the application of bit stuffing to some frames.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">217</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="0d94147670f318e3">
        <source>Original frame</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">220</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">258</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="2100ad2c1c37a0a9">
        <source>Transmitted frame</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">220</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">258</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="11d14d9edc7b607b">
        <source>0001001001001001001000011</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">222</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="485ce7f7789afc1c">
        <source>01111110000100100100100100100001101111110</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">222</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="21b319437ff79511">
        <source>0110111111111111111110010</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">223</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="f96f0ee8753ec328">
        <source>01111110011011111011111011111011001001111110</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">223</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="88c5c5365d9324de">
        <source>01111110</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">224</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="a2da19c5ca45360b">
        <source>0111111001111101001111110</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">224</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="eb24e08079accf33">
        <source>For example, consider the transmission of `0110111111111111111110010`. The sender will first send the `01111110` marker followed by `011011111`. After these five consecutive bits set to `1`, it inserts a bit set to `0` followed by `11111`. A new `0` is inserted, followed by `11111`. A new `0` is inserted followed by the end of the frame `110010` and the `01111110` marker.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">228</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="f9a966b7452cf928">
        <source>`Bit stuffing` increases the number of bits required to transmit each frame. The worst case for bit stuffing is of course a long sequence of bits set to `1` inside the frame. If transmission errors occur, stuffed bits or markers can be in error. In these cases, the frame affected by the error and possibly the next frame will not be correctly decoded by the receiver, but it will be able to resynchronize itself at the next valid marker.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">231</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="33553124e9fa9c68">
        <source>`Bit stuffing` can be easily implemented in hardware. However, implementing it in software is difficult given the complexity of performing bit manipulations in software. Software implementations prefer to process characters than bits, software-based datalink layers usually use `character stuffing`. This technique operates on frames that contain an integer number of characters. In computer networks, characters are usually encoded by relying on the :term:`ASCII` table. This table defines the encoding of various alphanumeric characters as a sequence of bits. :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></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">236</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="b67235644a98458c">
        <source>`A` : `1000011` b</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">238</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="4e1617348d46e6c1">
        <source>`0` : `0110000` b</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">239</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="26c9e432541f85f4">
        <source>`z` : `1111010` b</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">240</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="1f1dadffca2cabd0">
        <source>`@` : `1000000` b</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">241</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="6c8dddc019383287">
        <source>`space` : `0100000` b</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">242</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="de0c84460a7f219b">
        <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 `BEL` character which causes the terminal to emit a sound.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">244</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="f0f4e366a1ae18f9">
        <source>`NUL`: `0000000` b</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">246</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="d8a13aff13f581f9">
        <source>`BEL`: `0000111` b</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">247</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="7806175f9d229e7a">
        <source>`CR` : `0001101` b</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">248</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="ba9d4248e53642d7">
        <source>`LF` : `0001010` b</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">249</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="bcb018dd984b82b5">
        <source>`DLE`: `0010000` b</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">250</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="dd97f706a7f39459">
        <source>`STX`: `0000010` b</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">251</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="5e61b04ca4e44416">
        <source>`ETX`: `0000011` b</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">252</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="8c7fbeabefda4e4f">
        <source>Some characters are used as markers to delineate the frame boundaries. Many `character stuffing` techniques use the `DLE`, `STX` and `ETX` characters of the ASCII character set. `DLE STX` (resp. `DLE ETX`) is used to mark the beginning (end) of a frame. When transmitting a frame, the sender adds a `DLE` character after each transmitted `DLE` character. This ensures that none of the markers can appear inside the transmitted frame. The receiver detects the frame boundaries and removes the second `DLE` when it receives two consecutive `DLE` characters. For example, to transmit frame `1 2 3 DLE STX 4`, a sender will first send `DLE STX` as a marker, followed by `1 2 3 DLE`. Then, the sender transmits an additional `DLE` character followed by `STX 4` and the `DLE ETX` marker.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">254</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="5c22fc86bf772560">
        <source>**1** **2** **3** **4**</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">260</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="079c57310b4b1b95">
        <source>`DLE STX` **1** **2** **3** **4** `DLE ETX`</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">260</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="4cf8937beb818ae6">
        <source>**1** **2** **3** **DLE** **STX** **4**</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">261</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="1d1324882485b126">
        <source>`DLE STX` **1** **2** **3** **DLE** `DLE` **STX** `4` `DLE ETX`</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">261</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="f3bbe12a9a9afcda">
        <source>**DLE STX DLE ETX**</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">262</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="49c1bf4054951f90">
        <source>`DLE STX` **DLE** `DLE` **STX** **DLE** `DLE` ETX** `DLE ETX`</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">262</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="806227768c41d67e">
        <source>Recovering from transmission errors</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">304</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="056a985ee2729448">
        <source>In this section, we develop a reliable datalink protocol running above the physical layer service. To design this protocol, we first assume that the physical layer provides a perfect service. We will then develop solutions to recover from the transmission errors.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">306</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="3564c5c8a1f50889">
        <source>The datalink layer is designed to send and receive frames on behalf of a user. We model these interactions by using the `DATA.req` and `DATA.ind` primitives. However, to simplify the presentation and to avoid confusion between a `DATA.req` primitive issued by the user of the datalink layer entity, and a `DATA.req` issued by the datalink layer entity itself, we will use the following terminology :</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">308</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="d852b0737f4d71e3">
        <source>the interactions between the user and the datalink layer entity are represented by using the classical `DATA.req` and the `DATA.ind` primitives</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">310</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="b371b397747cdb13">
        <source>the interactions between the datalink layer entity and the framing sub-layer are represented by using `send` instead of `DATA.req` and `recvd` instead of `DATA.ind`</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">311</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="4b882270de419300">
        <source>To solve this problem, a reliable protocol must include a feedback mechanism that allows the receiver to inform the sender that it has processed a frame and that another one can be sent. This feedback is required even though there are no transmission errors. To include such a feedback, our reliable protocol must process two types of frames :</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">334</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="226e0c52c2c17acc">
        <source>data frames carrying a SDU</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">336</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="064cadfa4d674a5e">
        <source>These two types of frames can be distinguished by dividing the frame in two parts :</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">339</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="503d93d466517b44">
        <source>the `header` that contains one bit set to `0` in data frames and set to `1` in control frames</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">341</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="82b3681c465ad560">
        <source>the payload that contains the SDU supplied by the application</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">342</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="50eb9a4104657850">
        <source>The datalink entity can then be modeled as a finite state machine, containing two states for the receiver and two states for the sender. The figure below provides a graphical representation of this state machine with the sender above and the receiver below.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">344</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="ef62d4a26e8eeccf">
        <source>The above FSM shows that the sender has to wait for an acknowledgment from the receiver before being able to transmit the next SDU.  The figure below illustrates the exchange of a few frames between two hosts.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">353</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="c84dd783b54e5d94">
        <source>Services and protocols</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">372</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="68eacebbd7c637ae">
        <source>Reliable data transfer on top of an imperfect link</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">389</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="66506f451ee5b0c6">
        <source>The datalink layer must deal with the transmission errors. In practice, we mainly have to deal with two types of errors in the datalink layer :</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">391</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="12f9e3210bfb2988">
        <source>Frames can be corrupted by transmission errors</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">393</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="96464322d63910b1">
        <source>Frames can be lost or unexpected frames can appear</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">394</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="887ebce56ecb752f">
        <source>To deal with these types of imperfections, reliable protocols rely on different types of mechanisms. The first problem is transmission errors. Data transmission on a physical link can be affected by the following errors :</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">399</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="6f051d9a3070aa81">
        <source>random isolated errors where the value of a single bit has been modified due to a transmission error</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">401</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="28294876d66d86fd">
        <source>random burst errors where the values of `n` consecutive bits have been changed due to transmission errors</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">402</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="18cb876bfc3f39f9">
        <source>random bit creations and random bit removals where bits have been added or removed due to transmission errors</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">403</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="bb9c6c46439aa23f">
        <source>The only solution to protect against transmission errors is to add redundancy to the frames that are sent. `Information Theory` defines two mechanisms that can be used to transmit information over a transmission channel affected by random errors. These two mechanisms add redundancy to the transmitted information, to allow the receiver to detect or sometimes even correct transmission errors. A detailed discussion of these mechanisms is outside the scope of this chapter, but it is useful to consider a simple mechanism to understand its operation and its limitations.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">405</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="d97e39ed51f9467a">
        <source>`Information theory` defines `coding schemes`. There are different types of coding schemes, but let us focus on coding schemes that operate on binary strings. A coding scheme is a function that maps information encoded as a string of `m` bits into a string of `n` bits. The simplest coding scheme is the (even) parity coding. This coding scheme takes an `m` bits source string and produces an `m+1` bits coded string where the first `m` bits of the coded string are the bits of the source string and the last bit of the coded string is chosen such that the coded string will always contain an even number of bits set to `1`. For example :</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">407</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="5b4b722e9ad63922">
        <source>`1001` is encoded as `10010`</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">409</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="283724cd429a7432">
        <source>`1101` is encoded as `11011`</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">410</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="d946a127c2408d49">
        <source>This parity scheme has been used in some RAMs as well as to encode characters sent over a serial line. It is easy to show that this coding scheme allows the receiver to detect a single transmission error, but it cannot correct it. However, if two or more bits are in error, the receiver may not always be able to detect the error.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">412</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="3fe32a86cd96e98a">
        <source>Some coding schemes allow the receiver to correct some transmission errors. For example, consider the coding scheme that encodes each source bit as follows :</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">414</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="07ea641b6f46d697">
        <source>`1` is encoded as `111`</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">416</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="d237afbb9cd1e8c2">
        <source>`0` is encoded as `000`</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">417</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="d8d8e9a9a23dfae4">
        <source>For example, consider a sender that sends `111`. If there is one bit in error, the receiver could receive `011` or `101` or `110`. In these three cases, the receiver will decode the received bit pattern as a `1` since it contains a majority of bits set to `1`. If there are two bits in error, the receiver will not be able anymore to recover from the transmission error.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">419</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="834628bd7f7a44cc">
        <source>To understand `error detection codes`, let us consider two devices that exchange bit strings containing `N` bits. To allow the receiver to detect a transmission error, the sender converts each string of `N` bits into a string of `N+r` bits. Usually, the `r` redundant bits are added at the beginning or the end of the transmitted bit string, but some techniques interleave redundant bits with the original bits. An `error detection code` can be defined as a function that computes the `r` redundant bits corresponding to each string of `N` bits. The simplest error detection code is the parity bit. There are two types of parity schemes : even and odd parity. With the `even` (resp. `odd`) parity scheme, the redundant bit is chosen so that an even (resp. odd) number of bits are set to `1` in the transmitted bit string of `N+r` bits. The receiver can easily recompute the parity of each received bit string and discard the strings with an invalid parity. The parity scheme is often used when 7-bit characters are exchanged. In this case, the eighth bit is often a parity bit. The table below shows the parity bits that are computed for bit strings containing three bits.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">426</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="0eb60136c56de55b">
        <source>3 bits string</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">429</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="a5063c9e1ecf323f">
        <source>Odd parity</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">429</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="fd8c3c3d44fc7786">
        <source>Even parity</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">429</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="cebce96cf46cfc11">
        <source>000</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">431</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">448</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="dfbd4c12eb9e51b0">
        <source>1</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">431</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">432</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">433</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">434</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">435</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">436</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">437</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">438</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">452</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">453</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">454</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">455</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="eba030ebb7f9b8e1">
        <source>0</source>
        <target state="translated">0</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">431</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">432</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">433</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">434</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">435</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">436</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">437</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">438</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">448</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">449</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">450</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">451</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="3718a43712eb855f">
        <source>001</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">432</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">449</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="e8f83601acada220">
        <source>010</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">433</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">450</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="afaa0dead75b1f6f">
        <source>100</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">434</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">451</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="72d656772f2452ae">
        <source>111</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">435</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">452</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="db231dea66900c64">
        <source>110</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">436</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">453</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="140a197ebf27d954">
        <source>101</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">437</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">454</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="52ed52ed46fb7c26">
        <source>011</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">438</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">455</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="11de8f20b509141a">
        <source>The parity bit allows a receiver to detect transmission errors that have affected a single bit among the transmitted `N+r` bits. If there are two or more bits in error, the receiver may not necessarily be able to detect the transmission error. More powerful error detection schemes have been defined. The Cyclical Redundancy Checks (CRC) are widely used in datalink layer protocols. An N-bits CRC can detect all transmission errors affecting a burst of less than N bits in the transmitted frame and all transmission errors that affect an odd number of bits. Additional details about CRCs may be found in [Williams1993]_.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">441</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="ffb3fa7530124be1">
        <source>It is also possible to design a code that allows the receiver to correct transmission errors. The simplest `error correction code` is the triple modular redundancy (TMR). To transmit a bit set to `1` (resp. `0`), the sender transmits `111` (resp. `000`). When there are no transmission errors, the receiver can decode `111` as `1`. If transmission errors have affected a single bit, the receiver performs majority voting as shown in the table below. This scheme allows the receiver to correct all transmission errors that affect a single bit.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">443</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="24e7fcea74b192ad">
        <source>Received bits</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">446</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="c5728608f9596188">
        <source>Decoded bit</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">446</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="e886500e589bf11f">
        <source>Other more powerful error correction codes have been proposed and are used in some applications. The `Hamming Code &lt;https://en.wikipedia.org/wiki/Hamming_code&gt;`_ is a clever combination of parity bits that provides error detection and correction capabilities.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">458</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="4468eb54d0346d83">
        <source>Reliable protocols use error detection schemes, but none of the widely used reliable protocols rely on error correction schemes. To detect errors, a frame is usually divided into two parts :</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">461</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="818b9fbf71e21cd0">
        <source>a `header` that contains the fields used by the reliable protocol to ensure reliable delivery. The header contains a checksum or Cyclical Redundancy Check (CRC) [Williams1993]_ that is used to detect transmission errors</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">463</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="2534ed9e37ecd9e9">
        <source>a `payload` that contains the user data</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">464</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="f875ad623884f9b1">
        <source>Some headers also include a `length` field, which indicates the total length of the frame or the length of the payload.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">466</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="c01d18ff55e549ac">
        <source>The simplest error detection scheme is the checksum. A checksum is basically an arithmetic sum of all the bytes that a frame is composed of. There are different types of checksums. For example, an eight bit checksum can be computed as the arithmetic sum of all the bytes of (both the header and trailer of) the frame. The checksum is computed by the sender before sending the frame and the receiver verifies the checksum upon frame reception. The receiver discards frames received with an invalid checksum. Checksums can be easily implemented in software, but their error detection capabilities are limited. Cyclical Redundancy Checks (CRC) have better error detection capabilities [SGP98]_, but require more CPU when implemented in software.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">468</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="e54bc16a263de964">
        <source>To solve this problem, datalink protocols associate a `sequence number` to each data frame. This `sequence number` is one of the fields found in the header of data frames. We use the notation `D(x,...)` to indicate a data frame whose sequence number field is set to value `x`. The acknowledgments also contain a sequence number indicating the data frames that it is acknowledging. We use `OKx` to indicate an acknowledgment frame that confirms the reception of `D(x,...)`. The sequence number is encoded as a bit string of fixed length. The simplest reliable protocol is the Alternating Bit Protocol (ABP).</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">552</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="9d54701a601f5be8">
        <source>The initial state of the sender is `Wait for D(0,...)`. In this state, the sender waits for a `Data.request`. The first data frame that it sends uses sequence number `0`. After having sent this frame, the sender waits for an `OK0` acknowledgment. A frame is retransmitted upon expiration of the retransmission timer or if an acknowledgment with an incorrect sequence number has been received.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">567</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="d82a0a2f47c0154f">
        <source>The receiver first waits for `D(0,...)`. If the frame contains a correct `CRC`, it passes the SDU to its user and sends `OK0`. If the frame contains an invalid CRC, it is immediately discarded. Then, the receiver waits for `D(1,...)`. In this state, it may receive a duplicate `D(0,...)` or a data frame with an invalid CRC. In both cases, it returns an `OK0` frame to allow the sender to recover from the possible loss of the previous `OK0` frame.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">569</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="87a861c80bcc67d7">
        <source>Dealing with corrupted frames</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">579</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="8be589acb2005670">
        <source>The receiver FSM of the Alternating bit protocol discards all frames that contain an invalid CRC. This is the safest approach since the received frame can be completely different from the frame sent by the remote host. A receiver should not attempt at extracting information from a corrupted frame because it cannot know which portion of the frame has been affected by the error.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">581</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="291f6db211a34064">
        <source>The figure below illustrates the operation of the alternating bit protocol.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">584</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="ed20d6e5f26067e0">
        <source>The Alternating Bit Protocol can recover from transmission errors and frame losses. However, it has one important drawback. Consider two hosts that are directly connected by a 50 Kbits/sec satellite link that has a 250 milliseconds propagation delay. If these hosts send 1000 bits frames, then the maximum throughput that can be achieved by the alternating bit protocol is one frame every :math:`20+250+250=520` milliseconds if we ignore the transmission time of the acknowledgment. This is less than 2 Kbits/sec !</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">675</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="2d45e5897573934c">
        <source>Go-back-n and selective repeat</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">685</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="a624e328f4ebce29">
        <source>Pipelining improves the performance of reliable protocols</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">693</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="7092fd54821c6668">
        <source>`Pipelining` allows the sender to transmit frames at a higher rate. However this higher transmission rate may overload the receiver. In this case, the frames sent by the sender will not be correctly received by their final destination. The reliable protocols that rely on pipelining allow the sender to transmit `W` unacknowledged frames before being forced to wait for an acknowledgment from the receiving entity.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">695</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="865aacb636443222">
        <source>The sliding window</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">703</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="94508ce1de957dc9">
        <source>Sliding window example</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">712</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="13f9c9861e2e7138">
        <source>In practice, as the frame header includes an `n` bits field to encode the sequence number, only the sequence numbers between :math:`0` and :math:`2^{n}-1` can be used. This implies that, during a long transfer, the same sequence number will be used for different frames and the sliding window will wrap. This is illustrated in the figure below assuming that `2` bits are used to encode the sequence number in the frame header. Note that upon reception of `OK1`, the sender slides its window and can use sequence number `0` again.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">715</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="534fa44e3b134f87">
        <source>Utilisation of the sliding window with modulo arithmetic</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">722</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="5fb91609c40ab341">
        <source>Unfortunately, frame losses do not disappear because a reliable protocol uses a sliding window. To recover from losses, a sliding window protocol must define :</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">727</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="5b8edb7475a1e682">
        <source>a heuristic to detect frame losses</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">729</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="cedfeec798ce35ab">
        <source>a `retransmission strategy` to retransmit the lost frames</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">730</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="0390c9fe105f9922">
        <source>The figure below shows the FSM of a simple `go-back-n` receiver. This receiver uses two variables : `lastack` and `next`. `next` is the next expected sequence number and `lastack` the sequence number of the last data frame that has been acknowledged. The receiver only accepts the frame that are received in sequence. `maxseq` is the number of different sequence numbers (:math:`2^n`).</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">737</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="f0f76cdf753c5ef6">
        <source>The operation of `go-back-n` is illustrated in the figure below. In this figure, note that upon reception of the out-of-sequence frame `D(2,c)`, the receiver returns a cumulative acknowledgment `C(OK,0)` that acknowledges all the frames that have been received in sequence. The lost frame is retransmitted upon the expiration of the retransmission timer.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">757</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="347f6f1ae26a138e">
        <source>Go-back-n : example</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">763</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="48f04843b294ccc2">
        <source>The main advantage of `go-back-n` is that it can be easily implemented, and it can also provide good performance when only a few frames are lost. However, when there are many losses, the performance of `go-back-n` quickly drops for two reasons :</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">766</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="299425bb2a503d81">
        <source>the `go-back-n` receiver does not accept out-of-sequence frames</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">768</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="6b29b1783337734e">
        <source>the `go-back-n` sender retransmits all unacknowledged frames once it has detected a loss</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">769</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="35f35cf3a5d8f233">
        <source>`Selective repeat` is a better strategy to recover from losses. Intuitively, `selective repeat` allows the receiver to accept out-of-sequence frames. Furthermore, when a `selective repeat` sender detects losses, it only retransmits the frames that have been lost and not the frames that have already been correctly received.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">776</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="bf647fff63e8397b">
        <source>A `selective repeat` receiver maintains a sliding window of `W` frames and stores in a buffer the out-of-sequence frames that it receives. The figure below shows a five-frame receive window on a receiver that has already received frames `7` and `9`.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">778</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="dd84fd633c41cb28">
        <source>The receiving window with selective repeat</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">784</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="c512baa1c7c05c46">
        <source>A `selective repeat` receiver discards all frames having an invalid CRC, and maintains the variable `lastack` as the sequence number of the last in-sequence frame that it has received. The receiver always includes the value of `lastack` in the acknowledgments that it sends. Some protocols also allow the `selective repeat` receiver to acknowledge the out-of-sequence frames that it has received. This can be done for example by placing the list of the correctly received, but out-of-sequence frames in the acknowledgments together with the `lastack` value.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">786</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="d839eeb8bbe3f05c">
        <source>When a `selective repeat` receiver receives a data frame, it first verifies whether the frame is inside its receiving window. If yes, the frame is placed in the receive buffer. If not, the received frame is discarded and an acknowledgment containing `lastack` is sent to the sender. The receiver then removes all consecutive frames starting at `lastack` (if any) from the receive buffer. The payloads of these frames are delivered to the user, `lastack` and the receiving window are updated, and an acknowledgment acknowledging the last frame received in sequence is sent.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">788</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="dcc8a8280d2b67fa">
        <source>The `selective repeat` sender maintains a sending buffer that can store up to `W` unacknowledged frames. These frames are sent as long as the sending buffer is not full. Several implementations of a `selective repeat` sender are possible. A simple implementation associates one retransmission timer to each frame. The timer is started when the frame is sent and canceled upon reception of an acknowledgment that covers this frame. When a retransmission timer expires, the corresponding frame is retransmitted and this retransmission timer is restarted. When an acknowledgment is received, all the frames that are covered by this acknowledgment are removed from the sending buffer and the sliding window is updated.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">790</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="eac6c1e574f53297">
        <source>The figure below illustrates the operation of `selective repeat` when frames are lost. In this figure, `C(OK,x)` is used to indicate that all frames, up to and including sequence number `x` have been received correctly.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">792</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="162150a9081e1247">
        <source>Selective repeat : example</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">798</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="4be7bb9b6904370b">
        <source>Pure cumulative acknowledgments work well with the `go-back-n` strategy. However, with only cumulative acknowledgments a `selective repeat` sender cannot easily determine which frames have been correctly received after a data frame has been lost. For example, in the figure above, the second `C(OK,0)` does not inform explicitly the sender of the reception of `D(2,c)` and the sender could retransmit this frame although it has already been received. A possible solution to improve the performance of `selective repeat` is to provide additional information about the received frames in the acknowledgments that are returned by the receiver. For example, the receiver could add in the returned acknowledgment the list of the sequence numbers of all frames that have already been received. Such acknowledgments are sometimes called `selective acknowledgments`. This is illustrated in the figure above.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">802</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="7f0942685cc0792b">
        <source>In the figure above, when the sender receives `C(OK,0,[2])`, it knows that all frames up to and including `D(0,...)` have been correctly received. It also knows that frame `D(2,...)` has been received and can cancel the retransmission timer associated to this frame. However, this frame should not be removed from the sending buffer before the reception of a cumulative acknowledgment (`C(OK,2)` in the figure above) that covers this frame.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">811</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f52d9d1b2e40d4fc">
        <source>Maximum window size with `go-back-n` and `selective repeat`</source>
        <target state="translated">Taille maximale de fenêtre avec le `go-back-n` et `selective repeat`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">815</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="1943139f84356e6e">
        <source>A reliable protocol that uses `n` bits to encode its sequence number can send up to :math:`2^n` successive frames. However, to ensure a reliable delivery of the frames, `go-back-n` and `selective repeat` cannot use a sending window of :math:`2^n` frames. Consider first `go-back-n` and assume that a sender sends :math:`2^n` frames. These frames are received in-sequence by the destination, but all the returned acknowledgments are lost. The sender will retransmit all frames. These frames will all be accepted by the receiver and delivered a second time to the user. It is easy to see that this problem can be avoided if the maximum size of the sending window is :math:`{2^n}-1` frames. A similar problem occurs with `selective repeat`. However, as the receiver accepts out-of-sequence frames, a sending window of :math:`{2^n}-1` frames is not sufficient to ensure a reliable delivery. It can be easily shown that to avoid this problem, a `selective repeat` sender cannot use a window that is larger than :math:`\frac{2^n}{2}` frames.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">817</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="7c09c416af3b2650">
        <source>Reliable protocols often need to send data in both directions. To reduce the overhead caused by the acknowledgments, most reliable protocols use `piggybacking`. Thanks to this technique, a datalink entity can place the acknowledgments and the receive window that it advertises for the opposite direction of the data flow inside the header of the data frames that it sends. The main advantage of piggybacking is that it reduces the overhead as it is not necessary to send a complete frame to carry an acknowledgment. This is illustrated in the figure below where the acknowledgment number is underlined in the data frames. Piggybacking is only used when data flows in both directions. A receiver will generate a pure acknowledgment when it does not send data in the opposite direction as shown in the bottom of the figure.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">863</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="33a41c7b1a0b8d5d">
        <source>Piggybacking example</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">869</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c4216746468d4eb9">
        <source>SDU is the acronym of Service Data Unit. We use it as a generic term to represent the data that is transported by a protocol.</source>
        <target state="translated">SDU est l'acronyme de Service Data Unit. On l'utilise comme terme générique pour désigner les données qui sont transmises par un protocole.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">877</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" id="7d87167e8bc8abed">
        <source>The size of the sliding window can be either fixed for a given protocol or negotiated during the connection establishment phase. Some protocols allow to change the maximum window size during the data transfer. We will explain these techniques with real protocols later.</source>
        <target></target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/reliability.rst</context>
          <context context-type="linenumber">879</context>
        </context-group>
      </trans-unit>
    </body>
  </file>
</xliff>
