II. Panne et redémarrage des hôtes
Des problèmes importants peuvent survenir lorsqu'un hôte tombe en panne puis tente de redémarrer. Deux cas se distinguent aisément. Le premier est une panne « douce », où le système est prévenu à l'avance que la machine va s'arrêter ; il reste alors suffisamment de temps pour exécuter les procédures de préparation à la reprise. L'autre cas peut être qualifié de panne « dure », souvent la conséquence d'une défaillance système. L'avertissement est généralement insignifiant, mais surtout, l'état de la machine après la reprise est rarement prévisible.
Lorsqu'un hôte revient d'une panne dure, le réseau se trouve dans un état indéfini. Très probablement, les structures de données du NCP sont détruites ou dénuées de sens. Le réseau a déclaré l'hôte mort -- mais seulement vis-à-vis des processus qui ont tenté une transmission de données et ont été refusés. La seule alternative pour l'hôte victime de la panne est la réinitialisation de ses tables. Quelles sont les alternatives pour les hôtes distants ?
Nous souhaitons proposer l'ajout de deux commandes de contrôle : RESET (RST) et RESET REPLY (RSR). Chacune se composerait uniquement d'un code d'opération sans paramètres. À la réception d'un RST, un hôte mettrait immédiatement fin à toutes les connexions avec l'hôte émetteur, mais n'émettrait aucun CLS. Le récepteur du RST prendrait également note que l'émetteur du RST est vivant, puis renverrait un RSR à l'expéditeur. Lorsqu'un hôte reçoit un RSR, il devrait alors prendre note que l'hôte qui répond est vivant. (La fonction du RST peut être partiellement simulée si un hôte ferme immédiatement toutes les entrées de tables concernées dès qu'il découvre qu'un autre hôte est tombé.)
Ainsi, après une panne dure, toutes les connexions et toutes les demandes de connexion sont terminées. Le RST informe également tous les hôtes distants que nous sommes de nouveau vivants, et un RSR est reçu de chaque NCP fonctionnel. Une table des hôtes vivants (voir la NWG/RFC #55) peut être aisément constituée, et l'établissement de connexions peut reprendre.
Des problèmes apparents se posent également lorsque l'on envisage de synchroniser le réseau, qui peut encore transporter des messages générés avant la panne, avec un NCP dont l'environnement a été initialisé. Il nous manque les moyens de débloquer les liaisons, d'écarter les messages, etc. -- des moyens que cette proposition rendra nécessaires. De nouvelles interactions avec BBN devraient résoudre ces difficultés.
Les problèmes liés aux pannes « douces » sont bien moins pressants, et ils exigent des solutions plus sophistiquées (c'est-à-dire plus complexes). Notre expérimentation préliminaire sur le réseau montre qu'un bon protocole d'initialisation et de reprise est bien plus nécessaire.
Bon nombre des idées présentées ici ont germé et/ou pris forme au cours de conversations avec Steve Crocker et Jon Postel. Nous tenons également à remercier Jim Balter et Charles Kline de l'UCLA, qui ont consacré beaucoup d'efforts à aider à développer le programme en pseudo-Algol, qui a été le prélude d'une bonne partie de notre documentation récente.
Note: Cette RFC a été mise sous forme lisible par machine, pour intégration aux archives RFC en ligne, par Katsunori Tanaka en 2/98.