MILLESABORDS est un logiciel libre de nommage pour systèmes répartis, comme par exemple un réseau “ad hoc” (d'où ce mauvais jeu de mots bruxellois).

J'ai défini ce système de nommage durant ma thèse, en 1994, pour répondre aux contraintes liées à la désignation d'objets de liaison dans un système réparti fortement évolutif. Dans de tels systèmes, il n'y a pas d'organe central qui régisse la topologie du réseau. Le réseau est constitué naturellement par la connexion et la déconnexion spontanées de ces composants. Le système de nommage que j'ai dessiné, s'appuie sur la diffusion de message et était mal adapté à des réseaux de type centralisé. Vingt ans après, ces travaux prennent tous leurs importances avec l'affirmation des réseaux “ad hoc” dans notre quotidien.

Par définition, sous Unix tout est fichier. Cependant, même si un répertoire est un fichier en mémoire, le contraire n'est pas vrai (un fichier n'est pas considéré comme potentiellement un répertoire).

Et pourtant, n'importe quel fichier pourrait être considérer comme un répertoire, un nœud d'information. C'est bien le cas en XML, n'importe quelle feuille peut devenir à son tour nœud d'information.

Dans le système de nommage MILLESABORDS, tout élément est un composant de désignation qui peut à son tour servir à désigner d'autres composant. C'est le composant lui même qui connaît le nom (ou les noms) qu'il possède dans un (ou plusieurs) contexte(s) d'utilisation.

L'objectif est bien de disposer d'un système de désignation stable, alors même que le réseau se compose de matériels en perpétuels mutation. Les composants eux-mêmes sont amenés à se déplacer d'un matériel à un autre, en conservant leurs propriétés de désignation.

Les propriétés fondamentales du systèmes sont :

• l'encapsulation : le composant est le seul à gérer sa désignation. Les noms d'un composant et le composant sont localisés sur le même matériel (dans le même espace).
• l'exacte représentation : si un composant se trouve sur un matériel qui n'est plus directement accessible par le réseau, alors il ne peut plus et ne doit plus être désigné. Réciproquement, un composant qui se trouve sur un matériel qui est directement accessible par le réseau, même si son (ou ses) contexte(s) n'est (ne sont) plus accessible(s), doit pouvoir être désigné.
• l'ubiquité : un composant peut être désigné par plusieurs chemins. Aucun de ces chemins n'a un rôle prépondérant par rapport aux autres. A chaque instant, un chemin peut disparaître ou apparaître.
• la redondance : un chemin peut désigner un ou plusieurs composants, dans le but
  • soit de pouvoir rendre un service de tolérance aux pannes,
  • soit d'offrir naturellement un mécanisme d'ensemble réparti (groupe de composant fournissant le même service).
• le choix d'interaction : un chemin désigne un ensemble de composants. Il doit donc facilement permettre la mise en place de mécanismes d'interaction individuelle ou collective. (i.e. invocation d'un service auprès : d'un membre du groupe, de tous les membres synchronisés du groupe, ou d'un sous-ensemble).
• l'unicité : chaque composant dispose d'un identifiant unique.

Je vous invite à consulter l'architecture de MILLESABORDS pour plus d'information.

Pour comprendre un concept, le plus simple est de suivre une illustration. L'exemple qui suit n'est pas exhaustif du potentiel de ce système de nommage. Son seul but est d'amener à s'interroger sur la faisabilité et l'utilité du système de nommage MILLESABORDS.

La plupart des systèmes s'appuie sur un répertoire courant. Ce dernier pointe l'arborescence de nommage au fil des déplacements. Ces déplacements s'opèrent vers la racine (“cd ..”), sur place (“cd .”) ou vers une branche fille (“cd nomBranche”).

La force de MILLESABORDS réside, en particulier, dans le fait que l'on ne dispose pas d'un répertoire courant, mais simultanément d'un ensemble de contextes courant.

Certains peuvent craindre que manipuler un ensemble (plutôt qu'un contexte unique) engendre la confusion. C'est bien le contraire qui se produit. Les noms multiples à une même chose sont inhérents au système de nommage. Dans un système d'exploitation classique, une désignation multiple peut être résolue par l'utilisation de liens symboliques.

Leurs utilisations provoquent un déplacement à grande distance dans l'arbre de nommage. Si ce déplacement est immédiatement suivi d'un rapprochement vers la racine (i.e. “cd ..”), tout repère devient impossible. Cette confusion vient du fait qu'un système, qui s'appuie sur les liens symboliques, privilégie un chemin par rapport aux autres.

Pour suivre cet exemple, voici un court extrait des commandes de MILLESABORDS.

Dans les commandes, “path” désigne un chemin d'accès suivant les conventions usuelles. C'est à dire une suite de noms séparés par un caractère spécial (dans notre exemple le “/”). Nous conservons pour désigner les répertoires courants et ascendants, les conventions de nommage d'Unix : “.” et “..”.

Voici les commandes seront utilisées dans l'exemple suivant.

$ cat > path <<EOF
Voici le texte que doit contenir le fichier
EOF
$

Pour une présentation complète des commandes il faut se reporter au manuel de MILLESABORDS.

L'exemple s'inspire de l'installation d'un serveur web (tel Apache) sur un système Unix. L'installation comprenant, entre autres, un répertoire des traces d'accès et d'erreurs. Ces informations de traces devront être à la fois accessibles par la structure de données de l'application serveur (/etc/httpd), mais aussi par la structure d'administration de la machine serveur (/var/log).

Pour cet exemple, nous commençons par mettre en place une partie de la structure de l'application.

$ create -p /etc/httpd/logs/access_log << EOF
> Contenu du fichier access_log
> EOF
$ create -p /etc/httpd/logs/error_log << EOF
> Contenu du fichier error_log
> EOF
$

Nous poursuivons par la mise en place de la structure d'administration de la machine.

$ touch -p /var/log
$ link /etc/httpd/logs /var/log/httpd
$

Nous vérifions que les données sont accessibles par la structure d'administration de la machine. Le contexte des traces est bien accessible via la structure applicative et administrative.

$ cd /etc/httpd/logs
$ ls
access_log      error_log
$ pwd
/etc/httpd/logs /var/log/httpd
$

Nous vérifions que les données restent accessibles par la structure d'administration de l'application. Le contexte des traces reste accessible via la structure applicative et administrative.

$ cd /var/log/httpd
$ ls
access_log      error_log
$ pwd
/etc/httpd/logs /var/log/httpd
$

Le parcourt du graphe de nommage reste cohérent. Il fait appel non pas à un contexte (répertoire) courant mais à des contextes courants.

$ cd ..
$ pwd
/etc/httpd      /var/log
$ ls
httpd   logs
$ cd logs
$ pwd
/etc/httpd/logs /var/log/httpd
$ ls
access_log      error_log
$

Je vous invite à consulter les Exemples de MILLESABORDS pour plus d'information.

Pour maîtriser le concept de nommage réparti MILLESABORDS, le mieux reste de manipuler le démonstrateur qui a été réalisé par des étudiants de l'UBS. J'ai mené ses développements dans le cadre de projets tuteurés :

• à l'UFR science : DESS ASIR avec la collaboration de Nelly Ngo, Tolojanahary Ravelomanantsoa et Florent Leroux
• à l'IUT : DUT informatique avec la collaboration de Rémi Lavergne, Sylvain Delezir, Nicolas HACHET et Sébastien DERRIEN

Le démonstrateur se compose de 3 éléments :

• Un lanceur de serveurs de noms comprenant un interpréteur de commande (de type “shell”),
• Un lieur de serveurs de noms, qui permet de simuler la configuration du réseau “ad hoc”,
• Un producteur d'identifiant unique nécessaire à la création des serveurs de noms.

Le démonstrateur est écrit en Java et peut donc être exécuté sur n'importe quelle machine. Chacun des éléments du démonstrateur est associé à un fichier jar. Il est donc possible de lancer plusieurs représentants de chaque élément.

Je vous invite à consulter le manuel d'installation de MILLESABORDS pour plus d'information.