Discussion centrée sur les applications réparties

Une application répartie (AR) est un ensemble de processus qui sont interconnectés via un réseau afin d’effectuer une tâche commune. Accéder à une base de données à distance pour réserver un billet d’avion, surfer sur le web ou encore transférer des fichiers à l’aide d’une application pair à pair sont autant d’exemples d’AR. L’explosion d’Internet a entraîné dans son sillage la multiplication et la diversification des AR. Pour faire face à cela, les développeurs de produits logiciels ont besoin d’outils adaptés à la gestion de ce problème. Cette adaptation peut se faire à différents niveaux : extension du langage de programmation ou bien librairies fournissant un ou plusieurs services répartis, des plus simples au plus complexes. Aussi, actuellement on cherche de plus en plus à utiliser des AR sans serveur. En effet le serveur nécessite une infrastructure qui lui est dédiée et introduit donc un surcoût. De plus, le serveur est un point unique d’échec de l’AR : si le serveur tombe en panne, c’est l’AR au complet qui cesse de fonctionner. Les techniques pair à pair semblent particulièrement bien adaptées aux architectures sans serveur. Elles ont fait l’object d’un groupe de discussion CETIC qui s’est déroulé le 5 octobre dernier.

Une assemblée attentive aux explications et démos.

Etendre les langages de programmation
pour tenir compte de la répartition

En matière d’extensions de langages, trois approches différentes sont possibles : messagerie, appel à distance et partage d’entités.

Dans les systèmes basés sur l’échange de messages, à chaque processus est associé un identificateur unique, un canal de communication et un pool de réception. Connaître l’identificateur d’un autre processus permet de lui envoyer un message sur son canal de communication. Les messages contiennent uniquement des valeurs. Tous les messages envoyés à un même processus sont placés dans son pool de réception, dans l’ordre d’arrivée. Un processus peut extraire des messages de son pool quand il le souhaite, d’une manière bloquante ou non, avec un timeout ou non. L’envoi et la réception des messages sont donc totalement asynchrones : il y a une opération explicite pour l’envoi et une opération explicite pour la réception. Par exemple le langage de programmation Erlang développé par Ericsson utilise cette approche.

Dans le cas de l’appel à distance, chaque processus peut exposer au monde extérieur une ou plusieurs procédures/méthodes. Un autre processus peut appeler à distance cette procédure/méthode en lui passant les paramètres qu’il souhaite, et éventuellement en récupérant les résultats si la procédure/méthode en retourne (cas d’une fonction par exemple). Les appels de procédure/méthode à distance sont bloquants, tout comme le sont les appels locaux habituels. Par exemple le langage Java utilise cette approche.

Enfin, dans le partage d’entités, les processus peuvent avoir des références sur les mêmes entités du langage. Par exemple un processus peut créer un objet, et l’offrir publiquement aux autres processus. Ces derniers peuvent récupérer la référence à cet objet, et l’utiliser comme s’il était local. Il est a noter que cet objet peut utiliser plusieurs types de protocoles réseaux :

• l’objet peut être stationnaire : il reste physiquement présent sur le site qui l’a créé ; les autres sites font des appels à distance comme décrit précédemment.
• l’objet peut être migrant : à chaque fois qu’un site veut l’utiliser, il se déplace d’abord sur ce site s’il n’y était pas déjà présent. Ces objets agissent comme des caches : un site qui veut utiliser beaucoup un objet partagé le ramène d’abord chez lui, puis effectue toutes les opérations localement.
• un mélange des deux cas précédents peut également être envisagé.

Le mécanisme de partage d’entités est utilisé dans le langage Oz et a notamment permis la création d’interfaces utilisateurs migratoires, qui peuvent se déplacer d’une machine à l’autre.

Ce programme de dessin peut migrer du portable (droite) vers l’iPaq (à gauche)

Des librairies spécialisées sont toutefois nécessaires

Ces différentes extensions facilitent grandement le travail du développeur pour l’écriture d’AR. Cependant à eux seuls, ces mécanismes ne poussent pas les développeurs à s’écarter du modèle client-serveur. Pour cette raison, il est important d’avoir des libraires qui abstraient tout ce qui touche à l’architecture de communication du réseau et offrent des solutions efficaces pour l’écriture d’applications sans serveur.

Le CETIC développe actuellement deux librairies offrant une abstraction de l’architecture de communication du réseau.

Global Store (GS) est une mémoire virtuelle partagée entre plusieurs processus. La vitesse d’un réseau étant de l’ordre de 104 fois plus lente que la mémoire d’un ordinateur, cette mémoire virtuelle est donc beaucoup plus inefficace que la mémoire physique réelle. Pour combler cette lacune, le GS offre un mécanisme transactionnel optimiste : chaque modification est effectuée dans une transaction. Localement, on prend toujours instantanément en compte les modifications locales : c’est le côté optimiste. Au bout d’un moment, le système détermine si un conflit a eu globalement lieu pendant une transaction. Le cas échéant, cette modification est soit mise à jour globalement, soit annulée localement. En pratique les applications utilisant le GS ont une réactivité indépendante des performances du réseau, au risque de voir annuler une partie du travail, et garantissent la cohérence des données entre les différents participants. Le risque de perdre du travail porte généralement sur une portion minime de ce dernier, vu qu’il ne faut pas longtemps pour déterminer le succès ou l’échec d’une transaction.

P2PS est une libraire de communication pair à pair développée au CETIC, utilisant les dernières technologies pour permettre la connexion de millions de noeuds tout en minimisant les messages réseaux utilisés pour communiquer entre ces noeuds.

Les démos

Afin d’illustrer les fonctionnalités offertes par ces deux librairies, le groupe de discussion a été ponctué de démos :

• Une feuille de calcul distribuée (Distributed Spreadsheet) et un agenda distribué (Distributed Agenda) qui utilisent le GS pour offrir un espace de travail virtuel partagé et collaboratif.
• Matisse, qui utilise le P2PS en librairie de communication. Il s’agit d’une application de dessin pour les enfants en bas âge, qui leur permet de dessiner à plusieurs en même temps. Cette application ne nécessite aucune configuration : il suffit de lancer un client pour qu’il trouve les autres clients situés sur le même réseau local et commence à travailler avec eux.

Matisse, une application de dessin pour les enfants en bas âge,
leur permet de dessiner à plusieurs en même temps.