Ch1

317 vues

Publié le

0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
317
Sur SlideShare
0
Issues des intégrations
0
Intégrations
4
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • 2. => prof et discipline informatique : important même si pas spécifiquement télécom. Car le logiciel est de plus en plus présent => maîtriser le développement d'un système (par exemple télécom) nécessite aussi et parfois surtout de maîtriser le développement de son logiciel => important d'être sensibilisé à ce problème, à ce que l'on appelle la crise du logiciel => si un jour vous êtes chefs de projet, on vous demandera de suivre les règles de l'ingénierie système => dans la même lignée que les cours UML et JAVA 3. Attention : cours abstrait et difficile, nécessairement un peu verbeux. Ma tâche est difficile : vous justifier l'existence de la discipline du génie système et en particulier génie logiciel, avec ses règles alors que vous n'avez pas encore été confronté au problème. 4. En pratique : exam à la fin du cours (scéances de TD + exos en cours). Support de cours = transparents.
  • Total software - 100,000 lines (“small”) Very good software process
  • Highlighted three main aspects we shall study: modeling, specifications, and algorithms
  • Ch1

    1. 1. 1Ingénierie des protocoles decommunicationHaykal TejInst. Sup. d’Informatique et des TechnologiesdeCommunication, Hammam SousseUniversité de Soussehtej@gmx.de
    2. 2. 2Chapitre 1Généralités sur les protocoles etles méthodes de génie deprotocoles
    3. 3. Préambule Un protocole est un ensemble de règles qui gouvernent linteractionentre processus parallèles dans les systèmes distribués La conception de protocoles nest pas une discipline à part, elle est liéeà la fois aux réseaux et à lingénierie des systèmes Décrire complètement et sans ambiguïté un protocole est difficile Prouver quun protocole est correct est une tâche encore plus ardue=> Le but du cours nest pas denseigner de nouveaux protocoles, mais demontrer comment on peut (bien) les décrireProtocoles de communication…
    4. 4. Autopsie dun accident…Accident du tunnel de Clayton, 1861 un train peut entrer dans le tunnel si le sémaphore est vert en passant le sémaphore, le train le met au rouge automatiquement ; en cas de défaillance dusystème, cest lopérateur qui agite un drapeau rouge cest lopérateur qui remet le sémaphore au vert quand il est sur que le train a quitter le tunnel deux télégraphes permettent aux opérateurs de séchanger quelques messages « Train in tunnel » « Tunnel is clear » Pour plus de sécurité, un 3è message est prévu : "Has the train left the tunnel?"AB
    5. 5. Autopsie dun accident…Accident du tunnel de Clayton, 1861 : ce qui sest passé Un train passe le sémaphore A (vert), mais le sémaphore ne passe pas au rouge. Lopérateur réagit : il envoie le message "Train in tunnel" et agite un drapeau rougepour arrêter les trains suivants. Cependant, un 2è train est arrivé trop vite et est passé au vert. Heureusement, le conducteur a entrevu le drapeau rouge in extremis. Un 3è train arrive et sarrête Lopérateur envoie à nouveau le signal "Train in tunnel" pour avertir lautre quil y a 2trains dans le tunnel. Le protocole na pas prévu ce cas. Le problème pour lopérateur A est maintenant de savoir quand les deux trains ontquitté le tunnel afin dautoriser le 3è à entrer. Pour alerter son collègue, lopérateur A envoie le signal "Has the train left the tunnel?" Lorsque le premier train sort du tunnel, lopérateur B répond "Tunnel is clear" Ne sachant pas si les 2 trains ont quitté le tunnel, lopérateur A attend un certain temps,puis autorise le 3è train à entrer. Malheureusement, le conducteur du 2è train, qui avait vu le drapeau, sétait arrêté dansle tunnel. Après un certain temps de réflexion, il a même fait marche arrière…=> 23 morts et 176 blessés
    6. 6. Autopsie dun accident…Accident du tunnel de Clayton, 1861 : conclusion Il est difficile détablir la responsabilité de cet accident. A partir du moment où le 2è train est entré dans le tunnel, il ny avaitplus moyen de récupérer la situation. Lensemble des messages disponibles sur les télégraphes étaitincomplet. Le bon sens des opérateurs nétait pas suffisant.La réaction est toujours la même :I could not imagine that could ever happenAu début, beaucoup daccidents étaient dus au manque demoyens de communication, mais on a constaté ensuite quilétait surtout très difficile détablir des règles non ambiguësde communication.
    7. 7. Structure dun protocole…Pour définir un protocole, nous devons définir un ensemblede règles : définir comment un message est encodé comment une transmission est démarrée et terminée, etcDeux types derreurs sont difficiles à éviter : la conception dun ensemble incomplet de règles (incomplétude) la conception de règles contradictoires (inconsistance)Cela requiert : de définir tous les éléments essentiels du protocole une discipline pour les définir en séparant les éléments indépendantsLa vraie difficulté vient du parallélisme. Le nombre descénarios est en général énorme et difficile à appréhender
    8. 8. Historique…« Le génie logiciel, en tant que discipline informatique, est né enoctobre 1968 lors d’une conférence de l’OTAN à Garmisch-Partenkirchen pour répondre à un problème qui devenait deplus en plus évident : d’une part le logiciel n’est pas fiable,d’autre part il est incroyablement difficile de réaliser dans lesdélais prévus des logiciels satisfaisant leur cahier des charges »⇒ discipline de l’ingénieur du logiciel, pour l’aider développer dessystèmes informatiques fiables, i.e., satisfaisant leur cahier descharges, dans des délais raisonnables⇒ « génie logiciel » comme génie chimique, génie électrique,génie mécanique…= ensemble des techniques, outils et méthodes visant à optimiseret rationaliser la production du logiciel et son suivi1.1. Pourquoi lingé nierie des logiciels
    9. 9. Example: auto-pilotProblem:“Design a part in auto-pilot that avoids collision withother planes.”Solution:“When distance is 1km, give warning to other plane andnotify pilot. When distance is 300m, and no changes inthe course of other plane were noticed, go up to avoidcollision”
    10. 10. Problem with solutionBoth planes have the same software. Both go up...
    11. 11. This happens in real software!Some famous bugs NASA Space Rover, Intel floating point processor, etc.Hard to predict all behaviours! US aircraft went to southern hemisphere and … flipped whencrossing the equator Air traffic controller: US to Britain. It never dealt with problem of 0 degrees longitude. Result: software “folded” Britain along Greenwich Meridian Software written for US F-16 accidents when reused in Israeli aircraft flown over the DearSea(altitude < sea level) Year 2000 problem
    12. 12. Yet more such examplesNASA Space Shuttle software (in use since 1980) 16 severity-level 1 software errors 8 remained in code that was used in flights none encountered during flights total size - only 400,000 words
    13. 13. Remarque : les méthodes et techniques issues du génie logiciel sontimposées par les autorités de certification pour ledéveloppement de systèmes critiques (avionique,nucléaire…) normes de développement de systèmes (DO178B…)=> Pour continuer, quelques exemples de systèmescomplexes…1.1. Pourquoi lingé nierie des logiciels
    14. 14. Exemples : Le Système de Navigation et dAttaque dun Rafale = 2 millions de lignes de codes ADA 50 équipements (numériques ou analogiques), 12calculateurs Contraintes de temps < 1ms … combinatoire des modes et des états élevée Landing System : plus de 1014états possibles Side Displays Management : plus de 2.108états possibles 1/2 million d’instructions pour une expérience de physiquedes particules 1 million d’instructions dans un central téléphonique 50 millions d’instructions dans la navette spatiale⇒Nécessité de rigueur dans la conception1.1. Pourquoi lingé nierie des logiciels
    15. 15. Si lon veut maîtriser le développement de systèmes àlogiciels fiables, il faut : rédiger de façon claire les spécifications du système (ceque lon attend)=> comment être sûrs que ces spécifications sont complètes ?=> comment être sûrs que ces spécification sont cohérentes ? valider/vérifier toutes les étapes du développements=> a-t-on des moyens de validation/vérification (mathématiques)? de réutiliser des sous-systèmes déjà réalisés (mais pasnimporte comment)=> a-t-on des règles, des outils pour aider à la réutilisation ?⇒ nécessité d’une base théorique et d’une approcheingénierie (science de l’ingénieur) du logiciel1.1. Pourquoi lingé nierie des logiciels
    16. 16. Pour maximiser la qualité dun système il faut... Introduction dun cycle de vie : identifier un ensemble détape importante dans ledéveloppement, et des documents importants… analyse de besoins, spécification, conception,programmation, intégration… ranger ses étapes dans le temps et les unes parrapport aux autres=> cycles en cascade, en V, en Y, en spirale…1.2. Elé ments de terminologie
    17. 17. Pourquoi des techniques formelles…⇒Techniques formelles : reposent sur des fondements mathématiques expression mathématique des objets du développement (le comportementdes systèmes) expression mathématique des propriétés expression mathématique des preuves permettent lanalyse (mathématique) du comportement dun systèmeRemarque :certains organismes imposent déjà lutilisation de techniques mathématiques dans ledéveloppement de systèmes informatiques :→ dans le domaine de la sécurité : obligation dutiliser des méthodes formellespour certains niveaux de sécurité→ dans le ferroviaire… (métro Météor)
    18. 18. Quapportent les techniques formelles ?Les bases mathématiques (logique, théorie des ensembles…) d’unetechnique formelle fournissent les notions de consistance, cohérence à partir dune spécification S, on ne peut pas déduire "a" et "non a"Quest-ce quune technique formelle…ProgrammeSpécificationglobaleBesoins desutilisateursArchitecture etspécification descomposantsactivité de spécificationAxe dudéveloppementvérification de consistanceUne autre spécificationglobalevérification déquivalence
    19. 19. Quapportent les techniques formelles ?Les bases mathématiques (logique, théorie des ensembles…) d’unetechnique formelle fournissent les notions de correction dune implémentation par rapport à une spécification il est possible de décider si un programme P implémente unespécification SQuest-ce quune technique formelle…ProgrammeSpécificationglobaleBesoins desutilisateursArchitecture etspécification descomposantsactivité de spécificationactivité deconceptionactivité deprogrammationvérification vérificationAxe dudéveloppement
    20. 20. Que napportent pas les techniques formelles ?La démonstration de la validité de la spécification globale par rapport auxbesoins de lutilisateur est impossible=> parce que les besoins de lutilisateurs ne sont pas exprimés en termesmathématiques !Quest-ce quune technique formelle…ProgrammeSpécificationglobaleBesoins desutilisateursArchitecture etspécification descomposantsPreuves impossiblesvalidationactivité de spécificationAxe dudéveloppement
    21. 21. En résumé, ce que peuvent et ne peuvent pas les techniquesformellesQuest-ce quune technique formelle…ProgrammeSpécificationglobaleBesoins desutilisateursArchitecture etspécification descomposantsPreuves possiblesPreuves impossiblesvalidationactivité de spécificationactivité deconceptionactivité deprogrammationvérification vérificationAxe dudéveloppementvérification
    22. 22. Quel est lintérêt des techniques formelles ? précision des langages (due aux aspects mathématiques)=> non ambiguïtés des notationsdu fait du substrat mathématique, une spécification ou un programme na quuneseule signification=> diminution du "bruit" dans les spécifications (on ne parle que de ce qui a un sens)possibilité de détecter les informations inutiles dans une spécification=> meilleure compréhension de la spécification par léquipe de réalisation=> meilleure compréhension et dialogue entre clients et concepteursinterprétation "spécification formelle" vers "langage naturel" aisée=> meilleure documentation des systèmes=> meilleure réutilisation des composants augmentation de la phase de spécification mais diminution importante de la phasede test, et diminution des corrections en maintenance=> réduction globale des coûts du logiciel=> augmentation de la fiabilité du logiciel1. Quest-ce quune technique formelle…
    23. 23. Grande diversité des techniques formelles domaine détude de très nombreux centres de recherche ou grands groupesindustriels dans le monde (à lorigine européens) Se différencient selon les domaines dapplicationsDifférentes classifications possibles selon le substrat mathématique (support de la sémantique) logique, théorie des ensemble, théorie des automates, algèbre, λ-calcul... selon le domaine de prédilection base de données, systèmes réactifs… selon la nature du système de preuve sous-jacent incrémental, automatique... orientées propriétés ou orientées modèles à spécifications exécutables ou nonBref panorama des techniques formelles…
    24. 24. Model Checking Denotes algorithmic analysis to check that a model (not necessarily finitestate) satisfies a specified property In logic, “model” denotes a structure over which formulas are interpreted “Model checking” checks (preferably automatically) whether a givenformula holds in a given model
    25. 25. 25Analyse de modè les, Model Checkingbyte n;proctype Aap() {do:: n++:: noot!MIESod}Modèle M[] (n<3)Propriété φAnalyseurEspace d’étatsOUIPropriétésatisfaiteNON,+ contre_exempleϕ=|MExplosion d’états.
    26. 26. Overview of Automated VerificationAnswer +Counter-exampleAnswer +Counter-exampleSW/HWartifactSW/HWartifactCorrectnesspropertiesCorrectnesspropertiesTemporallogicTemporallogicModel ofSystemModel ofSystemModelExtractionModelExtraction TranslationTranslationCheckerEngineCheckerEngineabstractionabstractionCorrect?
    27. 27. LimitationsAppropriate for control-intensive applications withinteresting interaction among components Data remains a problemDecidability and complexity remains an obstacleFalsification rather than verification Model, and not system, is verified Only stated requirements are checked: how to capturecorrectness in a formal language? Bugs in the model checkerFinding suitable abstractions requires expertise
    28. 28. The “Methodology” AnswerFormal verification does not aim toproduce mathematical certainty ofcorrectness, but to provide amethodology that, when followed,produces more reliable and robustsystems
    29. 29. Protocoles de communication
    30. 30. PréambuleUn protocole est un ensemble de règles qui gouvernentlinteraction entre processus parallèles dans les systèmesdistribuésLa conception de protocoles nest pas une discipline à part, elleest liée à la fois aux réseaux et à lingénierie des systèmesDécrire complètement et sans ambiguïté un protocole est difficileProuver quun protocole est correct est une tâche encore plusardue=> Le but du cours nest pas denseigner de nouveaux protocoles,mais de montrer comment on peut (bien) les décrireProtocoles de communication…
    31. 31. Protocoles de Communication … Protocole Réseau: Les protocoles peuvent etre implémentés en matériel et/ou logiciel. EIA-232-D est un protocole faisant partie de la couche physiqueimplémenté en materiel. Les protocoles TCP/IP sont implémentés en logiciel.
    32. 32. Protocol Data Units (PDU) Les entités communicantes échangent des fragments formattés selon leprotocole utilisé. Chaque fragment est une unité de donnée du protocole (Protocole Data Unitou PDU) Chaque PDU contient: Header (entête): Spécifie comment traiter et router le reste du PDU Message: le contenu du PDU Trailer (queue) sert en général pour le contrôle d’erreurs.Header Message Trailer
    33. 33. Structure dun protocole…Pour définir un protocole, nous devons définir un ensemblede règles : définir comment un message est encodé comment une transmission est démarrée et terminée, etcDeux types derreurs sont difficiles à éviter : la conception dun ensemble incomplet de règles (incomplétude) la conception de règles contradictoires (inconsistance)Cela requiert : de définir tous les éléments essentiels du protocole une discipline pour les définir en séparant les éléments indépendantsLa vraie difficulté vient du parallélisme. Le nombre descénarios est en général énorme et difficile à appréhender
    34. 34. Structure dun protocole…Les Cinq éléments dun protocole Le service à fournir par le protocole Les hypothèses sur lenvironnement dans lequel le protocolesexécute Le vocabulaire des messages utilisé par le protocole Le format de chaque message Les règles procédurales utilisées durant la communicationLa 5è partie est la plus délicate à définir et la plus difficile àvérifier.
    35. 35. Structure dun protocole…Un exemple1. Le service : Transfert de fichiers de texte comme séquences de caractères via une lignetéléphonique en se protégeant contre les erreurs de transmission(supposée toutes détectables) Bidirectionnel : 2 transferts en sens opposés possibles2. Les hypothèses : Composé de 2 utilisateurs et dun canal de transmission On suppose que chaque utilisateur peut soumettre une requête et attendrequelle sexécute Le canal peut modifier les messages, mais pas les perdre, les dédoubler, lesréarranger, ni en insérer un autre.3. Vocabulaire : trois messages ack : un message + un acquit positif nak : un message + un acquit négatif err : un message erroné
    36. 36. Structure dun protocole…Un exemple (suite)4. Les formats : Chaque message a un champ de contrôle identifiant le type demessage et un champ de données avec le code de caractère :Type PDU isrecordcontrol : tag,data : charendrecordType tag is {ack, nak, err}
    37. 37. Structure dun protocole…Un exemple (suite)5. Les règles procédurales :Soit 2 entités A et B1. Si la réception précédente est sans erreur, le prochain message sur le canalopposé contiendra un acquit positif.2. Si la réception précédente est erronée, le prochain message sur le canalopposé contiendra un acquit négatif.3. Si la réception précédente est erronée ou contient un acquit négatif, leprochain message sera une retransmission du message émisprécédemment; sinon, ce sera un nouveau message4. Si un utilisateur na pas de caractère à émettre, il peut envoyer un caractère« null »5. A démarre le transfert.
    38. 38. Structure dun protocole…Un exemple (suite)Représentation des règles procédurales :receive(i)fetch(o)fetch(o)nak(o)ack(i) errnak(i)ack(o) ack(o) nak(o)ÉmissionRéceptionAttenteActionProtocole correct ?
    39. 39. Structure dun protocole…Un exemple (suite)Un scénario derreur…
    40. 40. Structure dun protocole…Notion vocabulaire et de formatType PDU isrecordcontrol : tag,data : charendrecordType tag is {ack, nak, err}Exemple de codage :recordcontrol : bit,data : ASCII char,parity : bitendrecord+ des fonctions de calculs derreursAttention : il sagit deformats abstraits, et non duncodage
    41. 41. Structure dun protocole…Notion de règles procédurales Exprimées au niveau dabstraction adéquat (pas de détail inutile(codage)) Doivent être complètes, consistantes et non ambiguës=> nécessite un formalisme ou un langage approprié Il nexiste pas de méthode permettant de sassurer a priori de lacomplétude et de la consistance des règles=> vérification a posteriori La difficulté vient du parallélisme=> Les diagrammes de séquences ne conviennent pas. Ils permettent aumieux dillustrer un scénario derreur. Un protocole nest pas correct dans labsolu ; un protocole estcorrect par rapport à un ensemble de propriétés (la spécification deson service)=> Nécessité de formaliser les propriétés ou le service attendu
    42. 42. Rè gles dingé nierie… Simplicité — Concevoir des protocoles légers Faciles à comprendre, à implanter, à maintenir à jour, et souvent plus performants Modularité — Une hiérarchie de fonctions Un protocole complexe doit être construit à partir de modules plus simples qui interagissentde façon simple et bien définie Il ne faut pas mélanger des fonctions indépendantes (p. ex. contrôle derreur et contrôle deflux) dans un même module Un protocole doit être indépendant du système dexploitation, de lencodage des données,des formats dadresse, des débits utilisés…⇒ Facilite louverture (portabilité), lextensibilité ou le changement de modules... Un protocole doit être bien formé Pas de sur-spécification : pas de code non exécutable Pas de sous-spécification : pas de réception non prévue Borné : pas de débordement de tampon Auto-stabilisant : en cas derreur, retour dans un état stable après récupération
    43. 43. Rè gles dingé nierie… Robustesse Concevoir un protocole qui fonctionne bien dans des circonstances normales estfacile Cest linattendu qui défie le concepteur Il faut faire un minimum dhypothèses sur lenvironnement Un bon design doit résister à lévolution (vitesse des lignes, taille du réseau, …) Il faut éviter lajout de fonctions inutiles qui pourraient savérer être un frein à uneévolution ultérieure. Consistance : un protocole peut être incorrect de plusieurs façons Interblocages (deadlocks) : toutes les entités sont bloquées en attente demessage Cycles non productifs (livelocks) : le système boucle indéfiniment sansprogresser Terminaisons impropres : sans satisfaire certaines conditions
    44. 44. Rè gles dingé nierie…Pour finir : quelques règles de (bonnes conception)1. Etre sûr que le problème est bien défini : il faut énumérer tous les critères et contraintes avant de commencer2. Définir le service à fournir avant de concevoir le protocole le quoi avant le comment3. Principe KISS (Keep It Simple, Stupid)4. Séparer les fonctionnalités orthogonales.5. Un bon design résout une classe de problèmes plutôt quun problème isolé. Ne pas se restreindre inutilement. Ne pas introduire de détails inutiles.6. Procéder par prototypages de haut niveau avant dimplémenter7. Implémenter, mesurer les performances, et si nécessaire optimiser.8. Vérifier que limplémentation est équivalente au prototype de haut niveau.
    45. 45. Une première classification… les énoncés en langue naturelle (anglais, français…) + des tables et desschémas les plus courants mais les plus ambigues… et donc les plus risqués, et ne se prêtent pas àlanalyse (de complétude, de correction…) seul lœil humain peut analyser et corriger ces énoncés les techniques semi-formelles descriptions formatées (langue naturelle structurée) techniques graphiques à la UML…=> modèles entités-relations=> de plus en plus utilisées=> souvent clairs et facilement compréhensibles=> mais peut comporter encore des ambiguïtés (aux marges du formalisme), etne se prêtent toujours pas à lanalyse (de complétude, de correction…)Les moyens de description deprotocoles…
    46. 46. Techniques de description de protocoles : quels besoins ? Labstraction : permettre une description au bon niveau de détail=> pas de détails superflus=> capturer les aspects importants du protocole La modélisation des états et des logiques de changement détats Lindéterminisme=> au niveau de la spécification=> du comportement de lenvironementLes moyens de description deprotocoles…a b
    47. 47. Techniques de description de protocoles : quels besoins ? la causalité en actions (séquence) la concurrence entre actions (parallélisme) la synchronisation lanalysibilité (outil danalyse) la non ambiguïté (une sémantique formelle)=> il nexiste aucun formalisme répondant complètement à ces critèresLes moyens de description deprotocoles…a ba ba’ b’||a a’
    48. 48. FSM simpleExemple : état dun processus inactif, en attente UC, en attente ressource, actif inactifattenteUC ressourceattenteUCattenteressourceactifActivation?+UC? -UC?Fin!+UC?+R?-R?-UC? -R?+R?Les moyens de description deprotocoles…
    49. 49. FSM simple avec parallélismeExemple : le protocole du tunnel de ClaytonLes moyens de description deprotocoles…No train V1Trainv1?Train-in-tunnelv1!Tunne-is-clearv1?Has-the-train-left-the-tunnelv1?No train V2Train-in-tunnelv2?Out-trainv2Tunne-is-clearv2!Has-the-train-left-the-tunnelv2?Has-the-train-left-the-tunnelv2?Has-the-train-left-the-tunnelv2?Tunne-is-clearv2!||
    50. 50. 53Conception et description àcouches
    51. 51. 54Conception à couches des protocolesUn protocole contient normalement un grand nombrede fonctionnalitésPourrait être défini comme un seul programme, maisceci serait excessivement complexeLe manque de modularité rendrait aussi difficilel’échange de modules préfabriqués entre compagnies
    52. 52. 55Couches OSIRéf:http://www.irisa.fr/armor/lesmembres/cousin/Enseignement/Reseaux-generalites/Cours/4-3.htm
    53. 53. 56Modè le de ré fé rence Open SystemsInterconnection
    54. 54. 57Fonctionnement Global
    55. 55. 58Entité s OSIN+1-Protocol Entity N+1-Protocol EntityN-Service ProviderN+1-PDUsN-SDUsN-SDUsN-SAP N-SAPSAP: Service Access Point
    56. 56. Entité s OSINotion de service : modèle en couches Le service est une définition fonctionnelle de linterface entre couches Liste des primitives avec paramètres Ordonnancement permis des primitives Le service N est une abstraction des couches de protocole inférieures.
    57. 57. Entité s OSINotion denvironnement : abstraction des couches supérieureset inférieures Centrage sur une couche N et un protocole N Les couches supérieures sont vues comme des utilisateurs abstraits Les couches inférieures sont vues comme un milieu de transmission. Il décritles hypothèses qui caractérisent ces couches (pertes, doublons possibles, …) Le protocole N décrit le fonctionnement des entités N (A et B) en réaction auxprimitives de service N et aux PDU N venant de lentité homologue via le milieude transmission (médium). Lenvironnement dun protocole est composé des utilisateurs et du milieu detransmission.
    58. 58. 61Service Data Units (SDUs) Request : Une entité sollicite un service Indication : Une entité est informée dune demande de service Response : Une entité a rendu le service, si possible Confirmation : Une entité est informée que le service a été renduSAPREQUEST INDICATIONCONFIRMATION RESPONSEServicenon confirméServiceconfirméSAP
    59. 59. 64Mode non connecté (connectionless) 1 seule phase: le transfert de données chaque unité de transfert de données est acheminéeindépendamment les entités communicantes ne mémorisent rien("memoryless"). les messages échangées sont auto-suffisants ("self-content") pas d’acquittement de messages (no ack) exemple: datagrammes en IP
    60. 60. 65Mode Connecté (connection-oriented) 3 phases : phase détablissement de la connexion phase de transfert de données phase de libération de la connexion un contexte (réparti) est partagé par les membres de la connexion : par exemple : le numéro du paquet permet (facilite) le contrôle et la gestion du transfert de données : contrôle derreur, contrôle de flux, maintien en séquence, etc. les messages échangés comportent des informations qui ne sontutilisables que grâce à la connaissance de ce contexte : par exemple : le numéro de paquet / la largeur de la fenêtrecoulissante Exemple de protocole utilisant le mode connecté:TCP

    ×