II. Arresto e riavvio degli host
Possono sorgere problemi significativi quando un host si arresta e poi tenta di riavviarsi. Due casi si distinguono facilmente. Il primo è un crash "morbido", in cui il sistema ha un avviso preventivo che la macchina sta per arrestarsi; è disponibile tempo sufficiente per eseguire le procedure di pre-recupero. L'altro caso può essere definito crash "grave", spesso conseguenza di un guasto di sistema. Di solito l'avvertimento è minimo; ma, cosa più importante, lo stato della macchina dopo il recupero è raramente prevedibile.
Quando un host torna dopo un crash grave, la rete si trova in uno stato indefinito. Molto probabilmente le strutture dati dell'NCP sono distrutte o prive di significato. La rete ha dichiarato l'host morto -- ma solo ai processi che hanno tentato la trasmissione di dati ed è stato loro rifiutato. L'unica alternativa per l'host andato in crash è la reinizializzazione delle sue tabelle. Quali sono le alternative per gli altri host?
Vorremmo proporre l'aggiunta di due comandi di controllo: RESET (RST) e RESET REPLY (RSR). Ciascuno consisterebbe soltanto di un op code senza parametri. Alla ricezione di un RST, un host terminerebbe immediatamente tutte le connessioni con l'host mittente, ma non emetterebbe alcun CLS. Il ricevente dell'RST noterebbe anche che l'originatore dell'RST è vivo, e risponderebbe poi con un RSR al mittente. Quando un host riceve un RSR, dovrebbe allora notare che l'host che ha risposto è vivo. (La funzione dell'RST può essere parzialmente simulata se un host chiude immediatamente tutte le voci di tabella pertinenti non appena scopre che un altro host è giù.)
Così, dopo un crash grave, tutte le connessioni e le richieste di connessione vengono terminate. L'RST informa inoltre tutti gli altri host che siamo di nuovo vivi, e viene ricevuto un RSR da ogni NCP funzionante. Una tabella degli host vivi (vedi NWG/RFC #55) può essere facilmente assemblata, e l'instaurazione delle connessioni può riprendere.
Problemi correlati sorgono anche quando si considera il tentativo di sincronizzare la rete, che può ancora trasportare messaggi generati prima del crash, con un NCP che ha un ambiente inizializzato. Ci mancano le funzioni per sbloccare i link, scartare i messaggi, ecc. -- funzioni che questa proposta renderà necessarie. Un'ulteriore interazione con BBN dovrebbe risolvere queste difficoltà.
I problemi associati ai crash "morbidi" non sono così urgenti, ed essi richiedono soluzioni più sofisticate (cioè complesse). La nostra sperimentazione preliminare con la rete dimostra che un buon protocollo di inizializzazione e recupero è molto più necessario.
Molte delle idee qui presentate sono state germinate e/o consolidate attraverso conversazioni con Steve Crocker e Jon Postel. Vorremmo inoltre ringraziare Jim Balter e Charles Kline di UCLA, che hanno dedicato grande impegno ad aiutare a sviluppare il programma in pseudo-Algol che è stato il predecessore di gran parte della nostra documentazione recente.
Nota: Questa RFC è stata convertita in formato leggibile dalla macchina per l'inserimento negli archivi RFC online da Katsunori Tanaka 2/98.