Protocollo di livello superiore

La rete pone problemi speciali quando è richiesto un alto grado di interazione tra l'utente e un particolare sottosistema in un host remoto. Questi problemi sorgono a causa dell'eterogeneità delle console, dell'overhead dei sistemi operativi locali e dei ritardi di trasmissione della rete. A meno di usare strategie speciali, può essere difficile o persino impossibile per un utente distante avvalersi dei sottosistemi più sofisticati offerti. Sebbene queste difficoltà siano particolarmente gravi nell'area della grafica, possono sorgere problemi anche per l'interazione con una telescrivente. Per esempio, supponiamo che un sottosistema remoto sia progettato per console di telescriventi collegate via telefono, e che poi questo sottosistema diventi disponibile agli utenti della rete. Questo sottosistema potrebbe avere le seguenti caratteristiche.

1. Salvo che per l'eco e la correzione degli errori di digitazione, non viene intrapresa alcuna azione finché non viene digitato un ritorno a capo.
2. Tutti i caratteri, tranne "^", "<-" e i ritorni a capo, vengono ripetuti in eco man mano che il carattere viene digitato.
3. <- causa la cancellazione del carattere immediatamente precedente e viene ripetuto in eco come quel carattere.
4. ^ fa sì che tutti i caratteri digitati in precedenza vengano ignorati. Vengono ripetuti in eco un ritorno a capo e un avanzamento di riga.
5. Un ritorno a capo viene ripetuto in eco come un ritorno a capo seguito da un avanzamento di riga.

Se ogni carattere digitato viene inviato in un proprio messaggio, allora i caratteri

H E L L O <- <- P c.r.

causano nove messaggi in ciascuna direzione. Inoltre, ogni carattere è gestito da un programma a livello utente nell'host locale prima di essere inviato all'host remoto.

Ora è chiaro che, se questo particolare esempio fosse importante, implementeremmo rapidamente le regole da 1 a 5 in un programma dell'host locale e invieremmo all'host remoto solo righe complete. Se il programma dell'host remoto non potesse essere modificato in modo da non generare echi, allora il programma locale non solo potrebbe ripetere correttamente in eco, ma potrebbe anche scartare gli echi successivi provenienti dall'host remoto. Tuttavia, il problema non è un particolare schema di interazione; il problema è che ci aspettiamo che si presentino molti schemi di questo tipo. Non abbiamo trovato soluzioni generali a questi problemi, ma alcune osservazioni e congetture possono indicare la strada.

Per quanto riguarda le console eterogenee, osserviamo che, sebbene le console siano raramente compatibili, molte sono equivalenti. È probabilmente ragionevole considerare una telescrivente modello 37 equivalente a un IBM 2741. Analogamente, la maggior parte degli scope a memoria formerà una classe di equivalenza, e la maggior parte degli scope a display con refresh ne formerà un'altra. Inoltre, potrebbe emergere una gerarchia in cui i membri di una classe sono utilizzabili al posto di quelli di un'altra, ma non viceversa. Possiamo immaginare che qualsiasi scope possa essere un sostituto adeguato di una telescrivente, ma difficilmente il contrario. Questa osservazione ci porta a chiederci se sia possibile un linguaggio per console valido a livello di rete. Un tale linguaggio prevedrebbe un trattamento distinto per le diverse classi di console, con semantiche appropriate a ciascuna classe. Ogni sito potrebbe allora scrivere programmi di interfaccia per le proprie console, per farle apparire come dispositivi standard della rete.

Un'altra osservazione è che un utente valuta un sistema interattivo confrontando la velocità delle risposte del sistema con le proprie aspettative. A volte un utente ritiene di aver fatto solo una richiesta di minore importanza, quindi la risposta dovrebbe essere immediata; altre volte ritiene di aver fatto una richiesta sostanziale ed è quindi disposto ad attendere la risposta. Alcuni sottosistemi interattivi sono particolarmente piacevoli da usare perché è stato profuso molto lavoro per adattare le risposte alle aspettative dell'utente. Nella rete, tuttavia, un processo locale a livello utente si interpone tra una console locale e un sottosistema remoto, e possiamo aspettarci che il tempo di risposta per le richieste minori peggiori. Ora può accadere che tutto questo adattamento dell'interazione sia piuttosto indipendente dalla porzione del sottosistema che svolge il calcolo pesante o l'I/O. In tal caso, può essere possibile separare un sottosistema in due sezioni. Una sezione sarebbe un "front end" che formatta l'output per l'utente, accetta il suo input e controlla risposte computazionalmente semplici come gli echi. Nell'esempio precedente, il programma che accumula una riga e genera gli echi sarebbe il front end di un qualche sottosistema. Prendiamo ora atto del fatto che gli host locali hanno una potenza di calcolo sostanziale, ma i nostri progetti attuali utilizzano l'host locale solo come concentratore di dati. Ciò è in qualche modo ironico, poiché l'host locale non solo è poco utilizzato come concentratore di dati, ma degrada anche le prestazioni a causa dei ritardi che introduce.

Questi argomenti ci hanno portato a considerare la possibilità di un Network Interface Language (NIL), che sarebbe un linguaggio valido a livello di rete per scrivere il front end dei sottosistemi interattivi. Questo linguaggio avrebbe la caratteristica che i sottoprogrammi comunicano attraverso connessioni simili a quelle di rete. La strategia consiste allora nel trasportare il codice sorgente del front end di un sottosistema all'host locale, dove verrebbe compilato ed eseguito.

Nel corso di discussioni preliminari abbiamo convenuto che NIL dovrebbe avere almeno le seguenti proprietà semantiche, generalmente assenti in altri linguaggi.

1. Concorrenza. Poiché i messaggi arrivano in modo asincrono su connessioni diverse, e poiché l'input dell'utente non è sincronizzato con l'output del sottosistema, NIL deve includere semantiche per modellare accuratamente le possibili concorrenze.
2. Concatenazione di programmi. È molto utile poter inserire un programma tra due altri programmi. Per ottenere ciò, l'interconnessione dei programmi sarebbe specificata in fase di esecuzione e non sarebbe implicita nel codice sorgente.
3. Sostituibilità dei dispositivi. È usuale definire linguaggi in modo che un dispositivo possa essere sostituito con un altro. Il requisito qui è che qualsiasi dispositivo possa essere modellato da un programma NIL. Per esempio, se un controllore di display standard di rete manipola strutture ad albero in base ai messaggi a esso inviati, allora tali strutture devono essere facilmente implementabili in NIL.

NIL non è stato specificato completamente, e sono state espresse riserve sulla sua utilità. Tali riserve dipendono dalla nostra congettura che sia possibile dividere un sistema interattivo in un front end trasportabile, che soddisfa le aspettative dell'utente a basso costo, e in una sezione più sostanziale che rimane in sede. Se la nostra congettura è falsa, allora NIL non sarà utile; in caso contrario, sembra valga la pena perseguirla. La verifica di questa congettura e l'ulteriore sviluppo di NIL avranno la priorità dopo che il protocollo HOST-HOST di basso livello si sarà stabilizzato.