Ingnierie des protocoles de communication

Haykal Tej
htej@gmx.de
Inst. Sup. dInformatique et des Technologies de Communication, Hammam Sousse Universit de Sousse
1

Chapitre 1
Gnralits sur les protocoles et les mthodes de gnie de protocoles

Protocoles de communication
Prambule Un protocole est un ensemble de rgles qui gouvernent l'interaction entre processus parallles dans les systmes distribus

La conception de protocoles n'est pas une discipline part, elle est lie la fois aux rseaux et l'ingnierie des systmes
Dcrire compltement et sans ambigut un protocole est difficile Prouver qu'un protocole est correct est une tche encore plus ardue => Le but du cours n'est pas d'enseigner de nouveaux protocoles, mais de montrer comment on peut (bien) les dcrire

Autopsie d'un accident

Accident du tunnel de Clayton, 1861
A

un train peut entrer dans le tunnel si le smaphore est vert en passant le smaphore, le train le met au rouge automatiquement ; en cas de dfaillance du systme, c'est l'oprateur qui agite un drapeau rouge c'est l'oprateur qui remet le smaphore au vert quand il est sur que le train a quitter le tunnel deux tlgraphes permettent aux oprateurs de s'changer quelques messages Train in tunnel Tunnel is clear Pour plus de scurit, un 3 message est prvu : "Has the train left the tunnel?"

Autopsie d'un accident

Accident du tunnel de Clayton, 1861 : ce qui s'est pass Un train passe le smaphore A (vert), mais le smaphore ne passe pas au rouge. L'oprateur ragit : il envoie le message "Train in tunnel" et agite un drapeau rouge pour arrter 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'arrte L'oprateur 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 prvu ce cas. Le problme pour l'oprateur A est maintenant de savoir quand les deux trains ont quitt le tunnel afin d'autoriser le 3 entrer. Pour alerter son collgue, l'oprateur A envoie le signal "Has the train left the tunnel?" Lorsque le premier train sort du tunnel, l'oprateur B rpond "Tunnel is clear" Ne sachant pas si les 2 trains ont quitt le tunnel, l'oprateur A attend un certain temps, puis autorise le 3 train entrer. Malheureusement, le conducteur du 2 train, qui avait vu le drapeau, s'tait arrt dans le tunnel. Aprs un certain temps de rflexion, il a mme fait marche arrire => 23 morts et 176 blesss

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 rcuprer la situation. L'ensemble des messages disponibles sur les tlgraphes tait incomplet. Le bon sens des oprateurs n'tait pas suffisant.

La raction est toujours la mme : I could not imagine that could ever happen Au dbut, beaucoup d'accidents taient dus au manque de moyens de communication, mais on a constat ensuite qu'il tait surtout trs difficile d'tablir des rgles non ambigus de communication.

Structure d'un protocole

Pour dfinir un protocole, nous devons dfinir un ensemble de rgles :

dfinir comment un message est encod comment une transmission est dmarre et termine, etc

Deux types d'erreurs sont difficiles viter :

la conception d'un ensemble incomplet de rgles (incompltude) la conception de rgles contradictoires (inconsistance)

Cela requiert :

de dfinir tous les lments essentiels du protocole une discipline pour les dfinir en sparant les lments indpendants

La vraie difficult vient du paralllisme. Le nombre de scnarios est en gnral norme et difficile apprhender

1.1. Pourquoi l'ingnierie des logiciels

Historique
Le gnie logiciel, en tant que discipline informatique, est n en octobre 1968 lors dune confrence de lOTAN GarmischPartenkirchen pour rpondre un problme qui devenait de plus en plus vident : dune part le logiciel nest pas fiable, dautre part il est incroyablement difficile de raliser dans les dlais prvus des logiciels satisfaisant leur cahier des charges discipline de lingnieur du logiciel, pour laider dvelopper des systmes informatiques fiables, i.e., satisfaisant leur cahier des charges, dans des dlais raisonnables gnie logiciel comme gnie chimique, gnie lectrique, gnie mcanique = ensemble des techniques, outils et mthodes visant optimiser et rationaliser la production du logiciel et son suivi

1.1. Pourquoi l'ingnierie des logiciels

Remarque :

les mthodes et techniques issues du gnie logiciel sont imposes par les autorits de certification pour le dveloppement de systmes critiques (avionique, nuclaire) normes de dveloppement de systmes (DO178B)

=> Pour continuer, quelques exemples de systmes complexes

1.1. Pourquoi l'ingnierie des logiciels

Exemples :

Le Systme de Navigation et d'Attaque d'un Rafale =

2 millions de lignes de codes ADA 50 quipements (numriques ou analogiques), 12 calculateurs Contraintes de temps < 1ms combinatoire des modes et des tats leve

Landing System : plus de 1014 tats possibles Side Displays Management : plus de 2.108 tats possibles

1/2 million dinstructions pour une exprience de physique des particules 1 million dinstructions dans un central tlphonique 50 millions dinstructions dans la navette spatiale

Ncessit de rigueur dans la conception

1.1. Pourquoi l'ingnierie des logiciels

Si l'on veut matriser le dveloppement de systmes logiciels fiables, il faut :

rdiger de faon claire les spcifications du systme (ce que l'on attend)
=> comment tre srs que ces spcifications sont compltes ? => comment tre srs que ces spcification sont cohrentes ?

valider/vrifier toutes les tapes du dveloppements

=> a-t-on des moyens de validation/vrification (mathmatiques)?

de rutiliser des sous-systmes dj raliss (mais pas n'importe comment)

=> a-t-on des rgles, des outils pour aider la rutilisation ?

ncessit dune base thorique et dune approche ingnierie (science de lingnieur) du logiciel

1.2. Elments de terminologie

Pour maximiser la qualit d'un systme il faut...

Introduction d'un cycle de vie :

identifier un ensemble d'tape importante dans le dveloppement, et des documents importants analyse de besoins, spcification, conception, programmation, intgration ranger ses tapes dans le temps et les unes par rapport aux autres => cycles en cascade, en V, en Y, en spirale

Pourquoi des techniques formelles

Techniques formelles :

reposent sur des fondements mathmatiques expression mathmatique des objets du dveloppement (le comportement des systmes) expression mathmatique des proprits expression mathmatique des preuves permettent l'analyse (mathmatique) du comportement d'un systme

Remarque :
certains organismes imposent dj l'utilisation de techniques mathmatiques dans le dveloppement de systmes informatiques : dans le domaine de la scurit : obligation d'utiliser des mthodes formelles pour certains niveaux de scurit dans le ferroviaire (mtro Mtor)

Qu'est-ce qu'une technique formelle

Qu'apportent les techniques formelles ?
Les bases mathmatiques (logique, thorie des ensembles) dune technique formelle fournissent les notions de consistance, cohrence

partir d'une spcification S, on ne peut pas dduire "a" et "non a"

Une autre spcification globale activit de spcification vrification d'quivalence Spcification globale Architecture et spcification des composants Programme Axe du dveloppement

Besoins des utilisateurs

vrification de consistance

Qu'est-ce qu'une technique formelle

Qu'apportent les techniques formelles ?
Les bases mathmatiques (logique, thorie des ensembles) dune technique formelle fournissent les notions de correction d'une implmentation par rapport une spcification

il est possible de dcider si un programme P implmente une spcification S

activit de spcification

activit de conception

activit de programmation

Besoins des utilisateurs

Spcification globale

Architecture et spcification des composants

Programme

Axe du dveloppement

vrification

vrification

Qu'est-ce qu'une technique formelle

Que n'apportent pas les techniques formelles ?
La dmonstration de la validit de la spcification globale par rapport aux besoins de l'utilisateur est impossible
=> parce que les besoins de l'utilisateurs ne sont pas exprims en termes mathmatiques !
activit de spcification Architecture et spcification des composants

Besoins des utilisateurs

Spcification globale

Programme

Axe du dveloppement

validation Preuves impossibles

Qu'est-ce qu'une technique formelle

En rsum, ce que peuvent et ne peuvent pas les techniques formelles
activit de spcification

activit de conception

activit de programmation

Besoins des utilisateurs

Spcification globale

Architecture et spcification des composants vrification vrification

Programme

Axe du dveloppement

validation
Preuves impossibles vrification

Preuves possibles

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

Analyse de modles, Model Checking

Modle M
byte n; proctype Aap() { do :: n++ :: noot!MIES od }

Proprit [] (n<3)

Espace dtats

Analyseur

M |

Explosion dtats.

OUI Proprit satisfaite

NON, + contre_exemple

19

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

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

Protocoles de communication

Protocoles de communication
Prambule
Un protocole est un ensemble de rgles qui gouvernent l'interaction entre processus parallles dans les systmes distribus La conception de protocoles n'est pas une discipline part, elle est lie la fois aux rseaux et l'ingnierie des systmes Dcrire compltement et sans ambigut un protocole est difficile Prouver qu'un protocole est correct est une tche encore plus ardue => Le but du cours n'est pas d'enseigner de nouveaux protocoles, mais de montrer comment on peut (bien) les dcrire

Protocoles de Communication
Protocole Rseau:

Les protocoles peuvent etre implments en matriel et/ou logiciel. EIA-232-D est un protocole faisant partie de la couche physique implment en materiel. Les protocoles TCP/IP sont implments en logiciel.

Protocol Data Units (PDU)

Les entits communicantes changent des fragments formatts selon le protocole utilis. Chaque fragment est une unit de donne du protocole (Protocole Data Unit ou PDU) Chaque PDU contient: Header (entte): Spcifie comment traiter et router le reste du PDU Message: le contenu du PDU Trailer (queue) sert en gnral pour le contrle derreurs.
Header Message Trailer

Structure d'un protocole

Pour dfinir un protocole, nous devons dfinir un ensemble de rgles :

dfinir comment un message est encod comment une transmission est dmarre et termine, etc

Deux types d'erreurs sont difficiles viter :

la conception d'un ensemble incomplet de rgles (incompltude) la conception de rgles contradictoires (inconsistance)
de dfinir tous les lments essentiels du protocole une discipline pour les dfinir en sparant les lments indpendants

Cela requiert :

La vraie difficult vient du paralllisme. Le nombre de scnarios est en gnral norme et difficile apprhender

Structure d'un protocole

Les Cinq lments d'un protocole

Le service fournir par le protocole Les hypothses sur l'environnement dans lequel le protocole s'excute Le vocabulaire des messages utilis par le protocole Le format de chaque message Les rgles procdurales utilises durant la communication

La 5 partie est la plus dlicate dfinir et la plus difficile vrifier.

Structure d'un protocole

Un exemple 1. Le service :

Transfert de fichiers de texte comme squences de caractres via une ligne tlphonique en se protgeant contre les erreurs de transmission (suppose toutes dtectables) Bidirectionnel : 2 transferts en sens opposs possibles

2. Les hypothses : Compos de 2 utilisateurs et d'un canal de transmission On suppose que chaque utilisateur peut soumettre une requte et attendre qu'elle s'excute Le canal peut modifier les messages, mais pas les perdre, les ddoubler, les rarranger, ni en insrer un autre. 3. Vocabulaire : trois messages ack : un message + un acquit positif nak : un message + un acquit ngatif err : un message erron

Structure d'un protocole

Un exemple (suite) 4. Les formats :

Chaque message a un champ de contrle identifiant le type de message et un champ de donnes avec le code de caractre :
Type PDU is record control : tag, data : char endrecord
Type tag is {ack, nak, err}

Structure d'un protocole

Un exemple (suite) 5. Les rgles procdurales :

Soit 2 entits A et B
1. Si la rception prcdente est sans erreur, le prochain message sur le canal oppos contiendra un acquit positif. 2. Si la rception prcdente est errone, le prochain message sur le canal oppos contiendra un acquit ngatif. 3. Si la rception prcdente est errone ou contient un acquit ngatif, le prochain message sera une retransmission du message mis prcdemment; sinon, ce sera un nouveau message 4. Si un utilisateur n'a pas de caractre mettre, il peut envoyer un caractre null 5. A dmarre le transfert.

Structure d'un protocole

Notion de rgles procdurales

Exprimes au niveau d'abstraction adquat (pas de dtail inutile (codage)) Doivent tre compltes, consistantes et non ambigus
=> ncessite un formalisme ou un langage appropri Il n'existe pas de mthode permettant de s'assurer a priori de la compltude et de la consistance des rgles => vrification a posteriori

La difficult vient du paralllisme

=> Les diagrammes de squences ne conviennent pas. Ils permettent au mieux d'illustrer un scnario d'erreur.

Un protocole n'est pas correct dans l'absolu ; un protocole est correct par rapport un ensemble de proprits (la spcification de son service)
=> Ncessit de formaliser les proprits ou le service attendu

Conception et description couches

32

Conception couches des protocoles

Un protocole contient normalement un grand nombre de fonctionnalits Pourrait tre dfini comme un seul programme, mais ceci serait excessivement complexe Le manque de modularit rendrait aussi difficile lchange de modules prfabriqus entre compagnies

33

Couches OSI

Rf: http://www.irisa.fr/armor/lesmembres/cousin/Enseignement/Reseaux-generalites/Cours/4-3.htm

34

Modle de rfrence Open Systems Interconnection

35

Fonctionnement Global

36

Entits OSI

N+1-Protocol Entity N-SDUs N-SAP N+1-PDUs

N+1-Protocol Entity N-SDUs N-SAP

N-Service Provider

SAP: Service Access Point

37

Entits OSI
Notion de service : modle en couches

Le service est une dfinition fonctionnelle de l'interface entre couches Liste des primitives avec paramtres Ordonnancement permis des primitives Le service N est une abstraction des couches de protocole infrieures.

Entits OSI
Notion d'environnement : abstraction des couches suprieures et infrieures

Centrage sur une couche N et un protocole N Les couches suprieures sont vues comme des utilisateurs abstraits Les couches infrieures sont vues comme un milieu de transmission. Il dcrit les hypothses qui caractrisent ces couches (pertes, doublons possibles, ) Le protocole N dcrit le fonctionnement des entits N (A et B) en raction aux primitives de service N et aux PDU N venant de l'entit homologue via le milieu de transmission (mdium). L'environnement d'un protocole est compos des utilisateurs et du milieu de transmission.

Service Data Units (SDUs)

Request : Une entit sollicite un service Indication : Une entit est informe d'une demande de service Response : Une entit a rendu le service, si possible Confirmation : Une entit est informe que le service a t rendu

SAP

SAP

REQUEST

INDICATION

Service non confirm

Service confirm

CONFIRMATION

RESPONSE

40

Mode non connect (connectionless)

1 seule phase:

le transfert de donnes

chaque unit de transfert de donnes est achemine indpendamment les entits communicantes ne mmorisent rien ("memoryless"). les messages changes sont auto-suffisants ("selfcontent") pas dacquittement de messages (no ack) exemple: datagrammes en IP

43

Mode Connect (connection-oriented)

3 phases : phase d'tablissement de la connexion phase de transfert de donnes phase de libration de la connexion un contexte (rparti) est partag par les membres de la connexion : par exemple : le numro du paquet permet (facilite) le contrle et la gestion du transfert de donnes : contrle d'erreur, contrle de flux, maintien en squence, etc. les messages changs comportent des informations qui ne sont utilisables que grce la connaissance de ce contexte : par exemple : le numro de paquet / la largeur de la fentre coulissante Exemple de protocole utilisant le mode connect:TCP
44