Passa al contenuto principale

RFC 1 - Software host (Host Software)

Network Working Group: Steve Crocker
Request for Comments: 1
Istituzione: UCLA
Data: 7 aprile 1969

Sommario​

Questo documento è il primo RFC nella storia dell'ARPANET, che discute le considerazioni di progettazione per il software host. Il documento copre una panoramica del software IMP (Interface Message Processor, processore di messaggi di interfaccia), i requisiti per il software host-to-host, i meccanismi di stabilimento della connessione e i piani di esperimenti preliminari. Questo documento segna l'inizio della tradizione di documentazione dei protocolli Internet.

CONTENUTI (CONTENTS)​

INTRODUZIONE (INTRODUCTION)​

Il software per la rete ARPA esiste in parte negli IMP e in parte nei rispettivi host (HOSTs). BB&N ha specificato il software degli IMP ed è responsabilità dei gruppi host concordare sul software host.

Durante l'estate del 1968, i rappresentanti dei quattro siti iniziali si sono incontrati più volte per discutere il software host e gli esperimenti iniziali sulla rete. Da questi incontri è emerso un gruppo di lavoro di tre persone: Steve Carr dallo Utah, Jeff Rulifson da SRI e Steve Crocker da UCLA, che si sono incontrati durante l'autunno e l'inverno. L'incontro più recente si è tenuto nell'ultima settimana di marzo nello Utah. Era presente anche Bill Duvall di SRI, che ha recentemente iniziato a lavorare con Jeff Rulifson.

In modo alquanto indipendente, Gerard DeLoche di UCLA ha lavorato sull'interfaccia host-IMP.

Presento qui alcuni degli accordi provvisori raggiunti e alcune delle questioni aperte incontrate. Molto poco di ciò che è qui è definitivo e si attendono reazioni.

I. Un riepilogo del software IMP (A Summary of the IMP Software)​

Messaggi (Messages)​

Le informazioni vengono trasmesse da host a host in pacchetti chiamati messaggi (messages). Un messaggio è qualsiasi flusso di non più di 8080 bit, insieme alla sua intestazione. L'intestazione è di 16 bit e contiene le seguenti informazioni:

Destinazione (Destination)     5 bit
Collegamento (Link)            8 bit
Traccia (Trace)                1 bit
Riserva (Spare)                2 bit

La destinazione è il codice numerico per l'host a cui il messaggio deve essere inviato. Il bit di traccia segnala agli IMP di registrare informazioni di stato sul messaggio e inviare le informazioni al NMC (Network Measurement Center, centro di misurazione della rete, cioè UCLA). I bit di riserva non sono utilizzati.

Il campo di collegamento è un dispositivo speciale utilizzato dagli IMP per limitare determinati tipi di congestione. Funzionano come segue. Tra ogni coppia di host ci sono 32 connessioni logiche full-duplex (logical full-duplex connections) su cui i messaggi possono essere trasmessi in entrambe le direzioni. Gli IMP pongono la restrizione su questi collegamenti che nessun host può inviare due messaggi successivi sullo stesso collegamento prima che l'IMP di destinazione abbia inviato un messaggio speciale chiamato RFNM (Request for Next Message, richiesta del messaggio successivo). Questa disposizione limita la congestione che un host può causare a un altro se l'host mittente sta tentando di inviare troppo su un collegamento. Notiamo, tuttavia, che poiché l'IMP di destinazione non ha capacità sufficiente per gestire tutti i 32 collegamenti simultaneamente, i collegamenti servono il loro scopo solo se il sovraccarico proviene da uno o due collegamenti. È necessario che gli host cooperino in questo senso.

I collegamenti hanno le seguenti caratteristiche primitive. Sono sempre funzionanti e ce ne sono sempre 32.

Per "sempre funzionanti" intendiamo che gli IMP sono sempre pronti a trasmettere un altro messaggio su di essi. Nessuna nozione di inizio o fine di una conversazione è contenuta nel software IMP. Quindi non è possibile interrogare un IMP sullo stato di un collegamento (sebbene possa essere possibile interrogare un IMP sulla cronologia recente di un collegamento -- una questione completamente diversa!).

L'altra caratteristica primitiva dei collegamenti è che ce ne sono sempre 32, indipendentemente dal fatto che siano utilizzati o meno. Ciò significa che ogni IMP deve mantenere 18 tabelle, ciascuna con 32 voci, indipendentemente dal traffico effettivo.

Nonostante le obiezioni alla struttura dei collegamenti, i collegamenti sono facilmente programmabili all'interno degli IMP e sono probabilmente un'alternativa migliore a disposizioni più complesse proprio a causa della loro semplicità.

Trasmissione IMP e controllo errori (IMP Transmission and Error Checking)​

Dopo aver ricevuto un messaggio da un host, un IMP partiziona il messaggio in uno o più pacchetti (packets). I pacchetti non sono lunghi più di 1010 bit e sono l'unità di trasmissione dati da IMP a IMP. Un checksum ciclico (cyclic checksum) a 24 bit viene calcolato dall'hardware di trasmissione e viene aggiunto a un pacchetto in uscita. Il checksum viene ricalcolato dall'hardware di ricezione e viene controllato rispetto al checksum trasmesso. I pacchetti vengono riassemblati in messaggi all'IMP di destinazione.

Questioni aperte sul software IMP (Open Questions on the IMP Software)​

  1. Viene fornito un campo a 8 bit per la specifica del collegamento, ma vengono forniti solo 32 collegamenti, perché?

  2. L'host dovrebbe essere in grado di inviare messaggi al suo IMP. Come lo fa?

  3. Un host, in contrapposizione al suo IMP, può controllare gli RFNM?

  4. Gli IMP eseguiranno la conversione del codice? Come verrà controllata?

II. Alcuni requisiti per il software host-to-host (Some Requirements Upon the Host-to-Host Software)​

Uso semplice (Simple Use)​

Come con qualsiasi nuova struttura, ci sarà un periodo di utilizzo molto leggero fino a quando la comunità degli utenti sperimenterà la rete e inizierà a dipenderne. Uno dei nostri obiettivi deve essere quello di stimolare l'uso immediato e facile da parte di un'ampia classe di utenti. Con questo obiettivo, sembra naturale fornire la capacità di utilizzare qualsiasi host remoto come se fosse stato composto da un terminale TTY (teletype, telescrivente). Inoltre, vorremmo avere una certa capacità di trasmettere un file in modo in qualche modo diverso dalla simulazione di una telescrivente.

Uso approfondito (Deep Use)​

Uno dei problemi intrinseci nella rete è il fatto che tutte le risposte da un host remoto richiederanno dell'ordine di mezzo secondo circa, non importa quanto semplici. Per l'uso della telescrivente, potremmo passare a un'organizzazione di eco locale semi-duplex, ma questo distruggerebbe parte dell'utilità della rete. I sistemi 940, ad esempio, hanno un eco molto specializzato.

Quando consideriamo l'uso di stazioni grafiche o altri terminali sofisticati sotto il controllo di un host remoto, il problema diventa più grave. Dobbiamo cercare un metodo che ci permetta di utilizzare la nostra attrezzatura più sofisticata il più possibile come se fossimo collegati direttamente al computer remoto.

Controllo degli errori (Error Checking)​

Jeff Rulifson di SRI sottolinea che il controllo degli errori alle principali interfacce software è sempre una buona cosa. Sottolinea alcune esperienze presso SRI dove ha risparmiato molte dispute e sforzi sprecati. Su queste basi, vorremmo vedere un controllo da host a host. Oltre a controllare l'interfaccia software, controllerebbe anche l'hardware di trasmissione host-IMP. (BB&N afferma che l'hardware host-IMP sarà affidabile quanto i registri interni dell'host. Crediamo loro, ma vogliamo comunque il controllo degli errori.)

III. Il software host (The Host Software)​

Stabilimento di una connessione (Establishment of a Connection)​

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 (High Volume Transmission)​

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 (A Summary of Primitives)​

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 (Closer Interaction)​

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.

         /                                                      \
        |     +-----------+                    +-----------+    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     | terminal  |                    | terminal  |    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     +-----+-----+                    +-----+-----+    |
        |           |                                |          |
        |           |                                |          |
        |           |                                |          |
        |     +-----+-----+                    +-----------+    |
        |     |     |     | Request connection |     |     |    |
   UCLA {     |     |     | -> over link 25    |     |     |    } SRI
        |     |   +-+-+   |  +-+          +-+  |   +-+-+   |    |
        |     |   | OS|---+-=|I|----------|I|=-+---| OS|   |    |
        |     |   +-+-+   |  +-+          +-+  |   +---+   |    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     +-----------+                    +-----------+    |
        |      HOST: UCLA                        HOST: SRI      |
         \                                                     /
         /                                                      \
        |     +-----------+                    +-----------+    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     | 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 (After Receipt and Compilation of the DEL program)​

         /                                                     \
        |     +-----------+                    +-----------+    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     | terminal  |                    | terminal  |    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     +-----+-----+                    +-----+-----+    |
        |           |Trivial                         |          |
        |           |Responses                       |          |
        |           |                                |          |
        |     +-----+------+                    +-----------+   |
        |     |     |      |                    |     |     |   |
   UCLA {     |     |      |  Major Responses   |     |     |   } SRI ___
        |     |  +--+--+   |  +-+          +-+  |  +--+---+ |   |    /   |
        |     |  |DEL  |---+-=|I|----------|I|=-+--|OS|NLS| +---+---|    |
        |     |  |front|   |  +-+          +-+  |  +------+ |   |   |___/
        |     |  | end |   |                    |           |   |   |    |
        |     |  |prog.|   |                    |           |   |   |____|
        |     |  +-----+   |                    |           |   |
        |     |  | OS  |   |                    |           |   |
        |     |  +-----+   |                    |           |   |
        |     |            |                    |           |   |
        |     +------------+                    +-----------+   |
        |      HOST: UCLA                         HOST: SRI     |
         \                                                     /

Questioni aperte (Open Questions)​

  1. Se gli IMP eseguono la conversione del codice, il checksum non sarà corretto.

  2. La procedura per richiedere il front-end DEL non è ancora specificata.

IV. Esperimenti iniziali (Initial Experiments)​

Esperimento uno (Experiment One)​

SRI sta attualmente modificando il suo sistema di recupero online che sarà il principale componente software del centro di documentazione di rete in modo che possa essere operato con telescriventi modello 35. Il controllo delle telescriventi sarà scritto in DEL. Tutti i siti scriveranno compilatori DEL e utilizzeranno NLS attraverso il programma DEL.

Esperimento due (Experiment Two)​

SRI scriverà un front-end DEL per NLS completo, inclusa la grafica. UCLA e UTAH utilizzeranno NLS con grafica.

Nota: Questo RFC è stato convertito in formato leggibile da macchina per l'inserimento negli archivi RFC online da Celeste Anderson nel marzo 1997.

Risorse correlate​

  • Testo ufficiale: https://www.rfc-editor.org/rfc/rfc1.txt
  • Pagina ufficiale: https://datatracker.ietf.org/doc/html/rfc1

Significato storico​

RFC 1 è il primo documento RFC nella storia di Internet, segnando l'inizio della tradizione di documentazione dei protocolli ARPANET e Internet moderni. Scritto dal giovane studente laureato Steve Crocker, ha umilmente definito questi documenti "Request for Comments" (Richiesta di commenti), un nome che persiste ancora oggi. Questo documento incarna lo spirito di collaborazione e l'atteggiamento aperto dei pionieri di Internet.

Ultimo aggiornamento il