1. 1
Ingénierie des protocoles de
communication
Haykal Tej
Inst. Sup. d’Informatique et des Technologies
de
Communication, Hammam Sousse
Université de Sousse
htej@gmx.de

2. 2
Chapitre 1
Généralités sur les protocoles et
les méthodes de génie de
protocoles

3. Préambule
 Un protocole est un ensemble de règles qui gouvernent l'interaction
entre processus parallèles dans les systèmes distribués
 La conception de protocoles n'est pas une discipline à part, elle est liée
à la fois aux réseaux et à l'ingénierie des systèmes
 Décrire complètement et sans ambiguïté un protocole est difficile
 Prouver qu'un protocole est correct est une tâche encore plus ardue
=> Le but du cours n'est pas d'enseigner de nouveaux protocoles, mais de
montrer comment on peut (bien) les décrire
Protocoles de communication…

4. Autopsie d'un 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 du
système, c'est l'opérateur qui agite un drapeau rouge
 c'est l'opé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?"
A
B

5. Autopsie d'un accident…
Accident du tunnel de Clayton, 1861 : ce qui s'est passé
 Un train passe le sémaphore A (vert), mais le sémaphore ne passe pas au rouge.
 L'opérateur réagit : il envoie le message "Train in tunnel" et agite un drapeau rouge
pour 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 s'arrête
 L'opérateur envoie à nouveau le signal "Train in tunnel" pour avertir l'autre qu'il y a 2
trains dans le tunnel.
 Le protocole n'a pas prévu ce cas.
 Le problème pour l'opérateur A est maintenant de savoir quand les deux trains ont
quitté le tunnel afin d'autoriser le 3è à entrer.
 Pour alerter son collègue, l'opérateur A envoie le signal "Has the train left the tunnel?"
 Lorsque le premier train sort du tunnel, l'opérateur B répond "Tunnel is clear"
 Ne sachant pas si les 2 trains ont quitté le tunnel, l'opé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é dans
le tunnel. Après un certain temps de réflexion, il a même fait marche arrière…
=> 23 morts et 176 blessés

6. Autopsie d'un 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 n'y avait
plus moyen de récupérer la situation.
 L'ensemble des messages disponibles sur les télégraphes était
incomplet.
 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 happen
Au début, beaucoup d'accidents étaient dus au manque de
moyens de communication, mais on a constaté ensuite qu'il
était surtout très difficile d'établir des règles non ambiguës
de communication.

7. Structure d'un protocole…
Pour définir un protocole, nous devons définir un ensemble
de règles :
 définir comment un message est encodé
 comment une transmission est démarrée et terminée, etc
Deux types d'erreurs sont difficiles à éviter :
 la conception d'un 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 de
scénarios est en général énorme et difficile à appréhender

8. Historique…
« Le génie logiciel, en tant que discipline informatique, est né en
octobre 1968 lors d’une conférence de l’OTAN à Garmisch-
Partenkirchen pour répondre à un problème qui devenait de
plus en plus évident : d’une part le logiciel n’est pas fiable,
d’autre part il est incroyablement difficile de réaliser dans les
délais prévus des logiciels satisfaisant leur cahier des charges »
⇒ discipline de l’ingénieur du logiciel, pour l’aider développer des
systèmes informatiques fiables, i.e., satisfaisant leur cahier des
charges, 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 à optimiser
et rationaliser la production du logiciel et son suivi
1.1. Pourquoi l'ingé nierie des logiciels

9. Example: auto-pilot
Problem:
“Design a part in auto-pilot that avoids collision with
other planes.”
Solution:
“When distance is 1km, give warning to other plane and
notify pilot. When distance is 300m, and no changes in
the course of other plane were noticed, go up to avoid
collision”

10. Problem with solution
Both planes have the same software. Both go up...

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 when
crossing 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 Dear
Sea
(altitude < sea level)
 Year 2000 problem

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. Remarque :
 les méthodes et techniques issues du génie logiciel sont
imposées par les autorités de certification pour le
développement de systèmes critiques (avionique,
nucléaire…)
 normes de développement de systèmes (DO178B…)
=> Pour continuer, quelques exemples de systèmes
complexes…
1.1. Pourquoi l'ingé nierie des logiciels

14. Exemples :
 Le Système de Navigation et d'Attaque d'un Rafale =
 2 millions de lignes de codes ADA
 50 équipements (numériques ou analogiques), 12
calculateurs
 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 physique
des 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 conception
1.1. Pourquoi l'ingé nierie des logiciels

15. Si l'on 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 (ce
que l'on 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 pas
n'importe comment)
=> a-t-on des règles, des outils pour aider à la réutilisation ?
⇒ nécessité d’une base théorique et d’une approche
ingénierie (science de l’ingénieur) du logiciel
1.1. Pourquoi l'ingé nierie des logiciels

16. Pour maximiser la qualité d'un système il faut...
 Introduction d'un cycle de vie :
 identifier un ensemble d'étape importante dans le
développement, et des documents importants…
 analyse de besoins, spécification, conception,
programmation, intégration…
 ranger ses étapes dans le temps et les unes par
rapport aux autres
=> cycles en cascade, en V, en Y, en spirale…
1.2. Elé ments de terminologie

17. Pourquoi des techniques formelles…
⇒Techniques formelles :
 reposent sur des fondements mathématiques
 expression mathématique des objets du développement (le comportement
des systèmes)
 expression mathématique des propriétés
 expression mathématique des preuves
 permettent l'analyse (mathématique) du comportement d'un système
Remarque :
certains organismes imposent déjà l'utilisation de techniques mathématiques dans le
développement de systèmes informatiques :
→ dans le domaine de la sécurité : obligation d'utiliser des méthodes formelles
pour certains niveaux de sécurité
→ dans le ferroviaire… (métro Météor)

18. Qu'apportent les techniques formelles ?
Les bases mathématiques (logique, théorie des ensembles…) d’une
technique formelle fournissent les notions de
 consistance, cohérence
 à partir d'une spécification S, on ne peut pas déduire "a" et "non a"
Qu'est-ce qu'une technique formelle…
Programme
Spécification
globale
Besoins des
utilisateurs
Architecture et
spécification des
composants
activité de spécification
Axe du
développement
vérification de consistance
Une autre spécification
globale
vérification d'équivalence

19. Qu'apportent les techniques formelles ?
Les bases mathématiques (logique, théorie des ensembles…) d’une
technique formelle fournissent les notions de
 correction d'une implémentation par rapport à une spécification
 il est possible de décider si un programme P implémente une
spécification S
Qu'est-ce qu'une technique formelle…
Programme
Spécification
globale
Besoins des
utilisateurs
Architecture et
spécification des
composants
activité de spécification
activité de
conception
activité de
programmation
vérification vérification
Axe du
développement

20. Que n'apportent pas les techniques formelles ?
La démonstration de la validité de la spécification globale par rapport aux
besoins de l'utilisateur est impossible
=> parce que les besoins de l'utilisateurs ne sont pas exprimés en termes
mathématiques !
Qu'est-ce qu'une technique formelle…
Programme
Spécification
globale
Besoins des
utilisateurs
Architecture et
spécification des
composants
Preuves impossibles
validation
activité de spécification
Axe du
développement

21. En résumé, ce que peuvent et ne peuvent pas les techniques
formelles
Qu'est-ce qu'une technique formelle…
Programme
Spécification
globale
Besoins des
utilisateurs
Architecture et
spécification des
composants
Preuves possiblesPreuves impossibles
validation
activité de spécification
activité de
conception
activité de
programmation
vérification vérification
Axe du
développement
vérification

22. Quel est l'intérêt des techniques formelles ?
 précision des langages (due aux aspects mathématiques)
=> non ambiguïtés des notations
du fait du substrat mathématique, une spécification ou un programme n'a qu'une
seule 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 concepteurs
interpré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 phase
de test, et diminution des corrections en maintenance
=> réduction globale des coûts du logiciel
=> augmentation de la fiabilité du logiciel
1. Qu'est-ce qu'une technique formelle…

23. Grande diversité des techniques formelles
 domaine d'étude de très nombreux centres de recherche ou grands groupes
industriels dans le monde (à l'origine européens)
 Se différencient selon les domaines d'applications
Diffé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 non
Bref panorama des techniques formelles…

24. Model Checking
 Denotes algorithmic analysis to check that a model (not necessarily finite
state) satisfies a specified property
 In logic, “model” denotes a structure over which formulas are interpreted
 “Model checking” checks (preferably automatically) whether a given
formula holds in a given model

25. 25
Analyse de modè les, Model Checking
byte n;
proctype Aap() {
do
:: n++
:: noot!MIES
od
}
Modèle M
[] (n<3)
Propriété φ
Analyseur
Espace d’états
OUI
Propriété
satisfaite
NON,
+ contre_exemple
ϕ=|M
Explosion d’états.

26. Overview of Automated Verification
Answer +
Counter-example
Answer +
Counter-example
SW/HW
artifact
SW/HW
artifact
Correctness
properties
Correctness
properties
Temporal
logic
Temporal
logic
Model of
System
Model of
System
Model
Extraction
Model
Extraction TranslationTranslation
Checker
Engine
Checker
Engine
abstractionabstraction
Correct?

27. Limitations
Appropriate for control-intensive applications with
interesting 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 capture
correctness in a formal language?
 Bugs in the model checker
Finding suitable abstractions requires expertise

28. The “Methodology” Answer
Formal verification does not aim to
produce mathematical certainty of
correctness, but to provide a
methodology that, when followed,
produces more reliable and robust
systems

29. Protocoles de communication

30. Préambule
Un protocole est un ensemble de règles qui gouvernent
l'interaction entre processus parallèles dans les systèmes
distribués
La conception de protocoles n'est pas une discipline à part, elle
est liée à la fois aux réseaux et à l'ingénierie des systèmes
Décrire complètement et sans ambiguïté un protocole est difficile
Prouver qu'un protocole est correct est une tâche encore plus
ardue
=> Le but du cours n'est pas d'enseigner de nouveaux protocoles,
mais de montrer comment on peut (bien) les décrire
Protocoles de communication…

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 physique
implémenté en materiel.
 Les protocoles TCP/IP sont implémentés en logiciel.

32. Protocol Data Units (PDU)
 Les entités communicantes échangent des fragments formattés selon le
protocole utilisé.
 Chaque fragment est une unité de donnée du protocole (Protocole Data Unit
ou 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. Structure d'un protocole…
Pour définir un protocole, nous devons définir un ensemble
de règles :
 définir comment un message est encodé
 comment une transmission est démarrée et terminée, etc
Deux types d'erreurs sont difficiles à éviter :
 la conception d'un 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 de
scénarios est en général énorme et difficile à appréhender

34. Structure d'un protocole…
Les Cinq éléments d'un protocole
 Le service à fournir par le protocole
 Les hypothèses sur l'environnement dans lequel le protocole
s'exécute
 Le vocabulaire des messages utilisé par le protocole
 Le format de chaque message
 Les règles procédurales utilisées durant la communication
La 5è partie est la plus délicate à définir et la plus difficile à
vérifier.

35. Structure d'un protocole…
Un exemple
1. Le service :
 Transfert de fichiers de texte comme séquences de caractères via une ligne
téléphonique en se protégeant contre les erreurs de transmission
(supposée toutes détectables)
 Bidirectionnel : 2 transferts en sens opposés possibles
2. Les hypothèses :
 Composé de 2 utilisateurs et d'un canal de transmission
 On suppose que chaque utilisateur peut soumettre une requête et attendre
qu'elle s'exécute
 Le canal peut modifier les messages, mais pas les perdre, les dédoubler, les
ré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. Structure d'un protocole…
Un exemple (suite)
4. Les formats :
 Chaque message a un champ de contrôle identifiant le type de
message et un champ de données avec le code de caractère :
Type PDU is
record
control : tag,
data : char
endrecord
Type tag is {ack, nak, err}

37. Structure d'un protocole…
Un exemple (suite)
5. Les règles procédurales :
Soit 2 entités A et B
1. Si la réception précédente est sans erreur, le prochain message sur le canal
opposé contiendra un acquit positif.
2. Si la réception précédente est erronée, le prochain message sur le canal
opposé contiendra un acquit négatif.
3. Si la réception précédente est erronée ou contient un acquit négatif, le
prochain message sera une retransmission du message émis
précédemment; sinon, ce sera un nouveau message
4. Si un utilisateur n'a pas de caractère à émettre, il peut envoyer un caractère
« null »
5. A démarre le transfert.

38. Structure d'un 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)
Émission
Réception
Attente
Action
Protocole correct ?

39. Structure d'un protocole…
Un exemple (suite)
Un scénario d'erreur…

40. Structure d'un protocole…
Notion vocabulaire et de format
Type PDU is
record
control : tag,
data : char
endrecord
Type tag is {ack, nak, err}
Exemple de codage :
record
control : bit,
data : ASCII char,
parity : bit
endrecord
+ des fonctions de calculs d'erreurs
Attention : il s'agit de
formats abstraits, et non d'un
codage

41. Structure d'un protocole…
Notion de règles procédurales
 Exprimées au niveau d'abstraction 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 n'existe pas de méthode permettant de s'assurer a priori de la
complé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 au
mieux d'illustrer un scénario d'erreur.
 Un protocole n'est pas correct dans l'absolu ; un protocole est
correct par rapport à un ensemble de propriétés (la spécification de
son service)
=> Nécessité de formaliser les propriétés ou le service attendu

42. Rè gles d'ingé 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 interagissent
de façon simple et bien définie
 Il ne faut pas mélanger des fonctions indépendantes (p. ex. contrôle d'erreur et contrôle de
flux) dans un même module
 Un protocole doit être indépendant du système d'exploitation, de l'encodage des données,
des formats d'adresse, des débits utilisés…
⇒ Facilite l'ouverture (portabilité), l'extensibilité 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 d'erreur, retour dans un état stable après récupération

43. Rè gles d'ingé nierie…
 Robustesse
 Concevoir un protocole qui fonctionne bien dans des circonstances normales est
facile
 C'est l'inattendu qui défie le concepteur
 Il faut faire un minimum d'hypothèses sur l'environnement
 Un bon design doit résister à l'évolution (vitesse des lignes, taille du réseau, …)
 Il faut éviter l'ajout de fonctions inutiles qui pourraient s'avé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 de
message
 Cycles non productifs (livelocks) : le système boucle indéfiniment sans
progresser
 Terminaisons impropres : sans satisfaire certaines conditions

44. Rè gles d'ingé 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 commencer
2. Définir le service à fournir avant de concevoir le protocole
 le quoi avant le comment
3. 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 qu'un problème isolé.
 Ne pas se restreindre inutilement.
 Ne pas introduire de détails inutiles.
6. Procéder par prototypages de haut niveau avant d'implémenter
7. Implémenter, mesurer les performances, et si nécessaire optimiser.
8. Vérifier que l'implémentation est équivalente au prototype de haut niveau.

45. Une première classification…
 les énoncés en langue naturelle (anglais, français…) + des tables et des
schémas
 les plus courants
 mais les plus ambigues… et donc les plus risqués, et ne se prêtent pas à
l'analyse (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), et
ne se prêtent toujours pas à l'analyse (de complétude, de correction…)
Les moyens de description de
protocoles…

46. Techniques de description de protocoles : quels besoins ?
 L'abstraction : 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
 L'indéterminisme
=> au niveau de la spécification
=> du comportement de l'environement
Les moyens de description de
protocoles…
a b

47. Techniques de description de protocoles : quels besoins ?
 la causalité en actions (séquence)
 la concurrence entre actions (parallélisme)
 la synchronisation
 l'analysibilité (outil d'analyse)
 la non ambiguïté (une sémantique formelle)
=> il n'existe aucun formalisme répondant complètement à ces critères
Les moyens de description de
protocoles…
a b
a b
a’ b’
||
a a’

48. FSM simple
Exemple : état d'un processus
 inactif,
 en attente UC,
 en attente ressource,
 actif inactif
attente
UC ressource
attente
UC
attente
ressource
actif
Activation?
+UC? -UC?
Fin!
+UC?
+R?
-R?
-UC? -R?
+R?
Les moyens de description de
protocoles…

49. FSM simple avec parallélisme
Exemple : le protocole du tunnel de Clayton
Les moyens de description de
protocoles…
No train V1
Trainv1?
Train-in-tunnelv1!
Tunne-is-clearv1?
Has-the-train-left-the-tunnelv1?
No train V2
Train-in-tunnelv2?
Out-trainv2
Tunne-is-clearv2!
Has-the-train-left-the-tunnelv2?
Has-the-train-left-the-tunnelv2?
Has-the-train-left-the-tunnelv2?
Tunne-is-clearv2!
||

50. 53
Conception et description à
couches

51. 54
Conception à couches des protocoles
Un protocole contient normalement un grand nombre
de fonctionnalités
Pourrait être défini comme un seul programme, mais
ceci serait excessivement complexe
Le manque de modularité rendrait aussi difficile
l’échange de modules préfabriqués entre compagnies

52. 55
Couches OSI
Réf:
http://www.irisa.fr/armor/lesmembres/cousin/Enseignement/Reseaux-generalites/Cours/4-3.htm

53. 56
Modè le de ré fé rence Open Systems
Interconnection

54. 57
Fonctionnement Global

55. 58
Entité s OSI
N+1-Protocol Entity N+1-Protocol Entity
N-Service Provider
N+1-PDUs
N-SDUsN-SDUs
N-SAP N-SAP
SAP: Service Access Point

56. Entité s OSI
Notion de service : modèle en couches
 Le service est une définition fonctionnelle de l'interface 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. Entité s OSI
Notion d'environnement : abstraction des couches supérieures
et 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écrit
les 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 aux
primitives de service N et aux PDU N venant de l'entité homologue via le milieu
de transmission (médium).
 L'environnement d'un protocole est composé des utilisateurs et du milieu de
transmission.

58. 61
Service Data Units (SDUs)
 Request : Une entité sollicite un service
 Indication : Une entité est informée d'une demande de service
 Response : Une entité a rendu le service, si possible
 Confirmation : Une entité est informée que le service a été rendu
SAP
REQUEST INDICATION
CONFIRMATION RESPONSE
Service
non confirmé
Service
confirmé
SAP

59. 64
Mode non connecté (connectionless)
 1 seule phase:
 le transfert de données
 chaque unité de transfert de données est acheminée
indé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. 65
Mode 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 d'erreur, contrôle de flux, maintien en séquence, etc.
 les messages échangés comportent des informations qui ne sont
utilisables que grâce à la connaissance de ce contexte :
 par exemple : le numéro de paquet / la largeur de la fenêtre
coulissante
 Exemple de protocole utilisant le mode connecté:TCP