Fiabilité (réseau informatique)

Après que le réseau NPL ait mis en place pour la première fois la commutation de paquets, l'ARPANET fournit une procédure fiable de livraison de paquets à ses hôtes connectés, par l'intermédiaire de son interface 1822. Un ordinateur hôte arrangeait simplement les données dans le bon format de paquet, insérait l'adresse de l'ordinateur hôte de destination, et envoyait un message à travers l'interface vers l'Interface Message Processor auquel il était connecté. Une fois que le message avait été livré à l'hôte de destination, un accusé de réception était remis à l'hôte émetteur. Si le réseau ne pouvait pas livrer le message, il envoyait un message d'erreur à l'hôte émetteur.

Pendant ce temps, les développeurs de Cyclades et de ALOHAnet ont démontré qu'il était possible de construire un réseau informatique efficace sans fournir une transmission fiable des paquets. Ce savoir a plus tard été réemployé par les concepteurs de l'Ethernet.

Si un réseau ne garantit pas la livraison de paquets, il devient de la responsabilité de l'hôte de s'occuper de la fiabilité en détectant et retransmettant les paquets perdus. L'expérience sur l'Arpanet a démontré que le réseau lui-même ne pouvait pas détecter de manière fiable tous les échecs de livraison de paquets, ce qui a renvoyé la responsabilité de la détection des erreurs sur l'hôte émetteur dans tous les cas. Cela a conduit à l'élaboration du principe de bout en bout, qui est un des choix de design fondamentaux de l'Internet.

Un service fiable est un service qui informe l'utilisateur si la livraison échoue, tandis qu'un service peu fiable ne garantit pas ce comportement. Par exemple, IP fournit un service non fiable. Ensemble, TCP et IP fournissent un service fiable, alors que UDP et IP ne le font pas. Tous ces protocoles utilisent des paquets, mais les paquets UDP sont généralement appelés datagrammes. Dans le cadre de protocoles distribués, les propriétés de la fiabilité spécifient les garanties que le protocole prévoit à l'égard de la diffusion de messages au(x) destinataire(s).

Un exemple de propriété de la fiabilité pour un protocole de diffusion unicast est au moins une fois, c'est-à-dire qu'au moins une copie de ce message a la garantie d'être livrée à son destinataire.

Les propriétés de fiabilité pour les protocoles multicast peuvent être exprimées en fonction du destinataire (on parle alors de propriétés de fiabilité simples), ou elles peuvent avoir trait à la livraison et/ou à l'ordre de la livraison entre les différents destinataires (on parle de propriétés de fiabilité fortes).

Dans le cadre de protocoles de multicast, des propriétés de fiabilité fortes spécifient les garanties que le protocole prévoit quant à la diffusion de messages à des destinataires différents.

Un exemple d'une propriété de fiabilité forte est le rappel de la dernière copie, ce qui signifie que tant qu'au moins une copie d'un message demeure disponible à l'un des destinataires, tous les autres destinataires qui ne rencontrent pas d'erreur finiront par en recevoir aussi une copie. Des propriétés de fiabilité forte comme celle-ci exigent généralement que les messages soient retransmis ou transférés entre les destinataires.

Un exemple d'une propriété de fiabilité plus forte que le rappel de la dernière copie est l'atomicité. Cette propriété exige que, si au moins une copie d'un message a été transmise à un destinataire, tous les autres destinataires finiront par recevoir une copie de ce message. En d'autres termes, chaque message est toujours livré soit à tous, soit à aucun des destinataires.

L'une des propriétés de fiabilité les plus complexes est la synchronie virtuelle.

Des propriétés de fiabilité fortes sont proposées par des systèmes de communication de groupe (GCS) tels IS-IS, Appia framework, Spread, JGroups ou QuickSilver Scalable Multicast. Le QuickSilver Proprerties Framework est une plateforme flexible qui permet d'exprimer des propriétés de fiabilité fortes de manière purement déclarative, à l'aide d'un langage simple basé sur des règles, qui sont automatiquement traduites dans un protocole hiérarchique.

Il y a, cependant, un problème avec la définition de la fiabilité comme la livraison ou notification de l'échec (de livraison) en informatique en temps réel. Dans de tels systèmes, le défaut de livraison de données temps-réel nuit aux performances, et certains systèmes tels les systèmes critiques, et certains systèmes sécurisés critiques dans le cadre de la mission, doivent prouver qu'ils sont capables de garantir un niveau de service minimum. Ceci, à son tour, exige un minimum de fiabilité lors de la livraison des données critiques. Par conséquent, c'est seulement la livraison qui compte, et notifier l'expéditeur de l'échec de la transmission n'empêche pas, ni n'atténue, l'échec de la couche transport du système temps réel à délivrer les données.

Dans les systèmes temps réel stricts et souples, les données doivent être livrées dans un délai fixé, c'est-à-dire que des données délivrées en retard n'ont plus de valeur. Dans le cas de systèmes temps réel stricts, toutes les données doivent être fournies avant la date d'échéance, ou le système sera considéré comme en état de défaillance. Dans les systèmes temps réel dits souples, il existe une certaine probabilité acceptable que les données soient pas livrées ou soient livrées en retard - ce qui est équivalent.

Il y a un certain nombre de protocoles qui sont capables de répondre à des exigences de temps réel pour la fiabilité de la livraison et la ponctualité, du moins pour les systèmes temps réel dits souples (en raison des inévitables et inéluctables pertes causées, par exemple, par le taux d'erreurs de la couche physique):

MIL-STD-1553B et STANAG 3910 sont des exemples bien connus de tels protocoles ponctuels et fiables pour les bus de données en avionique. MIL-1553 utilise un média à 1 Mbit/s partagé pour la transmission de données et le contrôle de ces transmissions, et est largement utilisé dans les systèmes avioniques militaires (dans lequel Chaque système a ses propres ordinateurs exerçant ses propres fonctions.

Il utilise un contrôleur de Bus (BC) pour commander les terminaux à distance (RTs) connecté de recevoir ou transmettre ces données. Le BC peut donc s'assurer qu'il n'y ait pas de congestion, et les transferts sont toujours ponctuels. Le protocole MIL-1553 permet également les nouvelles tentatives automatiques qui peuvent toujours assurer la livraison endéans le temps imparti et augmenter la fiabilité au-dessus de la couche physique. STANAG 3910, aussi connu comme EFABus dans son utilisation sur l'Eurofighter Typhoon, est, dans les faits, une version de la norme MIL-1553 augmentée avec un bus média à 20 Mbit/s partagé pour les transferts de données, tout en gardant le bus media partagé de 1 Mbit/s destiné au contrôle.

Le Mode de Transfert Asynchrone (ATM), le Avionics Full Duplex Switched Ethernet (AFDX), et le Time Triggered Ethernet (TTEthernet) sont des exemples de protocoles réseaux à commutation de paquets dans lesquels la ponctualité et la fiabilité des transferts de données peuvent être assurées par le réseau. AFDX et TTEthernet sont également basés sur la norme IEEE 802.3 Ethernet, bien qu'ils ne soient pas entièrement compatible avec celle-ci.

ATM utilise des canaux virtuels (VCs) orientés connexion, qui ont des chemins entièrement déterministes à travers le réseau, ainsi que le contrôle des paramètres d'utilisation et de réseau (UPC/NPC), qui sont mis en œuvre au sein du réseau, afin de limiter le trafic sur chaque VC individuellement. Cela permet que l'utilisation des ressources partagées (tampons de switches) dans le réseau soit calculée à l'avance à partir des paramètres du trafic qui sera acheminé, c'est-à-dire au moment de la conception du système. Le fait qu'ils soient mis en œuvre par le réseau signifie que ces calculs restent valables, même si d'autres utilisateurs du réseau se comportent de manière inattendue, c'est-à-dire de transmettre plus de données que ce qui était attendu. Les usages calculés peuvent ensuite être comparés avec les capacités des ressources pour montrer que, étant donné les contraintes sur les routes et les bandes passantes de ces connexions, la ressource utilisée pour ces transferts ne sera jamais dépassée. Ces transferts ne seront dès lors jamais être affectés par des problèmes de congestion et il n'y aura pas de pertes dues à cet effet. Ensuite, à partir de l'utilisation maximum prédite des tampons des switches, le délai maximum à travers le réseau peut également être prédit. Cependant, pour prouver la fiabilité et la ponctualité, et pour que les preuves soient insensibles aux défaillances du réseau et aux actes de malveillance causés par l'équipement connecté au réseau, le calcul de ces utilisations de ressources ne peut pas être fondée sur des paramètres qui ne sont pas imposés de façon active par le réseau, c'est-à-dire qu'ils ne peuvent pas se baser sur ce que les sources de trafic sont censées faire ou sur des analyses statistiques des caractéristiques du trafic (voir calcul de réseau).

AFDX utilise la limitation du flux ou l'allocation de bande passante, ce qui permet que le trafic sur chaque lien virtuel (VL) soit limité, de sorte que les exigences en matière de ressources partagées puissent être prédites et la congestion évitée. On peut ainsi prouver qu'elle n'affectera pas les données critiques. Cependant, les techniques de prévision des besoins en ressources et de preuve de l'impossibilité de la congestion ne font pas partie du standard AFDX.

TTEthernet fournit la latence la plus faible possible dans le transfert de données sur un réseau en utilisant des méthodes de contrôle de domaine temporel – à chaque fois, le déclenchement d'un transfert est prévu à un moment précis, de sorte que les conflits pour les ressources partagées soient entièrement contrôlés, et la possibilité de congestion éliminée. Les switches du réseau imposent ce moment pour assurer une résistance aux défauts du réseau, et aux actes de malveillance de la part d'autres équipements connectés. Cependant, des « horloges locales synchronisées sont la condition sine qua non pour la communication déclenchée par le temps ». En effet, les sources des données critiques devront avoir la même conception du temps que le switch, afin qu'ils puissent transmettre au bon moment et que le switch l'interprète correctement. Cela implique également que la séquence dans laquelle un transfert critique est prévu doit être prévisible à la fois pour la source et le switch. Ceci, à son tour, limitera la planification de la transmission à une planification très déterministe, comme un cyclic executive.

Cependant, une faible latence dans le transfert des données sur le bus ou le réseau ne se traduit pas nécessairement par de faibles délais dans le transport entre l'application qui émet et celle qui reçoit ces données. Ceci est particulièrement vrai lorsque les transferts sur le bus ou le réseau sont prévus de manière cyclique (comme c'est souvent le cas avec la norme MIL-STD-1553B et STANAG 3910, et toujours le cas avec AFDX et TTEthernet), mais que les processus des applications sont asynchrones, comme le multitâche préemptif ou seulement plésiochrones par rapport à ce cycle. Dans ce cas, le délai et la gigue maximum sera égal au double de la fréquence de mise à jour pour le transfert cyclique (les transferts attendent pendant la durée de l'intervalle de mise à jour entre l'émission et la réception, puis attendent encore pendant la durée de l'intervalle de mise à jour entre la réception et l'utilisation de la donnée transmise).

Avec AFDX et TTEthernet, il y a d'autres fonctions additionnelles exigées des interfaces avec le réseau pour la transmission de données critiques, etc., ce qui rend difficile l'utilisation d'interfaces Ethernet standard. Le contrôle d'écart d'allocation de bande passante d'AFDX, et les exigences de TTEthernet quant à la synchronisation très précise de l'envoi des données sont des exemples de ces fonctions. D'autres méthodes de contrôle du trafic dans le réseau, qui permettraient l'utilisation d'interfaces standard IEEE 802.3 sont à l'étude actuellement.