Descrizione generale

Nella nostra visione del mondo, ogni host dispone di un insieme di quattro programmi che consentono a un telescrivente utente di comunicare con un monitor estraneo. L'implementazione esatta di questi programmi dipende fortemente dall'installazione. Pertanto, tutte le spiegazioni intendono descrivere caratteristiche funzionali piuttosto che la progettazione.

Questi quattro programmi si presentano in due coppie « maschio/femmina ». Un utente impiega un logger di invio sul proprio sito per comunicare con il logger di ricezione del sito estraneo appropriato, allo scopo di stabilire un collegamento duplex integrale tra il telescrivente dell'utente e il monitor della macchina estranea. Ciò lo pone in uno stato equivalente a quello di una sessione già aperta sull'altra macchina. Una volta stabilito il collegamento, i due logger escono di scena e l'utente conversa con un mittente della propria macchina, la cui funzione principale è prendere l'input dal telescrivente dell'utente e inviarlo sul collegamento stabilito dai logger verso il destinatario dell'host estraneo, che lo inoltra al proprio monitor (facendolo apparire come input proveniente da un telescrivente locale). Le risposte del monitor estraneo vengono da questo consegnate al destinatario, che le ritrasmette sul collegamento verso il mittente, il quale le visualizza sul telescrivente dell'utente. Il mittente e il destinatario di ciascuna macchina devono esistere in più copie, una per ogni utente della rete, oppure deve essercene una sola copia in grado di servire tutti gli utenti della rete. I logger, invece, devono poter servire un solo utente alla volta, poiché il loro compito si esaurisce rapidamente, lasciandoli liberi di soddisfare altre richieste. Dovrebbe comunque esistere un metodo per accodare le richieste che non possono essere soddisfatte immediatamente. Un'alternativa meno soddisfacente sarebbe restituire un messaggio di occupato a ogni utente che tenta di usare il logger mentre è occupato. (Ciò naturalmente non esclude la possibilità che un'installazione disponga di un logger rientrante o di più copie del logger.)

Il logger di ricezione dovrebbe essere l'utente zero in ogni macchina e dovrebbe sempre ascoltare il socket zero. (La stessa cosa può essere ottenuta facendo intercettare al NCP tutti i messaggi destinati all'utente zero, socket zero, e inviarli al logger di ricezione; ma è più semplice e più pulito che il logger sia effettivamente l'utente zero e che il NCP tratti i suoi messaggi come quelli di chiunque altro.)

Quando viene chiamato il logger di invio, questo preleva una coppia di socket inutilizzati (2N e 2N+1) da un pool di socket liberi ed esegue un CONNECT da 2N+1 verso l'utente 0, socket 0 dell'host estraneo desiderato. Ciò attiva il logger di ricezione, che accetta la connessione se dispone di uno slot per il telescrivente estraneo. Subito dopo chiude questa connessione per consentire l'avvio di collegamenti da altre sorgenti. Se invece non c'è spazio per il telescrivente estraneo (o se, per qualche altro motivo, il logger di ricezione non desidera connettersi), il tentativo di collegamento al socket zero viene rifiutato. Questo segnala al logger di invio che non può effettuare l'accesso all'host estraneo, ed esso ne informa l'utente. Non vi è però alcuna garanzia che la chiusura sia stata effettivamente inviata dal logger estraneo. Avrebbe potuto inviarla il NCP se, per esempio, la coda delle chiamate in sospeso per quel socket fosse sovraccarica.

Se il collegamento al socket zero è stato accettato (indicando così che il logger di ricezione può soddisfare la richiesta), dopo aver chiuso quel collegamento il logger di ricezione sceglie una coppia di socket disponibili (2M e 2M+1) dal proprio pool e si connette da 2M+1 verso 2N. (Ha scoperto l'identità di 2N quando il suo ascolto è stato soddisfatto dal collegamento con 2N+1.) Nel frattempo il logger di invio ha ascoltato il socket 2N e ora accetta il collegamento, quindi esegue un CONNECT da 2N+1 verso 2M. Il logger di ricezione era in ascolto su questo socket e accetta il tentativo di collegamento.

A questo punto esiste una connessione duplex integrale tra i due logger. Essi attivano quindi il mittente e il destinatario, che gestiscono ogni altra comunicazione tra l'utente e il monitor estraneo. (I mittenti e i destinatari possono far parte dei logger, oppure essere da essi chiamati, ecc.)

Quando l'utente ha terminato e torna al proprio monitor, spetta al mittente chiudere i collegamenti. Sul lato ricevente sarebbe altamente desiderabile che il NCP informasse il destinatario di questo fatto, così da poter disconnettere l'utente (se non lo ha già fatto lui stesso) e liberare le risorse che stava utilizzando.

Di seguito è riportato uno schema più formale del protocollo proposto, descritto nello scenario precedente:

Stato stabile: il logger di ricezione sull'host estraneo è in ascolto sull'utente 0, socket 0.
L'utente locale chiama il logger di invio.
Il logger di invio chiama CONNECT (port, 2N+1, <foreign host#,0,0>).
Il logger di invio chiama LISTEN (port, <local host#, user#, 2N>).
Il LISTEN del logger estraneo riceve risposta e gli vengono comunicati il numero di utente locale, l'host e #2N+1.
Il logger estraneo cerca socket disponibili (2M e 2M+1). Se esistono ed è in grado di stabilire la connessione, l'accetta e chiude subito il collegamento.
Il logger estraneo chiama CONNECT (port, 2M+1, <local host#, user#, 2N>).
Il logger estraneo chiama LISTEN (port, <local host#, user#, 2M>).
Il logger di invio ha ascoltato 2N e accetta il collegamento, quindi chiama CONNECT (port, 2N+1, <foreign host#, user#,2M>).
Il logger di ricezione, in ascolto su 2M, accetta il collegamento.
I logger attivano i gestori appropriati.
Quando l'utente ha terminato, il mittente chiude entrambi i collegamenti.

Questo metodo di base per stabilire una connessione duplex integrale dovrebbe essere standard in tutta la rete. Il modo in cui ciascuna installazione gestisce l'implementazione del mittente, del destinatario e dei due logger è irrilevante per la rete e dipende fortemente dalla macchina. (Persino la necessità di un mittente e di un destinatario dipende dalla macchina, poiché alcuni membri della rete potrebbero svolgere le loro funzioni in altro modo.) Tuttavia, è necessario stabilire alcune convenzioni riguardo alla comunicazione tra mittente e destinatario, o i loro equivalenti.