Tolérance aux fautes du réseau

Le taux de pannes du réseau HSL est très faible (comparable à celui d'un bus partagé). Néanmoins, nous avons souhaité sécuriser le protocole SCP/P, tout en gardant sa caractéristique <<zéro-copie>>, ce qui pose des problèmes peu communs :

Les données erronées, à la différence des protocoles classiques, peuvent être déposées dans la zone de réception, car l'automate de DMA matériel [3] calcule les codes CRC au fur et à mesure du dépôt des données, et c'est seulement lorsque le transfert est terminé qu'il indique éventuellement une erreur. Pour s'adapter à cette situation, le protocole MICP (Message Identifier Cleaner Protocol) vient s'intercaler, en cas de faute, entre les différentes émissions/réceptions et permet ainsi de gérer la validité des données locales.
L'opération Send n'émet les données sur le réseau que si l'opération Receive a été effectuée sur le nud distant pour indiquer la localisation des tampons de réception. Le récepteur ne peut donc pas distinguer l'absence de Send, de la perte d'un message Receive. Pour résoudre ce problème, la sous-couche SFCP (Sender Flow Control Protocol), sous l'impulsion de l'émetteur, transmet régulièrement au récepteur le numéro de séquence courant sur le canal. Le procédé est renouvelé jusqu'à ce qu'un acquittement soit reçu.
Dans un protocole sécurisé, on ne peut pas se contenter de prévenir l'utilisateur de Send lorsque les données sont rentrées dans le réseau. Le protocole RFCP (Receiver Flow Control Protocol), activé cette fois par le récepteur, permet la libération des données chez l'émetteur. Pour cela le récepteur lui indique le nombre de Send correctement reçus.
Lorsque des données sont perdues ou considérées comme telles après l'expiration d'un délai de garde, le récepteur doit envoyer à nouveau des informations à destination des boîtes aux lettres de l'émetteur. Il lui faut, pour ce faire, associer à cette écriture distante l'identificateur de la boîte aux lettre choisie. Mais si l'écriture précédente vers cette même boîte aux lettre a subi une perte partielle, c'est-à-dire que des paquets ont été corrompus ou perdus mais que d'autres ont été correctement acheminés, le comptage des paquets associés à l'identificateur de message en question va se trouver erroné, ce qui risque de provoquer prématurément l'interruption de fin de transfert. La couche MICP permet de contourner ce problème en réinitialisant les compteurs de paquets du côté émetteur comme du côté récepteur.

Les opérations Send et Receive sont regroupées dans la sous-couche BSCP (Basic SCP). Les sous-couches MICP, RFCP et SFCP utilisent des messages courts, qui sont transmis en un seul paquet sur le réseau. Cela permet de s'affranchir des problèmes de perte partielle de données, de la gestion des identificateurs de messages (un seul identificateur utilisé par chacune de ces sous-couches), et de la gestion de boîtes aux lettres (les données sont transportées hors-bande, il n'y a pas d'adresse locale ni distante à fournir).

Le coût de la sécurisation du protocole SCP, en l'absence d'erreur, est très faible : le protocole MICP n'est alors pas mis en uvre, et la bande passante occupée par les messages courts de SFCP et RFCP est négligeable. L'unique impact sur les performances se traduit par un délai supplémentaire avant la signalisation de fin de transaction chez l'émetteur comme chez le récepteur. Ce délai correspond au temps d'aller-retour d'un message court sur le réseau.

Notons que le problème de la tolérance aux fautes du réseau est résolu grâce à l'existence des messages courts, transportés en un seul paquet.

Next: Passage de messages en Up: Noyau de communication sécurisé Previous: Passage de messages en