Dans ce chapitre nous avons pr´esent´e notre proposition de support coop´eratif au syst`eme VNC. Cette proposition a voulu rendre plus flexible ce syst`eme, un aspect int´eressant pour des environnements spontan´es de communication.
Les prototypes r´ealis´es mettent en ´evidence les fonctionnalit´es qui transforment VNC en un syst`eme adaptable `a diverses situations de collaboration qui peuvent survenir dans un environnement de collaboration spontan´e. Une vue critique sur ces prototypes souligne principalement l’importance de l’interface offerte `a l’utilisateur et indique son am´elioration.
Chapitre 6
Conclusion
6.1 Bilan du travail
Dans le contexte des id´ees pr´esent´ees dans ce m´emoire, nous nous sommes propos´es d’´etudier deux infrastructures coop´eratives construites sur deux syst`emes tr`es r´epandus : le syst`eme de fenˆetrage X et le syst`eme d’affichage VNC. Nous analysons dans cette section les travaux r´ealis´es.
6.1.1 Le syst`eme de partage d’applications X
Nous avons vu dans le Chapitre 2 que pour r´ealiser un syst`eme de partage d’applications X, beaucoup des efforts se sont focalis´es sur l’int´egration d’unproxyd’une fa¸con transparente dans le syst`eme X Window. `A cause de la complexit´e du protocole X, `a notre avis cette tˆache pr´esente en soi un sujet d’´etude. Nous nous sommes limit´es dans notre travail `a impl´ementer un multiplexeur avec des fonctionnalit´es de base.
Nous n’avons pas pu impl´ementer le m´ecanisme de contrˆole de droit d’entr´ee floor, mais nous avons fourni une interface d’utilisateur `a ce m´ecanisme. `A notre avis, cette interface se distingue des autres solutions propos´ees par sa simplicit´e et la fa¸con naturelle dont elle s’int`egre dans le syst`eme X : l’interface est offerte par un client X qui attache sa fenˆetre `a la fenˆetre principale de l’application partag´ee. Nous avons vu que son point faible, tel qu’il est con¸cu pour le moment, est le fait que l’on ex´ecute une instance de ce client pour chaque participant `a la session. Cette op´eration pourraient consommer beaucoup de ressources de la machine locale dans le cas d’un grand nombre de participants1
.
Notre multiplexeur est impl´ement´e en tant qu’un service actif qui peut ˆetre charg´e
dyna-1
Cela d´epend ´egalement de la complexit´e du client.
72 CHAPITRE 6. CONCLUSION
miquement sur une plate-forme g´en´erique de noeud actif. De cette mani`ere, le multiplexeur devient un ´el´ement actif du r´eseau. Nous consid´erons qu’il apporte une nouvelle contribu-tion grˆace `a l’id´ee de traitement de paquets dans le r´eseau pour supporter une session de collaboration. L’utilisation de ce service actif dans le contexte d’un environnement spontan´e de communication est appropri´ee grˆace `a la caract´eristique de la plate-forme choisie pour son impl´ementation : elle permet de charger dynamiquement `a la demande de l’utilisateur ou d’un autre programme le service actif souhait´e. De plus, la plate-forme a ´et´e con¸cue dans un but d’adaptation au contexte : nous n’avons pas encore exploit´e cette fonctionnalit´e dans notre travail.
6.1.2 Le support coop´eratif ajout´e au syst`eme VNC
Nous avons vu dans le Chapitre 4 qu’une partie des contributions existantes apport´ees pour am´eliorer les caract´eristiques coop´eratives du syst`eme VNC se r´esument `a des modifi-cations qui s’int`egrent d’une fa¸con transparente au syst`eme. Les contributions majeures dans ce sens se basent sur la modification du syst`eme entier.
Par rapport `a ces contributions, nous nous sommes orient´es d’une part vers des op´erations sur des flots RFB et d’une autre part sur l’exploitation de l’existence des clients VNC en mode ”`a l’´ecoute”. Le syst`eme coop´eratif gagne ainsi en flexibilit´e par la programmation dynamique des sessions de collaboration sur unproxy(Newkey) introduit d’une fa¸con transparente dans le syst`eme VNC. Les sc´enarios donn´es au cours de la pr´esentation du Chapitre 5 illustrent la fa¸con dont le syst`eme VNC peut s’adapter `a diff´erentes situations de collaboration grˆace `a Newkey. Dans le but de contrˆole du proxy, nous avons d´efini un protocole de contrˆole (NewkeyCP). En plus de la programmation des sessions de collaboration, le protocole inclut des primitives pour le contrˆole d’entr´ee et une partie de gestion.
Quand nous avons con¸cu et impl´ement´e notre prototype, il n’y avait pas de support pour le contrˆole de droit d’entr´ee pour le syst`eme VNC. Collaborative VNC [1] apporte plusieurs politiques de contrˆole du droit d’entr´ee. Cependant, nous pensons avoir apport´e une r´eponse originale `a ce probl`eme dans le contexte du syst`eme VNC : notre travail offre un m´ecanisme du contrˆole du droit d’entr´ee et laisse la libert´e d’utiliser la politique la mieux adapt´ee au contexte de collaboration. Dans le m´emoire, dans la Section 5.4.3, nous avons montr´e comment les op´erations de contrˆole de droit d’entr´ee sont traduites en deux primitives du protocole NewkeyCP.
L’interface utilisateur au m´ecanisme de contrˆole du droit d’entr´ee est assur´ee par un serveur VNC d´edi´e (UI) qui s’affiche sur l’´ecran d’un participant. Celui-ci offre la possibilit´e d’op´erer sur le droit d’entr´ee. Ainsi, il communique avec le service qui g`ere la politique de contrˆole d’entr´ee.
Dans la conception d’un support coop´eratif au syst`eme VNC, nous avons essay´e de tirer des conclusions de l’analyse de la conception du syst`eme de partage d’applications X :