Introduzione
Il seguente riassunto è stato trascritto dagli appunti che ho preso a tre riunioni di rete tenutesi a Houston durante la Fall Joint Computer Conference del 1970. Per quanto abbia cercato di essere obiettivo, inevitabilmente questi appunti presentano una visione parziale delle riunioni. Ciò è dovuto in parte alla mia attenzione per certi argomenti e a possibili fraintendimenti di varie discussioni. Pur avendo cercato di parafrasare accuratamente le affermazioni dei partecipanti, il senso di alcune può essere stato distorto.
Partecipanti alla riunione di lunedì
Dick Benjamin MITRE
Jack Bouknight UI-CAC
Al Cocanower MIRUT
Steve Crocker UCLA
Dough Engelbart SRI
Richard Greenblatt MIT-MAC
Eric Harslem RAND
Frank Heart BBN
Allen Joseph ORNL (Oak Ridge)
Peggy Karp MITRE
William B. Kehl UCLA
Bob Long SDC
Jim Madden UI-CAC
Bob Metcalfe MIT-MAC
Edwin Meyer MIT-MAC
Ari Ollikainen UCLA
Tom O'Sullivan Raytheon
Jon Postel UCLA
Chris Reeve MIT-MAC
Tjaart Schipper UCAL-CCN
Michael S. Sher UI-CAC
Bob Sundberg Harvard
Hal van Zoeren CMU
Albert Vezza MIT-MAC
Alfred H. Vorhaus MITRE
Clark Weissman SDC
Riunione di rete
Lunedì 16 novembre 1970, ore 20:05
Crocker: Non ci sono ancora tutti, quindi parliamo finché non arriva più gente. tutti soddisfatti dell'ordine del giorno nel mio annuncio?
Meyer: Dovremmo parlare del logger protocol. L'uso operativo della rete, in contrapposizione agli esperimenti, dipende dalla sua implementazione.
Ci si presenta a vicenda.
Crocker: Ho un ordine del giorno, ma voglio suggerimenti sugli argomenti.
- Farò alcune osservazioni introduttive.
- Elencherò gli argomenti di interesse.
- Englebart parlerà del Network Information Center
- Esaminerò lo stato dei siti.
Osservazioni introduttive
- ARPA non pagherà il caffè e i dolci serviti, quindi contribuite anche voi per aiutarmi a pagarli.
- Dedicherò a tempo pieno, in veste ufficiale, al coordinamento della rete. I miei obiettivi sono: (a) accrescere l'usabilità della rete. (b) stabilire i livelli di protocollo, (c) ?
Aree di importanza
- Qualche sito o coalizione di siti dovrebbe preparare un metodo con cui collaudare l'NCP di un sito.
- Revisione del protocollo NCP. Alcune questioni potrebbero essere risolte meglio: (a) controllo degli errori, (b) controllo di flusso, (c) sovraccarico - perdita degli stati di rete, (d) semplificazione e riorganizzazione a strati del protocollo.
- Interazione con la console del sistema Telnet, o logger protocol. Come entrare nel sistema e come ottenere aiuto quando si è in difficoltà.
- Documentazione dei singoli host. Coinvolto il Network Info Center. Forse ogni sito potrebbe essere dotato di un dispositivo facsimile.
- Console più sofisticate, in particolare console grafiche, da collegare tramite la rete. Dovrebbe esserci un gruppo di lavoro per formulare e mettere a punto un formato per gestire console sofisticate. Ci sarà una riunione sulla grafica a gennaio in Colorado o nello Utah. Il prezzo d'ingresso è scrivere una proposta. Prevedo fino a 30 persone. Sceglierò un piccolo sottoinsieme per sviluppare le specifiche.
- Contabilità - Nella 2a metà del 1971 entreranno in funzione più siti in cui la contabilità è importante. (Vogliono inviare fatture.) Larry Roberts dice che ci sarà una specie di sistema bancario con fatture che circolano. Due tipi di siti: siti che fatturano, e siti di ricerca gratuiti ma ad accesso limitato. Non vedo problemi fondamentali. Cosa succede quando un sito di ricerca parla con un sito che fattura? Penso che sia fattibile.
- Misurazioni - la rete è uno strumento, ma è anche un modello migliore di un pacchetto di simulazione. Varie persone vogliono fare misurazioni. Questo potrebbe essere supportato tenendo statistiche negli NCP. E se si ampliassero gli NCP per includerle?
Long: Mettere la contabilità e le misurazioni negli NCP costa spazio. Mantenere le aggiunte al minimo.
Weissman: E la disponibilità programmata dei vari sistemi?
Crocker: Questo va coordinato con ogni singolo sistema
? : Cosa succede alle connessioni quando un sistema va giù?
Crocker: E le proposte sulla grafica? Scriverò un mio documento come proposta. Usa il DEC 340 come modello. Modes presuppone un sistema scope con memoria. Sia l'output sia l'input sono inclusi nella definizione degli standard. Voglio che dal gruppo di lavoro venga sviluppato un protocollo competente.
Crocker: E la documentazione?
Meyer: La documentazione su come usare gli altri sistemi è indispensabile. Solo questo può motivare l'uso operativo della rete.
--: E mettere i documenti on-line in ogni sito, o almeno gli abstract?
Crocker: Quali siti hanno documenti on-line? (MIT e Harvard) Cosa pensano i siti di tenere i documenti su qualche sistema esterno?
Crocker: E la revisione del protocollo?
Harslem: Ci siamo collegati al sistema UCSB e stiamo facendo debug in modo cooperativo.
Harslem: Siamo rimasti favorevolmente colpiti dall'eliminazione del marking e del padding (secondo l'RFC 67).
Crocker: Ne abbiamo discusso con i siti. La maggior parte sembrava accettarlo, ma con alcune riserve. E le modifiche al protocollo di base. Io Meyer ha qualcosa da dire.
Meyer: La posizione al Project MAC è che a questo punto siamo contrari a modifiche diverse dalle correzioni critiche. Il tempo speso in modifiche è tempo che non sarà speso a sviluppare altri protocolli e sistemi necessari e interessanti. E noi a Multics abbiamo tempi lunghi per la creazione e l'installazione delle modifiche.
Weissman: Preferisco inserire le modifiche in un unico blocco, diciamo a intervalli di 6 mesi. piuttosto che a pezzettini.
O'Sullivan: I sistemi attuali e quelli nuovi non possono funzionare contemporaneamente?
Crocker: Se le modifiche coinvolgono l'IMP, no, perché tutti gli IMP vogliono far funzionare lo stesso sistema.
Meyer: Al M.I.T. si ritiene che, per avere successo, la rete abbia disperatamente bisogno di essere usata operativamente. Se passa un altro anno senza un uso operativo significativo, potrebbe andare a rotoli.
--: E la documentazione è cruciale per motivare l'uso operativo.
Engelbart: Forse dovremmo rimandare la grafica di qualche mese per non ritardare le telescriventi. Le telescriventi sono importanti.
--: Ma sarebbe abbastanza impressionante per la gente del DOD?
Engelbart: Ma se fra due anni si rivela un vespaio...
--: Ma i due gruppi di sviluppo (telescriventi e grafica) interagiscono?
Vezza e Engelbart: Sì.
Crocker: Sentiamo di più su questo.
Harslem: Vogliamo poter accedere ai file.
Crocker: Allora forse lo sforzo sulla grafica diluirebbe lo sviluppo delle telescriventi. È consenso di questo gruppo che non dovremmo fare una riunione sulla grafica?
Vezza: I nuovi arrivati dovrebbero lavorare sulla grafica, non le persone già affermate. Vietare alle persone attuali di andare a questa riunione.
Meyer: Sarebbe molto frustrante.
Benjamin: Perché non sollecitare documenti di posizione (ma non fare riunioni).
Weissman: La trasmissione di caratteri è più facile della trasmissione grafica. Servono più esperimenti per la grafica. I tempi di sviluppo di un protocollo grafico sono molto più lunghi di quelli per le telescriventi.
Vezza: Sono d'accordo.
Crocker: Ci saranno altre riunioni nei prossimi giorni per lavorare sui problemi di come ottenere lavoro utile attraverso la rete.
Intervallo
21:15
Crocker: Engelbart parlerà del Network Information Center.
Engelbart: Il NIC è cresciuto come una cosa ad hoc, senza direttive specifiche da parte di ARPA. Che tipo di cose erano state immaginate? (1) Sistemi di interrogazione sofisticati, (2) Informazioni di base sui sistemi di ogni sito. Ognuno si sente molto vulnerabile riguardo allo stato della documentazione nel proprio sito. Tutti concordano: documenti migliori sono necessari. Ci vediamo come fornitori dei seguenti servizi: 1) raccolta di materiale cartaceo; 2) interrogazione on-line di cataloghi e indici di questi; 3) dare accesso a questo materiale. Abbiamo deciso di andare sul cartaceo invece che sull'on-line, forse su microfiche.
Engelbart: Il 940 doveva essere usato per il sistema di documentazione, ampliabile con l'aumentare dell'uso. Stiamo passando da un 940 a un 10X per ampliare meglio la capacità di servizio. La quantità di capacità aumenta considerevolmente. Questo ha bloccato il lavoro su altri aspetti. Un azzardo consapevole. Siamo preoccupati di decollare. Siamo a corto di fondi per altra memoria secondaria e siamo interessati a usare altri host per la memoria terziaria. Il costo di implementare il protocollo sul 940 era troppo alto rispetto ai potenziali guadagni, quindi è stato abbandonato. Pochi siti sarebbero stati attivi entro gennaio, quando il nostro 940 doveva essere spedito.
Engelbart: Abbiamo creato un Network Dialogue System. Questa è una rete di agenti umani. In ogni sito ci sono: a) un agente di comunicazione tecnica (segretaria) e b) una persona di collegamento tecnico. Incoraggiamo gli agenti a parlare con noi e abbiamo creato numeri di telefono «Enterprise» così possono parlare a chiamata gratuita.
Engelbart: All'inizio inviamo a ogni agente un piccolo kit, una raccolta crescente di informazioni di riferimento sulla rete. Una persona (agente) in ogni sito deve essere addestrata a gestire l'insieme dei documenti e a recuperare informazioni o a contattare il collegamento tecnico di un altro sito. Questo comporta un dialogo pubblico, tenendo un registro dei documenti che vanno e vengono. Questa è una specie di rete di «IMP umani», strutturata come segue:
________________________________
| |
| ________________ |
| | local | | one
| | reference | | <== site ____________
| | material | | ( )
| -----------------| | ( )
| | => (____________)
| | || \\
| | || Other sites
| | || \\
| ________ | || ____________
| local =====> | |================ ( )
| users | agent |=====|===============( )
| =====> |________| | (____________)
| |
|________________________________|
- La collezione principale ha tutto il materiale.
- Ogni collezione locale ha un sottoinsieme considerato più utile.
--: E limitare l'accesso ai documenti?
Engelbart: In questo sistema tutti i file sono file pubblici.
Vezza: Puoi mandare un promemoria privato invece di usare il servizio del NIC.
Engelbart: La collezione principale contiene libri e altri documenti. Catalogati on-line. Il materiale cartaceo può essere duplicato. Per le informazioni che superano il test del valore, il servizio consiste nel conservare, catalogare, indicizzare e fornire accesso ai documenti. Sosterremo diversi tipi di terminale. Siamo pronti ad andare avanti a lungo con gli elementi cartacei, ma possiamo istituire, a pagamento, un servizio di trascrizione da cartaceo a on-line.
Weissman: E distribuire le sfere Selectric OCR ai siti?
--: Il NIC prenderà quello che gli viene inviato o lo cercherà attivamente?
Engelbart: Più o meno quello che ci arriva. Un sistema esisterà nella primavera del 1971, per permettere a un agente di inserire elementi in un catalogo. Il dialogo che si svolge determinerà in che direzione cresce la base di dati. Siamo abbastanza sicuri che alla fine SRI dovrà far pagare, perché molti potenziali utenti non nei siti primari cercheranno risorse limitate.
--: E un NCP per il vostro 10X?
Engelbart: Se l'NCP di BBN è pronto per febbraio 1971, lo useremo.
Crocker: Come fanno le persone ad accedere?
Engelbart: Ogni sito è registrato. Chiunque entri con l'account di un sito ne ha l'accesso. Non ci preoccuperemo della contabilità finché non si raggiunge la saturazione. Vorremmo incoraggiare l'uso del sistema di agenti per creare e usare un censimento delle risorse di ogni sito. Qualche sottogruppo dovrebbe parlarne.
Crocker: Quando possono incontrarsi le persone per discuterne? (Domani mattina)
Engelbart: Abbiamo buone strutture per sviluppare liste di distribuzione, bibliografie private, profili del personale, ma dipende dall'interesse della gente della rete.
Engelbart: Sono stati istituiti agenti con MIT, UCLA, RAND, UI, Utah, ecc. Una buona percentuale dei siti
Vezza: Molti siti spediscono roba in 3a e 4a classe. Richiede troppo tempo.
Crocker: Rapporto sullo stato dei siti. ILLIAC IV non operativo prima di metà 71, sulla rete più tardi (72?). Altri possibili siti: RADC, AWS, NCAR. Attualmente attivi: UCSB, RAND. Imminenti (gennaio 71): MIT BBN, Harvard, UCLA, Utah, LL, SDC. Una certa percentuale entro la fine dell'anno, il resto a gennaio.
Heart: Domani entra in funzione un IMP system nuovissimo (modifica importante). Altri siti stanno pensando di entrare. La rete crescerà notevolmente oltre quello che è già a bordo. Anche noi siamo interessati alle informazioni sulle risorse dei siti. Nessun interesse a lungo termine, ma metteremo le informazioni su carta per aiutare ARPA.
Crocker: Un sacco di gente sta sbadigliando. E i programmi delle riunioni? Durante le FJCC? Riunioni di 1 giorno o di 2 giorni? E riunioni doppie sulla costa Est e Ovest?
Fine della riunione
Riunione di rete
Martedì 17 novembre 1970, ore 9:15
Crocker: Engelbart parlerà in maggiore dettaglio. Più tardi potremmo discutere del logger protocol e del trasferimento di file.
Engelbart: La cosa di base è una collezione di documenti con un catalogo che la descrive. La voce ha molti elementi di dati, incluso dove trovarla. Tecniche per aggiungere e aggiornare le voci. Lo facciamo già, ma vorremmo dare la capacità anche ad altri, in parte perché non possiamo determinare cosa abbia valore. (Ha mostrato 3 tipi di stampa.) 1) Elenco del catalogo, per indice ordinale nella collezione e indice NIC. per il controllo dell'inventario, per scoprire cosa c'è. 2) Formato compattato su una riga. 3) Ordinato per autore: una riga per voce. Avremo procedure con cui un utente non addestrato può gestire una collezione.
Meyer: Come sono implementati questi sistemi?
Engelbart: Abbiamo un compiler-compiler sul 940. I nostri sottosistemi sono scritti in un linguaggio specializzato di alto livello. Stiamo trasferendo tutto questo sul 10X.
Heart: Quante persone può supportare il 10X, all'incirca?
Engelbart: Forse 100-1000 collezioni.
--: Forse le persone potrebbero fornire i propri nastri DEC per memoria aggiuntiva.
Engelbart: Potrebbero, ma richiede un operatore in loco. Accesso lento. Non abbiamo soldi per più memoria, ma stiamo considerando di spedire i file giù a UCSB. Forniamo l'interrogazione on-line di dati on-line. Disposti a occuparci della gestione dei dati, che li conserviamo o no.
Crocker: Descrivi i vari sottosistemi, per favore. (Segue la descrizione di Engelbart.)
Heart: La gente ha provato a usarlo attraverso la rete?
Engelbart: No. Non abbiamo un NCP sul 940. Abbiamo deciso di non metterlo in un sistema che sta sparendo. Il problema più grande è quando il 10X avrà un NCP. Bobrow lo sta sviluppando, ma sta slittando.
Heart: Chi ci arriverà (a SRI) presto?
UI: Illinois può accedere solo a SRI, per cominciare.
Postel, UCLA: Contiamo di usarlo.
Heart: Sarebbe un compito significativo se qualcuno si ponesse come obiettivo di entrare nel sistema di Engelbart.
MITRE: Useremo altri sistemi dal 10X di BBN.
Engelbart: Stiamo cercando di isolare i sottosistemi essenziali perché la gente li possa usare facilmente. I file sono organizzati gerarchicamente e si completeranno con il passare degli anni. I documenti sono referenziati tramite pathname. (Segue una discussione sui sistemi.)
Crocker: Come si entra nel sistema? (Engelbart descrive la sequenza di ingresso a TOdas.)
Crocker: Come ci si registra sul sistema?
Engelbart: Alla fine tramite inserimento personale, ma attualmente c'è un solo user id per sito.
Meyer: Penso che stiamo ignorando problemi irrisolti nell'interfacciamento delle telescriventi. Per esempio, la sequenza di ingresso a TOdas, in cui l'utente digita uno o due caratteri e il sistema stampa i caratteri rimanenti di una parola chiave, sarà frustrante da usare da un sistema half-duplex come Multics. Il nostro sistema non riconoscerà una riga di input finché non viene digitata una nuova riga.
Various: Discussione sulla comunicazione 1/2 duplex. Fa emergere la distinzione tra a) sistemi full duplex in cui il sistema fa l'echo dell'input rispetto a 1/2 duplex in cui l'input è digitato localmente, e b) sistemi in cui ogni carattere è riconosciuto mentre viene digitato rispetto a sistemi in cui l'intera riga è riconosciuta solo dopo il carattere EOL.
Crocker: Multics non è l'unico sistema half-duplex orientato alle righe sulla rete?
Meyer: Non ci credo. I sistemi IBM non funzionano così?
Engelbart: Potremmo avere un'interfaccia 1/2 duplex sul nostro sistema (SRI). È l'hardware di Multics che impone questa restrizione?
Meyer: Sì, il controller di input-output.*
* L'adattatore per telescrivente del controller Multics IO è 1/2 duplex, ma può accettare caratteri di break diversi dal carattere «new line».
Engelbart: Ogni sistema dovrebbe avere un preprocessore per parlare con gli altri sistemi. Metteremo un'interfaccia grafica sulla rete.
Meyer: Come vedi queste interfacce? Aderiscono a qualche standard di rete, o ogni sistema costruirà un'interfaccia verso di voi?
Engelbart: Protocollo di rete standard.
Crocker: Passiamo ad altre cose.
O'Sullivan: E i 2741 sul vostro sistema 10X (CMU). Avete seri problemi di interfacciamento? (I 2741 della CMU passano attraverso un pacchetto software che li trasforma in TTY 37. Nessuna difficoltà seria.)
Various: Breve discussione su come Multics gestisce l'input.
Sundberg, HARVARD: Il nostro 10X può accettare input orientato ai caratteri, ma i nostri sottosistemi di livello superiore preferiscono l'input orientato alle righe.
--: E l'efficienza di trasmettere messaggi attraverso la rete un carattere alla volta?
Crocker: C'è più output, che va impacchettato, che input, quindi l'inefficienza dell'input è trascurabile.
Engelbart: Contiamo di avere diverse porte differenti verso il nostro sistema. Se ogni sistema avesse un modulo NIC, potrebbe comunicare con noi senza bisogno di un login. Preferiamo un sistema di tipo batch, in cui un sito invia un batch spooled di richieste di modifica, riceve indietro la roba e libera le porte. Il problema della trasmissione delle telescriventi per riga potrebbe essere gestito in modo simile alle richieste spooled. Incoraggiamo lo spooling, ma supporteremo gli utenti interattivi. Possiamo supportare più batch che persone interattive.
* L'adattatore per telescrivente del controller Multics IO è 1/2 duplex, ma può accettare caratteri di break diversi dal carattere «new line».
Vezza: La gente ritiene che il problema full e 1/2 duplex sia un problema? Che tutti tornino indietro e lo verifichino. Il M.I.T., con un sistema full e 1/2 duplex a 20 feet di distanza, può aiutare in questo.
O'Sullivan: Sembrano esserci 2 questioni: (1) l'echo (full duplex) rispetto a 1/2 duplex. (2) trasmissione di singolo carattere rispetto a riga intera.
Crocker: Due definizioni: serving host - fornisce la computazione; using host - parassitario, gestisce il terminale dell'utente. Questa vede l'uso della rete come un collegamento tra l'utente locale e il server esterno.
Vezza: E l'interconnessione 1/2 duplex - full duplex se alcuni sistemi full duplex fanno l'echo di qualcosa di diverso da ciò che è stato immesso?
Crocker: Due possibilità indipendenti. Facciamo uno schema:
| "2741" | "33, 35, 37" |
| hard wire | 2 separate |
| local echo | lines all |
| computer does | printed |
| not echo | |
____________|_________________|___________________|
Process | hard | X |
each | | |
character | | |
____________|_________________|___________________|
Process | X | easy |
only after | | |
EOL | | |
____________|_________________|___________________|
Crocker: Sostengo che in realtà ci sono solo due possibilità (contrassegnate da X).
Postel: E un sistema in cui l'echo è fatto a un livello così basso che non può essere eliminato?
Crocker: Se è così, è come il non-echo.
Van Zoeren: Il nostro sistema crede che abbiamo TTY full duplex, ma i nostri 2741 sono collegati tramite una scatola di trasformazione software.
Meyer: Cosa succede quando sistemi non-echoing vengono collegati a sistemi echoing tramite la rete? Digito la mia riga di input, poi il sistema echoing risponde con il mio input, poi un po' di output. Il mio sistema non può filtrarlo perché non c'è modo di distinguere l'echo dall'output.
Crocker: Non è necessariamente una cosa negativa. Digito un'abbreviazione di comando a SRI; poi la riga di output successiva è una forma estesa del comando immesso.
Meyer: Il nostro obiettivo dovrebbe essere un protocollo comune, piuttosto che un mucchio di schemi pasticciati per implementare la comunicazione tra specifiche coppie di host.
Long, SDC: Preferiamo ricevere una riga intera fatta passare attraverso la rete.
Crocker: Distinguiamo tra centri di ricerca e centri di servizio. Solo i centri di servizio sono interessati a un'interfaccia half-duplex. (X in basso a sinistra sul grafico). Questi includono SRI, BBN, Multics.
O'Sullivan: E i centri di ricerca?
Crocker: Possono chiamare i centri di servizio, ma essi stessi possono essere difficili da usare.
Illinois: Allora l'ILLIAC IV dovrà essere half-duplex.
Postel: Penso che l'half-duplex, orientato alle righe, sia più debole (di un protocollo full-duplex, orientato ai caratteri).
Sundberg: Harvard può andare in entrambi i modi, ma preferisce un sistema orientato alle righe.
Engelbart: I terminali grafici sono più difficili da mettere sulla rete a causa dell'input non standard.
Harslem: Stai pensando ai tasti come tasti funzione anziché come tasti di input.
Engelbart: Sono preoccupato per le persone che vogliono usare la grafica.
O'Sullivan: Non abbiamo affrontato il problema di che tipo di protocollo si debba stabilire.
Crocker: Non è una cosa tecnicamente difficile. Ci arriveremo più tardi e prenderemo una decisione.
Meyer: Non sono autorizzato a prendere alcuna decisione. Devo riferire al gruppo MAC.
Crocker: Va bene. Allora, una proposta, da accettare tramite il meccanismo normale. Intervallo
Crocker: Proporrò come gestire le caselle con la X, ignorando le caselle hard e ease:
Input orientato alle righe - ascii a 8 bit incluso il carattere End of Line:
n, C1,...,Cn;
Cn=EOL
120>n>>_1 n is the character count in an 8-bit field.
Il conteggio dei caratteri precede la riga, in modo da dare al sistema software la stessa efficienza del sistema hardware; il computer non deve scansionare alla ricerca dell'EOL.
Vezza: Non ottieni l'informazione sulla lunghezza con il messaggio IMP?
Crocker: La mia filosofia è che i confini dei messaggi IMP dovrebbero essere completamente invisibili.
Long: Sono contrario a dividere i messaggi delle telescriventi in due pezzi separati.
Crocker: Qual è la tua obiezione, 1) righe che iniziano sui confini dei messaggi o 2) messaggio che non inizia su un confine di riga?
Long: Entrambe.
Engelbart: Ogni host dovrebbe scrivere un'interfaccia per gestire i tipi di terminale più comuni.
Crocker: Il protocollo ufficiale non consente che i confini dei messaggi IMP abbiano alcun significato.
Engelbart: Non voglio preoccuparmi dei confini dei messaggi IMP. La rete dovrebbe essere invisibile (a questo livello).
Vezza, Long: Concediamo, ci stiamo.
Meyer: Vorrei cambiare la restrizione. L'ultimo carattere nel pacchetto di riga non deve necessariamente essere un EOL (come quando un output non va a capo), ma un EOL non può comparire in mezzo a un pacchetto.
Van Zoeren: Questa restrizione non mi piace.
Meyer: Il conteggio ci dice che ogni EOL è alla fine, non dobbiamo scansionare.
Crocker: L'EOL è il carattere che dice al sistema di agire.
Harslem: Il nostro sistema ha 46 tasti funzione, non solo un EOL.
Crocker: Che ne dici se C, E {breakset}; i=n. Questo è più complesso, perché bisogna trasmettere un breakset. Lo proporrò tra un momento. Che ne dici di questo: connessione orientata ai messaggi (1/2 duplex)
tra host User e Server per l'interazione con la console. Echo locale, nessun echo del server. Questo è per i sistemi di servizio orientati alle righe. Queste sono leggere generalizzazioni delle convenzioni di Multics.
Meyer: Sono sicuro che altri sistemi oltre a Multics lo usano. Non è così male come sembra che tu pensi.
Engelbart: I dirigenti dovrebbero sapere che è male.
Meyer: Non è chiaro. Ci sono questioni di efficienza.
Van Zoeren: Non voglio dover trasmettere i file in questo modo.
Crocker: Questo è per le console, non per la trasmissione di file.
Engelbart: Ci serve uno schema unificato per la trasmissione dei dati.
O'Sullivan: (Per le console) dobbiamo escogitare un modo per dire a un sistema dove deve essere simulato il suo interrupt.
Crocker: C'è un problema generale di trasmissione dei dati per nastri e file.
O'Sullivan: Ma abbiamo il problema specifico di implementare le comunicazioni delle telescriventi.
Engelbart: Ma quello che ci serve è un modo generale di mandare roba attraverso la rete (così è invisibile) e far sì che l'host la interpreti come vuole.
Meyer: Dovrebbe esserci un'unica interfaccia console per la rete, non diverse in ogni sito.
Crocker: Questo problema è forse sopravvalutato.
Engelbart, Meyer, O'Sullivan: Discussione sul supporto di tipi di terminale specifici.
Engelbart: Disegnerò un grafico di sistemi vs. tipo di terminale. L'intersezione di un sistema e di un terminale accettato da quel sistema è contrassegnata da un punto. Il problema della comunicazione di rete è trovare un terminale presso l'host locale che sia supportato anche dall'host di destinazione.
_____|_____|_____|_____|_____
| | | |
systems_____|_____|_____._____|_____
| | | |
_____|_____._____|_____|_____
| | | |
_____|_____|_____|_____|_____
| | | |
terminals
Crocker: C'è un problema generale di un sottosistema che reagisce all'input. Proponiamo che l'input venga inviato come messaggio completo o in multipli di 8-bit.
Vezza: Stiamo vincolando troppo?
Meyer: Perché è necessario avere multipli di 8-bit?
Crocker, Engelbart: Va bene, buttiamo via quello.
Fine della seconda riunione
Riunione di rete
Mercoledì 18 novembre 1970, ore 20:20
(I seguenti appunti sono molto condensati e cercano solo di presentare i temi principali discussi in questa riunione.)
Crocker: Incontriamoci alla SJCC con più organizzazione preventiva. Facciamo diverse riunioni di più giorni a intervalli di 2-3 mesi. Abbiamo avuto molte buone discussioni sul protocollo di livello successivo. Lasciamo che un sottogruppo lo elabori.
(Harslem si offre di riscrivere il logger protocol proposto nell'RFC 66. Meyer rivedrà la proposta nell'RFC 46.)
Meyer: Torniamo indietro, discutiamo queste questioni, scriviamo proposte. Più tardi avremo una riunione aperta per decidere su una proposta formale.
Crocker: Un gruppo piccolo è meglio, forse sceglierò un sottoinsieme.
Vezza: È vero che le cose qui non sono stabilite. Le proposte importanti dovrebbero essere su carta in preparazione di una riunione. Non possiamo legiferare su ciò che fa un gruppo piccolo. Non ha più autorità di un individuo.
(Karp di MITRE si offre di produrre una bibliografia dei documenti di rete, forse entro gennaio.)
(Chi ha implementato il logger protocol? UCSB e UCLA mod 91 lo hanno o lo stanno pianificando. SDC potrebbe averlo entro 21/1, l'ha trovato scomodo, disposto a cambiare.)
(Discussione sul trasferimento di file. Crocker propone che una futura modifica al protocollo possa associare a una connessione una dimensione di byte come 8, 32, 36 bit.)
(Riguardo ai link di controllo, tutto è trasmesso in byte da 8 bit tranne i comandi ECO, ERP, ERR. Non è stata espressa alcuna obiezione a cambiare il protocollo in modo che anch'essi debbano essere multipli di byte da 8 bit.)
(Discussione su come specificare la fine di un file. Trasmissione preliminare del conteggio dei bit, o invio del carattere EOR alla fine? Suggerimento che vogliamo una soluzione globale al problema generale di inviare un messaggio di lunghezza arbitraria, non solo la trasmissione di file.)
(Discussione sulle «transaction units» o dimensioni dei record. Qual è una dimensione ottimale dell'unità di transazione? I confini dei messaggi IMP sono invisibili (per decreto del protocollo) e non sono collegati a questa discussione. È stata sollevata la dimensione dei blocchi di Multics. La cosa più vicina è la dimensione di pagina, 1024 parole.)
(Come specificare la fine del file. Engelbart dice di inviare pacchetti di dati, poi un pacchetto EOF. Crocker suggerisce che chiudere la connessione (CLS) può fungere da EOF. Vezza suggerisce di usare i confini dei messaggi IMP per determinare la fine. Se meno di un messaggio IMP completo, questa è l'ultima parte del file. Meyer suggerisce l'uso di due connessioni, canale dati e canale di controllo, su cui passano tutti i messaggi di controllo, come nome del file, lunghezza in bit, ecc.)
(Discussione sulle diverse situazioni in cui si voleva l'intero file, parte del file, o l'intero file in blocchi arbitrari.)
Meyer: Perché non rimandiamo questo e parliamo delle comunicazioni delle telescriventi, che sono le più critiche.
Vezza: Engelbart vuole una soluzione generale e pulita.
Crocker: Se otteniamo una soluzione ad hoc ora, potrebbe interferire con l'implementazione di una soluzione generale più tardi.
(Crocker propone un formato per trasmettere un file di record di lunghezza arbitraria composti da byte di dimensione fissa di 8-26 bit. Un record è meno di 10^5 byte. Ogni record è preceduto da un byte di conteggio.)
1 2 n 1 2 m
|----------------------------------------------------|
| n | | | | | m | | | | |
|----------------------------------------------------|
<------- record -----------> <-------- record ------->
O'Sullivan: Questo modello si adatta a un terminale che ha modalità carattere e grafica?
(Discussione sulle differenze tra tastiera e trasmissione di file. Incertezza sul fatto che una soluzione globale possa andar bene per entrambe.)
(Chi vuole spedire file attraverso la rete? Multics e 6-10, RAND verso UCLA, MITRE usando BBN.)
Crocker: Andiamo via a pensarci e proponiamo soluzioni più tardi.
(Harslem propone un formato per trasmettere dati con codici di operazione. Ogni record consiste di: <opcode> <length> <data>. Dà l'opportunità di inviare molti tipi di informazioni di stato.)
(Discussione sull'invio di dati e informazioni di controllo mescolati o su connessioni separate. Questioni di inquinamento dei dati rispetto a problemi di sincronizzazione e race. Si sostiene che i problemi di sincronia si superano facilmente.)
(Suggerimento che in realtà non sappiamo molto di quest'area. Dovremmo andare via e scrivere.)
Intervallo
Crocker: Cosa si deve fare prima di poter accedere ad altri sistemi?
Meyer: 3 questioni: 1) come stabilire la connessione, 2) qual è il set di caratteri, 3) qual è il modo di trasmissione (relativo al problema full e 1/2 duplex).
(Discussione sull'orientare il protocollo standard verso i sistemi di servizio, che in genere sono orientati alle righe e 1/2 duplex. Ogni sistema che offre servizi deve avere un'interfaccia 1/2 duplex.)
(Discussione se sia possibile o auspicabile che il logger protocol consenta la trasmissione di righe parziali in un messaggio IMP. Meno efficiente prendere righe parziali, ragionevole inviare la riga intera. È stato fatto notare che il protocollo NCP non attribuisce alcun significato ai confini dei messaggi IMP, quindi i sistemi devono essere preparati ad accettare righe a cavallo dei confini dei messaggi IMP. Tuttavia, è meglio inviare la riga completa.)
(Discussione se il protocollo orientato alle righe debba piegarsi per accettare la trasmissione di singoli caratteri dai sistemi full duplex. Sembra che stiamo arrivando a un protocollo che permette a qualsiasi sistema di usare un sistema orientato alle righe. Usare un sistema orientato ai caratteri da altri sistemi è più difficile e richiede un protocollo separato.)
Heart: Sono favorevole a una soluzione immediata.
Postel: Una volta che qualcosa entra, sarà difficile cambiarlo.
Crocker: Penso che queste riunioni si riveleranno più importanti di quanto avessimo mai voluto. Mi preoccupano più gli effetti a lungo termine della data di inizio.
Van Zoeren: Se non lo decidiamo noi, qualcun altro lo deciderà nel modo sbagliato.
Nota: Questo RFC è stato messo in forma leggibile da una macchina per l'inserimento negli archivi RFC online da Gottfried Janik 2/98.