Protocolli di connessione iniziale
Desideriamo formulare due osservazioni su specifici Protocolli di Connessione Iniziale (IPC). In primo luogo, l'IPC descritto in NEW/RFC #66 -- la sua generalità e una riformulazione di tale ICP. In secondo luogo, una proposta di variante dell'ICP che usa fondamentalmente la stessa logica di NWG/RFC #66.
I. NWG/RFC #66
L'unico errore tecnico in questo IPC è che, come illustrato nel diagramma, sia il server sia l'utente inviano tutti i messaggi prima che le connessioni siano stabilite, il che è incoerente con il Network Document No. 1. Ciò può essere facilmente corretto, come sarà mostrato nella riformulazione che segue.
In termini di generalità, qualsiasi ICP adottato come standard dovrebbe applicarsi a più situazioni di un processo che chiama un Logger. Vale a dire, alcuni processi di servizio di Rete che si collegano direttamente a un processo utente, indipendentemente dall'azione del Logger, potrebbero forse usare un ICP standard. Così, come mostrato di seguito, il campo del nome del processo del socket del server dovrebbe essere un parametro, con il valore zero che costituisce un caso speciale per i Logger.
Riformulazione di NWG/RFC #66 (usando la stessa formulazione dove opportuno)
- Per avviare il contatto, il processo utente collega un socket di ricezione (US) e richiede la connessione al processo SERV socket #1 nell'HOST servente. (SERV = 0 per l'ICP verso il Logger.) Di conseguenza il NCP dell'utente invia:
1 4 3 1 1
+-----+---------------------+---------------+-----+-----+
| RTS | US | SERV | 1 | P |
+-----+---------------------+---------------+-----+-----+
sul collegamento 1, dove P è il collegamento di ricezione.
- Il processo servente (SERV) può decidere di rifiutare la chiamata, nel qual caso chiude la connessione. Se accetta la chiamata, il processo servente completa la connessione (tramite una chiamata di sistema INIT, quindi un STR).
1 3 1 4
+-----+----------------+-----+--------------------+
| STR | SERV | 1 | US |
+-----+----------------+-----+--------------------+
- Quando la connessione è completata, il processo utente assegna alla connessione una quantità nominale di spazio, facendo sì che il NCP invii:
1 1 4
+-----+-----+--------------------+
| ALL | P | SPACE |
+-----+-----+--------------------+
dove SPACE è la quantità.
-
Il processo servente seleziona quindi la coppia di socket che desidera assegnare a questo utente. Invia sulla connessione esattamente un numero pari di 32 bit. Questo numero pari di 32 bit (SS) è il socket di ricezione nell'HOST servente. Questo socket e il socket immediatamente superiore sono riservati al processo utente.
-
Poi chiude la connessione. Il NCP servente invia (passo 4):
4
+---------------------+
| SS |
+---------------------+
sul collegamento P, e (passo 5):
1 3 1 4
+-----+----------------+-----+--------------------+
| CLS | SERV | 1 | US |
+-----+----------------+-----+--------------------+
sul collegamento di controllo (che viene ripetuto dal NCP dell'utente).
- Ora che sia il server sia l'utente sono a conoscenza della coppia di socket remoti per la connessione duplex, è possibile scambiare più <STR, RTS>.
Il server invia all'utente
1 4 4
+-----+--------------------+--------------------+
| STR | SS + 1 | US |
+-----+--------------------+--------------------+---+
| RTS | SS | SS + 1 | Q |
+-----+--------------------+--------------------+---+
dove Q è il collegamento di ricezione del server.
L'utente invia al server
1 4 4
+-----+--------------------+--------------------+
| STR | US + 1 | SS |
+-----+--------------------+--------------------+---+
| RTS | US | SS + 1 | R |
+-----+--------------------+--------------------+---+
dove R è il collegamento di ricezione dell'utente.
Si possono quindi inviare ALLocates e iniziare la trasmissione.
II. Una variante di NWG/RFC #66
Questa variante riduce i messaggi di Rete ed elimina la duplicazione del trasferimento di informazioni.
I passi 3 e 4 precedenti vengono eliminati. Al processo utente non viene notificato direttamente quale dei socket del server gli sarà assegnato. Il processo utente, tuttavia, ascolterà sui socket US e US + 1 le chiamate provenienti da SERV dopo il passo 5 precedente. Può rifiutare eventuali chiamate spurie. Accettando le chiamate da SERV, la connessione viene stabilita.
La seguente sequenza di esempio illustra questo ICP. (La notazione è come sopra).
- Utente --> Server
1 4 3 1 1
+-----+--------------------+----------------+-----+-----+
| RTS | US | SERV | 1 | P |
+-----+--------------------+----------------+-----+-----+
- Server --> Utente
Se accettata:
1 3 1 4
+-----+----------------+-----+---------------------+
| STR | SERV | 1 | US |
+-----+----------------+-----+---------------------+
| CLS | SERV | 1 | US |
+-----+----------------+-----+---------------------+
Se rifiutata:
1 3 1 4
+-----+----------------+-----+---------------------+
| CLS | SERV | 1 | US |
+-----+----------------+-----+---------------------+
-
Se accettata, l'utente ascolta su US e US + 1.
-
Server --> Utente
1 4 4
+-----+--------------------+---------------------+
| STR | SS + 1 | US |
+-----+--------------------+---------------------+---+
| RTS | SS | US + 1 | Q |
+-----+--------------------+---------------------+---+
- L'utente accetta le chiamate, quindi:
Utente --> Sender
1 4 4
+-----+---------------------+--------------------+
| STR | US + 1 | SS + 1 |
+-----+---------------------+--------------------+---+
| RTS | US + 1 | SS | R |
+-----+---------------------+--------------------+---+
e la connessione viene stabilita.
Questo riduce di due il numero di messaggi di Rete e trasmette le informazioni relative ai socket del server una sola volta, tramite RTS e STR.