Protocollo utente-utente (proposta)

Il protocollo seguente è destinato ad applicarsi ai bit di dati nei messaggi compresi tra la fine dei bit di marcatura e l'inizio dei bit di riempimento. Gli attuali protocolli IMP-IMP e HOST-HOST non sono toccati da questa proposta.

Il principio generale è che ogni segmento (questo non è un termine tecnico) di dati è preceduto da informazioni di controllo che ne specificano la natura e l'estensione. Lo schema di base è stato sviluppato a partire da quello usato nel sistema di buffering SOS (si vedano gli articoli su JACM, aprile 1959 e in particolare quello di O.R. Mock).

Il nostro punto di vista è che un collegamento è un vettore di informazioni. Le informazioni sono trasportate in segmenti di lunghezza massima fissa chiamati messaggi [1]. Che sia così è un accidente, dal punto di vista dell'utente; quando desidera trasmettere un flusso contiguo di dati, in generale lo segmenterà in modo diverso (dal punto di vista del protocollo IMP-IMP o HOST-HOST) — chiameremo il suo segmento un record. Dovrebbe essere chiaro che questo è del tutto analogo alla nozione di blocco (fisico) e di record (logico). Per inciso, anche i sistemi di memorizzazione di file fanno uso di informazioni di controllo e di stato; lo faremo anche noi.

A livello del protocollo USER-USER, tutte le informazioni trasmesse sul collegamento sono una sequenza di flag seguiti da blocchi di dati (eventualmente nulli).

Il formato generale sarà:

        OPERATION     COUNT     DATA

Il campo OPERATION è sempre presente ed è lungo quattro bit. Il campo COUNT, quando presente, fornisce il numero di byte di dati che seguono nel blocco di dati. La dimensione del byte è fissata dall'ultimo flag SIZE precedente (nella maggior parte dei casi). Il byte può essere lungo tra zero e 255 bit (Sì, Virginia, zero è zero anche quando si ha un System/360). Il campo OPERATION e il campo COUNT (quando presente) sono chiamati il flag, e i byte di dati (quando presenti) il blocco di dati. I flag seguiti da blocchi di dati (anche quando nulli per un conteggio pari a zero) sono chiamati flag di blocco, e gli altri flag sono chiamati flag whyte [2].

Va notato che, poiché il flag SIZE fissa la dimensione del byte per i blocchi seguenti, la dimensione del byte può essere fissata a quella "naturale" per l'HOST mittente o per l'HOST ricevente, a seconda dell'accordo locale tra i processi mittente e ricevente. È specificamente richiesto che un flag SIZE compaia in ogni messaggio prima di qualsiasi flag di blocco (tranne il flag ASCII); il flag SIZE può essere introdotto su base predefinita dalla o dalle routine che implementano il protocollo ed è inteso in parte come mezzo per individuare certe classi di errore.

Il campo COUNT è lungo 8 bit (tranne nel flag EOM, dove è lungo 16 bit). I flag sono i seguenti:

Flag Whyte

Flag	Nome	Significato
0	NUL	Nessuna operazione (considera il flag successivo)
1	RS	Separatore di record (fine del record)
2	GS	Separatore di gruppo (fine del gruppo)
3	FS	Separatore di file (fine del file)
4	ESC	Fuga verso la convenzione locale per i flag
5		(riservato per assegnazione successiva)
6	EOM N	Fine del messaggio (N è il conteggio totale dei bit)
7	SIZE N	La dimensione del byte è di N bit
8	IGNORE N	Ignora i bit di dati seguenti

Flag di blocco

Flag	Nome	Significato
9	SYS N	N byte di dati per il sistema HOST ricevente
10	CONTROL N	Seguono N byte di dati di controllo
11	STATUS N	Seguono N byte di dati di stato
12	LABEL N	Seguono N byte di dati di identificazione
13	KEY N	Seguono N byte di dati di chiave
14	ASCII N	Seguono N byte (a 8 bit) di dati ASCII
15	BLOCK N	Seguono N byte di dati

Ho già menzionato il requisito per SIZE. L'assenza del flag SIZE in qualsiasi messaggio contenente flag di blocco (tranne ASCII) è un errore certo. EOM è in parte un altro dispositivo di controllo degli errori e in parte un dispositivo per aggirare l'enigma del riempimento. Un programma utente non dovrebbe mai vedere EOM in ingresso; l'utente può scrivere un EOM per forzare la trasmissione. EOM delimita la fine delle informazioni utili nel messaggio e ribadisce il numero totale di bit nel messaggio, a partire dal primo bit successivo alla marcatura e fino all'ultimo bit del campo di conteggio EOM, per verificare una possibile perdita di informazioni. Si tratta di un controllo contro errori nell'interfaccia elettrica IMP-HOST e nel mushyware dell'HOST. EOM deve comparire alla fine di ogni messaggio, a meno che sia comparso ESC.

ESC è inteso come un (si spera) inutilizzato portello di fuga, per il non uso da parte di quelle installazioni e/o applicazioni che desiderano evitare di usare più di quattro bit del protocollo USER-USER su qualsiasi collegamento. Per esempio, si può desiderare di usare un collegamento come flusso di bit, ignorando persino i confini dei messaggi. Se e quando gli anarchici riusciranno a raggiungere un accordo locale, tanto di cappello a loro!

NUL e IGNORE sono intesi come riempitivi di spazio, nel caso sia utile far cadere il primo bit del successivo blocco di dati su un confine di indirizzo comodo. (Una routine di interrupt dell'HOST particolarmente servizievole potrebbe persino incollare una combinazione di NUL e IGNORE sopra i bit di marcatura al momento della ricezione di un messaggio — nel qual caso il loro conteggio di bit dovrebbe essere trasmesso alle routine GET per correggere il controllo del conteggio di bit EOM). Le operazioni separatore introducono le nozioni di record logico, gruppo e file. In particolare, non vi è alcun requisito che un record sia contenuto interamente in un messaggio o che in un messaggio sia contenuto un solo record! Inoltre, non vi è alcun requisito che durante una connessione venga trasmesso un solo file. Per esempio, un utente potrebbe voler usare un collegamento per trasmettere una raccolta di routine, e poi fare qualcos'altro con il collegamento.

Per accordo locale, dunque, una singola routine potrebbe consistere di un certo numero di record che formano un gruppo, l'intera raccolta potrebbe formare un file, e il collegamento potrebbe rimanere connesso dopo la ricezione del flag FS.

L'interpretazione dei vari flag di blocco è parimenti aperta all'accordo locale. I due flag destinati a veicolare dati puri sono ASCII e BLOCK; la differenza tra loro è solo (per quanto riguarda il protocollo) che la dimensione del byte è implicita per ASCII (8 bit) ed esplicita per BLOCK (il campo di conteggio del flag SIZE immediatamente precedente). Oltre a ciò, tuttavia, il contenuto semantico del blocco che segue ASCII è governato dagli standard correnti per ASCII; le informazioni EBCDIC non possono essere trasmesse in un blocco ASCII!!

CONTROL e STATUS sono destinati alla comunicazione di informazioni di controllo tra processi utente, e l'interpretazione dei loro blocchi di dati di accompagnamento è aperta all'accordo locale. In generale, CONTROL significa "prova a fare quanto segue" e STATUS significa "ma io la sento così, dottore". Un flag CONTROL provocherà un flag STATUS di ritorno, prima o poi, o mai. LABEL è destinato all'uso nell'identificazione della o delle unità di dati seguenti, a livello di file o di gruppo. Anche in questo caso, l'interpretazione specifica è materia di accordo locale. KEY è inteso a imitare la nozione di indirizzo o chiave — questo a livello di record, di elemento di dati o persino di blocco di memorizzazione fisica. Per chi ha familiarità con il sistema PDP-10 e/o OS/360, si offrono i seguenti paralleli come guida:

   USER-USER protocol      OS/360            PDP-10
   __________________      ______            ______

     CONTROL               OPEN              OPEN

                           CLOSE             CLOSE

     LABEL                 DSCB              File retrieval information

     KEY                   KEY               USETI/USETO argument

     CONTROL               READ              IN/INPUT

                           WRITE             OUT/OUTPUT

                           ALLOCATE ?        ENTER

                           OPEN ?            LOOKUP

     STATUS                ?                 GETSTS

Le notazioni "?" sopra indicano l'assenza di un parallelo molto diretto. Vale la pena notare che GET e PUT dell'OS/360 hanno paralleli diretti in qualsiasi implementazione del protocollo USER-USER che incarni la nozione di record; la nostra implementazione del protocollo porterà all'introduzione di questa nozione per tutto l'input/output del PDP-10 che coinvolge memoria a disco e a nastro, nonché la comunicazione via IMP.

Se conoscessi la terminologia di MULTICS, potrei estendere l'insieme dei paralleli sopra con maggiore precisione. Sebbene la mia terminologia sia stata tratta da sistemi con imperativi di input/output espliciti, desidero sottolineare che questa impostazione è intesa a gestire in generale la comunicazione di controllo e di dati; MULTICS è un sistema in cui la distinzione classica tra memoria esterna e interna è sfumata (dal punto di vista dell'utente) in un modo che desidero veder sfumato nel protocollo USER-USER. Offro SYS con solo lieve trepidazione. La nozione generale è che si dovrebbe poter comunicare direttamente con un HOST straniero anziché tramite un processo utente straniero come suo intermediario. SYS è come una UUO o una SVC, ma per il consumo dell'HOST straniero anziché del mio HOST. Dal punto di vista dell'HOST, il problema nell'implementazione sta nello stabilire un record di contesto di processo non collegato ad alcun processo utente locale. Questo, tuttavia, è fortemente associato al nostro attuale enigma del LOGON. Sul PDP-10, per esempio, gli utenti sono più o meno identificati con le linee di telescrivente locali, e qualsiasi collegamento non è una di quelle! Quindi è necessario un sotterfugio per permettere a un utente straniero di effettuare il log on. OS/360 è altrettanto (in realtà, più) perverso a modo suo.

Il processo di far accedere un processo straniero al mio sistema locale non è (tranne forse per MULTICS) una semplice questione di avere presente uno speciale (!!) job utente che si incarica di farlo. Quando e se qualcos'altro è possibile, l'HOST deve fornire un'istruzione di sistema (UUO o SVC o quant'altro) che fornisca le informazioni necessarie a stabilire un processo indipendente in tutti i sensi dal processo che ha fatto la richiesta. Altrimenti, meccanismi di autoprotezione ragionevoli per qualsiasi sistema ci renderanno tutti molto più interdipendenti di quanto desideriamo. Per fare ciò, deve esistere in ogni sistema una UUO/SVC che faccia la cosa giusta (ATTACH, ma dimenticami). Se questo è vero, allora il processo di LOGON sulla Network equivale all'emissione di una UUO/SVC straniera da parte di un altro nodo nella Network. Non vedo alcun modo ragionevole per aggirare questo. Se le cose stanno così, allora SYS N è il tipo di flag da usare per veicolare i dati necessari. Se è così, allora è del tutto ragionevole lasciare che SYS veicoli una richiesta per qualsiasi istruzione del sistema operativo a livello dell'interfaccia tra programma utente e sistema operativo!

Le questioni pratiche di implementazione sono un'altra cosa! Nel caso del PDP-10, riesco abbastanza bene a vedere come trasformare un SYS in una richiesta di LOGON per eseguire un comando del monitor o una UUO (magari fossero la stessa cosa), a seconda dei casi. OS/360 è più sofisticato, purtroppo. MULTICS potrebbe farcela. Nondimeno, spero sia chiaro che ciò che vogliamo fare, che è ciò che il protocollo dovrebbe riflettere, è una questione del tutto diversa da quella di come debba essere fatto nel contesto di uno specifico sistema HOST. Ciò che vogliamo fare è, in generale, piuttosto indipendente dal sistema con cui abbiamo a che fare per quanto riguarda il protocollo, e non dovremmo mancare di introdurre nozioni generali nel protocollo solo perché siamo incerti su come esse debbano essere tradotte in una particolare prassi implementativa.