Introduzione

(Quelle qui esposte sono sia le mie opinioni personali sia quelle che ritengo rappresentino un consenso del Network Working Group al Project MAC. I pronomi « io » e « noi » servono a distinguerle.)

Il 21 e il 23 aprile, Thomas P. Skinner e io abbiamo avuto conversazioni telefoniche con Steve Crocker, a UCLA, sul protocollo di rete e più precisamente sulla nostra proposta nel NWG/RFC 46. Sono stati discussi i punti seguenti. (Spero che Steve mi perdonerà se lo parafraso inesattamente.)

Steve ha dichiarato che, a suo avviso, l'esigenza di una riconnessione dinamica sarebbe stata riconosciuta più tardi dai partecipanti alla rete. Tuttavia, per mancanza di consenso, essa non sarà inclusa nell'implementazione iniziale. (Noi del Project MAC siamo favorevoli a questo approccio di non includerla all'inizio.)
Steve ha sostenuto l'implementazione del comando di rete INT descritto nel NWG/RFC 46.

Questo comando consente a un processo che ha accettato di ricevere interruzioni su una connessione socket di essere interrotto in modo affidabile dal processo all'altro estremo. L'interruzione induce un processo a sospendere l'esecuzione in corso e a eseguire una procedura che ha designato come gestore di INT. (Il NCP non specifica il gestore di INT. È compito dei protocolli di livello superiore.)

Il comando INT è concepito specificamente per essere usato da un protocollo di controllo e comunicazione utente (UCC) di terzo livello per realizzare un segnale « quit ». In un tale protocollo, il richiedente e il processo creato convengono che un INT relativo a una determinata connessione socket e trasmesso sul collegamento di controllo del NCP al processo creato costituisce il segnale « quit » standard. Il processo creato fornisce un gestore di INT che realizza questa funzione « quit ». (Ciò non preclude una diversa interpretazione di INT da parte di altri protocolli di terzo livello.)

Sebbene molti sistemi realizzino il « quit » come carattere di controllo nel flusso di input del telescrivente, sistemi come CTSS, Multics e altri lo realizzano come una spaziatura di 200 ms sulla linea. Noi del MAC riteniamo che il primo metodo sia un'implementazione indesiderabile all'interno della rete (mentre il secondo è impossibile). Ho esposto diverse ragioni al riguardo (e credo che Steve fosse d'accordo).

(a) Il collegamento sul quale deve essere trasmesso il carattere di quit può essere bloccato.

(b) Sebbene l'interruzione sia realizzata nel modo più efficace all'interno del NCP, non è desiderabile che il NCP imponga una struttura particolare ai dati trasmessi. (Vedere la discussione qui sotto.) Ciò sarebbe necessario se il NCP dovesse scandire un flusso di dati alla ricerca di un carattere di controllo.

(c) La scansione del flusso di input riduce fortemente l'efficienza del NCP in un sottosistema in cui la velocità è determinante per un funzionamento efficace.

Steve ha fatto notare che realizzare INT come « quit » non dovrebbe necessariamente precludere che un HOST interpreti come « quit » anche un carattere di controllo presente nel flusso di input.

Steve è contrario sia a includere il tag di istanza nell'identificatore di socket sia a riservare un campo nullo nell'identificatore per una definizione futura. Ha citato diverse ragioni:

(a) I processi multipli di un singolo utente devono essere indistinguibili per un processo estraneo. (Sono d'accordo in certi casi, quando i processi sono coordinati in un'azione comune. Ma che dire del caso in cui due processi dello stesso utente vogliono usare la rete indipendentemente l'uno dall'altro?)

(b) Un processo che desidera connettersi a uno dei processi di un utente estraneo non conosce il tag di istanza del processo particolare che vuole raggiungere, e non può scoprirlo facilmente.

(c) Se in seguito un tag di istanza si rivelasse desiderabile, lo si potrebbe aggiungere con qualche difficoltà. (Sostengo che una cosa fondamentale come la lunghezza di un identificatore di socket si rivelerà molto resistente al cambiamento.)

Tom ha dichiarato che forse i tre bit di ordine inferiore del codice utente potrebbero essere riservati a una successiva interpretazione come tag di istanza. Non ritiene che un campo separato sia di grande importanza.

Gli argomenti di Steve sembrano avere un certo valore. Forse il suggerimento di Tom è la strada da seguire. Al momento sono indeciso su questa questione.

Sembra che tutti noi (Steve e il MAC) conveniamo che al livello del NCP non debba essere imposta alcuna struttura particolare ai dati trasmessi. Per un NCP, tutti i dati da trasmettere sono stringhe di bit di lunghezza arbitraria. Un felice risultato è che la difficile questione degli insiemi di caratteri non deve essere risolta a questo livello di protocollo. Includere una specifica dell'insieme di caratteri al livello del NCP ritarderebbe l'accordo sul protocollo e renderebbe tale insieme di caratteri più resistente al cambiamento. (Se deve esserci un insieme di caratteri standard, preferiamo l'ASCII. Dopotutto è lo standard preferito del nostro ente finanziatore.)

Conveniamo inoltre con Steve che non deve esserci alcun echo opzionale dei messaggi al livello del protocollo NCP. (Questa è anche la posizione della gente dell'SDC nel RFC 44.)

Shoshani, Long e Landsberg dichiarano anch'essi (RFC 33) di preferire l'allineamento dei messaggi in modo che terminino su un confine di parola, anziché il doppio riempimento. Steve concorda con noi nel non gradire il doppio riempimento.
Nella nostra proposta (RFC 46) suggeriamo che gli RFC siano accodati solo per i socket aperti, e che gli RFC destinati a socket inattivi o connessi siano respinti automaticamente mediante il comando CLS. Steve propone che gli RFC destinati a questi socket siano brevemente accodati. Se il socket rimane in uno stato inaccettabile per un intervallo determinato dopo l'arrivo dell'RFC, questo viene respinto. Questo schema consente di implementare certi tipi di interazione tra comandi di rete che comportano corse critiche. Un tale schema di accodamento limitato non mi sembra irragionevole.
Steve, Tom e io abbiamo discusso strategie per un protocollo di controllo e comunicazione utente (UCC). Steve ha detto che non gradiva la nostra strategia UCC (RFC 46) perché richiede di mantenere due connessioni full-duplex verso il processo richiedente e di commutare tra esse.

Steve ha avanzato una proposta alternativa: un processo che desidera creare un processo utente su un HOST estraneo emette RFC verso i socket 0 e 1 appartenenti all'utente di cui vuole creare il processo. Se questi socket sono inattivi, il NCP indirizza automaticamente tali richieste al processo di login (logger) dell'HOST estraneo. Il logger accetta la connessione ed esegue il rituale di accesso. Se ha successo, il logger crea un processo utente e rilascia i socket usurpati, affinché il processo creato possa usarli per comunicare con il processo richiedente. (Osservo che ciò non usa la riconnessione a livello di rete, poiché il logger usa socket appartenenti all'utente finale. Comporta però una riconnessione interna.)

Tom e io ci siamo opposti perché ciò introduce il protocollo UCC al livello del NCP. (Il NCP deve indirizzare tutti gli RFC ai socket 0 e 1 inattivi verso un processo di login.) Ho fatto una rapida proposta: forse le nostre due proposte potrebbero essere combinate in modo che il richiedente emetta un RFC di « segnalazione » verso un socket « segnale » del processo UCC. L'UCC rifiuta l'RFC ma ricorda chi sta chiamando. Tenta poi di connettere due socket del processo da creare ai socket del richiedente e conduce attraverso essi il rituale di accesso. Steve apprezzò la cosa e mi suggerì di metterla per iscritto.

Dopo la conversazione, ho pensato a diversi svantaggi di questa strategia UCC:

(a) Se i socket di controllo di un processo creato sono limitati a 0 e 1, è possibile che un utente legittimo non riesca a comunicare con un UCC estraneo perché l'UCC sta già usando quei socket per comunicare con un impostore. Il logger lo scoprirà e disattiverà l'impostore, ma si tratta di una falla di sicurezza aggravante. Un processo malevolo potrebbe emettere richieste multiple simultanee per occupare i socket e impedire l'accesso a un utente legittimo. Una soluzione migliore è consentire a qualsiasi coppia di socket del potenziale processo utente di fungere da percorso di controllo. Ciò permette all'UCC di condurre interrogazioni simultanee di richiedenti concorrenti.

(b) Uno svantaggio sia dell'UCC di Crocker sia dell'UCC combinata è che l'utente da collegare viene specificato fornendo un socket appartenente a un particolare utente. Il logger deve ora fare la verifica aggiuntiva che l'utente che sta collegando appartenga davvero alla coppia di socket su cui sta parlando. Ciò sembra l'inverso del processo preferito: identificare un utente e poi determinare il codice utente dei suoi identificatori di socket.

(c) L'utente può non conoscere il codice utente del socket dell'utente che desidera collegare sull'HOST estraneo. (Dopotutto, non c'è alcuna ragione fondamentale per cui i processi richiedente e creato debbano avere lo stesso codice utente, purché il richiedente soddisfi il logger estraneo.)

(d) Nella strategia combinata, il richiedente non ha modo di specificare quale codice utente di socket desidera. L'unica ipotesi che l'UCC può fare è che il processo richiedente voglia collegare un processo avente lo stesso codice utente di socket del proprio. (Può sembrare poco importante, ma immagino uno schema in cui esista un processo locale che consenta alle console collegate all'HOST locale di accedere a un HOST estraneo senza essere connesse localmente.)

(e) L'idea di consentire a un processo di mascherarsi all'interno della rete come un altro processo (anche con le migliori intenzioni) usando il proprio codice utente di socket introduce una falla di sicurezza potenzialmente pericolosa. Ritengo che dovrebbe essere una legge fondamentale del protocollo che nessun processo, quale che sia, richieda o accetti connessioni, né trasmetta o riceva dati, su un socket il cui codice utente non sia il proprio. Ciò non si applica a un processo NCP che ha la responsabilità di tale trasmissione, né impedisce a un processo privilegiato di chiudere o rifiutare connessioni tra un processo estraneo e un altro processo locale.

Ritengo ancora che la proposta UCC che abbiamo avanzato nel RFC 46 sia un buono schema realizzabile. Non richiede riconnessione di socket (né esplicitamente in tutta la rete, né implicitamente all'interno di un NCP), e nessuna delle obiezioni sollevate sopra vi si applica. L'unico svantaggio particolare che vedo è che obbliga il processo richiedente a mantenere due connessioni full-duplex e a commutare tra esse. Non lo considero un ostacolo serio. In particolare, gradirei i commenti dei partecipanti alla rete su questo punto.

Per fortuna l'UCC è un protocollo di terzo livello. Il NCP di secondo livello può essere specificato prima che si raggiunga un accordo finale su un UCC, purché il NCP consenta l'implementazione di un UCC realizzabile.

Steve ha espresso l'idea che non sia necessario un UCC standard iniziale e che possano esserci più UCC. Noi del MAC non siamo d'accordo. Se dobbiamo parlare tutti tra noi, e non solo tra sottoinsiemi limitati di HOST della rete, deve esistere un UCC standard iniziale che tutti implementino. (Steve ha naturalmente ragione nel dire che possono essere implementati anche altri UCC sperimentali.)

È teoricamente possibile che ogni HOST fornisca più insiemi di software per consentire a un processo richiedente di comunicare con i logger degli HOST che implementano UCC diversi. Non ritengo che in pratica funzionerà così. Ogni HOST implementerà il protocollo UCC che gli è più congeniale e fornirà un solo insieme di software, cosicché un processo richiedente potrà comunicare soltanto con gli HOST che implementano UCC simili.

Non ritengo che al Project MAC vi sia molto entusiasmo per implementare un UCC non standard solo per poter parlare tra noi. Vogliamo implementare un unico UCC supportato in tutte le installazioni, in modo da poter accedere a tutti gli HOST con questo protocollo e da consentire agli utenti di tutti gli HOST estranei di accedere da noi.

Nota: Questo RFC è stato reso in forma leggibile da macchina per l'inserimento negli archivi RFC in linea da Altair Petrofsky 7/97.