Académique Documents
Professionnel Documents
Culture Documents
problèmes
de contrôle du flux de données
1
Deux généraux qui doivent prendre
une ville…
Seulement en agissant ensemble peuvent-ils gagner…
Un général n’attaquera que s’il est certain que l’autre attaquera
aussi
Le seul moyen de communication est un pigeon…
2
http://www.clipart-darktreasures.com
Un dialogue sans espoir…
Général A envoie un message: attaquons à 6h demain
Attaqueront-ils?
Non, A attendra confirmation
Général B envoie une réponse: d’accord à 6h demain
Attaqueront-ils?
Non, B attendra confirmation
Général A répond encore: d’accord à 6 h demain
Attaqueront-ils?
Non, A attendra confirmation
Etc…
3
Il n’y a pas de protocole pour résoudre ce
problème!
Preuve (informelle):
Supposez qu’un protocole existe
4
Erreurs résiduels
Après analyse, on découvre que ce résultat s’applique à n’importe
quel protocole!
Il n’est pas possible d’établir l’accord certain dans le cas de canaux
avec perte
• Un aspect fondamental de la preuve est que nous ne savons pas combien
de fois le système va échouer
• Si nous savons que sûrement il y aura succès au moins 1 fois sur 10,
alors l’envoi de 10 pigeons suffira
Étant donné que normalement il est impossible d’établir ce type de
borne, il n’est pas possible d’établir la certitude globale dans les
systèmes répartis
N’importe la complexité du protocole et la fiabilité du milieu, il y a
toujours la possibilité d’erreurs résiduels
On parle donc de taux d’erreur résiduel (residual error rate)
Il est vrai cependant que dans les supports de communication
modernes (fibres optiques, etc.) la fiabilité est extrêmement élevée
5
Problèmes de sécurité
Considérez aussi la possibilité que le
pigeon puisse être intercepté et
remplacé par un autre pigeon avec un
message différent…
6
Position du problème
1. Synchronisation entre la vitesse de transmission et
celle de propagation et réception
2. Optimiser l’utilisation du canal
3. Éviter la congestion
7
Objectif du cours
Établir un système de contrôle de flux complet à
partir d’une séquence de modifications apportées à
un modèle basique simple
8
Contrôle de flux
Le contrôle de flux est un mécanisme pour empêcher
l’émetteur d’envoyer plus que le récepteur ne peut
recevoir (à cause de l’espace de tamponnage disponible)
9
Notations
mesg:o dans une instruction d’entrée ou sortie
indique le message du type mesg avec le champs de
données o est émit ou reçu
10
Structure d’un organigramme
Les actions d’un processus sont spécifiées par des symboles.
Six types de symboles :
12
Structure d’un organigramme
Les arêtes directionnelles indiquent que le contrôle
du flux converge uniquement vers les connecteurs
Elles peuvent diverger aux conditions d’attentes et
aux tests booléens
13
Structure d’un organigramme
14
Structure d’un organigramme
Les outputs, déclarations, conditions d’attente, événements
internes et les tests booléens peuvent apparaître à n’importe
quelle localisation dans l’organigramme
15
Structure d’un organigramme
Une condition d’attente (receive) suspend l’exécution du
processus jusqu’a se que le type du message contenu dans la
première trame de la file d’attente soit défini dans l’une des
entrées (inputs) qui suit le symbole d’attente
Si le message dans la première trame de la file est d’un autre
type, il s’agit d’une erreur de protocole
Un délai d’attente (timeout) est une condition de
synchronisation interne représentée par un événement interne.
16
Structure d’un organigramme
Deux actions internes pour modéliser les accès : next et accept
next:a,b indique l’extraction interne des éléments a et b d’une
base de données interne
accept:a,b le stockage des données dans une base de
données interne
Les deux actions next et accept inclus touts les processus
associés respectivement à l’extraction et le stockage des
données
17
Modèle de protocole basique
Ce protocole est fiable ssi le récepteur est plus rapide que l’émetteur
Violation d’une règle basique de la conception des systèmes répartis:
Ne jamais imposer une hypothèse sur les vitesses des processus
concurrents18
Synchronisation émetteur-récepteur
Rôle du récepteur :
1. interpréter les données
2. décider ce qu’il doit faire avec
3. allouer la mémoire
4. orienter les données vers un destinataire approprié
Consommation d’un temps considérable
Rôle de l’émetteur :
1. trouver le fournisseur des données à transférer
2. il est en arrêt tant qu’il n’y a pas de données à transférer
3. libérer de la mémoire après le transfert
moins de temps à consommer
Le goulot dans le protocole est le processus de
réception
19
Première technique de contrôle
de flux: protocole X-on X-off
Plus ancien, moins fiable
Deux messages de contrôle :
suspend : suspendre le trafic
resume : réinitialiser le trafic
Hypothèses :
canal est idéal (pas d’erreurs de transmission)
vocabulaire du protocole : V = { mesg, suspend, resume }
20
Protocole X-on X-off : Processus
d’émission
21
Protocole X-on X-off : Processus
de réception
Le message de 22données passe du compteur vers le processus d’acceptation à travers une file
d’attente interne
Limites du protocole X-on X-off
Le fonctionnement correcte d’un protocole dépend des
caractéristiques du canal
La perte ou le retard d’un message suspend introduit
un problème de dépassement
23
Limites du protocole X-on X-off
24
Protocole stop and wait
Résout le problème de dépassement mais pas celui de la
perte des données
25
Limites du protocole X-on X-off
t : temps de propagation
a : temps de réception (traitement et acceptation)
p : temps de transmission
L’émetteur nécessite un délai de (2t + a – p) pour chaque message transmit
(retard)
26
Protocole à fenêtre
Dans la phase d’initiation d’appel, le récepteur
peut informer l’émetteur de l’espace mémoire
réservé aux messages entrants
27
Protocole à fenêtre : canal idéal
29
Délais d’attente : timeouts
ARRÊT ET ATTENTE: Stop and Wait Protocol
L’émetteur envoie, attend acquittement
Si l’acquittement arrive, continue avec proch. message
Sinon (le message ou l’acquittement pourraient être
perdus!) renvoie message précédent
Problème: combien de temps attendre
Solution: établir un temps sur la base du temps
d’allée/retour du message et son acquittement (le
double?)
Minuterie: positionner , annuler
30
Faute usuelle,
l’émetteur et le récepteur utilisent tout les deux des
délais d’attente
32
Solutions proposées
Leçon n°1
La retransmission est initiée par l’une des deux entités
(émetteur ou récepteur)
En général la retransmission est à la responsabilité de
l’émetteur
l’émetteur (seul) sait avec certitude quand une nouv donnée a
été transmise
Leçon n°2
L’acquittement doit indiquer quel message a été acquitté,
même dans le cas de l’émission d’un message par période
Ajouter le numéro de séquence pour chaque message de
données ou de contrôle
33
Numérotation des séquences
Le numéro de séquence appartient à un intervalle fini,
il faut vérifier que le recyclage des numéros ne
perturbe pas le bon fonctionnement du protocole
34
Le protocole du bit alterné
(BA)
Le protocole BA est le 1er protocole qui fut spécifié en
utilisant la notion de modèle de transitions d’état
Article de Bartlett et Scantlebury dans Comm. ACM May
1969, disponible à partir de http://portal.acm.org/portal.cfm
• Excellent et fameux article, 2 pages seulement!
• Parfois cité comme 1er article dans l’ingénierie des protocoles
BA est un des plus simples protocoles de liaison données,
mais il
Démontre les principes fondamentaux de tous les protocoles de
liaison de données
Réussit à récupérer des erreurs de transmission
• Dans certaines limites…
Il a été utilisé dans un grand nombre d’études sur la
validation des protocoles
Cependant chaque étude dépend d’un formalisme
particulier
35
Découvrons le protocole du bit
alterné
Exigence: un protocole qui accepte une séquence
de paquets de données et les remet à l’autre côté
dans le même ordre
Message 0 0
1 1
2 2
3 3
36
Contrôle d’erreurs
Problème, le canal peut perdre des données
0 0
1 Le récepteur a perdu
l’ordre des messages
2 1
3 2
37
Compter les messages
Chaque message contient son numéro, de façon à ce
que le récepteur sache quel message il vient de
recevoir
38
Utilisation du bit alterné
Au début, les deux se mettent d’accord pour
commencer à 0
bit=0 Attend 0, OK
Message 0 0
1
Message 1
0 Attend 1, reçoit 0
2 Erreur
40
Protocole bit alterné: Arrêt et
attente cas normal
OK A
minuterie t annulée t
n messages transmis
D1
Message n B0
Positionne
Minuterie
Temporisation
Doit renvoyer n B0
n
A0
43
Protocole bit alterné: Arrêt et
attente
Cas de perte d’acquittement (OK)
D0
n
Positionne
Minuterie A0
Temporisation Attend 1: écarté
Doit renvoyer n D0
A0
44
Protocole bit alterné: Arrêt et
attente
Chevauchement de message! (OK)
n D0
Positionne
Minuterie
Temporisation
Doit renvoyer D0
n
Attend 1, reçoit 0
A0 Écarter
45
Protocole bit alterné: Arrêt et
attente
Chevauchement d’ack! (OK)
D0
n
Positionne
Minuterie
A0
Temporisation
Doit renvoyer D0
Attend 1, écarter
Attend ack de
0, OK D1
n+1 n+1
A1
46
Bit alterné unidirectionnel,
diagramme de transition
A B
48
Notations
Deux type de messages : mesg et ack
Format :
{ mesg, data, sequence number }
{ ack, sequence number }
mesg:o:s spécifie un message mesg avec un champ de
données o et un numéro de séquence s.
Toutes
49 les variables sont initiées à zéro
Problèmes
(montrant que ce protocole n’est pas parfait, comme attendu)
D0
n n
A0
n+1 D1 n+1
A1
50
Réceptions non spécifiées
dans BA
Que va faire l’envoyeur avec un A0 après avoir reçu un A1
lorsqu’il n’a rien envoyé?
Il pourrait l’écarter
• le récepteur recevra un deuxième D0 qu’il acquittera et ignorera
51
Et aussi…
Double chevauchement d’ACK
D0
n n
A0
n D0
A0
D1
n+1 n+1
A1
D0
A0
D1
52 D0 n’a pas été reçu, D1
sera écarté
Protocoles à fenêtre d’anticipation
(sliding window)
Le protocole du BA peut être généralisé en utilisant un
compteur de plusieurs bits: p. ex. 4 bits
56
Modèle de protocole de fenêtre
d’anticipation
Soit M l’intervalle des numéros de séquences disponibles et W
le budget initial des messages.
M est suffisamment large pour éviter les problèmes de
confusion dus au recyclage
L’émetteur doit mémoriser les messages non acquittés dans
cette fenêtre.
Deux vecteurs de valeurs binaires sont utilisés à ces fins :
busy[s] = true si le message avec le numéro de séquence s est
émit mais pas acquitté
store[s] = true si le message avec le numéro de séquence s est
le dernier message émit
Initialement, busy[s] = store[s] = true
57
Fonctionnement du protocole :
niveau émetteur
L’objectif peut être découpé en 3 sous objectifs
1. Transmission des messages
2. Traitements des acquittements
3. Retransmission des messages non acquittés
58
Organigramme BA coté émetteur
59
Fonctionnement du protocole :
niveau récepteur
Le récepteur est divisé en 2 processus :
1. Processus de réception : reçoit et stocke les messages
2. Processus d’acceptation : accepte et acquitte les messages en
utilisant les num de séquences pour les remettre dans l’ordre
62
Terminologie
le contrôle de flux utilisant des acquittements pour contrôler la
retransmission est désigné par ARQ (Automatic Repeat Request).
Trois variantes :
Stop-and-wait ARQ
Selective repeat ARQ
Go-back-N continuous ARQ
63
La couche liaison aujourd’hui
La couche liaison était très importante à l’époque où
les réseaux étaient lents et peu fiables (contrôle d’erreurs)
et les ressources de mémoire des noeuds étaient limitées (contrôle
de flux)
Aujourd’hui les réseaux sont très rapides, très fiables, et les
ressources de mémoire sont importantes
À fins d’efficacité et simplicité, beaucoup d’applications sont bâties
directement sur la couche physique (typiquement, IP)
Chose qui n’avait pas été prévue par les concepteurs de
l’architecture OSI!
Quel est le résultat dans le cas d’erreur?
Certaines applications ne sont pas sensible aux erreurs occasionnels
• p.ex. voix sur IP, multimédia
L’application peut être bâtie pour détecter et récupérer des erreurs à son
niveau
• p.ex. un programme de consultation de bases de données peut
reconnaître l’erreur car les données ne sont pas reçues dans le
64 format approprié et peut donc demander retransmission