MINI PROJET 3

ECOLE POLYTECHNIQUE DE MONTREAL
Département de génie électrique
Section informatique
Cours INF4402: Systèmes répartis sur l'Internet (Hiver 2001)
3 crédits (3-1.5-4.5)

Objectifs

Ce projet vise à introduire l'étudiant au développement d'applications réparties répliquées avec accès en lecture et écriture, et mises à jour atomiques.

Description

Les serveurs de noms permettent d'associer une adresse à un nom. Ils servent de nombreuses requêtes en lecture pour fournir l'adresse associée à un nom et quelques requêtes pour ajouter ou modifier une association nom-adresse.

Les serveurs de noms, qui sont constamment utilisés, doivent être répliqués afin d'offrir une bonne performance et une grande disponibilité. La question des mises à jour entre les réplicats prend alors toute son importance.

Pour ce projet, un client et un serveur de noms sont fournis et doivent être modifiés pour fonctionner en service répliqué avec mises à jour atomiques.

Réalisation

Un squelette du client et serveur demandés est fourni. Le client essaie déjà de communiquer avec plus d'un serveur et se satisfait dès qu'un serveur répond. Cela fonctionne très bien pour les accès en lecture. Pour les mises à jour, il faut modifier le serveur de sorte qu'il communique la mise à jour aux autres serveurs, tout en s'assurant qu'en aucun moment deux serveurs puissent donner des réponses différentes. Il est cependant acceptable qu'un serveur rende une réponse vide pour signifier que la valeur est en changement.

Le client reçoit les arguments suivants:

-get nom

Nom pour lequel on veut trouver l'adresse.

-set nom adresse

Changer ou ajouter une association nom-adresse.

Le serveur reçoit les arguments suivants:

-server nom

Nom du serveur. Ce nom devrait être server1, server2, ou server3, les serveurs cherchés par défaut, dans l'ordre, par le client.

Le serveur conserve les associations nom-adresse dans une table. Vous devez implanter un système qui fonctionne correctement lorsque trois serveurs répliqués démarrent sans fichier pré-existant et fonctionnent en continu. Cependant, vous devez réfléchir sur les aspects suivants qu'un système réel devrait prendre en compte:

• Qu'arrive-t-il aux clients pour les accès de type get lorsqu'un ou plusieurs serveurs tombent en panne? Quel est le nombre minimal de serveurs requis pour fonctionner? Comment la performance est-elle affectée? Est-il bon que tous les clients accèdent aux serveurs dans le même ordre de préférence?

• Qu'arrive-t-il aux clients pour les accès de type set lorsqu'un ou plusieurs serveurs tombent en panne? Peut-on fonctionner avec un nombre réduit de serveurs à condition d'avoir quorum d'une majorité de serveurs? Dans ce cas l'atomicité peut-elle toujours être garantie?

• Lorsqu'un serveur qui était tombé en panne revient, comment peut-on le resynchroniser tout en préservant l'atomicité?

Evaluation

Le barème suivant sera appliqué au rapport du mini projet 3. Chacune des rubriques citées doit apparaître dans le rapport. Un rapport bref et concis est un atout. Le rapport doit être écrit en bon français et être remis avant la date et l'heure prévus à l'horaire (les pénalités habituelles s'appliquent).

• Introduction (2 points)

• Implantation simple, structurée, bien commentée et opérationnelle des fonctions requises. (8 points)

• Discussion des questions concernant les accès get en cas de pannes. (3 points)

• Discussion des questions concernant les accès set en cas de pannes. (3 points)

• Discussion des questions concernant le redémarrage d'un serveur après une panne. (2 points)

• Conclusion: améliorations suggérées au serveur de noms développé. (2 points)

Le professeur: Michel Dagenais (A-306.18, tel. 340-4711 etx.4029)