Passa al contenuto principale

IV - Protocollo di controllo e comunicazione utente

Deve esistere un processo che accetti di ascoltare chiunque nella rete e di creare un processo per lui dietro adeguata identificazione. Questo processo è chiamato logger e interagisce attraverso l'NCP tramite il modulo di controllo e comunicazione utente (UCC) relativo alla rete, che implementa il protocollo necessario. A parte un solo caso (la chiusura (CLOSE) delle connessioni di processi morti), il processo che gestisce il modulo UCC non ha privilegi di rete speciali.

Nel quadro del protocollo UCC, un processo "richiedente" che ha indirizzato la creazione di un processo "remoto" mantiene due connessioni pseudo-telescriventi full-duplex: una verso il logger remoto e una verso il processo creato. La connessione duplex verso il logger remoto serve a identificare il processo richiedente presso il logger e, dopo l'accesso, a restituire al processo richiedente informazioni di base sullo stato di salute del processo creato. La connessione duplex verso il processo creato serve alla comunicazione di controllo con esso.

Mantenere due connessioni full-duplex evita problemi di riconnessione sia quando il logger trasferisce la comunicazione al processo creato, sia quando deve riprendere il controllo. Ciò avviene al modico prezzo di richiedere al processo richiedente di commutare le comunicazioni telescriventi tra due insiemi di connessioni.

Il modo in cui la comunicazione viene stabilita è essenzialmente il seguente: il processo richiedente riserva dapprima quattro dei propri socket con codici di socket contigui. Poi "segnala" all'UCC, specificando uno di questi socket. Dal "segnale" l'UCC sa quale processo sta chiamando e, per protocollo, su quale coppia di socket del richiedente l'UCC deve comunicare con il processo richiedente, e quale coppia di socket del richiedente il processo creato deve usare per le proprie comunicazioni. Ciò è specificato più in dettaglio qui di seguito.

Stabilire e gestire un processo remoto​

L'UCC di ogni HOST tiene sempre aperto (attivo e non connesso) un socket di invio con numero utente = 0 e instance tag = 0 come socket "signal", e verifica periodicamente la presenza di INIT verso questo socket. I processi che desiderano creare un processo su questo HOST devono prima segnalare all'UCC emettendo un INIT verso questo socket.

Il processo richiedente deve avere quattro socket liberi con codici di socket contigui: da <base_socket> (ricezione) fino a <base_socket+3> (invio). L'insieme di socket di invio/ricezione con numeri alti è usato per la comunicazione telescrivente con l'UCC remoto, quello con numeri bassi per la comunicazione telescrivente con il processo creato.

  1. Il processo "richiedente" chiama due volte LISTEN per aprire la coppia ricezione/invio <base_socket+2> e <base_socket+3>, attraverso la quale parlerà con l'UCC remoto. Poi emette una chiamata INIT "di segnalazione" su <base_socket> verso il socket "signal" dell'UCC. L'unica cosa che l'UCC fa con questa chiamata INIT "di segnalazione" è annotare il numero di socket <base_socket> da cui essa è partita. L'UCC rifiuta immediatamente questa richiesta, in modo da mantenere aperto il proprio socket "signal" per altri segnali.

  2. Dopo aver ricevuto il REJECT atteso sulla sua chiamata INIT iniziale verso il socket di segnalazione dell'UCC, il processo richiedente emette LISTEN per <base_socket> e <base_socket+1>. (Il processo creato eseguirà INIT su questi socket per stabilire la comunicazione di controllo con il processo richiedente.) Il processo richiedente si blocca poi chiamando STATUS <base_socket+2> .

  3. L'UCC esegue INIT di una coppia di socket di invio/ricezione libera verso <base_socket+2> e <base_socket+3> del richiedente, sui quali il processo richiedente presumibilmente è in ascolto. Il processo richiedente ha chiamato STATUS <base_socket+2> con l'opzione di blocco dopo aver ascoltato i due socket, così quando l'INIT dall'UCC remoto raggiunge il processo richiedente, STATUS ritorna con l'indicazione di INIT. Il processo richiedente verifica che sia l'UCC il processo che chiama, poi esegue ACCEPT della chiamata. Il processo richiedente chiama poi STATUS <base_socket+3> e ritorna quando l'INIT per quel socket lo raggiunge. Esegue una verifica e un ACCEPT analoghi. (La scelta di quale socket il processo richiedente interroghi per primo con STATUS è arbitraria.) La comunicazione bidirezionale è stabilita quando il processo richiedente ha accettato (ACCEPT) entrambi gli INIT dell'UCC. Questa connessione è mantenuta durante il rituale di accesso e per tutta la vita del processo creato. Se il processo richiedente non risponde adeguatamente entro un tempo limitato agli INIT dell'UCC, l'UCC abbandona il tentativo di connessione.

  4. Il processo richiedente deve poi eseguire il rituale di accesso con l'UCC. (Il protocollo iniziale potrebbe standardizzare il rituale di accesso.) Se il logger non è soddisfatto e desidera tagliare fuori il richiedente, il modulo UCC esegue CLOSE su <base_socket+2> e <base_socket+3>, magari dopo che il logger ha inviato un messaggio adeguato.

  5. Se è soddisfatto, il logger crea un processo per l'utente. L'UCC mantiene la comunicazione diretta con il richiedente, ma questa connessione è ora usata solo per riportare informazioni di base sul processo creato.

  6. Il primo compito di un processo creato è stabilire una doppia connessione di controllo pseudo-telescrivente con il proprio processo richiedente. Il processo creato esegue INIT di una delle proprie coppie di socket di invio/ricezione verso <base_socket> e <base_socket+1> del richiedente. Se entrambe le richieste sono accettate (ACCEPT), il processo creato invia un messaggio iniziale su questa connessione. Poi passa al livello di comando, dove attende un messaggio di comando telescrivente sulla connessione. Se il processo creato non riesce a stabilire una comunicazione duplex con il processo richiedente, dovrebbe distruggere se stesso. L'UCC eseguirà CLOSE sulle proprie connessioni con il richiedente oppure prenderà provvedimenti perché venga creato un altro processo.

  7. Quando un processo creato viene disconnesso, l'UCC usa un ingresso privilegiato verso l'NCP per eseguire CLOSE su tutte le connessioni tra il processo morto e gli altri processi, e per disattivare tutti i socket aperti del processo morto. L'UCC trasmette un messaggio di ritorno al processo richiedente, poi esegue CLOSE sulle due connessioni tra esso e il processo richiedente.

  8. La chiamata INTERRUPT ha un significato standard di "quit" quando è inviata da un processo richiedente a un processo creato attraverso il socket di ricezione <base_socket> del richiedente. Tutto l'output in attesa dal processo creato viene annullato, ed esso entra nel "livello di comando", dove attende un comando sulla connessione telescrivente verso il processo richiedente. L'elaborazione interrotta può essere ripresa emettendo un comando "start" verso il processo creato. (Si noti che la regola sull'output in attesa è più restrittiva di quella implementata dal comando INT dell'NCP.)

Questo documento è stato preparato mediante il comando "runoff" di MULTICS. Un file sorgente composto da testo e richieste "runoff" frammisti è stato creato con l'editor di testo "qed". Questo file è stato poi compilato dal comando "runoff" per produrre una copia definitiva. La versione più recente di questo documento esiste in linea in MULTICS nel segmento

>udd>Multics>Meyer>network_protocol.runoff

(END)

      REQUESTOR                                  FOREIGN
      PROCESS                                    LOGGER
      --------------                             -------------
      a. LISTEN to sockets
      <base_socket+2> and
      <base_socket+3> to be
      connected to foreign logger.

      b. INIT <base_socket>
      to "signal" socket of
      foreign logger.
                =======================================>

                                                c. remember <base_socket>
                                                   and REJECT connection
                                                   to signal socket.

      d. LISTEN to sockets                      e. INIT a logger socket
      <base_socket> and                            pair to the requestor's
      <base_socket_1> to be                       <base_socket+2> and
      connected to the created  process.          <base_socket+3>.
                                                   /
                       <==========================/

      f. ACCEPT connection
      with sockets from
      foreign logger.

                             PERFORM LOGIN RITUAL
                                                CREATED
                                                PROCESS
                                                -------------
                                                g. INIT any socket pair
                                                   to requestor's
                                                   <base_socket> and
                                                   <base_socket+1>
                                                    /
                       <===========================/
      h. ACCEPT connection
      with sockets from created
      process.

Figura 4: Stabilire un processo su un HOST remoto

Nota: Questo RFC è stato reso in forma leggibile dalla macchina per l'inserimento negli archivi RFC in linea da Miles McCredie 11/99.