III. Il software host
Stabilimento di una connessione
La connessione più semplice che possiamo immaginare è quella in cui l'host locale agisce come se fosse un TTY e ha composto l'host remoto. Dopo aver considerato i problemi di avvio e terminazione di tale connessione, è stato deciso di riservare il collegamento 0 per la comunicazione tra i sistemi operativi host. I restanti 31 collegamenti devono quindi essere utilizzati come linee da comporre.
Ogni sistema operativo host deve fornire ai suoi programmi a livello utente una primitiva (primitive) per stabilire una connessione con un host remoto e una primitiva per interrompere la connessione. Quando queste primitive vengono invocate, il sistema operativo deve selezionare un collegamento libero e inviare un messaggio tramite collegamento 0 all'host remoto richiedendo una connessione sul collegamento selezionato. Il sistema operativo nell'host remoto deve accettare e inviare un messaggio di accettazione tramite collegamento 0. Nel caso in cui entrambi gli host selezionino lo stesso collegamento per avviare una connessione ed entrambi inviino messaggi di richiesta essenzialmente nello stesso momento, verrà invocato un semplice schema di priorità in cui l'host di priorità inferiore cede e seleziona un altro collegamento libero. Uno schema di priorità utilizzabile è semplicemente la classificazione degli host in base ai loro numeri di identificazione. Si noti che entrambi gli host sono consapevoli che sono state fatte richieste simultanee, ma intraprendono azioni complementari: l'host di priorità superiore ignora la richiesta mentre l'host di priorità inferiore invia sia un'accettazione che un'altra richiesta.
La connessione così stabilita è una connessione di tipo TTY nello stato pre-login. Ciò significa che il sistema operativo dell'host remoto tratterà inizialmente il collegamento come se un TTY avesse appena chiamato. L'host remoto genererà gli stessi echi, si aspetterà la stessa sequenza di login e cercherà gli stessi caratteri di interruzione.
Trasmissione ad alto volume
Le telescriventi che fungono da terminali hanno due svantaggi particolari quando consideriamo la trasmissione di un file di grandi dimensioni. Il primo è che alcuni caratteri sono caratteri di interruzione speciali. Il secondo è che vengono spesso impiegate tecniche di buffering speciali, e queste sono appropriate solo per trasmissione a bassa velocità carattere per carattere.
Definiamo quindi un'altra classe di connessione da utilizzare per la trasmissione di file o altri grandi volumi di dati. Per avviare questa classe di collegamento, i programmi a livello utente a entrambe le estremità di un collegamento di tipo TTY stabilito devono richiedere lo stabilimento di una connessione di tipo file parallela al collegamento di tipo TTY. Lo schema di priorità entra nuovamente in gioco, poiché l'host di priorità superiore invia un messaggio tramite collegamento 0 mentre l'host di priorità inferiore lo attende. I programmi a livello utente, ovviamente, non se ne preoccupano. La selezione del collegamento libero viene effettuata dall'host di priorità superiore.
I collegamenti di tipo file si distinguono per il fatto che non viene eseguita alcuna ricerca di caratteri di interruzione e vengono utilizzate tecniche di buffering appropriate per velocità di dati più elevate.
Un riepilogo delle primitive
Ogni sistema operativo host deve fornire almeno le seguenti primitive ai suoi utenti. Questo elenco è noto per essere necessario ma non sufficiente.
a) Avviare una connessione di tipo TTY con l'host x.
b) Terminare la connessione.
c) Inviare/Ricevere caratteri tramite connessione di tipo TTY.
d) Avviare una connessione di tipo file parallela alla connessione di tipo TTY.
e) Terminare la connessione di tipo file.
f) Inviare/Ricevere tramite connessione di tipo file.
Controllo degli errori
Proponiamo che ogni messaggio porti un numero di messaggio, un conteggio di bit e un checksum nel suo corpo, che è trasparente all'IMP. Per un checksum suggeriamo una somma end-around-carry a 16 bit calcolata su 1152 bit e poi spostata circolarmente a destra di un bit. Lo spostamento circolare a destra ogni 1152 bit è progettato per catturare errori nel riassemblaggio dei messaggi da parte degli IMP.
Interazione più stretta
Le primitive sopra descritte suggeriscono come un utente può fare un uso semplice di una struttura remota. Non fanno luce su come debba essere effettuato un uso molto più complesso della rete. Specificamente, siamo preoccupati per il fatto che in alcuni siti è stato investito molto lavoro per rendere il computer altamente reattivo a una console sofisticata. Le console di Culler alla UCSB e quelle di Englebart a SRI sono almeno due esempi. È chiaro che ritardi di circa mezzo secondo per risposte banali di tipo eco degradano l'interazione fino al punto di rendere irrilevante la sofisticazione della console.
Crediamo che la maggior parte dell'interazione con la console possa essere divisa in due parti, una parte essenzialmente locale, immediata e banale e una parte remota, più lunga e significativa. Come semplice esempio, consideriamo un utente a una console composta da una tastiera e uno schermo di visualizzazione rinfrescante. Il programma in cui l'utente sta digitando accumula una stringa di caratteri fino a quando non viene incontrato un ritorno carrello, quindi elabora la stringa. Mentre i caratteri vengono digitati, visualizza i caratteri sullo schermo. Quando viene digitato un carattere di cancellazione (rubout), elimina il carattere non di cancellazione precedente. Se l'utente digita H E L L O <- <- P <CR> dove <- è cancellazione e <CR> è ritorno carrello, ha effettuato nove pressioni di tasti. Se ognuna di queste pressioni di tasti causa l'invio di un messaggio che a sua volta invoca istruzioni alla nostra stazione di visualizzazione, ci annoieremo rapidamente.
Una soluzione migliore sarebbe avere il front-end del programma remoto -- cioè la parte che cerca <- e <CR> -- residente nel nostro computer. In quel caso, verrebbe inviato solo un messaggio di cinque caratteri, cioè H E L P <CR>, e lo schermo verrebbe gestito localmente.
Proponiamo di implementare questa soluzione creando un linguaggio per il controllo della console. Questo linguaggio, attualmente denominato DEL, verrebbe utilizzato dai progettisti di sottosistemi per specificare quali componenti sono necessari in un terminale e come il terminale deve rispondere agli input dalla sua tastiera, Lincoln Wand, ecc. Quindi, come parte del protocollo iniziale, l'host remoto invierebbe all'host locale il testo del linguaggio sorgente del programma che controlla la console. Questo programma sarebbe stato scritto dal progettista del sottosistema in DEL, ma verrà compilato localmente.
Le specifiche di DEL sono in discussione. I seguenti diagrammi mostrano la sequenza delle azioni.
A. Prima dello stabilimento del collegamento
/ \
| +-----------+ +-----------+ |
| | | | | |
| | | | | |
| | terminal | | terminal | |
| | | | | |
| | | | | |
| +-----+-----+ +-----+-----+ |
| | | |
| | | |
| | | |
| +-----+-----+ +-----------+ |
| | | | Request connection | | | |
UCLA { | | | -> over link 25 | | | } SRI
| | +-+-+ | +-+ +-+ | +-+-+ | |
| | | OS|---+-=|I|----------|I|=-+---| OS| | |
| | +-+-+ | +-+ +-+ | +---+ | |
| | | | | |
| | | | | |
| +-----------+ +-----------+ |
| HOST: UCLA HOST: SRI |
\ /
B. Dopo lo stabilimento del collegamento e il login
/ \
| +-----------+ +-----------+ |
| | | | | |
| | | | | |
| | terminal | | terminal | |
| | | | | |
| | | | | |
| +-----+-----+ +-----+-----+ |
| | | |
| | | |
| | | |
| +-----+-----+ "Please send front"+-----------+ |
| | | | end control" | | | |
UCLA { | | | -> | | | } SRI ___
| | +-+-+ | +-+ +-+ | +--+---+ | | / |
| | | OS|---+-=|I|----------|I|=-+--|OS|NLS| +----+---| |
| | +-+-+ | +-+ +-+ | +------+ | | |___/
| | | DEL prog. | | | | |
| | | <- | | | |____|
| +-----------+ +-----------+ |
| HOST: UCLA HOST:SRI |
\ /
C. Dopo la ricezione e la compilazione del programma DEL
/ \
| +-----------+ +-----------+ |
| | | | | |
| | | | | |
| | terminal | | terminal | |
| | | | | |
| | | | | |
| +-----+-----+ +-----+-----+ |
| |Trivial | |
| |Responses | |
| | | |
| +-----+------+ +-----------+ |
| | | | | | | |
UCLA { | | | Major Responses | | | } SRI ___
| | +--+--+ | +-+ +-+ | +--+---+ | | / |
| | |DEL |---+-=|I|----------|I|=-+--|OS|NLS| +---+---| |
| | |front| | +-+ +-+ | +------+ | | |___/
| | | end | | | | | | |
| | |prog.| | | | | |____|
| | +-----+ | | | |
| | | OS | | | | |
| | +-----+ | | | |
| | | | | |
| +------------+ +-----------+ |
| HOST: UCLA HOST: SRI |
\ /
Questioni aperte
-
Se gli IMP eseguono la conversione del codice, il checksum non sarà corretto.
-
La procedura per richiedere il front-end DEL non è ancora specificata.