Notre système est un système entièrement répliqué. Cela implique que chacun des participants possède sa propre structure de données et donc sa propre partition. Dans ce cas il faut que les différentes répliques soient identiques.
Les arguments généralement utilisés contre l'implémentation d'un processus central et
donc d'un serveur sont les suivants [28]:
- Lenteur et temps de réponse : en effet puisque tout ordre passe par le serveur avant
d'être réémis vers tous les participants, il risque d'avoir un temps de réponse plus lent,
que si chaque participant traitait localement son action avant d'en informer les autres.
- La perte de robustesse : une session ne peut fonctionner que si le serveur tourne.
- La dérive entre le serveur central servant juste de relais pour les
ordres, et le traitement central des ordres. En effet une fois le serveur implémenté, il est
très tentant de lui faire traiter quelques actions au lieu de simplement les transmettre
aux participants. Dans ce cas l'implémentation a priori simple du serveur deviendrait
assez vite complexe et nécessiterait l'intégration d'une réplique des données propre au
serveur.
Nous allons maintenant discuter ces arguments puis montrer les avantages d'un tel système.
La lenteur de l'interface dépend avant tout de la taille des données transmises. Nous avons effectué différents tests dont voici les résultats. Nous avons implémenté un petit serveur qui accepte une connexion par socket sur un port donné et qui se contente de renvoyer à l'expéditeur la chaîne que celui-ci lui envoie. Pour une connexion Internet de type PPP à 33,6 kbs, la moyenne des temps que met une chaîne de 255 caractères pour faire l'aller-retour est de l'ordre de 15 ms. Pour un serveur acceptant 5 connexions et avec 5 participants connectés, le temps moyen de réponse n'augmente presque pas.
Enfin sur notre applet, en mode local, c'est-à-dire sans passer par le serveur, le temps moyen de réponse à un clic d'ajout de note par exemple est de 140 ms. En mode réseau ce temps ne dépasse pas 170 ms. La différence de temps est due au temps du trajet mais aussi au temps consommé pour synthétiser la chaîne à transmettre puis à décoder la chaîne reçue du serveur.
Il existe donc effectivement une augmentation du temps de réponse de l'interface, mais celle-ci reste raisonnable.
En ce qui concerne la perte de robustesse, les solutions qui peuvent être apportées sont les mêmes que pour les serveurs web. En effet, quand une machine hébérgeant un site web tombe en panne, le site ne peut plus être visité. Mais il existe un certain nombre de solutions classiques, comme les serveurs miroirs, ou la redirection automatique de requêtes vers un autre serveur. De plus, il est possible de mettre en place sur la même machine que le serveur un autre processus qui vérifie régulièrement son activité normale. En cas de problème, comme une absence de réponse du serveur, ou une lenteur anormale, ce processus se charge d'arrêter le serveur puis de le redémarrer. Les participants connectés à ce moment là se trouveraient déconnectés brusquement, mais ce genre d'incidents ne devrait arriver que très rarement.
En ce qui concerne le degré d'implication du serveur dans le traitement des actions, nous avons tenu à garder le serveur complètement transparent aux actions propres à l'édition. Par contre le serveur répond à toute sorte de requêtes comme calculer le nombre de participants, le temps de connexion de chacun d'eux, etc.
Enfin l'implémentation d'un serveur permet de sérialiser les actions des différents utilisateurs et donc d'éviter le conflit.
L'alternative à l'implémentation d'un serveur central consiste à faire en sorte que chaque
participant dialogue directement avec tous les autres. Cette méthode présente les
inconvénients suivants :
- chaque participant doit gérer l'arrivée et le départ des autres participants, car il faut
que chacun sache qui est là pour pouvoir lui envoyer des messages.
- chaque participant doit pouvoir dialoguer avec les autres. Dans ce cas il est exclu
d'envisager une implémentation de type applet téléchargeable. En effet pour des raisons
de sécurité une applet n'a le droit d'ouvrir de connexions que vers la machine dont elle
provient. Il serait impossible donc de dialoguer avec les autres participants.
- sur un réseau public de la taille d'Internet, la situation deviendrait incontrôlable,
alors qu'un serveur central permet d'archiver les connexions et donc d'en garder une
trace.
- le gestion des conflits nécessiterait un algorithme très complexe. En effet dans le
cadre de l'édition du texte ou du dessin structuré la situation est plus simple que dans le
cas de la musique. Il faudrait pouvoir décider de l'ordre des actions et donc pouvoir en
annuler en supprimer, etc. Dans le cadre de l'édition musicale l'utilisateur devra presque
gérer les conflits à la main.