Breve discussione

Lo spazio PDP-10 richiesto per implementare il protocollo di cui sopra è di circa 400 istruzioni, diviso equamente tra il lato di input e quello di output. È stata scritta abbastanza codifica sperimentale da confermare la fattibilità di questa strategia di base, insieme all'esperienza maturata con l'implementazione e l'uso del sistema di buffering SOS.

Quanto sopra non tocca la questione del protocollo LOGON, se non indirettamente. Ritengo che possa essere accomodata nel quadro di questa proposta, ma non ho ancora messo alla prova questa teoria. Come indicato più sopra, sarei tentato di gestire la cosa con il flag SYS, dato che i dati SYS sono interpretati direttamente dal sistema (nel nostro sistema, useremmo la UUO RUN per eseguire il CUSP LOGON, che a sua volta farebbe l'handshake usando dati ASCII sul collegamento). In questo modo, penso che potremmo fare a meno della nozione di socket dedicati e del pantano della riconnessione.

Un altro punto che richiede riflessione è la questione di come gestire la funzionalità di interrupt sul collegamento. Dovrebbe avere una relazione diretta con le UUO GET/PUT, o essere gestita a parte? Sono incline a pensare che dovrebbe essere trattata qua interrupt del processo utente, del tutto indipendentemente dalla questione della trasmissione dei dati sul collegamento. Parte del nostro lavoro attuale sul monitor del PDP-10 si presterebbe abbastanza facilmente a un'implementazione come vero interrupt.