Un serveur tourne en permanence sur la machine mère. Au démarrage l'applet cliente essaie de s'y connecter, si elle y arrive elle l'informera de toutes les opérations d'édition qu'elle opère sur la page courante. Le serveur transmet alors l'information à tous les autres clients connectés à la même session au même moment.
Le résultat est qu'un client donné n'est informé que des opérations qui ont lieu à partir du moment de sa connexion.
Cette méthode présente néanmoins un problème illustré par l'exemple ci-dessous. Soient deux Clients A et B travaillant sur la même partition :
Le client A envoie le message : suppression de la zone 50 50 100 100 qui veut
dire qu'il efface tous les composants qui sont situés dans cette région de la page. Au même
moment, le client B rajoute une note justement dans cette zone avant de recevoir le message
d'effacement du client A. Dans ce cas il peut exister un conflit dont voici un bilan
chronologique :
- Le client A efface ladite zone sur sa page en informe le serveur et la voit
effectivement s'effacer.
- Le client B rajoute une note, en informe le serveur, et la voit apparaître sur sa
page.
- Pendant ce temps le message de A arrive au serveur, il en informe B qui efface
donc la note de sa page.
- Et enfin le message de B arrive au serveur qui en informe A qui rajoute donc la
fameuse note.
Résultat : A et B n'ont pas la même partition !
La deuxième solution qui empêche ce comportement, consiste à faire en sorte que
le serveur informe tous les clients (y compris l'envoyeur) de tous les événements, et que
chaque client attende le retour du serveur pour effectivement procéder au changement, notre
exemple devient :
- Le client A demande l'effacement de la zone mais ne fait rien pour
l'instant.
- Le client B demande l'ajout d'une note et attend.
- Le message de A arrive au serveur qui en informe A et B, qui effacent la zone sur
les deux pages.
- Le message de B arrive au serveur qui en informe A et B, qui rajoutent tous les
deux la note sur la page.
Résultat: A et B ont la même partition. Cette solution est satisfaisante dans le cas où il y a effectivement plusieurs clients qui interviennent en même temps, mais fait perdre à l'application une fluidité d'exécution, même dans le cas où il y a un seul client.
Finalement, une troisième solution repose sur deux modes d'exécution un localet l'autre en réseau. Quand un client demande une nouvelle connexion au serveur, celui-ci teste s'il existe d'autres clients déjà connectés. S'il n'y en a pas, alors il informe le client qu'il est en mode local. Celui-ci n'avertit plus le serveur de ses changements mais reste, cependant, à son écoute.
Par contre, si le serveur trouve un seul autre client déjà connecté, alors il informe les deux clients (l'ancien et le nouveau venu) qu'ils sont en mode réseau, et qu'il doivent informer le serveur de tous les changements.
De plus, il demande à l'ancien de mettre à jour la page du nouveau, en lui transmettant l'état (toutes les notes) de la page courante.
Enfin si le serveur trouve plusieurs autres clients déjà connectés, il informe le nouveau client qu'il est en mode réseau puis demande au plus ancien client de mettre à jour le nouveau.
Voici un organigramme qui résume l'action du serveur au moment d'une connexion :
En mode réseau il faut garantir la sérialisation des ordres, c'est-à-dire qu'il faut être sûr que si le client B effectue une opération avant le client A, l'ordre de B est effectivement exécuté en premier. Avec un réseau de la taille d'Internet il est impossible de contrôler la vitesse de transmission, car le trajet parcouru par un ordre donné n'est pas fixé à l'avance.
Cela étant dit, et puisque en mode réseau tous les ordres passent par le serveur, on peut être sûr que B et A recevront les différents messages dans le même ordre, bien que cet ordre puisse être différent de celui avec lequel les actions ont été lancées. Le serveur gère donc la sérialisation des messages seulement à partir du moment où il les reçoit.
Comment aurions-nous pu remédier à cela ?
Une façon de résoudre ce problème consisterait à adapter le serveur aux différentes vitesses de transmissions. Au moment de la connexion et grâce à un message envoyé par le client contenant l'heure de la machine cliente, le serveur répond en ajoutant l'heure à laquelle il a reçu ce message, et de nouveau le client répond en rajoutant l'heure à laquelle il a reçu la réponse. Le serveur peut calculer le délai de transmission dans le sens Serveur/Client et dans le sens Client/Serveur.
Une fois cette donnée sauvegardée, le serveur pourra adapter ses temps de réponses en fonction des vitesses de transmissions des uns et des autres. Par exemple dans le cas de deux clients A et B : si le temps de transmission d'un message de A vers le serveur est de 1 seconde, et si le délai de transmission d'un message de B vers le serveur est de 0,7 seconde, quand le serveur recevra un message de B il attendra 0,3 seconde pour être sûr que A n'a rien envoyé, puis traitera l'action. De plus il est possible de répéter l'action de calcul des temps de transmission plusieurs fois régulièrement au cours de la session.
Mais cette méthode s'est révélée inefficace pour les raisons suivantes :
- La vitesse de transmission d'un message est loin d'être constante, elle varie d'ailleurs presque
avec chaque message.
- Quand un message est trop grand, il est découpé en paquets, qui ne suivent pas forcément le même
chemin sur le réseau, il en résulte donc des délais de transmission très variables.
Une autre méthode consisterait à utiliser une horloge logique. Ce procédé ne permet pas de connaître les délais de transmission, mais par contre peut établir un ordre total de la session. En d'autres termes il permet à un participant donné de classer dans l'ordre chronologique les actions reçues [33]. Ce procédé serait donc utile dans le cas où un client reçoit deux messages dans l'ordre inverse par exemple. Nous n'excluons pas de l'implémenter.
