INSTITUT NATIONAL POLYTECHNIQUE DE GRENOBLE
N◦ attribue´ par la bibliothe`que
.........................................
The`se
pour obtenir le grade
de Docteur de l’INPG
pre´pare´e a` Dassault Syste`mes et au laboratoire
SIRAC (INRIA Rhoˆnes-Alpes) dans le cadre de l’e´cole doctorale
« Mathe´matiques, sciences et technologies de l’information, informatique »,
spe´cialite´ « Informatique : syste`mes et communications », pre´sente´e
et soutenue publiquement le 9 septembre 2002 par
Nicolas Esposito
Coopeer : une architecture d’e´gal a`
e´gal pour la conception collaborative
—
Me´thode optimiste de re´solution automatique des
conflits pour la cohe´rence de donne´es re´plique´es
Directeur de the`se : Michel Riveill
Jury :
Jacques Mossie`re Pre´sident
Bernadette Charron-Bost Rapporteur
Christian Toinard Rapporteur
Michel Riveill Directeur
Daniel Hagimont Examinateur
Arnaud Ribadeau-Dumas Examinateur

Avant-propos
Les travaux de recherche de cette the`se ont principalement e´te´ re´alise´s
au sein du service de recherche1 de la socie´te´ Dassault Syste`mes2 dans le
cadre d’une bourse CIFRE. Les re´sultats de ces travaux ont fait l’objet de
deux de´poˆts de brevet [96, 97], ce qui a largement retarde´ la possibilite´ de
publication.
Note : les figures et les tableaux repris dans ce document et traduits
de l’anglais vers le franc¸ais apparaissent en versions originales en annexe C
(page 97).
Je remercie mon directeur de the`se (Michel Riveill), les membres du
jury pour leur richesse de discussion, ceux qui ont rendu cette the`se possible
a` Dassault Syste`mes (Ste´phane Decle´e, Alan Hudin et Arnaud Ribadeau
Dumas), ceux qui ont participe´ au projet (ValentinChartier, FlorentCar-
pentier, Se´bastien Lagarrigue, Nizar Es-Skali et Alexandru Popescu),
les relecteurs (Raphae¨l Leblanc, Lo¨ıc Lefeuvre, Jean Buffet, David Le-
sage et Danielle Esposito), Nicolas Salzmann, Renaud Sirdey et Chrys-
telle.
1Service Recherche et nouvelles technologies (division Strate´gie et recherche, de´parte-
ment Recherche et de´veloppement).
2http://www.3ds.com/
1

2 AVANT-PROPOS

Table des matie`res
Avant-propos 1
Introduction 11
1 Contexte de la conception collaborative 13
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2 Contraintes lie´es aux applications de CAO . . . . . . . . . . . 13
1.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2.2 Poids des donne´es et longueur des calculs . . . . . . . . 13
1.2.3 Complexite´ de l’architecture . . . . . . . . . . . . . . . 14
1.2.4 Complexite´ du mode`le de donne´es . . . . . . . . . . . . 15
1.2.5 Nommage ge´ne´rique . . . . . . . . . . . . . . . . . . . 16
1.2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3 Gestion de la cohe´rence de donne´es re´plique´es . . . . . . . . . 18
1.3.1 Pre´sentation du proble`me . . . . . . . . . . . . . . . . 18
1.3.2 Contexte social . . . . . . . . . . . . . . . . . . . . . . 19
1.4 Architecture re´seau . . . . . . . . . . . . . . . . . . . . . . . . 20
1.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 20
1.4.2 Client/serveur . . . . . . . . . . . . . . . . . . . . . . . 21
1.4.3 D’e´gal a` e´gal . . . . . . . . . . . . . . . . . . . . . . . 22
1.4.4 Comparaison . . . . . . . . . . . . . . . . . . . . . . . 22
1.4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2 Solutions de conception collaborative 25
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2 Produits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.1 Partage d’application . . . . . . . . . . . . . . . . . . . 26
2.2.2 Partage de donne´es . . . . . . . . . . . . . . . . . . . . 27
2.2.3 Re´fe´rences . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 28
3

4 TABLE DES MATIE`RES
2.3 Recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.2 Projets . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 34
3 Une architecture d’e´gal a` e´gal 37
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2 Premier sce´nario de collaboration . . . . . . . . . . . . . . . . 37
3.3 Architecture re´seau . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4 Transmission des ope´rations . . . . . . . . . . . . . . . . . . . 38
3.5 Composant de partage de donne´es . . . . . . . . . . . . . . . . 38
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4 Proble`me de la gestion des conflits 41
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2 Conflits d’ordonnancement . . . . . . . . . . . . . . . . . . . . 41
4.3 Conflits de simultane´ite´ . . . . . . . . . . . . . . . . . . . . . . 41
4.4 Exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.5 Ordonnancement et TCP/IP . . . . . . . . . . . . . . . . . . . 42
4.6 Respect de l’intention de l’utilisateur . . . . . . . . . . . . . . 43
4.7 Contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.8 Autres caracte´ristiques . . . . . . . . . . . . . . . . . . . . . . 45
4.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5 E´tat de l’art 47
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2 Syste`me distribue´/re´parti . . . . . . . . . . . . . . . . . . . . 47
5.3 Temps logique . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 49
5.3.2 De´pendance causale . . . . . . . . . . . . . . . . . . . . 49
5.3.3 Horloges de Lamport . . . . . . . . . . . . . . . . . . . 49
5.3.4 Historiques et graphes de de´pendance . . . . . . . . . . 50
5.3.5 Horloges vectorielles . . . . . . . . . . . . . . . . . . . 50
5.3.6 Matrices . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.4 Proble`mes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.4.1 Exclusion mutuelle . . . . . . . . . . . . . . . . . . . . 52
5.4.2 E´lection . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.4.3 Terminaison . . . . . . . . . . . . . . . . . . . . . . . . 53
5.4.4 Communication par se´quenceur . . . . . . . . . . . . . 53
5.4.5 Communication fiable . . . . . . . . . . . . . . . . . . 54
5.4.6 Communication causale . . . . . . . . . . . . . . . . . 54

TABLE DES MATIE`RES 5
5.5 Controˆle de la concurrence . . . . . . . . . . . . . . . . . . . . 56
5.5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 56
5.5.2 Cohe´rence . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.5.3 Approches pessimistes . . . . . . . . . . . . . . . . . . 58
5.5.4 Transformation d’ope´ration . . . . . . . . . . . . . . . 58
5.5.5 Exe´cution re´versible . . . . . . . . . . . . . . . . . . . 60
5.5.6 Versions multiples . . . . . . . . . . . . . . . . . . . . . 60
5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6 Une me´thode de gestion des conflits 63
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.2 Principes de la me´thode . . . . . . . . . . . . . . . . . . . . . 63
6.3 Algorithme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.3.1 Contenu d’un message . . . . . . . . . . . . . . . . . . 66
6.3.2 Contenu d’une estampille . . . . . . . . . . . . . . . . . 66
6.3.3 Structures de donne´es pour chaque machine . . . . . . 66
6.3.4 E´mission (l’ope´ration est fournie en entre´e) . . . . . . 66
6.3.5 Re´ception (le message est fourni en entre´e) . . . . . . 66
6.3.6 Traitement (le message est fourni en entre´e) . . . . . . 66
6.3.7 Exe´cution (le message est fourni en entre´e) . . . . . . 67
6.3.8 Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.4 Exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.5 Gestion des priorite´s . . . . . . . . . . . . . . . . . . . . . . . 72
6.6 Impact sur l’interface utilisateur . . . . . . . . . . . . . . . . . 72
6.7 Applications et extensions . . . . . . . . . . . . . . . . . . . . 73
6.8 Re´sultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7 Gestion du groupe et tole´rance aux pannes 79
7.1 Pre´ambule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
7.2 Tole´rance aux pannes . . . . . . . . . . . . . . . . . . . . . . . 79
7.2.1 Pre´sentation du proble`me . . . . . . . . . . . . . . . . 79
7.2.2 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.2.3 Un me´canisme de tole´rance aux pannes . . . . . . . . . 81
7.2.4 Algorithme . . . . . . . . . . . . . . . . . . . . . . . . 81
7.2.5 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.3 Gestion du groupe . . . . . . . . . . . . . . . . . . . . . . . . 82
7.3.1 Pre´sentation du proble`me . . . . . . . . . . . . . . . . 82
7.3.2 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.3.3 Deux me´canismes de connexion . . . . . . . . . . . . . 83
7.3.4 Algorithme de notre second me´canisme . . . . . . . . . 84

6 TABLE DES MATIE`RES
7.3.5 Exemple pour notre second me´canisme . . . . . . . . . 84
7.3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 85
8 Conclusion 87
8.1 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
8.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
A Algorithme en pseudo code 91
B Arguments de validation 93
B.1 Syste`me de datation . . . . . . . . . . . . . . . . . . . . . . . 93
B.1.1 Pre´ce´dence causale directe . . . . . . . . . . . . . . . . 93
B.1.2 De´tection de la concurrence . . . . . . . . . . . . . . . 93
B.2 Gestion des conflits . . . . . . . . . . . . . . . . . . . . . . . . 94
B.2.1 Ordonnancement . . . . . . . . . . . . . . . . . . . . . 94
B.2.2 Simultane´ite´ . . . . . . . . . . . . . . . . . . . . . . . . 94
B.2.3 Priorite´s . . . . . . . . . . . . . . . . . . . . . . . . . . 94
B.3 Diffusion ordonne´e . . . . . . . . . . . . . . . . . . . . . . . . 94
B.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 94
B.3.2 Proprie´te´ de suˆrete´ . . . . . . . . . . . . . . . . . . . . 94
B.3.3 Proprie´te´ de vivacite´ . . . . . . . . . . . . . . . . . . . 95
C Versions originales 97
Bibliographie 101
Index 110

Table des figures
1.1 SolidWorks, une application de CAO largement diffuse´e. . . . 14
1.2 Vision simplifie´e d’une application de CAO. . . . . . . . . . . 15
1.3 Exemple d’arbre de construction avec la ge´ome´trie associe´e. . 16
1.4 Exemple d’utilisation du langage Cell Descriptor. . . . . . . . 18
1.5 Exemple n◦ 1 de causalite´ non respecte´e. . . . . . . . . . . . . 19
1.6 Exemple n◦ 2 de causalite´ non respecte´e. . . . . . . . . . . . . 20
1.7 Architectures client/serveur et d’e´gal a` e´gal. . . . . . . . . . . 21
1.8 Exemple d’architecture hybride. . . . . . . . . . . . . . . . . . 24
2.1 Cohe´rence via partage d’e´tat [59]. . . . . . . . . . . . . . . . . 25
2.2 Diffe´rentes approches pour une confe´rence de conception [18]. . 26
2.3 Conception d’une poubelle avec Alibre Design. . . . . . . . . . 28
3.1 Inte´gration du composant Distributeur. . . . . . . . . . . . . . 39
4.1 Conflit d’ordonnancement. . . . . . . . . . . . . . . . . . . . . 42
4.2 Conflit de simultane´ite´. . . . . . . . . . . . . . . . . . . . . . . 42
4.3 Exemple de conflit d’ordonnancement. . . . . . . . . . . . . . 43
4.4 Exemple de conflit de simultane´ite´. . . . . . . . . . . . . . . . 43
4.5 Conflit d’ordonnancement avec trois machines. . . . . . . . . . 44
4.6 Exemple de non respect de l’intention de l’utilisateur. . . . . . 45
5.1 Exemples de topologies fre´quemment utilise´es [86]. . . . . . . . 48
5.2 Trois types d’e´ve´nements dans un syste`me distribue´. . . . . . 48
5.3 Exemple simple d’utilisation des horloges. . . . . . . . . . . . 50
5.4 Exemple simple d’utilisation des vecteurs. . . . . . . . . . . . 51
5.5 Exemple simple d’utilisation des matrices. . . . . . . . . . . . 52
5.6 ABCAST utilise 3n messages pour une e´mission vers n sites. . 54
5.7 Re´ception, mise en attente, puis livraison d’un message. . . . . 55
5.8 Exemple d’exe´cution de CBCAST. . . . . . . . . . . . . . . . . 56
5.9 E´ve´nements concurrents (e et f). . . . . . . . . . . . . . . . . 56
5.10 Classification des approches de controˆle de la concurrence [9]. . 57
7

Liste des tableaux
1 Utilisation de la CAO a` travers le temps et l’espace [48, 20]. . 11
1.1 Comparaison des architectures client/serveur et d’e´gal a` e´gal. . 23
2.1 Exemples de produits utilisant le partage d’application. . . . . 26
2.2 Produits permettant la conception collaborative. . . . . . . . . 27
2.3 Projets de recherche en conception collaborative. . . . . . . . . 35
2.4 Le´gende du tableau 2.3. . . . . . . . . . . . . . . . . . . . . . 35
5.1 Niveaux d’optimisme pour le verrouillage [31]. . . . . . . . . . 57
5.2 Trois degre´s de cohe´rence [41]. . . . . . . . . . . . . . . . . . . 58
6.1 Exemple de crite`res pour calculer une priorite´ en fonction des
conditions de connexion. . . . . . . . . . . . . . . . . . . . . . 72
C.1 The use of CAD across time and space [48, 20]. . . . . . . . . 97
C.2 Levels of optimism for locking [31]. . . . . . . . . . . . . . . . 99
9

12 INTRODUCTION
dont le contenu des cellules peut comporter une se´mantique assez complexe).
Pour cela, nous partirons d’une premie`re proble´matique, le partage de
donne´es7, afin de mettre en e´vidence les proble`mes que cela pose :
– le chapitre 1 pre´sente le contexte de la conception collaborative ;
– le chapitre 2 fait un tour des solutions existantes ;
– le chapitre 3 de´crit l’architecture que nous choisissons comme base.
Puis, nous utiliserons ces proble`mes comme support de re´flexion pour e´laborer
une me´thode de gestion des conflits :
– le chapitre 4 pre´sente le proble`me de la gestion des conflits ;
– le chapitre 5 est un e´tat de l’art des diffe´rents aspects qui sont lie´s aux
syste`mes distribue´s et que nous avons a` notre disposition pour re´soudre
ce proble`me ;
– le chapitre 6 de´crit notre me´thode, Coopeer.
Enfin, nous e´tendrons cette me´thode de fac¸on a` ge´rer le groupe de travail et
la tole´rance aux pannes (chapitre 7) avant de conclure (chapitre 8).
7C’est-a`-dire permettre aux multiples instances de l’application pre´sente sur le re´seau
d’avoir acce`s aux meˆmes donne´es.

18CHAPITRE 1. CONTEXTE DE LA CONCEPTION COLLABORATIVE
Fig. 1.4 – Exemple d’utilisation du langage Cell Descriptor.
paragraphe d’un texte, reviendrait le plus souvent a` lui attribuer toute la
pie`ce tant les relations sont nombreuses.
1.3 Gestion de la cohe´rence de donne´es re´pli-
que´es
1.3.1 Pre´sentation du proble`me
On ne peut pas diviser l’arbre en sous parties inde´pendantes et l’on ne
peut donc pas permettre les ope´rations simultane´es.
En effet, toutes les ope´rations doivent eˆtre effectue´es exactement dans le
meˆme ordre sur toutes les machines, le proble`me e´tant d’obtenir strictement
le meˆme re´sultat chez tous les participants. Si deux features n’ont pas le
meˆme ordre dans l’arbre de construction sur deux machines diffe´rentes, le
re´sultat peut ne pas provoquer d’erreur mais eˆtre diffe´rent. L’e´tat global des
donne´es est alors incohe´rent, les re´plicats divergent.
Par exemple, si un utilisateur pose un conge´ avec propagation selon les
tangences (c1) sur une areˆte d’un cube et qu’un autre utilisateur pose, au
meˆme moment, un autre conge´ avec propagation minimale (c2) sur une areˆte

20CHAPITRE 1. CONTEXTE DE LA CONCEPTION COLLABORATIVE
Fig. 1.6 – Exemple n◦ 2 de causalite´ non respecte´e.
rait la construction d’une pie`ce me´canique, le lien social entre les participants
pouvant par exemple s’e´tablir graˆce a` une confe´rence te´le´phonique ou vide´o.
On conside`re ainsi les ope´rations simultane´es comme des e´ve´nements rela-
tivement peu fre´quents et dont les participants pourront comprendre qu’ils
ne´cessitent un traitement particulier [76].
1.4 Architecture re´seau
1.4.1 Introduction
Deux grands types d’architectures s’opposent lorsqu’il s’agit de collaborer
graˆce a` Internet : l’architecture client/serveur et l’architecture d’e´gal a` e´gal9
(voir figure 1.7).
9On dit aussi pair a` pair ou peer-to-peer en anglais.

1.4. ARCHITECTURE RE´SEAU 23
Client/serveur D’e´gal a` e´gal
Communication Transmission indirecte des
messages, ils passent tous par
le serveur ; deux clients ne
peuvent pas dialoguer entre
eux directement
Transmission directe des mes-
sages ; chaque client connaˆıt les
autres clients
Gestion
du groupe
Gestion centralise´e du groupe Gestion re´partie du groupe
Tole´rance
aux pannes
La session de travail collabo-
ratif se termine si le serveur
tombe en panne
La panne d’une des machines
ne pe´nalise pas la session de
travail collaboratif
Se´curite´ Les machines des participants
ne sont que clientes
Les machines des participants
doivent aussi eˆtre serveurs
Installation Un serveur est e´videmment
ne´cessaire, il doit faire l’ob-
jet d’un de´veloppement logiciel
spe´cifique et il doit aussi eˆtre
administre´
Les machines des participants
suffisent
Gestion des mes-
sages
Le serveur peut faciliter la ges-
tion des messages
Une gestion distribue´e sans as-
sistance est ne´cessaire
Tab. 1.1 – Comparaison des architectures client/serveur et d’e´gal a` e´gal.
1.4.5 Conclusion
L’architecture client/serveur pre´sente des contraintes fortes sur lesquelles
on ne peut pas revenir (communication, tole´rance aux pannes et serveur
en lui-meˆme). Par contre, les inconve´nients de l’architecture d’e´gal a` e´gal
(gestion du groupe, se´curite´ et gestion des messages) peuvent eˆtre contourne´s
si l’on est capable de mettre en place des me´canismes re´solvant ces proble`mes.
Nous choisissons donc cette solution.
Concernant la se´curite´, on peut compter sur les administrateurs syste`me
des entreprises utilisatrices pour limiter le port de´die´ a` l’application au pro-
tocole utilise´. Par ailleurs, nous n’abordons pas ici les proble`mes d’authen-
tification et d’encryption ; e´tant donne´ le nombre important de solutions
existantes, libre a` chacun d’utiliser la me´thode qui lui convient.
Notons enfin qu’une architecture hybride telle que celle de la figure 1.8
cumule des inconve´nients des deux autres types d’architectures (tole´rance
aux pannes, serveur en lui-meˆme, se´curite´ et gestion des messages). Nous ne
retiendrons donc pas cette solution.

2.2. PRODUITS 27
2.2.2 Partage de donne´es
Le partage de donne´es nous concerne plus dans le sens ou` chaque par-
ticipant dispose de l’application sur sa machine, contrairement au partage
d’application ou` l’on offre un acce`s multiple a` une meˆme application. Dans le
partage d’application, on fait une distinction entre la machine maˆıtre qui fait
tourner l’application et les machines esclaves. Ce n’est pas ne´cessaire dans
le partage de donne´es et on peut ainsi envisager des architectures d’e´gal a`
e´gal. Les solutions commerciales de partage de donne´es pre´sentent de fortes
restrictions (voir la synthe`se du tableau 2.2), tant en termes de gestion des
conflits qu’en termes de fonctionnalite´s.
Produit E´diteur Site Web
Alibre Design Alibre http://www.alibre.com/
(voir figure 2.3) Conception collaborative ou` il faut demander la main sur le
mode`le pour y apporter des modifications
IX SPeeD ImpactXoft http://www.impactxoft.com/
Conception collaborative dans laquelle chaque participant
envoie les modifications de son choix au moment ou` il le
de´sire ; les participants doivent ge´rer eux-meˆmes les conflits
OneSpace CoCreate http://www.cocreate.com/
Conception collaborative limite´e a` certains types de
modifications sur de la ge´ome´trie (a` ce niveau, on a perdu
les features) ; les conflits peuvent provoquer des erreurs
et l’intention des participants peut ne pas eˆtre respecte´e
Tab. 2.2 – Produits permettant la conception collaborative.
2.2.3 Re´fe´rences
Voici une se´lection de tests particulie`rement inte´ressants qui pre´sentent
des produits de conception collaborative :
– Greco (Joe), Real-Time 3D Collaboration, http://www.cadenceweb.
com/cadscope_zeroing/scopegreco.htm
– Greco (Joe), Alibre Design-Web-Based 3D CAD, mai 2000, http:
//www.cadenceweb.com/2000/0500/cadoptions0500.html
– Rowe (Jeffrey), Teamwork 24/7, juin 2000, http://www.mcadcafe.
com/MCADVision/June2000/Collaboration.html
– MacKrell (John), CoCreate OneSpace, fe´vrier 2001, http://www.
deskeng.com/articles/01/Feb/cover/main.htm
– Greco (Joe), The CAD Collaboration Trials, aouˆt 2001, http://cgw.
pennnet.com/Articles/Article_Display.cfm?Section=Articles&

30 CHAPITRE 2. SOLUTIONS DE CONCEPTION COLLABORATIVE
– composant de collaboration : VIPER [88].
Cocadam [38] :
– anne´e de publication : 1996 ;
– domaine : CAO ;
– architecture : re´plication des donne´es sur les clients et le serveur, trai-
tements sur les clients ;
– approche : il faut avoir la main sur le mode`le pour y apporter des
modifications ;
– niveau de partage : mode`le ;
– coˆte´ serveur : gestion des sessions, gestion de la ge´ome´trie, bases de
donne´es pour les sessions et la ge´ome´trie ;
– coˆte´ client : application de CAO (Anvil-5000), base de donne´es pour la
ge´ome´trie, composants de distribution ;
– composant de collaboration : proprie´taire.
DIVEdit [78] :
– anne´e de publication : 1996 ;
– domaine : mode´lisation 3D ;
– architecture : re´plication des donne´es sur les clients, traitements sur les
clients ;
– approche : un objet ne peut eˆtre modifie´ que par un participant a` la
fois ;
– niveau de partage : objets ;
– coˆte´ serveur : liste des sessions ;
– coˆte´ client : application DIVE de mode´lisation 3D ;
– composant de collaboration : DIVE [11] (qui utilise ISIS [7]).
Synchronous Collaborative Design [48] :
– anne´e de publication : 1997 ;
– domaine : CAO ;
– architecture : donne´es et traitements sur le serveur ;
– approche : il faut avoir la main sur le mode`le pour y apporter des
modifications ;
– niveau de partage : application ;
– coˆte´ serveur : base de donne´es Postgres, application de CAO (Auto-
CAD), outils d’annotation et de suivi des donne´es, espace de travail
partage´ ;
– coˆte´ client : client le´ger ;
– composant de collaboration : base´e sur X Share [53].
ARCADE [79] :

2.3. RECHERCHE 31
– anne´e de publication : 1997 ;
– domaine : CAO ;
– architecture : re´plication des donne´es sur les clients, traitements sur les
clients ;
– approche : un objet ne peut eˆtre modifie´ que par un participant a` la
fois ;
– niveau de partage : objets ;
– coˆte´ serveur : gestion des sessions, base de donne´es ;
– coˆte´ client : application de CAO proprie´taire (base´e sur le modeleur
ge´ome´trique ACIS) ;
– composant de collaboration : proprie´taire.
TOBACO [18, 92] :
– anne´es de publication : 1997 et 1999 ;
– domaine : CAO ;
– architecture : re´plication des donne´es sur les clients, traitements sur les
clients ;
– approche : il faut avoir la main sur le mode`le pour y apporter des
modifications ;
– niveau de partage : mode`le ;
– coˆte´ serveur : gestion et historique des sessions ;
– coˆte´ client : application de CAO proprie´taire [18] (base´e sur le modeleur
ge´ome´trique ACIS) ou AutoCAD augmente´ d’une extension [92] ;
– composant de collaboration : TOBACO [18].
DCEE [52] :
– anne´e de publication : 1998 ;
– domaine : CAO ;
– architecture : re´plication des donne´es sur les clients et le serveur, trai-
tements sur les clients ;
– approche : la se´lection d’un objet verrouille celui-ci ;
– niveau de partage : objets ;
– coˆte´ serveur : gestion des sessions, bases de donne´es ;
– coˆte´ client : environnement collaboratif d’inge´nierie ;
– composant de collaboration : proprie´taire.
CollIDE [56] :
– anne´e de publication : 1998 ;
– domaine : CAO ;
– architecture : re´plication des donne´es sur les clients et le serveur, trai-
tements sur les clients ;

2.3. RECHERCHE 35
Projets An Dm Dn Tr Ap Nv Sr Cl
Teledesign [76] 1994 C C C V E M - A C
Co-CAD [29] 1994 C C C V O S A
SVMU [89] 1995 S C C V O S A
Cocadam [38] 1996 C S C C V M S G B A B C
DIVEdit [78] 1996 M C C V O S A
SCD [48] 1997 C S S V A S B A F L
ARCADE [79] 1997 C C C V O S B A
TOBACO [18, 92] 97/99 C C C V M S H A
DCEE [52] 1998 C S C C V O S B A
CollIDE [56] 1998 C S C C P P S B A F
CSCW-Feature [80] 1998 C C C - M - A
WBC CAAD [4] 1999 A S C S P M S G B W F
NetFeature [45] 1999 C S C S - M S G B W
CSM [12] 1999 C S C S V P S G W
webSpiff [90, 91] 2000 C S S S D S G W W
Syco3D [57] 2001 C C C P P S A F
Tab. 2.3 – Projets de recherche en conception collaborative.
An Anne´e de publication
Dm Domaine C pour CAO, S pour sculpture et M pour mode´lisation 3D
Dn Donne´es S pour sur le serveur et C pour re´plication sur les clients
Tr Traitements S pour sur le serveur et C pour sur les clients
Ap Approche V pour verrouillage, P pour partitionnement, S pour
se´rialisation, E pour exe´cution re´versible et - pour pas de ges-
tion des conflits
Nv Niveau
de partage
O pour objets, M pour mode`le, A pour application, P pour
pie`ce d’un assemblage et D pour donne´es
Sr Coˆte´ serveur S pour gestion des sessions, G pour gestion de la ge´ome´trie, B
pour base de donne´es, A pour application de CAO ou autre,
H pour historique des sessions, W pour serveur Web et - pour
pas de serveur
Cl Coˆte´ client A pour application de CAO ou autre, B pour base de donne´es,
C pour composant de distribution, L pour client le´ger, F pour
feneˆtre supple´mentaire et W pour navigateur Web
SVMU Sculpture virtuelle multi-utilisateurs
SCD Synchronous Collaborative Design
WBC CAAD Web Based Collaborative CAAD
CSM Collaborative Solid Modelling
Tab. 2.4 – Le´gende du tableau 2.3.

38 CHAPITRE 3. UNE ARCHITECTURE D’E´GAL A` E´GAL
Lorsqu’un utilisateur de´cide de partager le mode`le qu’il est en train
d’e´diter, celui-ci est mis a` disposition sur le re´seau. Un autre utilisateur peut
alors interroger la machine du premier et choisir de rejoindre la session de
conception collaborative. L’ensemble des donne´es constituant le mode`le est
alors transfe´re´, ainsi que les informations concernant la session (en particulier
la liste des participants et l’historique).
Le groupe de travail est donc ge´re´ de fac¸on distribue´e. Chaque utilisateur
dispose de la liste des participants qui est mise a` jour de la fac¸on suivante :
lorsqu’un participant fourni le mode`le a` un nouvel arrivant, il informe les
autres de son arrive´e.
3.4 Transmission des ope´rations
Les donne´es sont re´plique´es sur chaque machine. Elles ne circulent pas
sur le re´seau1, ce sont les ope´rations qui y transitent. A` chaque fois qu’une
ope´ration est exe´cute´e, elle est transmise aux autres machines du groupe de
travail. De cette fac¸on, en partant des meˆmes donne´es et en y appliquant les
meˆmes ope´rations dans le meˆme ordre avec la meˆme application, on devrait
obtenir le meˆme re´sultat.
Les ope´rations que nous transmettons sont celles qui ont un impact sur
les donne´es (par exemple, le changement de point de vue n’est pas envoye´).
Nous devons envoyer un identifiant pour l’ope´ration, mais aussi le contexte
de son exe´cution. Par exemple, pour la suppression d’un e´le´ment de l’arbre
de construction, il faudra envoyer l’identifiant de l’ope´ration de suppression,
mais aussi l’identifiant de l’e´le´ment qui doit eˆtre de´truit.
Une ope´ration complexe peut eˆtre de´crite comme une suite d’ope´rations
e´le´mentaires sur les donne´es. Si une machine ne dispose pas de l’ope´ration,
il sera ainsi possible de lui communiquer sa description.
3.5 Composant de partage de donne´es
L’impact au niveau de l’architecture applicative correspond a` l’ajout d’un
composant de distribution, le Distributeur (voir figure 3.1), qui a les fonctions
suivantes :
– envoi des ope´rations locales aux autres participants ;
– re´ception des ope´rations des autres participants ;
– gestion de la session de travail collaboratif (notamment le groupe).
1Sauf lorsqu’un participant rejoint la session.

40 CHAPITRE 3. UNE ARCHITECTURE D’E´GAL A` E´GAL

Chapitre 4
Proble`me de la gestion des
conflits
4.1 Introduction
Comme nous l’avons vu, nous sommes en architecture d’e´gal a` e´gal. Les
donne´es sont re´plique´es et les ope´rations sont e´change´es entre les partici-
pants graˆce a` un composant de distribution. Ce composant de distribution,
qui permet principalement l’envoi a` tous les autres participants d’ope´rations
au sein de messages et leur re´ception, n’apporte pas de proprie´te´s particulie`re
au syste`me. On a notamment aucune assurance sur la fiabilite´ ou l’ordre des
messages. Sur cette base, les tests pratiques de notre imple´mentation ont
permis de valider la pre´sence de deux types de conflits : les conflits d’ordon-
nancement et les conflits de simultane´ite´. Dans ce chapitre, nous allons les
de´finir, puis nous pre´ciserons le cadre de notre intervention.
4.2 Conflits d’ordonnancement
Un conflit d’ordonnancement survient lorsqu’au moins deux messages sont
rec¸us par une machine dans un ordre diffe´rent de celui de l’e´mission (voir
figure 4.1).
4.3 Conflits de simultane´ite´
Un conflit de simultane´ite´ survient lorsqu’au moins deux ope´rations sont
effectue´es au meˆme moment sur deux machines diffe´rentes, c’est-a`-dire lors-
qu’aucune ne de´pend de l’autre (voir figure 4.2).
41

44 CHAPITRE 4. PROBLE`ME DE LA GESTION DES CONFLITS
Fig. 4.5 – Conflit d’ordonnancement avec trois machines.
ture client/serveur, cet ordre peut-eˆtre donne´ par le serveur.
Si la seconde ope´ration provoque une erreur, on peut pre´venir son auteur
qu’il n’est pas possible de l’exe´cuter correctement (par exemple : la modifi-
cation d’un e´le´ment apre`s sa suppression). Si elle ne provoque pas d’erreur,
il se peut qu’il n’y ait pas de proble`me, mais il se peut aussi que l’utilisateur
constate une diffe´rence entre ce qu’il voulait faire et ce qui a effectivement
e´te´ fait. Dans ce cas, le syste`me ne respecte pas son intention.
La figure 4.6, sur la base des exemples de la section 1.3.1 (page 18),
pre´sente un cas d’intention non respecte´e.
4.7 Contraintes
Voici les contraintes que nous nous fixons pour ge´rer les conflits :
– ge´rer les conflits d’ordonnancement ;
– ge´rer les conflits de simultane´ite´ ;
– re´soudre les conflits de fac¸on automatique ;
– ne pas allonger le temps de re´ponse de l’application, les ope´rations
doivent eˆtre exe´cute´es de`s qu’elles sont invoque´es ;
– ne pas ajouter d’interme´diaire pour la transmission des messages ;
– ne pas augmenter la taille des messages de manie`re significative ;
– limiter l’ajout de messages en plus de la transmission des ope´rations ;
– conserver l’architecture d’e´gal a` e´gal ;
– ne pas tenir compte de la se´mantique des ope´rations ;
– respecter l’intention de l’utilisateur ;
On ajoutera aussi par la suite :
– autoriser la connexion et la de´connexion d’utilisateurs en cours de ses-
sion ;
– eˆtre tole´rant aux pannes.

Chapitre 5
E´tat de l’art
5.1 Introduction
Ce chapitre est un e´tat de l’art des diffe´rents aspects qui sont lie´s aux
syste`mes distribue´s et que nous avons a` notre disposition pour ge´rer les
conflits. Apre`s avoir introduit les syste`mes distribue´s, nous verrons com-
ment dater les e´ve´nements. Nous e´tudierons ensuite les principaux proble`mes
des syste`mes distribue´s avant de s’inte´resser en particulier au controˆle de la
concurrence.
5.2 Syste`me distribue´/re´parti
Le syste`me qui nous concerne (les machines des participants relie´es en
re´seau) est assimilable a` un syste`me distribue´ [46]. Il s’agit en l’occurrence
d’un syste`me re´parti (en opposition a` un syste`me centralise´) dont chaque
site est lie´ a` tous les autres (architecture d’e´gal a` e´gal). Le re´seau est donc
comple`tement maille´. En the´orie des graphes, on parle de clique [30] (voir
figure 5.1 [86]).
Dans un syste`me distribue´, on distingue trois types d’e´ve´nements (voir
figure 5.2) :
– les e´ve´nements internes (e) ;
– les e´ve´nements d’e´mission de message (f) ;
– les e´ve´nements de re´ception de message (g).
Par ailleurs, on utilise le vocabulaire suivant pour de´signer les entite´s qui
s’e´changent des messages : processeurs, processus ou sites. Il s’agit pour nous
des machines des participants (leur micro-ordinateur, leur station de travail).
Les participants, quant a` eux, peuvent eˆtre de´finis en tant qu’utilisateurs qui
prennent part a` une session de travail collaboratif.
47

48 CHAPITRE 5. E´TAT DE L’ART
Ring Tree
CliqueStar Hypercube
Fig. 5.1 – Exemples de topologies fre´quemment utilise´es [86].
f
e g
Fig. 5.2 – Trois types d’e´ve´nements dans un syste`me distribue´.
Dans un tel syste`me, les horloges physiques1 des machines ne sont pas
synchronise´es. On ne peut donc pas compter sur ces horloges pour dater les
e´ve´nements. On ne peut pas non plus connaˆıtre le temps de transmission d’un
message. A` de´faut de temps physique fiable, il nous faut e´tablir un temps
logique. C’est ce que nous verrons dans la section suivante. Nous verrons en-
suite quelques-uns des principaux algorithmes distribue´s avant de s’inte´resser
plus particulie`rement au controˆle de la concurrence.
1Anne´e, mois, jour, heures, minutes, secondes, etc.

5.3. TEMPS LOGIQUE 51
L’ide´e est de remplacer l’historique d’un site par un entier (le nombre
d’e´ve´nements). Les historiques de tous les sites peuvent ainsi eˆtre repre´sente´s
par un vecteur d’entiers dont la taille est e´gal au nombre de sites (n).
Un vecteur local (v) de taille n est initialise´ a` 0 sur chaque site. A` chaque
e´ve´nement interne, d’e´mission de message ou de re´ception de message sur le
site s, vs[s] est incre´mente´ de 1. Les messages sont estampille´s avec ce vecteur
qui repre´sente leur date d’e´mission. A` la re´ception d’un message estampille´
avec vs′ , on met a` jour vs de la fac¸on suivante (voir figure 5.4) :
∀i : vs[i] = max(vs[i], vs′ [i])
1, 2
1, 0
1, 1
2, 00, 0
0, 0
3, 2
Fig. 5.4 – Exemple simple d’utilisation des vecteurs.
L’ordre obtenu est partiel [22, 23, 50, 63, 64]. Pour deux vecteurs v et v′
de dimension n, on a :
v ≤ v′ ⇔ ∀i : v[i] ≤ v[i]
v < v′ ⇔ v ≤ v′ et v 6= v′
v ‖ v′ ⇔ ¬(v < v′) et ¬(v′ < v)
Cet ordre co¨ıncide avec la relation de pre´ce´dence causale entre les e´ve´ne-
ments. Pour e date´ par v(e) et f date´ par v(f), on a :
e → f ⇔ v(e) < v(f)
e ‖ f ⇔ v(e) ‖ v(f)
D’autre part, Bernadette Charron-Bost a montre´ en 1991 qu’un ordre
partiel ne pouvait pas eˆtre caracte´rise´ si la taille des horloges logiques n’e´tait
pas au moins e´gale au nombre de sites. Notons aussi que la mise en œuvre
des horloges logiques ne convient pas a` toutes les utilisations. Des travaux
en ont montre´ les limitations [16, 25, 69].
5.3.6 Matrices
Les matrices [67, 61, 72, 65, 74, 94, 26] sont un autre type d’horloges
logiques.

52 CHAPITRE 5. E´TAT DE L’ART
Une matrice locale (m) de n sur n est initialise´e a` 0 sur chaque site. A`
chaque e´ve´nement interne, d’e´mission de message ou de re´ception de message
sur le site s, ms[s, s] est incre´mente´ de 1. Les messages sont estampille´s avec
cette matrice qui repre´sente leur date d’e´mission. A` la re´ception d’un message
estampille´ avec ms′ , on met a` jour ms de la fac¸on suivante (voir figure 5.5) :
∀i : ms[s, i] = max(ms[s, i],ms′ [s′, i])
∀i, j : ms[i, j] = max(ms[i, j],ms′ [i, j])
1, 0
0, 0
0, 0
0, 0
0, 0
0, 0
2, 0
0, 0
1, 0
1, 1
1, 0
1, 2
3, 2
1, 2
Fig. 5.5 – Exemple simple d’utilisation des matrices.
Les matrices, plus comple`tes que les vecteurs, permettent de de´terminer
la proprie´te´ suivante : s peut savoir si tous les autres sites savent que s′
a progresse´ jusqu’au temps t. Cela permet de supprimer de l’information
obsole`te.
5.4 Proble`mes
5.4.1 Exclusion mutuelle
L’exclusion mutuelle permet de s’assurer qu’a` un instant donne´, un seul
site peut entrer en section critique (pour modifier les donne´es par exemple).
On peut aussi dire qu’ainsi, les sections critiques sont se´rialise´es. Pour cela,
on peut faire appel au principe des permissions [70, 47] (il faut obtenir la
permission de tous les sites pour entrer en section critique) ou au principe du
jeton [55, 62] (il faut posse´der le jeton pour entrer en section critique ; soit
le jeton circule sur un anneau, soit il faut le demander).
5.4.2 E´lection
L’e´lection consiste a` choisir un site (un seul parmi un ensemble de sites).
Par exemple, en cas de perte de jeton circulant, on peut e´lire le site qui doit

54 CHAPITRE 5. E´TAT DE L’ART
5.4.5 Communication fiable
Pour qu’un protocole de communication soit qualifie´ de fiable3, il doit eˆtre
tole´rant aux pannes des sites ou du syste`me de communication (un message
envoye´ a` un groupe de sites doit eˆtre rec¸u par tous les sites de ce groupe qui
ne sont pas en panne ou par aucun).
Une solution possible est de proce´der en deux phases (pre´paration puis
validation). C’est cette solution qui est mise en œuvre dans ABCAST [6, 7, 8],
un protocole de communication fiable du projet ISIS.
La distribution des messages se fait dans le meˆme ordre sur chaque site
(l’ordre est total). Chaque message est estampille´ avec une date d’e´mission
et un nume´ro de site e´metteur. Cette estampille est provisoire. Les sites qui
rec¸oivent le message le mettent en attente et renvoient un accuse´ de re´ception
avec une nouvelle estampille (phase de pre´paration). Lorsque l’e´metteur les
a tous rec¸us, il attribue au message une estampille de´finitive qu’il retransmet
aux destinataires (phase de validation). Ces derniers font la mise a` jour et
peuvent conside´rer le message comme preˆt a` eˆtre de´livre´. La livraison des
messages preˆts se fait dans l’ordre des estampilles de´finitives. En cas de panne
d’un e´metteur, il y a e´lection d’un remplac¸ant qui doit se charger de reprendre
le protocole. L’ordre de re´ception est uniforme, mais il peut eˆtre diffe´rent de
l’ordre d’e´mission et le couˆt de ce protocole est e´leve´ (voir figure 5.6).
Estampille
provisoire
Nouvelle
estampille
Estampille
définitive
Fig. 5.6 – ABCAST utilise 3n messages pour une e´mission vers n sites.
5.4.6 Communication causale
L’ordonnancement causal [6, 60, 75, 7, 65, 61] consiste a` livrer les messages
en suivant l’ordre causal : si le message m est envoye´ avant le message m′ alors
3Reliable en anglais.

5.5. CONTROˆLE DE LA CONCURRENCE 57
Contrôle de la concurrence
Optimiste Pessimiste
Contrôle décentraliséControl centralisé
Avec vote Sans vote
Passage de jeton
Unité de contrôle
Consensus
Vote pondéré
Écrire tous, lire
n'importe lequel
Vote avec témoin
Copie disponible
Vote dynamique
Vote par classe
Vote multidimensionel
Vote hiérarchique
Verrouillage
Passage de jeton
Transaction
Transformation
Schéma de codage
Protocole de grille
Fig. 5.10 – Classification des approches de controˆle de la concurrence [9].
concurrence. On parle aussi de me´thodes semi optimistes (voir tableau 5.1
[31]).
Niveau d’optimisme Peut manipuler Peut livrer
l’object pendant l’objet modifie´
l’attente de son pendant l’attente
verrouillage de son verrouillage
Non optimiste Non Non
Semi optimiste Oui Non
Optimiste Oui Oui
Tab. 5.1 – Niveaux d’optimisme pour le verrouillage [31].

58 CHAPITRE 5. E´TAT DE L’ART
5.5.2 Cohe´rence
La cohe´rence de donne´es re´plique´es peut se de´finir selon diffe´rents degre´s
[41, 68] : cohe´rence faible, causale ou forte (voir tableau 5.2 [41]).
Cohe´rence faible La mise a` jour de toute copie doit avoir lieu au bout
d’un temps fini (en pratique, on impose a` ce de´lai
une borne supe´rieure) ; ne´anmoins, on n’impose pas
de contraintes sur l’ordre des mises a` jour.
Cohe´rence causale Elle comple`te la cohe´rence faible par la contrainte
suivante : les modifications de toutes les copies
doivent eˆtre faites dans le meˆme ordre, de´fini par
l’ordre causal des mises a` jour.
Cohe´rence forte Toute consultation d’une copie quelconque doit
refle´ter le re´sultat de toutes les modifications
ante´rieures (au sens de l’ordre causal).
Tab. 5.2 – Trois degre´s de cohe´rence [41].
Selon ces de´finitions, nous sommes concerne´s par la cohe´rence faible puis-
que nous acceptons que les donne´es puissent eˆtre temporairement diffe´rentes
d’une machine a` l’autre (voir section 4.8, page 45).
5.5.3 Approches pessimistes
Les me´thodes pessimistes de controˆle de la concurrence ne´cessitent un
temps d’attente pour effectuer le verrouillage. On allonge ainsi le temps de
re´ponse de l’application, les ope´rations ne sont pas exe´cute´es de`s leur invo-
cation. Nous ne nous orienterons donc pas vers ce genre de me´thode.
5.5.4 Transformation d’ope´ration
La transformation d’ope´ration est une approche optimiste qui garantit
une cohe´rence causale. Elle consiste a` se´rialiser les ope´rations concurrentes
tout en respectant l’intention de l’utilisateur. L’exemple de la figure 5.11
[82] montre, sur une architecture centralise´e, le principe de cette approche.
Si les deux ope´rations concurrentes sont se´rialise´es sans transformation, le
re´sultat peut eˆtre incorrect. Si elles sont se´rialise´es avec transformation, le
re´sultat est correct. Dans ce cas, l’ope´ration qui arrive en seconde position est
transforme´e pour que son re´sultat soit conforme a` l’intention de l’utilisateur.
Ce type d’approche s’inte´resse a` la se´mantique des ope´rations (voir fi-
gure 5.12). En effet, pour transformer une ope´ration, on doit eˆtre capable

5.5. CONTROˆLE DE LA CONCURRENCE 59
Usager 1 Usager 2Objet
"lessystème de..."
insérer(4, ' ')
"les système de..."
"les systèmse de..."
insérer(11, 's')
A : résultat incorrect
Usager 1 Usager 2Objet
"lessystème de..."
insérer(4, ' ')
"les système de..."
"les systèmes de..."
insérer(11, 's')
B : résultat correct
insérer(12, 's')
Fig. 5.11 – Exe´cution d’ope´ration concurrentes [82].
d’en connaˆıtre a` l’avance le re´sultat. Le domaine d’application de cette ap-
proche est donc limite´ et nous ne pourrons pas l’utiliser puisque nous ne
sommes pas en mesure de pre´voir l’impact d’une ope´ration.
p
o
o' = T(o, p)
p' = T(p, o)
Fig. 5.12 – Gestion de la concurrence par transformation d’ope´ration.
Les me´thodes de transformation d’ope´ration peuvent utiliser diffe´rentes
techniques de datation. dOPT [19] utilise des horloges vectorielles (cette
me´thode ge`re deux ope´rations concurrentes, mais pas plus). REDUCE [83] et
SOCT2 [81, 82] utilisent aussi des horloges vectorielles. Mais LICRA [36, 37]
utilise un contexte de de´pendance directe.

60 CHAPITRE 5. E´TAT DE L’ART
5.5.5 Exe´cution re´versible
L’exe´cution re´versible [73] est un autre principe pour ge´rer les ope´rations
concurrentes de fac¸on optimiste. Les ope´rations sont date´es et sont e´xecute´es
dans l’ordre de re´ception. Si une ope´ration conflictuelle est rec¸ue (son estam-
pille est infe´rieure a` l’horloge locale) alors on annule la se´quence d’ope´ration
en conflit, puis on exe´cute l’ope´ration et enfin on refait la se´quence pre´ce´dente
(voir figure 5.13, le soulignement indique l’annulation de l’ope´ration). Les an-
nulations peuvent eˆtre ainsi eˆtre fre´quentes. On constate par ailleurs que les
ope´rations concurrentes sont se´rialise´es, ce qui peut eˆtre source de non-respect
de l’intention de l’utilisateur.
o p
p p, o, p
p
o
p, o, p
p
Fig. 5.13 – Gestion des conflits par exe´cution re´versible.
L’exe´cution re´versible est utilise´e dans ORESTE [39] (la me´thode de con-
troˆle de la concurrence d’un outil de dessin multi-utilisateur, GroupDesign
[40]). ORESTE limite le nombre d’annulations en utilisant la commutativite´
et le masquage des ope´rations (on s’inte´resse alors a` leur se´mantique, ce qui
nous interdit l’utilisation de cette me´thode).
5.5.6 Versions multiples
Une autre possibilite´ est de cre´er plusieurs versions des donne´es. Ce
concept de versions multiples permet de conserver le travail relatif aux ope´-
rations conflictuelles [84].
L’inte´reˆt des versions multiples est aussi de laisser se de´velopper des ver-
sions divergentes, par exemple suite a` la de´connexion d’un des participants,

5.6. CONCLUSION 61
pour une synchronisation ulte´rieure ou le choix par les participants d’une des
versions.
5.6 Conclusion
Nous avons vu que notre re´seau de machines est assimilable a` un syste`me
re´parti. On pourra y e´tablir un temps logique avec une simplification de
l’historique. Cette datation nous permettra d’ordonner les messages. Elle
nous permettra aussi de de´tecter les conflits de simultane´ite´. Mais nous ne
connaissons pas de me´thode optimiste re´pondant a` nos besoins pour traiter
ces derniers.

6.2. PRINCIPES DE LA ME´THODE 65
On pourra e´videmment y ajouter l’information ne´cessaire pour identifier de
fac¸on unique la session de travail collaboratif dont il s’agit. Et si d’autres
types de messages sont e´change´s au cours de cette session, on pourra aussi
ajouter une information de typage a` cette estampille.
Les messages sont ordonne´s de fac¸on simple, graˆce a` une liste d’attente
(voir figure 6.3, A1 de´signe l’exe´cution de l’ope´ration n◦ 1 du participant A
et ainsi de suite).
A2A1
A1
A2
B
A
Fig. 6.3 – Gestion de l’ordonnancement de Coopeer.
Des ope´rations simultane´es peuvent se produire, Coopeer se charge de les
ge´rer sans intervention des participants. Il s’agit donc d’une me´thode opti-
miste et automatique. L’application re´pond tout de suite, les ope´rations sont
exe´cute´es et e´ventuellement corrige´es. La gestion de la simultane´ite´ se base
sur des priorite´s attribue´es aux participants. Celles-ci de´terminent l’ope´ration
qui sera garde´e parmi les ope´rations simultane´es. Dans le cas le plus simple,
l’ope´ration du participant non-prioritaire est ignore´e alors que l’ope´ration du
participant prioritaire ne´cessite l’annulation de l’ope´ration pre´ce´dente (voir
figure 6.4, A est prioritaire sur B, le soulignement indique l’annulation de
l’ope´ration).
A1
B1 B1, A1
B
A
Fig. 6.4 – Gestion de la simultane´ite´ de Coopeer.
La section 6.4 (page 67) pre´sente des exemples plus complets base´s sur
l’algorithme de la section suivante. Cet algorithme est pre´sente´ de fac¸on non
formelle, mais une version en pseudo code se trouve en annexe (annexe A,
page 91), ainsi que des arguments de validation (annexe B, page 93).

66 CHAPITRE 6. UNE ME´THODE DE GESTION DES CONFLITS
6.3 Algorithme
6.3.1 Contenu d’un message
• Ope´ration.
• Estampille.
6.3.2 Contenu d’une estampille
• Identifiant d’e´metteur.
• Compteur d’ope´ration.
• Compteur d’annulation.
• Identifiant d’e´metteur du message pre´ce´dent.
• Compteur d’annulation du message pre´ce´dent.
6.3.3 Structures de donne´es pour chaque machine
• Identifiant d’e´metteur.
• Historique des messages correspondant aux ope´rations exe´cute´es.
• Liste de messages en attente.
• Compteur d’annulation.
6.3.4 E´mission (l’ope´ration est fournie en entre´e)
• Calcul d’une estampille pour l’ope´ration (compteur d’ope´ration = nom-
bre d’ope´rations dans l’historique).
• Constitution d’un message contenant l’ope´ration et l’estampille.
• Ajout du message a` l’historique.
• Retour du message pour qu’il puisse eˆtre diffuse´ aux autres participants.
6.3.5 Re´ception (le message est fourni en entre´e)
• Traitement du message.
• Traitement de chaque message de la liste de messages.
6.3.6 Traitement (le message est fourni en entre´e)
• Si le compteur est e´gal au nombre d’ope´rations dans l’historique + 1
et si l’e´metteur et le compteur d’annulation du message pre´ce´dent sont
e´gaux a` ceux de la dernie`re ope´ration de l’historique :
◦ Exe´cution de l’ope´ration.

68 CHAPITRE 6. UNE ME´THODE DE GESTION DES CONFLITS
A B C
Exe´cution de A1 Exe´cution de B1
Diffusion de A1 Diffusion de B1
(estampille = (estampille =
A, 1, 0, -, 0) B, 1, 0, -, 0)
Exe´cution de A2 Re´ception de A1 Re´ception de B1
Diffusion de A2 Annulation de B1 Exe´cution de B1
(estampille = Exe´cution de A1
A, 2, 0, A, 0)
Re´ception de B1 Re´ception de A2 Re´ception de A2
Mise en attente de B1 Exe´cution de A2 Mise en attente de A2
Re´ception de A1
Annulation de B1
Exe´cution de A1
Exe´cution de A2
qui e´tait en attente
Historiques de fin de session
A1, A2 A1, A2 A1, A2
A1 A2
B1 B1, A1 A2
B1 B1, A1
A2
B
C
A
Fig. 6.5 – Exemple n◦ 1 de conflits ge´re´s par Coopeer.

70 CHAPITRE 6. UNE ME´THODE DE GESTION DES CONFLITS
A B C
Exe´cution de A1 Exe´cution de B1
Diffusion de A1 Diffusion de B1
(estampille = (estampille =
A, 1, 0, -, 0) B, 1, 0, -, 0)
Re´ception de B1
Exe´cution de B1
Re´ception de B1 Exe´cution de B2 Re´ception de A1
Mise en attente de B1 Diffusion de B2 Annulation de B1
(estampille = Exe´cution de A1
B, 2, 0, B, 0)
Exe´cution de C2
Diffusion de C2
(estampille =
C, 2, 1, A, 0)
Re´ception de C2 Re´ception de C2 Re´ception de B2
Exe´cution de C2 Mise en attente de C2 Mise en attente de B2
Re´ception de B2 Re´ception de A1
Mise en attente de B2 Annulation de B2
Annulation de B1
Exe´cution de A1
Exe´cution de C2
Historiques de fin de session
A1, C2 A1, C2 A1, C2
A1
B1
B1 B1, A1 C2
C2
B2
B2, B1, A1
C2
B
C
A
Fig. 6.7 – Exemple n◦ 3 de conflits ge´re´s par Coopeer.

72 CHAPITRE 6. UNE ME´THODE DE GESTION DES CONFLITS
6.5 Gestion des priorite´s
La fonction qui renvoie la priorite´ d’un message se base sur l’identifiant
d’e´metteur de ce message. Elle peut eˆtre imple´mente´e selon de nombreuses
approches.
En voici quelques-unes :
– ordre alphabe´tique ;
– ordre d’arrive´e dans la session ;
– ordre de´fini par les participants, notamment par rapport a` leur fonc-
tion ;
– priorite´s en fonction des conditions de connexion.
Les priorite´s en fonction des conditions de connexion ne´cessitent de con-
naˆıtre tous les participants possibles avant le de´but de la session de travail
collaboratif. On analyse les performances du re´seau d’e´gal a` e´gal ainsi forme´
et l’on obtient une note qui de´termine la priorite´ de chaque participant sur les
autres. On pourra par exemple utiliser les crite`res du tableau 6.1 et faire la
moyenne de ses quatre valeurs pour obtenir une note. En cas d’e´quivalence,
on pourra coupler ce calcul des priorite´s avec l’une des autres strate´gies
cite´es auparavant. L’inte´reˆt de cette approche est de permettre de favoriser
les participants qui disposent de bonnes conditions de connexion.
Moyenne E´cart type
Temps de latence x1 x2
De´bit x3 x4
Tab. 6.1 – Exemple de crite`res pour calculer une priorite´ en fonction des
conditions de connexion.
6.6 Impact sur l’interface utilisateur
Coopeer est une me´thode optimiste, il n’est donc pas ne´cessaire de ver-
rouiller les donne´es et de demander la main sur le mode`le a` chaque fois que
l’on souhaite y apporter une modification. D’autre part, l’utilisation de Co-
opeer au sein d’une application est transparente pour les participants en ce
qui concerne les conflits d’ordonnancement (voir figure 6.9). Et dans le cas
des conflits de simultane´ite´, l’affichage d’une boˆıte de dialogue peut pre´venir
les participants non-prioritaires qu’une ou plusieurs ope´rations vont eˆtre an-
nule´es ; le participant prioritaire n’est pas concerne´ pas cet impact (voir fi-
gure 6.10, A est prioritaire sur B).

74 CHAPITRE 6. UNE ME´THODE DE GESTION DES CONFLITS
BAA B
Données
identiques
A1
B1 A1
B1
Données
différentes
Sans Coopeer Avec Coopeer
Données
identiques
B1
A1
A1
Données
identiques
B1
Boîte de
dialogue
-
Fig. 6.10 – Impact de la gestion de la simultane´ite´ sur l’interface utilisateur.
L’architecture re´seau elle-meˆme peut e´voluer. Cette meˆme gestion des
conflits a notamment e´te´ adapte´e a` l’architecture client/serveur de´crite dans
la section 1.4.2 (page 21).
Enfin, le principe de non simultane´ite´ peut eˆtre remis en cause si l’on peut
identifier des sous-syste`mes inde´pendants, c’est-a`-dire des sous-ensembles de
donne´es qui ne sont pas lie´s4. C’est ce qu’on pourra faire par exemple dans des
sce´narios d’assemblage ou` les pie`ces n’ont pas d’autres relations que de faire
partie du meˆme produit. On ajoutera alors un identifiant de sous-syste`me
dans l’estampille.
6.8 Re´sultats
La me´thode de´crite ici respecte les contraintes que nous nous sommes
fixe´es (sachant que la gestion du groupe de travail et la tole´rance aux pannes
sont traite´es dans le chapitre suivant). Lorsqu’un conflit de simultane´ite´ in-
tervient, on peut remarquer qu’il y a toujours une ope´ration qui est exe´cute´e
4Comme peuvent l’eˆtre les calques, ou couches, dans un logiciel de dessin en 2D.

76 CHAPITRE 6. UNE ME´THODE DE GESTION DES CONFLITS
Fig. 6.12 – Application de CAO au sein de laquelle Coopeer a e´te´ inte´gre´.

6.8. RE´SULTATS 77
Fig. 6.13 – Application d’annotation collaborative 3D.

Chapitre 7
Gestion du groupe et tole´rance
aux pannes
7.1 Pre´ambule
Nous de´finissons, pour traiter les proble`mes de la gestion du groupe et
de la tole´rance aux pannes, deux nouveaux types de message. Un avis est
un message qui n’est pas pris en compte par la gestion des conflits. Et une
notification est un message qui est pris en compte par la gestion des conflits,
mais qui n’est pas une ope´ration de l’application collaborative.
7.2 Tole´rance aux pannes
7.2.1 Pre´sentation du proble`me
Tel que de´crit pre´ce´demment, Coopeer fonctionne en ignorant le proble`me
des pannes. Afin de placer la me´thode dans un cadre plus re´aliste (notam-
ment celui d’Internet) si on ne dispose pas d’une couche de communication
fiable, nous lui ajoutons un me´canisme de tole´rance aux pannes.
On distingue diffe´rents types de pannes (voir figure 7.1 [34]) :
– panne franche : panne qui rend de´finitivement 81 le syste`me inope´rant ;
– panne par omission : panne lie´e au fait que le syste`me perd un message ;
– panne de temporisation : panne due a` une re´ponse en avance ou en
retard ;
– panne byzantine : panne provenant du comportement arbitraire du
syste`me.
79

7.3. GESTION DU GROUPE 83
A1
B
C
A
Avis de
connexion
A1 B2
B2
B3
Réception des
données
B4
B3 B4
Fig. 7.3 – Exemple d’ope´ration rate´e par un nouveau participant.
7.3.2 Solutions
Deux solutions sont propose´es pour LICRA1 [37]. La premie`re consiste a`
faire une pause dans la session afin d’accueillir un nouveau participant (par
exemple en utilisant en algorithme de terminaison, voir section 5.4.3 page 53).
La seconde solution e´vite d’interrompre la session en introduisant un e´tat
dit semi actif . Le nouveau participant se voit attribuer un parrain suite a`
une requeˆte de participation. Le nouvel arrivant est alors en e´tat semi actif, il
ne peut pas eˆtre l’auteur d’une ope´ration. Son parrain lui envoie les donne´es
et lui transmet les messages provenant des autres participants. Quand le
nouveau participant rec¸oit un message d’un autre, il en informe le parrain
qui arreˆte alors la transmission des messages pour ce participant. Quand le
parrain a rec¸u des acquittements pour tous les autres participants, il envoie
un e´ve´nement de fin de parrainage qui indique le passage en e´tat actif.
Notons qu’on pourrait simplifier le syste`me des acquittements en les fai-
sant envoyer directement par les autres participants.
7.3.3 Deux me´canismes de connexion
Nous proposons deux autres me´canismes de connexion en cours de session.
Le premier consiste a` utiliser le protocole simple de la figure 7.3 en comp-
tant sur le me´canisme de tole´rance aux pannes pour re´cupe´rer les ope´rations
manquantes. La figure 7.4 illustre cela. C dispose de B4, mais ne peut pas
l’exe´cuter. Il envoie alors un avis de recherche a` B qui lui renvoie B3. C
l’exe´cute et peut ainsi exe´cuter B4.
1Me´thode de gestion de la concurrence par transformation d’ope´ration.

84CHAPITRE 7. GESTION DUGROUPE ET TOLE´RANCE AUX PANNES
A1
B
C
A
Avis de
connexion
A1 B2
B2
B3
Réception des
données
B4
B3 B4
Avis de
recherche
B3 B4
Fig. 7.4 – Exemple de re´cupe´ration d’une ope´ration manquante.
Notre second me´canisme repose sur l’utilisation de la machine prioritaire
qui diffuse une notification de connexion prioritaire sur toutes les ope´rations
(voir l’algorithme de la section suivante). Notons que, si la machine prioritaire
est en panne, la machine venant apre`s dans l’ordre des priorite´s devient
prioritaire.
7.3.4 Algorithme de notre second me´canisme
• Le nouveau participant envoie un avis de recherche de la machine prio-
ritaire a` l’un des participants qui lui renvoie l’information.
• Le nouveau participant envoie une notification de connexion au parti-
cipant prioritaire.
• Ce dernier diffuse aux autres la notification (message estampille´ qui
peut annuler des ope´rations simultane´es) et renvoie les donne´es de la
session au nouveau participant.
• Le nouveau participant est alors preˆt et les autres ont connaissance de
sa participation a` la session.
7.3.5 Exemple pour notre second me´canisme
L’exemple de la figure 7.5 montre une ope´ration simultane´e (B3) a` une
notification de connexion (celle de C, envoye´e par A). On constate alors qu’a`
la re´ception de la notification (A3), B annule B3 puisque A3 est prioritaire,
exe´cute A3 et diffuse correctement B4 vers A et C.

7.3. GESTION DU GROUPE 85
A1
B
C
A
Notification de
connexion
A1 B2
B2
B3
Réception des
données
B4
B4
B4
Avis de recherche de
machine prioritaire
A3
B3, A3
Notification de
connexion de C
Fig. 7.5 – Exemple d’ope´ration rate´e qui est annule´e.
7.3.6 Conclusion
Nous avons e´voque´ quatre me´canismes de connexion en cours de session.
Le premier ne´cessite une pause dans la session. Le deuxie`me ne´cessite de
passer par un e´tat semi actif. Le troisie`me est transparent mais fait intervenir
la tole´rance aux pannes. Le quatrie`me, quant a` lui, profite des priorite´s de
Coopeer pour annuler les ope´rations qui pourraient manquer au nouveau
participant.

86CHAPITRE 7. GESTION DUGROUPE ET TOLE´RANCE AUX PANNES

8.2. PERSPECTIVES 89
avec un annuaire (UDDI), un langage de description de services/ressources
(WSDL) et un langage d’interrogation (SOAP), mais en architecture d’e´gal
a` e´gal. Nous pouvons aussi envisager d’autres types de ressources, et notam-
ment du code. En effet, un participant peut exe´cuter une macro ope´ration2
sans que les autres n’en disposent localement. On peut aussi imaginer qu’un
participant exe´cute une ope´ration dont le code n’est pre´sent que sur sa ma-
chine. Alors, il faut transmettre du code sur le re´seau (comme c’est le cas
en ce qui concerne les agents mobiles [33]) et l’inte´grer dynamiquement dans
l’application hoˆte [5]. Ce code peut meˆme repre´senter des composants. Si
une ope´ration fait appel a` un composant qui n’est pas pre´sent sur la ma-
chine, il faudra aussi l’inte´grer dynamiquement [32]. Un protocole est ainsi
ne´cessaire afin de permettre un tel partage de ressources. Les proble´matiques
sont nombreuses. Comment tenir compte des caracte´ristiques des machines et
du re´seau ? Comment impliquer l’utilisateur ? Comment traiter les diffe´rences
de versions des ressources ? Comment ge´rer les proble`mes lie´s aux licences
logicielles ?
2Une se´quence d’ope´rations enregistre´e au pre´alable.

Annexe A
Algorithme en pseudo code
Types de donne´es utilise´s :
- M = [O, E]
Message = [ope´ration, estampille] ;
- E = [I, C, CA, IP, CAP]
Estampille = [identifiant, compteur, compteur d’annulation, identifiant
pre´ce´dent, compteur d’annulation pre´ce´dent].
Structures de donne´es pour chaque machine :
- I = monId pour l’identifiant ;
- H = [] pour l’historique (liste de messages) ;
- L = [] pour la liste des messages en attente ;
- CA = 0 pour le compteur d’annulation.
Notes sur les listes :
- les e´le´ments d’une liste de taille n sont nume´rote´s de 1 a` n ;
- une liste renvoie sa taille a` l’appel de sa me´thode taille() ;
- une liste renvoie son dernier e´le´ment a` l’appel de sa me´thode dernier() ;
- une liste renvoie si oui ou non elle contient un e´le´ment a` l’appel de sa
me´thode contient().

91

Annexe B
Arguments de validation
B.1 Syste`me de datation
B.1.1 Pre´ce´dence causale directe
Nous exe´cutons une ope´ration si la dernie`re de l’historique la pre´ce`de
causalement. Pour valider cette condition, notre estampille fournit une iden-
tification de l’ope´ration du message (un compteur permettant la datation
et un identifiant d’e´metteur) et de l’ope´ration pre´ce´dente. L’inte´grite´ de ce
syste`me de datation est garantie par deux compteurs d’annulation (un pour
l’ope´ration, l’autre pour l’ope´ration pre´ce´dente). Ils permettent de distinguer
les ope´rations qui auraient la meˆme identification (meˆme compteur et meˆme
identifiant d’e´metteur), cas possible suite a` une annulation (voir section 6.4,
page 67). Notre estampille permet ainsi de caracte´riser la pre´ce´dence causale
directe dont nous avons besoin.
B.1.2 De´tection de la concurrence
La de´tection d’une ope´ration simultane´e se fait sur le compteur (s’il
n’est pas supe´rieur a` celui de la dernie`re ope´ration de l’historique), sur la
pre´ce´dence causale directe de´crite dans la section pre´ce´dente et les priorite´s.
Ainsi, on sait si l’ope´ration appartient au passe´, si elle est causalement lie´e
a` l’historique et si elle est prioritaire. Si ces trois conditions sont remplies,
alors il s’agit d’une ope´ration simultane´e.
93

94 ANNEXE B. ARGUMENTS DE VALIDATION
B.2 Gestion des conflits
B.2.1 Ordonnancement
L’ordonnancement de Coopeer est base´ sur une classique liste d’attente.
Si une ope´ration n’est pas exe´cute´e et qu’elle n’est pas conside´re´e comme
simultane´e, alors elle est place´e dans cette liste. Ensuite, la pre´ce´dence causale
directe est utilise´e pour savoir si on peut la supprimer de la liste et l’exe´cuter.
B.2.2 Simultane´ite´
Le traitement d’une ope´ration simultane´ite´ se fait par annulation d’ope´-
rations. Le fait que l’e´metteur de l’ope´ration simultane´e doit eˆtre de priorite´
supe´rieure garantit le fait que les ope´rations annule´es ne devront pas eˆtre
refaites.
B.2.3 Priorite´s
Le niveau de priorite´ d’un participant par rapport aux autres est unique
et invariable. De plus, l’ensemble des niveaux de priorite´ est connu de tous, de
fac¸on identique. Il n’y a donc pas de confusion possible entre deux ope´rations
simultane´es.
B.3 Diffusion ordonne´e
B.3.1 Introduction
Nous de´clinons ici les proprie´te´s de suˆrete´ et de vivacite´ [43, 58, 1] pour
notre diffusion ordonne´e. La proprie´te´ de suˆrete´, selon laquelle rien de mal
ne se produit, correspond au fait que les messages ne sont pas de´livre´s dans
un ordre diffe´rent de celui de leur diffusion. La proprie´te´ de vivacite´, selon
laquelle quelque chose de bien peut arriver, correspond a` une progression, au
fait que l’on ne reste pas bloque´.
B.3.2 Proprie´te´ de suˆrete´
Si deux messages sont diffuse´s par une meˆme machine, ils seront de´livre´s
sur toutes les autres dans le meˆme ordre (l’ordre de diffusion) :
– si ces messages sont rec¸us dans l’ordre de diffusion, ils seront de´livre´s
selon cet ordre ;

Annexe C
Versions originales
Cette annexe propose les versions originales des figures et des tableaux
repris dans ce document et traduits de l’anglais vers le franc¸ais.
Same Time Different Times
Same Single User CAD with data
Place CAD management
Different Collaborative Distruted
Places Design CAD
Tab. C.1 – The use of CAD across time and space [48, 20].
Master
Geometry
Model
3D Scene
Pixel
Image
Slave
Pixel
Image
User A
Geometry
Model
3D Scene
Pixel
Image
User B
Pixel
Image
Geometry
Model
3D Scene
Mes-
sages
Applic.
Sharing
Fig. C.1 – Different approaches for a design conference [18].
97

98 ANNEXE C. VERSIONS ORIGINALES
Model
View
Display Display
File
Shared View
Model
View
Display Display
File
Shared Model
View
Model
View
Display Display
File
Shared File
View
Model
Fig. C.2 – Consistency via Shared State [59].
Ring Tree
CliqueStar Hypercube
Fig. C.3 – Examples of frequently used topologies [86].