Le simulateur HDLC (High-Level Data Link Control) 1

Le simulateur HDLC (High-Level Data Link Control) 1 Meriem Berkane et François Petitit encadrés par Mme S. Vial 13 mai 2005 1Travail d'etude et de Recherche, classe de Maîtrise Informatique, Université d'evry Val d'essonne

Chapitre 1 Présentation du projet 1.1 Le projet Le TER, proposé et encadré par Mme Vial, consistait à poursuivre un projet qui avait déjà été commencé l'an dernier par Sébastien Jobert et Dominique Pillou. Le but était de développer un logiciel permettant de simuler une session d'échanges de trames dans le cadre du protocole de réseaux HDLC, qui est un protocole de type 802.2 de la couche liaison de données. L'intérêt de ce sujet, était de mettre à la disposition des étudiants en réseaux, en particulier les étudiants en Licence Informatique, un outil pédagogique, pratique et clair, qui leur permettrait de se familiariser avec cette classe de protocoles, de faciliter la compréhension et l'assimilation de mécanismes souvent compliqués, et aussi de rendre les cours et les travaux pratiques concernant ce protocole plus pratiques et plus agréables. Nos objectifs dans le cadre de ce TER étaient donc les suivants : 1. étudier le protocole HDLC en détail, et essayer d'assimiler l'intégralité de ses fonctionnalités ; 2. En premier lieu, faire un travail d'étude et d'analyse du logiciel déjà réalisé, an d'apporter les améliorations nécessaires, et d'essayer d'achever le travail déjà commencé ; 3. Réaliser, dans la deuxième partie de ce TER, un véricateur de scénario, qui serait un outil pédagogique pour les étudiants et une véritable aide pour les professeurs lors de la correction des comptes rendus, car il permettrait aux étudiants et professeurs, de tester si leurs scénarios satisfont bien les normes HDLC. Les raisons qui nous ont poussées à choisir ce sujet, sont diverses : 1

Implémenter un protocole de réseaux n'est pas une chose facile, cela demande une grande phase de documentation et une étude approfondie des mécanismes de ce dernier. Pour nous, c'était une occasion intéressante de toucher à des domaines variés, que l'on allait forcément retrouver lors de nos futurs stages et emplois, tels que le conception et la gestion de projets, le génie logiciel, l'algorithmique avancée, les réseaux ainsi que le développement dans un langage objet. Nous avions réalisé lors de notre cursus universitaire, de nombreux projets, où nous devions répondre à des questions précises, et réaliser un travail bien précis et bien identié dès le départ. Dans ce TER, nous étions très attirés par la liberté d'action que nous avions. En eet, Mme. Vial a précisé lors de la présentation des sujets de TER, que nous étions susamment autonomes quant aux choix techniques et algorithmiques, et ceci à plusieurs niveaux, notamment le choix de nos outils et logiciels de travail, ainsi que la manière d'implémenter le protocole et de dénir l'interface entre l'utilisateur et le logiciel. Nous savions également, que nir un travail qui a déjà été commencé, par d'autres étudiants, qui ont leur façon de programmer, leur façon de penser, et une conception personnelle du protocole, qui est peut être diérente de la nôtre, ne serait certainement pas une chose facile, nous étions d'ailleurs le seul binôme à choisir ce sujet. Nous étions cependant, conscients que dans notre future vie active, nous allions peut être nous confronter à une situation identique, et que c'était un bon entraînement, et un bon dé à relever. Enn, étant très attirés par le domaine des réseaux (nous allons d'ailleurs, réaliser des stages dans ce domaine pendant les vacances d'été), développer ce logiciel nous permet d'approcher de plus près le domaine des réseaux, et de faire un premier pas pratique dans ce sens. Voilà donc les principales raisons qui nous ont poussées à choisir ce sujet. A présent, nous vous souhaitons une agréable lecture de ce rapport. 2

Chapitre 2 Le déroulement du projet 2.1 Documentation sur le protocole HDLC Comme nous l'avons expliqué dans le premier chapitre, la première étape de ce TER, était tout naturellement, la phase de documentation. Nous nous sommes donc plongés dans l'univers HDLC pendant les premières semaines du TER, et nous avons essayé de comprendre ses mécanismes et d'assimiler ses fonctionnalités, même les plus avancées. Nous allons dans cette partie, vous donner une dénition globale, concise et complète de ce protocole. 2.1.1 Généralités Le premier protocole de liaison réalisé par l'entreprise américaine IBM, pour son architecture SNA s'appelait SDLC (Synchronous Data Link Control). Le but de ce protocole, était de s'aranchir de deux principaux problèmes de communication entre machines locales ou distantes : 1. Les erreurs de transmission dûes aux perturbateurs ; 2. Le contrôle de ux entre machines ayant des débits diérents. SDLC était superieur aux autres protocoles alors existants de type envoyer et attendre qui génère des délais. Les organismes de normalisation intervinrent alors : 1. L'ANSI en t le ADCCP(Advanced Data Communication Procedure) ; 2. l'iso en t HDLC(High Level Data Control), entre 1980 et 1984. Le protocole HDLC(High Level Data Link Control) ou LAP-B issue de la norme ISO 8802,2 est, comme son nom l'indique, un protocole de haut niveau de la couche liaison de donées du modèle OSI. La couche liaison de données fait interface entre la couche physique et la couche réseau. Elles reçoit les données brutes sous forme de bits de la couche inférieure, les organise en trames appelées L-PDU(Link Protocol Data Unit) et gère l'envoi 3

de celles-ci jusqu'à une autre machine(connexion point à point). Cette gestion comprend : Un contrôle et une correction d'erreurs(vérication de la correction des données arrivées). Un système d'acquittement de messages ( L'émetteur peut ainsi savoir les quelles des trames envoyées ont été correctement reçues). Un contrôle de ot, lorsque la machine ne peut plus recevoir de trames, le transfert des données est ainsi gelé. Le protocole étudié, fait partie de la demi couche supérieure(llc -Logical Link Control-) de la couche liaison de donnée. Il assure l'envoi de messages entre 2 machines ou sites, c'est-à-dire que l'on doit s'assurer qu'ils arrivent bien, grâce à un système d'acquittement : soit sous forme de piggy backing, soit en envoyant un message d'acquittement. Une session HDLC se décompose en trois phases : 1. Connexion ; 2. Envoi/Réception de messages ; 3. Déconnexion. Nous allons maintenant voir les diérents types de trames. 2.1.2 Les diférents types de trames Voici le schéma d'une trame HDLC : Fig. 2.1 schéma d'une trame HDLC Les trames d'infomation Le champs commande de ce type de trames a la forme suivante : Fig. 2.2 champs contrôle d'une trame d'information 4

Le premier bit à gauche, positionné ici à 0, sert à identier ce type de trames comme étant des trames d'information. Le champ N(S) (codé sur 3 bits), correspond au numéro de la trame envoyée. Le champ P/F, correspond à un booléen, sa valeur est mise à vrai, si le site émetteur exige que le message émit soit acquitté dès sa réception, sa valeur est mise à faux dans le cas contraire. Le champ N(R) (codé sur 3 bits également), correspond au numéro de la prochaine trame attendue par le site émetteurau moment de l'envoi(ce champ est très utile pour les acquittements). Les trames de supervision Le champs commande de ce type de trames a la forme suivante : Fig. 2.3 champs contrôle d'une trame de supervision Ces trames ne contiennent pas de données à émettre, le champs données est donc vide ici, ce type de messages comprend 4 trames diérentes par leur utilité : RR : Receive And Ready : qui signie que le site émetteur a reçu toutes les trames ayant un numéro inférieur au numéro stocké dans le champs N(R), et qu'il est prêt à recevoir la prochaine trame ; RNR : Receive And Not Ready : qui signie que le site émetteur a reçu toutes les trames ayant un numéro inférieur au numéro stocké dans le champs N(R), mais qu'il souhaite geler la réception des messages, an de pouvoir gérer son ux, le site opposé devra donc attendre de recevoir un message RR, avant de pouvoir reprendre la communication avec ce site ; Les deux trames RR et RNR ont donc pour but, d'acquitter des trames, la diérence entre ces deux types de message, est que le premier permet de poursuivre le transfert des données, alors que le deuxième suspend temporairement l'envoi et la réception de messages ; REJ : REJect : qui signie que le site émetteur a reçu une ou plusieurs trames déséquencées(des trames non attendues), le champ N(R) ici, contient le numéro de la prochaine trame réellement attendue. Dans ce mode de reprise sur erreur, les messages non attendus(déséquencés) sont immédiatement détruits, et ne sont donc ni mémorisés, ni pris en compte ; 5

SREJ : Selective REJect : Dans ce cas aussi, le site émetteur a reçu une ou plusieurs trames déséquencées(des trames non attendues), mais la gestion de ces messages est diérente dans ce cas. En eet, le site émetteur du Srej, mémorise les messages déséquencées, et demande la réemission de messages manquants, il envoie donc un Srej par message manquant, le N(R) ici, comprend donc le numéro du message que ce site attend. Une fois que les messages manquants sont réceptionnés, les messages mémmorisés et mis en attente, sont immédiatement traités. Dans la pratique, le mode de reprise sur erreur le plus utilisé, est le REJ, le SREJ n'est utilisé, que dans des cas précis, où le risque qu'une trame soit perdue est inme, c'est le cas par exemple dans la transmission de données vers ou depuis des satellites. Là, la mémorisation des trames déséquencées s'avère très rentable, dans tous les autres cas, le REJ est très ecace. Les trames non numérotées : Le champs commande de ce type de trames a la forme suivante : Fig. 2.4 champs contrôle d'une trame non numérotée Il existe 4 types de trames non-numérotées : SABM : Set Asynchronous Balanced Mode, Cette trame correspond à une demande de connexion ; DISC : DISConnection, qui correspond à une demande de déconnexion ; UA : Unumbered Acknowledgement), qui correspond à une acceptation d'une connexion ou d'une déconnexion ; DM : Disconnected Mode, qui correspond au refus d'une connexion(qui est donc la suite de la réception d'une trame SABM). 2.1.3 Paramètres de connexion Avant d'entamer une session HDLC, les deux machines doivent se mettre d'accord sur un certain nombre de paramètres, avant de se connecter. Voici les principaux paramètres : T1 : La durée du timer out de réémission, qui correspond au délai maximum au delà duquel toute trame non acquittée sera réémise ; 6

T2 :La durée du timer out d'acquitement, qui correspond au délai maximum au delà duquel toute trame reçue doit être acquittée ; W :La taille de la fenêtre, c'est à dire le nombre maximum de messages qu'un site peut envoyer successivement, sans que aucune d'elles ne soit acquittée. Naturellement la taille de la fenêtre est égale à 8 au maximum(car elle est codée sur 3 bits) ; N1 : La taille maximum des données émises dans une trame d'information ; N2 :Le nombre maximum qu'une trame est réémise avant de considérer que la connexion avec le site opposée n'est plus valable ; Le mode de reprise sur erreur : REJ ou SREJ. 2.1.4 Détection des erreurs : HDLC appartient à une famille de protocoles orientés bits(donc sans notion de caractère), et utilise un mécanisme de détection d'erreurs de type CRC Contrôle de Redondance Cyclique. L'idée du CRC est de transmettre, conjointement avec les données signicatives, une valeur calculée par l'émetteur à partir des données à transmettre. Le récepteur eectue le même calcul de son côté, et si le résultat est identique, alors le message n'a pas été modié. Dans tout les autres cas, le message reçu est détruit, et il n'est donc pas pris en compte. Le calcul va utiliser une opération de base : la division des polynômes. HDLC, comme bien d'autres protocoles de la même famille, utilise le polynôme générateur du standard X25 comme polynôme générateur(diviseur). cette partie sera plus détaillée dans le chapitre Aspects techniques, où nous vous présenterons les outils binaires, et la détection des erreurs telle que nous l'avons réalisée. Notre présentation du protocole HDLC est à présent terminée, si vous désirez plus de documentation sur HDLC vous pouvez vous référer à l'annexe où nous avons mis à votre disposition une importante liste de documents et de liens qui nous ont été d'une aide considérable. Ces annexes peuvent être un excellent outil pour les étudiants utilisateurs de ce logiciel, car nous elles nous ont beaucoup appris nous-mêmes sur le protocole. 2.2 L'analyse du projet réalisé l'an dernier Après la phase de documentation, vient alors la phase d'étude et d'analyse des fonctionnalités et des bases de HDLCSim, logiciel réalisé par Dominique Pillou et Sébastien Jobert l'année dernière. 7

Nous tenons, avant de rendre compte de cette analyse, remercier Dominique et Sébastien, car leur conception du logiciel, et leur rapport, nous ont été d'une aide considérable, dans cette partie. Ils ont en eet facilité la compréhension de leur code source et détaillé leur travail dans le rapport qui nous a été remis par Mme. Vial. 2.2.1 Les fonctionnalités de HDLCSim Le choix d'un certain nombre de paramètres de connexion Le temps de traitement d'un message d'information ; Le temps de transmission d'un message d'information ; La taille de la fenêtre W ; Le nombre maximum de fois qu'un message d'information peut être réémis, N2 ; L'acquittement des messages, utilisant des trames RR ; La gestion des messages déséquencés, avec mode de reprise sur erreur REJ. L'envoi et la réception des messages L'envoi de messages d'information ; La gestion des messages déséquencés, avec mode de reprise sur erreur REJ. L'interface graphique Une fenêtre de saisie des paramètres de connexion ; Une fenêtre de saisie des choix des actions par l'utilisateur ; Une fenêtre pour l'achage du diagramme. 2.2.2 La conception de HDLCSim Après une longue phase d'étude et de test de HDLCSim, nous avons énuméré un certain nombre d'améliorations à apporter. La connexion et la déconnexion ne sont pas implémentées dans HDLCSim, en eet cette partie du protocole est simpliée dans HDLCSim. L'envoi des messages d'information se gère intérieurement par le logiciel, un certain nombre de choix de paramètres ne sont pas proposés à l'utilisateur, comme c'est le cas par exemple pour le champ N(s), le numéro de la trame d'information à envoyer, nous avons jugé ce choix peu pédagogique. 8

Plus en profondeur, nous avons remarqué que la gestion des acquittements et des réémissions telle qu'elle a été réalisée dans HDLCSim, n'est pas complètement dèle au protocole HDLC. En eet, la gestion des timerouts est faite intérieurement par le logiciel et n'est pas transparente pour l'utilisateur, puisque le logiciel gère toujours le premier timerout expirant, suivant l'ordre chronologique, ce qui ne se fait pas forcément dans HDLC (voir la partie aspects techniques). Là aussi nous avons trouvé ce choix peu pédagogique. Un certain nombre de scénarios provoquaient une sortie brutale du logiciel, nous avons pensé, qu'un achage adapté à l'erreur serait plus pédagogique, et plus instructif. Sans compter que cela provoque une perte de temps aux étudiants, car ils doivent relancer le logiciel et recommencer leur scénario, en cas d'erreur de frappe ou d'erreur de maladresse, l'étudiant ou l'utilisateur perd du temps avant de pouvoir corriger une simple erreur. Une partie des fonctionnalités de HDLC n'étaient pas implémentées, ou n'étaient pas gérées dèlement à HDLC, c'est le cas comme nous l'avons dit plus haut de la connexion, la déconnexion, mais aussi du mode de reprise sur erreur SREJ, et la gestion de la busy condition, suite à l'envoi d'un message RNR. Certaines fonctionnalités de l'interface graphique ne fonctionnaient pas correctement, comme la sauvegarde et le chargement des scénarios sauvés par exemple. Dans l'implémentation d'un protocole, il est important que l'interface graphique soit indépendante des bases du protocole. Dans HDLCSim, un grand nombre de choix de l'utilisateur sont contrôlées par l'interface graphique. En eet, si une action n'est pas faisable, le champ correspondant apparaît en gris(désactivé), l'utilisateur est donc très guidé dans sa démarche, ce qui n'est pas très pédagogique, puisque l'élève a besoin d'essayer des scénarios, et si les actions voulues ne sont pas possibles, un message d'erreur doit apparaître an qu'il comprenne la raison pour laquelle son action n'est pas valide. Le dernier point évoqué ici, est très important, car il met l'accent sur la stratégie d'implémentation et la conception de HDLCSim, nous nous sommes donc rendus compte, que nous n'avions pas la même perception du protocole. De plus, nous trouvions que le code de HDLCSim, bien qu'il soit clair et compréhensible, n'ore pas la possibilité d'évolution vers d'autres outils(comme un véricateur de scénario par exemple), et à partir de là nos objectifs ont changé. 9

Après concertation avec Mme. Vial, qui a suivi notre analyse, nous nous sommes xé les objectifs suivants : Implémenter le protocole en essayant d'être les plus dèles et les plus proches possible de HDLC ; Le logiciel se doit d'être pédagogique et intéractif, et doit donc orir plus de liberté et de choix d'actions à l'utilisateur ; Le code que nous produirons devra être facilement modiable, et évolutif vers un véricateur de scénario, où les étudiants et professeurs, rentreront leurs scénario, et le véricateur retournera le résultat de la vérication ; Nous avons enn, proposé à Mme.Vial de prendre en compte le protocole en entier, y compris la partie détection des erreurs de transmission lors du transfert des données binaires, et de mettre à la disposition des étudiants des outils pertinents, et pédagogiques, qui sont destinés à optimiser leur temps, et de rendre les cours et travaux dirigés plus agréables, et plus intéractifs. Le dernier objectif a été jugé un peu ambitieux par notre encadrante, qui nous a conseillé de le faire uniquement si nous avions du temps à la n, d'autant plus que les autres objectifs n'étaient pas faciles à atteindre, et nécessitaient une période de conception assez importante, et c'est ainsi que nous avons procédé. Ceci était donc la phase étude et analyse de HDLCSim, et les conclusions que nous avons tiré à partir de cette dernière. 2.3 L'implémentation de notre logiciel L'étude que nous avons réalisée dans le chapitre précédent, nous a montré l'importance de la conception du logiciel. En eet, nous devions rééchir à un moyen ecace, qui nous permettrait d'atteindre progressivement les objectifs dénis dans la partie précédente. Après une longue réexion, nous avons mis au point une stratégie qui, malgré sa complexité algorithmique, présentait des avantages multiples : Complète indépendance entre l'interface graphique et l'implémentation du protocole ; Facilité d'évolution et d'intégration de nouvelles fonctionnalités ; Clarté du code source ; Mais avant tout, des intérêts pédagogiques, ce qui est très important à nos yeux, car nous n'avons pas oublié que les premiers utilisateurs de notre logiciel, seront des étudiants. La solution que nous avons adopté est donc la suivante : 10

1. Pour chaque type de trame HDLC, dénir des conditions pour lesquelles une trame de ce type peut être envoyée et réceptionnée, c'est ce que nous avons appelé les algorithmes de vérication ; 2. Toute tentative d'envoi d'un message non valide(ne satisfaisant pas les fonctions de vérications), un achage adéquat est mis au point, an d'expliquer à l'étudiant la raison pour laquelle ce message est invalide, et donc pourquoi son scénario ne correspond pas à un scénario HDLC valide ; 3. Pour chaque trame envoyée, dénir le traitement adéquat. Cette solution(qui sera détaillée dans les parties Tests et Aspects techniques), est complexe algorithmiquement, car, comme nous l'avons expliqué plus haut, elle suppose une compréhension profonde des mécanismes d'hdlc, et une analyse détaillée des diérents scénarios possibles dans HDLC, même les plus subtils. Comme cette stratégie permettait une évolution souple du logiciel, nous avons implémenté des fonctionnalités et outils suplémentaires, qui ont rendu le logiciel plus confortable et plus agréable à utiliser. Ces fonctionnalités sont les suivantes : 1. Des outils binaires qui ont comme but, de faire gagner du temps aux étudiants, tout en garantissant une compréhension globale de la partie détection et correction des erreurs(voir les parties tests et aspects techniques ainsi que l'onglet Outils binaires) ; 2. Un bouton supprimer, qui a comme but, de permettre à l'étudiant de faire des tests multiples, sans hésiter et sans perte de temps, puisqu'il pourra revenir en arrière autant de fois qu'il le souhaitera ; 3. Notre simulateur a été facilement transformé en un véricateur de scénarios, grâce à cette technique d'implémentation(voir l'onglet véricateur) ; 4. Un onglet Diagramme, accompagné d'un bouton capturer, a été mis à la disposition des utilisateurs, étudiants ou professeurs, an de sauver leurs scénarios ; 5. Enn, nous avons pris en compte l'intégralité du protocole, puisque nous avons rajouté la vérication des messages en binaire, ce qui nous a donc permis d'atteindre nos objectifs(voir la partie tests et aspects techniques, ainsi que l'onglet simulateur) ; 6. Un système de sauvegarde et de chargement de scénarios a été réalisé l'année dernière, il ne fonctionnait pas parfaitement, mais nous avons réussi à le rendre opérationnel, et nous l'avons donc intégré à notre logiciel. Les étudiants pourront ainsi, en plus du bouton capturer de l'onglet Diagramme, sauver et recharger leurs scénarios ; 11

7. Comme tout logiciel, un onglet Aide, contenant une quantité importante d' informations sur le logiciel et sur le protocole, destiné à aider les utilisateurs en général, et les étudiants en particulier à mieux utiliser le logiciel, et à approfondir leurs connaissances. Dans la partie Tests, nous allons donc mettre à votre disposition, une série de scénarios et de captures d'écran, correspondant à des situations diverses et variées, et couvrant l'intégralité de notre travail, an de montrer comment la stratégie présentée plus haut, permet d'implémenter correctement HDLC. Dans la partie aspects techniques, nous allons vous donner de brefs descriptifs, et les points clés de notre implémentation. 12

Chapitre 3 Aspects techniques 3.1 L'implémentation du protocole La phase de conception a abouti à un choix dans la structure des objets manipulés(les classes). C'est ce point de recherche que nous allons vous présenter brièvement dans cette partie( voir le diagramme UML fourni). Dans la partie implémentation de notre logiciel, nous avons présenté la stratégie d'implémentation suivie, ainsi que ses avantages et sa complexité algorithmique. Nous allons ici, approfondir les points clés de cette stratégie, ainsi que les principales méthodes qui forment les piliers de notre logiciel. Commençons donc par une brève description des classes implémentées : 13

3.1.1 Diagramme UML Fig. 3.1 diagramme de classes du protocole 3.1.2 Présentation des classes La classe Evenement Cette superclasse représente tous les évènements d'un scénario. Un Evenement est caractérisé par trois attributs : La date : un entier positif représentant la date à laquelle il a lieu. Le site : Un caractère ('A' ou 'B') représentant le site ou la machine sur laquelle il se produit( ou encore l'émetteur lorsque l'évèneent est un message). Le type : une chaîne de caractères représentant les type de l'évènement( parmi (message ou TimerOut ). Cette classe a deux sous classes, la classe Message et la classe TimerOut. 14

La classe Message En plus des attributs de la classe Evenement dont elle hérite, elle est caractérisée par les attributs suivants : correctmessage : un booléen déterminant si le message arrive correctement, ou s'il est perdu pendant la transmission. BinaireCorrect : un booléen, qui détermine(en cas d'envoi de messages binaires), si ce message est reçu correctement du point de vue binaire(voir la partie traduction de messages, dans l'implémentation des outils binaires). PF : un caractère : 'P' ou 'F' ou 0, représentant le bit P/F d'un message. TpsTransm : un entier positif, représentant le temps que mettra un message pour arriver(s'il arrive corrextement). TypeMessage : une chaîne de caractère, représentant le type du message envoyé, cette chaîne est choisie parmi les suivantes :SABM, UA, DM, DISC, INFO, REJ, SREJ, RR, RNR. Nous avons fait correspondre à chaque type de message présenté ci-dessus, une classe spécique, qui, naturellement, hérite des attributs de la classe Message( et donc de la classe Evenement également). La classe SABM Comme nous l'avons décrit dans le deuxime chapitre(partie documentation), ce type de message correspond à une demande de connexion. Cette classe ne contient que les attributs hérités de la classe Message. La classe DISC En opposition au type de message précedent, les messages DISC représentent une demande de déconnexion, et comme pour les messages SABM, ils n'ont comme attributs, que leur héritage. La classe UA Comme nous l'avons décrit dans le deuxime chapitre(partie documentation), ce type de message correspond à une acceptation de connexion ou de déconnexion. Cette classe ne contient que les attributs hérités de la classe Message. La classe DM ce type de message correspond à une acceptation de connexion. Cette classe ne contient que les attributs hérités de la classe Message. La classe messageinfo La classe messageinfo, représente les messages d'information. En plus des attributs de la classe message, cette classe est caractérisée par les champs suivants : info : un tableau de bits(0 ou 1 ), représentant les données à transmettre. Ns : un entier positif, représentant le numéro de la trame envoyée. 15

Nr : un entier positif représentant le numéro de la prochaine trame reçue. Cet entier est utilisé dans la procédure d'acquittement par Piggy Backing, où les messages de type Info servent d'aquittement. La classe rej En plus des attributs de la classe Message, cette classe bénécie du champ Nr, qui représente le numéro de la première trame à réemettre(en cas de trames arrivées déséquencées). Comme pour les messages de type Info, ce champ sert également à acquitter les messages envoyés, ayant un numéro de trames inférieur à ce Nr. La classe srej Comme pour la classe rej, cette classe bénécie du champ Nr. En revanche, sa signication est quelque peu diérente ici. En eet, le Nr ici, représente le numéro de la trame à réemettre, et non forcément la première, car comme nous l'avons déjà expliqué dans la partie documentation, dans ce mode de reprise sur erreur, le récepteur des messages déséquencés, mémorise ces mesages reçus, et émet un Srej par message manquant. Ici aussi, ce champ sert également à acquitter les messages envoyés, ayant un numéro de trames inférieur à ce Nr. La classe Rr Les messages Rr, sont des messages de supervision servant dans le cas du contrôle de ux. En eet, ils servent à acquitter des messages, dans la mesure où l'émetteur du Rr n'a pas de messages d'information à émettre an d'acquitter par le Piggy Backing. Le champ Nr de cette classe a la même signication que celui de la classe messageinfo. La classe Rnr Les messages Rnr, sont également des messages de supervision servant dans le cas du contrôle de ux. En eet, ils servent à acquitter des messages, dans la mesure où l'émetteur du Rnr n'a pas de messages d'information à émettre an d'acquitter par le Piggy Backing. La diérence entre les messages de type Rr et Rnr, est que l'envoi d'un Rnr conduit à ce qu'on appelle une busy condition, qui signie que ce site est dans l'impossibilité de gérer le ux de messages qui lui arrive par cette connexion. La n d'une busy condition, est marquée par l'envoi d'un message Rr par le site initiateur de la busy condition. Le champ Nr de cette classe a la même signication que celui de la classe messageinfo. La classe TimerOut Cette classe, en plus des attributs de la classe Evenement, est caractérisée par deux attributs : 16

indiceliste : un entier positif qui représente l'indice dans la liste des évènements d'un scénario, du message qui a provoqué son insertion dans la liste, cette dénition est valable pour les timerout de réemission(r), d'acquittement(a), et de traitement des messages déséquensés(s). En revanche pour les timerout de traitement d'un Rej ou d'un Srej(T), cet entier représente le numéro de la trame à réemettre. ReemAcq : c'est un caractère dénissant le type du timerout parmi : R pour réemission, A pour Acquittement, S pour les messages de supervision Rej et Srej, car ce timerout représente la durée avant laquelle un site doit émettre un rej ou un srej(selon le mode choisi initialement). Et enn, T pour traitement du Rej ou du Srej reçu. En eet ce timerout représente la durée avant laquelle le site récepteur d'un Rej ou un Srej, doit envoyer le message correspondant. La classe listeevenements Cette liste est notre objet principal, car elle contient toutes les actions eectuées par les deux sites, elle est triée par ordre chronologique, et découpée en deux parties : La partie des messages, et la partie des timerouts. Ces deux parties sont accessibles grâce à un attribut de cette classe, qui est indicetimer, représentant l'indice du premier TimerOut gurant dans cette liste ( séparant dynamiquement la partie messages de la partie TimerOuts). La classe scénario Cette classe est le coeur de notre logiciel, car c'est dans cette dernière que le déroulement d'un scénario s' eectue réellement. Les attributs de cette classe sont les suivants : Les attributs xes : les paramètres de conexion TailleFenMax : la taille de la fenêtre (W). TailleMaxDonnees :La taille maximale des données (N2). RejOuSrej : un caractère qui représente le mode de reprise sur erreur choisi par l'utilisateur : R pour Rej et S pour Srej. DureeTimerAcq : la durée d'un timerout d'acquittement. DureeTimerReem : la durée d'un timerout de réemission. Les attributs évoluant durant le scénario datecourante : un entier positif représentant la date à laquelle le dernier message a été envoyé. DatePhaseTransfertA (et B) : représente la date à laquelle le site A(respectivement B) a été considéré comme connecté. DernierMessageEnvoyeA (et B) :représente le numéro du dernier message envoyé par le site A(respectivement B). DernierMessageRecuA (et B) :représente le numéro du dernier message reçu par le site A(respectivement B). 17

DernierMessageAcqA (et B) :représente le numéro du dernier message pour lequel le site A(respectivement B) a reçu un acquittement. 3.1.3 Les algorithmes clés Nous allons ici vous présenter de façon très brève les 3 principales catégories d'algorithmes que nous avons élaborés pour l'implémentation du protocole HDLC. Les algorithmes de vérication de messages Nous avons créé pour chaque type de messages, une fonction de vérication (appelées verifinfo, verifsabm, etc.) qui déterminent suivant l'état actuel d'un scénario, si l'envoi d'un message déni par l'utilisateur est cohérent dans le cadre du protocole HDLC. Dans le cas où un message est considéré incohérent, la fonction renvoie un message expliquant les raisons de ce refus. Ce qui est très utile du point de vue pédagogique. Cette solution est assez compliquée algorithmiquement car il faut prendre en compte toutes les possibilités permises par HDLC, même les plus subtiles. Par exemple, pour verier qu'un message de type INFO peut être envoyé, il faut s'assurer que l'on n'est pas à cette date en "busy condition", qu'on n'ait pas à gérer de messages déséquencés à cette date là, qu'on ne dépasse pas un timerout, etc. Sans compter les vérications de bases (que la date d'envoi soit supérieure ou égale à la date courante, que ce site n'a pas déjà envoyé un message à cette date là, etc.). Les algorithmes d'ajout de messages Lorsque la vérication d'un message est positive, il faut l'ajouter au scénario. Un traitement particulier doit être réalisé pour chaque type de message. Il existe donc de même une fonction d'ajout pour chaque type de message (appelées ajoutinfo, ajoutrej, etc.). Ces fonctions constituent une implémentation rigoureuse au détail près du protocole. Les algorithmes de calcul et de mise-à-jour des attributs évolutifs Certaines proriétés d'un scénario ne peuvent être gérées par des variables. Il est nécessaire de les calculer à chaque fois que l'on en a besoin. C'est le cas pour l'attribut "dernier message reçu" de la classe scénario. Par exemple, dans le cas représenté par ce diagramme, si B veut envoyer un message INFO à la date entourée en rouge, le champs N(R) du message info ne doit pas prendre le message INFO envoyé par A, ayant été reçu par B après l'envoi de son message. On ne peut donc pas se contenter de mettre 18

à jour la variable du dernier message reçu par un site lors de la réception d'un message. Il a donc fallu créer un algorithme (une méthode) de calcul de dernier message reçu. Cela s'applique également pour le dernier message acquitté. En revanche, le dernier message envoyé se gère aisément avec une variable. La principale diculté dans ces algorithmes a été la gestion des messages déséquencés, puisqu'ils ne doivent pas être comptés comme messages reçus, mais plutôt insérés dans des listes d'attente dans le cas d'un mode SREJ ou détruits dans le cas d'un mode REJ. De même, un message reçu lors d'une busy condition ne doit pas être pris en compte. (voir la partie "tests"). 19

3.2 L'implémentation de l'interface Fig. 3.2 diagramme de classes de l'interface présentation L'interface a été conçue pour être la plus complète et simple d'utilisation possible. Le logiciel développé l'an dernier orait une interface composée de nombreuses fenêtres "pop-up", qui s'ouvraient momentanément pour l'envoi d'un message ou la gestion des paramètres par exemple. De même, le diagramme possédait sa propre fenêtre. Nous trouvions cela peu pratique et avons préféré créer une fenêtre globale qui contiendrait tout ce que nous voudrions acher. swing L'interface a été programmée avec les bibliothèques Swing/AWT de java. Nous avons utilisé 7 classes dont nous allons maintenant donner une description de leur rôle et de leur contenu. 20

3.2.1 La classe autreinterface La classe "autreinterface" est la classe la plus importante. Elle contient tout d'abord les dénitions des fenêtres composant la fenêtre principale. C'est dans cette classe que sont collectées les informations sur les actions de l'utilisateur. C'est donc elle qui est chargée d'exécuter les bonnes fonctions avec les bons arguments, et c'est aussi elle qui va créer les messages et les scénarios entrés par l'utilisateur. Cette classe dénit des "panneaux" (l'objet "JPanel" en Java), c'est-à-dire une partie de la fenêtre de chaque onglet, pour y greer les diagrammes des scénarios, contenus dans la classe "fengraphe. 3.2.2 Les classes fengraphe, diagrammehdlc et Arrow Nous avons repris ces classes créées (fengraphe et diagrammehdlc) ou utilisées (Arrow) par les étudiants de l'an dernier pour l'achage d'un scénario HDLC au moyen d'un datagramme. Ces classe convenant parfaitement à nos besoins, nous les avons incorporées à notre interface en y apportant de très légères retouches, pour qu'elles soient compatibles avec nos propres scénarios. La classe fengraphe contient le dessin du diagramme ainsi que l'échelle et le bouton permettant de la manipuler. La classe diagrammehdlc permet de dessiner le diagramme, et la classe Arrow sert à dessiner les èches représentant les messages. 3.2.3 Les classe demarrage,fermeture et auteurs Ces trois classes ont été créées pour égayer un peu le logiciel et apporter des informations complémentaires (courrier électronique des auteurs, nom de l'université, etc.). 3.3 L'implémentation des outils binaires Les outils binaires sont implémentés dans la classe Binaire. Il y a 2 grands points dans ces outils : 1. la "traduction" d'une trame binaire, c'est-à-dire une suite de 1 et de 0, en un message tel que nous les utilisons dans les scénarios. 2. la division polynomiale, utilisée pour savoir si une trame a été correctement transmise, grâce au champs FCS, comme expliqué dans la partie de documentation sur HDLC. 21

Nous allons vous présenter maintenant comment ont été réalisés ces 2 outils. 3.3.1 La traduction de message Nous avons vu que les trames HDLC sont composées de 6 champs : fanion début, adresse, commande, données (parfois vide, quand ce n'est pas une trame d'information), FCS et fanion n. Voici comment nous déterminons les attributs d'un message : l'émetteur : si le champs adresse est égal à 11000000 alors l'émetteur est A, s'il est égal à 10000000 alors c'est B le type : Il se déduit de certains bit du champs commande. Voici la table de correspondance : n de bit : 01234567 sabm 1111p110 ua 1100p110 dm 1111p000 disc 1111p010 rej 1001p*** srej 1011p*** rr 1000p*** rnr 1010p*** info 0"""p*** Fig. 3.3 Table de traduction des trames 'p' représente le bit P/F. Si p=1 alors le bit P/F de la trame est positionné, sinon il ne l'est pas. *** représente le champs N(R) des trames. On met donc la valeur N(R) des trames à la valeur décimale de ce champs. """ représente le champs N(S) des trames de type INFO. On met donc de même la valeur N(S) des trames INFO à la valeur décimale de ce champs. l'attribut "correctbinaire" des trames dépend de 4 facteurs qui doivent tous être vrais : 1. Les fanions de début et de n doivent impérativement être égaux à 01111110. 2. Le message doit être traduisible. C'est-à-dire que les valeurs du champs adresse doivent représenter le site A (11000000) ou le site B(10000000) et le champs commande doit représenter un type de message existant. 22

3. La taille des données doit être égale à 0 si ce n'est pas une trame d'informations, ou strictement inférieure à la taille maximale des données choisie dans le scénario. Remarquons que, pour des raisons de simplicité d'utilisation, nous avons choisi de ne pas prendre en compte ce paramètre dans l'utilisation de l'onglet des outils binaires (il a été xé à 10000), mais il est très facilement changeable dans le code. 4. On fait la division polynomiale du champs données + du champs FCS par la représentation binaire du polynome choisit pour le logiciel : 1000010000001000. On compare le reste de la division avec le champs FCS de la trame. Les 2 doivent être égaux (c'est-àdire les mêmes bit par bit) pour que la valeur de "correctbinaire" soit mise à "vrai". Sinon elle est mise à "faux". 3.3.2 La division polynomiale Nous avons tout d'abord voulu utiliser l'algorithme de calcul du CRC-16, contenu dans une libraire de Java, mais nous avons préféré ensuite implémenter l'algorithme générale de la division polynomiale. En eet, l'algorithme de CRC-16 ne permet que de faire la division par des polynomes de degré 16. Cela aurait bien convenu à HDLC, mais était moins intéressant pour les étudiants qui utilisent plus souvent des polynomes plus petits pour leurs exercices. Notre algorithme est l'implémentation de la manière de calculer que nous avons apprise en licence. Nous avons programmé la fonction intermédiaire ouexclusif qui, appliquée sur 2 tableaux T1 et T2, renvoie un tableau T3 suivant l'opération T3 = T1 xor T2/ Voici le pseudo-code de la division polynomiale, qui renvoie le reste de la division : 23

int[] divisionpolynomiale(int[] dividende, int[] diviseur) { int[] res = int[diviseur.length - 1]; int[] tabtemp = int[diviseur.length]; for (j = 0; j < diviseur.length; j++) { tabtemp[j] = dividende[j]; } for (i = 0; i < dividende.length - diviseur.length; i++) { /* si le premier bit à gauche du dividende est 1 on fait un XOR entre le dividende et le diviseur et on recolle avec les bits de droite du dividende */ if (tabtemp[0] == 1) { tabtemp = ouexclusif(tabtemp, diviseur); for (j = 0; j < diviseur.length - 1; j++) { tabtemp[j] = tabtemp[j + 1]; } } /* si le premier bit à gauche du dividende est 0 on passe d la suite */ else { for (j = 0; j < diviseur.length - 1; j++) { tabtemp[j] = tabtemp[j + 1]; } } tabtemp[diviseur.length - 1] = dividende[i + diviseur.length] for (j = 0; j < diviseur.length; j++) { } } /* la dernière itération : si le reste est supérieur au diviseur on divise une fois de plus */ if (tabtemp[0] == 1) { tabtemp = ouexclusif(tabtemp, diviseur); } else { for (j = 0; j < diviseur.length - 1; j++) { tabtemp[j] = tabtemp[j + 1]; } } /* on renvoie le résultat */ return tabtemp; } 24

Chapitre 4 Mode d'emploi du logiciel 4.1 La barre de menu Fig. 4.1 la barre de menu La barre de menu ore les fonctions suivantes : 1. Le bouton "Scénario" : nouveau scénario (remise à zéro du scénario courant) sauvegarde et chargement de scénario fermeture du logiciel 2. Le bouton "Astuces" : la capture de diagramme 3. Le bouton "Aide" : l'aide pour le logiciel et pour le protocole 4. Le bouton "A-propos" : une fenêtre présentant les le logiciel et les auteurs 25

4.2 L'onglet du simulateur Fig. 4.2 l'onglet du simulateur L'utilisateur entre tout d'abord les paramètres du scénario dans le cadre en haut à gauche, puis valide en cliquant sur "charger paramètres". Ensuite, Fig. 4.3 le réglages des paramètres il peut envoyer des trames avec les boutons du milieu, qui lui permettent de 26

choisir les paramètres de ces trames : type, émetteur, date d'envoi, temps de transmission, bit P/F placé ou non, numéro de trame d'information, et de préciser si la trame arrive bien à destination, ou s'il est perdu. Il peut aussi Fig. 4.4 l'envoi d'un message envoyer une trame binaire. Il doit rentrer la trame envoyée par le site et celle reçue par l'utilisateur. Cela permet de simuler les erreurs de transmission, et donc d'utiliser le FCS pour vérier la correction d'un message. Fig. 4.5 l'envoi d'un message binaire Le diagramme, en haut à droite, représente les trames envoyées et les timers actifs pour chacun des deux sites, et la date courante (correspondant à la date d'envoi de la dernière trame envoyée). La fenêtre de texte déroulant en bas à droite ache les paramètres de la connexion, ainsi que la liste des trames déjà émises. Elle pourra également acher des messages pour aider l'utilisateur, par exemple des messages lui précisant la raison pour laquelle une trame qu'il a voulu envoyer a été refusée. Cela agira en quelque sorte comme un interpréteur de commandes. 27

Chose très pratique, on peut annuler le dernier message envoyé, et ainsi revenir en arrière dans le scénario autant de fois que l'on veut, grâce au bouton "Annuler", en bas à gauche. 4.3 L'onglet du véricateur Fig. 4.6 l'onglet du véricateur L'utilisation du véricateur est semblable à celle du simulateur, sauf qu'ici les trames ne sont pas vériées. L'utilisateur peut demander la vérication de son scénario à n'importe quel moment, en cliquant sur le bouton "vérier le scénario", en bas à droite. 28

Le cadre de texte déroulant ache alors le résultat de la vérication, c'està-dire si le scénario est correct ou s'il y a des erreurs. 29

4.4 L'onglet du diagramme Fig. 4.7 l'onglet du diagramme L'onglet du diagramme permet d'avoir un diagramme du scénario plus grand que celui gurant dans l'onglet du simulateur. Il permet également de faire un capture du diagramme. Celui-ci sera sauvé au format.jpeg, sous le nom et dans le répertoire choisi par l'utilisateur. 30

4.5 L'onglet des outils binaires Fig. 4.8 l'onglet des outils binaires L'onglet des outils binaires comporte deux parties : le traducteur de message binaire : l'utilisateur tape un message codé en binaire, le logiciel lui renvoie la décomposition en champs du message, et le décodage de ce message, c'est-à-dire son type, son émetteur, le bit P/F placé ou non, les champs NS et NR si c'est un message info. la division polynomiale : divise un polynôme écrit sous forme binaire (par exemple x5 + x2 s'écrira 100100) par un polynôme de degré 15 ou 16 écrit sous forme binaire également(par exemple, x16 + x11 + x3 (1000010000001000 en binaire) est utilisé par la norme X25 européenne, x16 + x12 + x5 + 1 (10001000000100001) par le CCITT). Signalons-là un cas très important :le polynôme diviseur doit toujours être de 16 bit. Par conséquent, le polynôme utilisé par X25 s'écrira 0001000000100001. 31

Dans le protocole HDLC,le polynôme générateur a pour degré 15 ou 16. Exemple de division polynomiale : x23 + x21 + x14 par x16 + x12 + x5 + 1. Il faut rentrer les polynômes en notation binaire, ici cela donne 101000000100000000000000 divisé par 10001000000100001. Le résultat sera : 11110101111010100, c'est-à-dire : x16 +x15 + x14 + x13 + x11 + x9 + x8 + x7 + x6 + x4 + x2. Le résultat est la valeur du FCS du message. 32

4.6 L'onglet de l'aide Fig. 4.9 l'onglet de l'aide Cet onglet fournit à l'utilisateur le mode d'emploi du logiciel, ainsi qu'une aide sur le protocole HDLC. Cele est très utile étant donné le but pédagogique du logiciel, qui doit servir à des étudiants qui apprennent ce protocole. Il permet d'avoir tous les documents utiles "sous la main". 33

Chapitre 5 jeux de test 5.1 Exemples de scénarios La connexion Comme nous l'avons déjà expliqué, une session HDLC commence toujours par une phase de connexion. Nous allons dans cette section, vous montrer que notre logiciel simule correctement la connexion, telle qu'elle se passe réellement. Dans HDLC, un site souhaitant commencer une phase de transfert de données avec un autre site, doit envoyer un message SABM. Le site récepteur, doit alors répondre positivement en envoyant un message UA, ou négativement en envoyant un message DM. Voici une série d'exemples de scénarios de connexion possibles : 1 - Un scénario simple pour commencer : Le site A envoie un message SABM à B, un timerout de type R(réémission) est alors chargé au niveau du site A( la demi ligne verte en pointillés). Le site B reçoit correctement cette demande de connexion, il charge donc un timerout de type A (Acquittement), avant lequel ce message doit être traité. Dans ce scénario, B répond positivement, en envoyant un message UA, et se considère connecté. A à son tour, dès réception du message UA, il se considère connecté. Si B décide de répondre négativement, les deux sites restent déconnectés. 34

2 - SABM perdu : Imaginons le cas suivant : A envoie un SABM, mais ce dernier est perdu(ce qui explique la demi èche). A charge un timerout de réémission. Quand le timerout de réémission que A a chargé expire, A est contraint de réémettre le message SABM. 3 - UA perdu : Imaginons le cas suivant : A envoie un message SABM, ce dernier arrive correctement, B répond positivement ou négativement(ce n'est pas important dans ce cas), mais ce message de réponse est perdu. Dans ce cas, B ne réémet pas le message de réponse envoyé(il n'y a pas de timerout de réémission chargé à la suite d'un envoi d'un message UA ou DM) ; En revanche, A ne recevant pas de réponse avant l'expiration du timerout de type R(chargé au niveau de A), il est contraint de réemettre le message SABM. 35

4 - Les deux sites envoient des demandes de connexion : 5 - Dans le scénario ci-dessus, les deux sites envoient une demande de connexion( cela est possible, car aucun d'eux n'aura reçu la demande du site opposé). Chacun d'eux, aura donc à répondre, à la demande de connexion du site opposé : Un certain nombre d'actions, ne sont bien évidemment pas tolérés. Si un message numéroté (autre que SABM, UA, DM et DISC) veut être envoyé alors que le site émetteur n'est pas connecté, le logiciel ache un message d'erreur : 36

Nous ne détaillerons pas tous les messages d'erreur, étant donné le grand nombre d'erreurs possibles. La phase de tranfert de données Le piggybacking Le piggybacking étant un point intéressant de HDLC, nous allons détailler un scénario l'illustrant : Après une connexion classique, B envoie un message INFO a A : On remarque les timers ajoutés, notamment celui de réémission pour B à la date 49. Celui-ci ne peut s'enlever que si A acquitte cette trame INFO. Cela ne pouvait se faire que grâce à l'envoi par A d'une trame REJ, SREJ, RR ou RNR. Or en réalité la plupart des messages sont acquittés avec des trames INFO grâce au mécanisme de piggybacking. Voici comment cela se passe : A envoie un message INFO à B : 37

La réception de ce message a supprimé le timer de ré-émission du site B. La reprise sur erreurs Dans le cas du mode de reprise sur erreur REJ, lorsque le site B reçoit un message INFO déséquencé (gure ci-dessous), il va envoyer immédiatement à l'émetteur un message REJ ayant comme champs N(R) le numéro de la trame attendue. La trame reçue déséquencée sera immédiatement détruite. Dans le cas du SREJ, prenons l'exemple où 2 messages de N(S) 0 et 1 ont été perdus et Le site reçoit la trame de N(S) 2 : 2 timersout de type S sont insérés. Le site va alors émettre 2 SREJ et l'émetteur va réémettre les 2 trames perdues : Maintenant, le site A va reprendre l'envoi de message INFO à-partir de la trame de N(S)=3, car la trame reçue déséquencée a été prise en compte par B : 38

Si A avait envoyé une quatrième trame avant de réemettre les trames perdues, B n'aurait toujours eu que deux messages SREJ à émettre, comme l'illustre la gure suivante : 39

La busy condition La busy condition débute quand un site n'arrive plus à gérer son ux et envoie une trame RNR. Par exemple ici B envoie un message RNR : A va envoyer une trame INFO avant d'avoir reçu le RNR. Mais B ne va pas le traiter : En eet, il n'y a pas de timer d'acquittement sur le site B. Pour arrêter la busy condition, le site B devra émettre une trame RR. Bien entendu, les trames RNR et RR servent aussi à acquitter des messages reçus. Quelques cas subtils et points de recherche Le premier test subtil que nous allons vous présenter concerne la situation suivante : Après la phase de déconnexion, A envoie un message de type Info de numéro 0, à la date 9, qui arrive correctement, comme vous voyez sur le diagramme suivant : 40

Ensuite, A envoie un deuxième message d'informatio(ns =1) : B envoie maintenant un message de type RNR à la date 35, avant la date de réception du deuxième message envoyé par A, ce qui entraînera le début d'une busy condition : Remarquez ici, que le début de la busy condition, a entraîné la suppression du timer d'acquittement au niveau de B concernant le dernier message reçu de la part de A, non pas parce qu'il l'a acquitté en envoyant le message RNR, bien au contraire, puisque on remarque toujours le timer de type réemission au niveau du site A, mais parce que la date de réception de ce message, est supérieure à la date d'envoi du message RNR(bien que le message de type Info ait été inséré avant le message RNR). Ce scénario, permet de montrer que l'ordre dans le quel l'utilisateur rentre ses messages(valides), n'inut pas le traitement eectué, et que notre logiciel, simule dèlement le protocole HDLC. Un deuxième cas à la fois subtil, et curieux dans HDLC est le suivant : Pour cela, il faut que la durée d'un timer out d'acquittement soit la même que celle d'un timer out de réémission(dans l'exemple elle est mise à 40). 41

Après la phase de connexion, A envoie un message de type Info : Dans cette conguration, il est impossible pour B d'envoyer un message de type RR ou de type RNR! La raison est simple, suposons que B veuille acquitter le message reçu par un message de type RR ou de type RNR. Il faudrait donc envoyer un message RR ou RNR à la date à laquelle le timer d'acquittement est chargé(dans l'exemple à la date 58). Cela est impossible, car dans ce cas, on aurait dépassé le timer out de type réémission, il faudra donc réemettre le message avant. Et ce scénario se répètera jusqu'à ce que le nombre maximum de réémission d'un message soit atteint, ou que B envoie un message de type information permettant l'acquittement par piggybacking. Ce scénario est très intéressant, car il met l'accent sur un détail important dans HDLC : le rapport entre la durée du timerout d'acquittement, la durée du timerout de réemission, et la durée du temps de transmission d'un message. Certaines version de HDLC se servent du temps moyen de transmission d'un message, an de xer à l'avance les durées de ces timers, mais dans notre logiciel, nous avons pensé qu'il était plus instructif et plus pédagogique, de permettre aux étudiants de jouer avec le logiciel, en essayant des valeurs diérentes de ces durées, et de déduire par eux-mêmes la relation entre ces paramètres. La déconnexion Les mécanismes de déconnexion sont similaires à ceux de la connexion, à la diérence près que le site récepteur du message DISC, ne peut envoyer qu'un message de type UA(ne peut que accepter la déconnexion). 5.2 Exemples d'envois de messages binaires Nous détaillons dans les exemples d'utilisation des outils binaires des exemples de messages binaires, mais nous voulons ici montrer un exemple très intéressant car il met à jour les limites du protocole HDLC. Le cas est le suivant : 42

Un site envoie une trame INFO à un autre. Comme nous l'avons vu, le site qui reçoit la trame vérie l'intégrité des données en calculant la division polynomiale des champs données + FCS par le polynome choisi par les 2 sites (par exemple celui de la norme X25), et en comparant ce résultat avec le FCS. S'ils sont égaux, alors le message est traité. Or si les données de la trame envoyée ont été modiées pendant le transport, mais que le résultat de la division polynomiale est bien égal au FCS, alors le message sera considéré comme correct et bien traité. Bien qu'il soit en réalité incorrect. C'est le cas lors de l'envoi de ces trames : 0111111011000000000010001000010000001000000000000000000001111110 0111111011000000000010000000000000000000000000000000000001111110 Fig. 5.1 exemple illustrant les limites d'hdlc en terme de détection d'erreurs Le timer d'acquittement du site B, entouré au milieu prouve que le message envoyé a bien été traité. Nous avons cependant pu voir dans de nombreux documents qu'une telle possibilité est quasi-impossible, car le nombre d'erreurs exigée est bien trop grand par-rapport à la réalité. 43

5.3 Exemples d'utilisation des outils binaires Voici des exemples de trames à rentrer en binaire et leur traduction : On a Fig. 5.2 traduction d'une trame binaire traduit la trame binaire : 011111100000000011110110000000000000000001111110. La première partie du cadre nous donne la décomposition en champs de la trame binaire. Cela est très pratique car, s'il y a une erreur, on peut tout de suite voir d'où vient le problème. Remarquons que le champs données est vide. En eet, seul les trames d'information peuvent contenir des données. Ici c'est une trame SABM. Cette trame est donc une trame de type SABM, grâce à la valeur 11110110 du champs commande, émise par B, grâce à la valeur 00000000 du champs adresse. Nous avons xé arbitrairement car nous n'avions pas le choix le champs adresse à 00000000 pour A et 00000001 pour B. L'adresse étant celle du destinataire, l'émetteur est l'autre site. La trame est correcte. La valeur du champs ayant été expliquée dans la partie "aspects techniques". 5.3.1 Exemples de messages binaires Voici une liste non exhaustive de trames binaires avec leur traduction, que nous avons utilisées pour tester le logiciel. Cela s'avère très pratique d'avoir une liste de trames à disposition, car l'écriture est assez fastidieuse. 44