Les algorithmes vus en cours, et que l'on implémentera dans les TP, sont adaptés ou prévus pour fonctionner dans un certain contexte. Ce contexte comporte notamment un modèle de faute et un modèle temporel. Les salles de TPs sont un environnement d'exécution particulier puisqu'on l'est dans le cadre d'un réseau local où les temps de propagation des messages sont très courts et les pertes de messages quasi inexistantes, tout comme les crash de processus.
Pour pouvoir simuler des contextes de fautes et temporels variés, un framework de communication a été réalisé et simulera des temps de propagation plus ou moins longs ainsi qu'un certain niveau de perte de messages ou de crash de processus. En pratique, ce framework s'appuie sur des sockets TCP.
La suite de cette page web décrit les éléments principaux de ce framework. Une description plus complète est disponible ici : framework-tp.pdf.
On considère que le système est formé d'un ensemble de processus, utilisant chacun un élément de communication et possèdant une adresse unique permettant de les identifier.
Un processus est identifié par une instance de ProcessIdentifier gérée par son élément de communication. En pratique, on utilisera la spécialisation de cette classe pour le contexte IP : IPProcessIdentifier. Un processus est alors identifié par un triplet :
Les processus s'envoient des messages (instances de Message). Un
message contient un identifiant de processus et une donnée (un objet
Java quelconque - mais qui implémente
java.io.Serializable pour pouvoir transiter à travers les
sockets).
Dans le cas d'une émission de message, l'identifiant est celui du processus destinataire et en réception de message, l'identifiant contient celui de l'émetteur.
L'interface de communication ICommunication définit les services pour émettre et recevoir des messages. En réception, on pourra choisir entre une version asynchrone (non bloquante) et une version synchrone (bloquante en attente du prochain message non lu). Dans un contexte fiable, l'émission d'un message pourra lever une exception en cas de problème de communication.
L'élément de communication est le coeur de la couche de communication. Il permet à chaque processus de communiquer avec les autres processus.
Il existe 2 types d'éléments de communication :
Les niveaux de fautes sont au nombre de quatre, comme spécifié dans ReliabilitySetting, et sont chacun de type FaultLevel :
Le tableau ci-dessous donne les valeurs correspondantes pour les niveaux de fautes :
| NONE | LOW | MEDIUM | HIGH | HIGHEST | FULL | |
| Perte de paquets (%) | Aucune | 20 | 40 | 60 | 80 | Tous |
| Délai minimum (ms) | 0 | 20 | 80 | 180 | 320 | 500 |
| Délai maximum(ms) | 0 | 50 | 400 | 1350 | 3200 | 6250 |
Note : ces délais ou pertes de messages sont rajoutés de manière artificielle à ce que le système réel peut engendrer. La couche de communication n'assure donc pas, avec des niveaux tous à NONE, qu'il n'y aura aucune perte de messages ou délais de propagation non négligeables.