Brève discussion

L'espace PDP-10 requis pour implémenter le protocole ci-dessus est d'environ 400 instructions, réparties également entre le côté entrée et le côté sortie. Un codage expérimental suffisant a été réalisé pour confirmer la faisabilité de cette stratégie de base, compte tenu également de l'expérience acquise dans l'implémentation et l'utilisation du système de tamponnement SOS.

Ce qui précède n'aborde pas la question du protocole de LOGON, sauf indirectement. Je crois qu'il peut être pris en charge dans le cadre de cette proposition, mais je n'ai pas encore testé cette théorie. Comme indiqué plus haut, je serais tenté de traiter la question avec le fanion SYS, étant donné que les données SYS sont interprétées directement par le système (dans notre système, nous utiliserions l'UUO RUN pour exécuter le CUSP LOGON, qui, à son tour, ferait la poignée de main au moyen de données ASCII sur la liaison). De cette façon, je pense que nous pourrions nous passer de la notion de sockets dédiés et du bourbier de la reconnexion.

Un autre point qui mérite réflexion est la question de savoir comment traiter la facilité d'interruption sur liaison. Devrait-elle avoir un rapport direct avec les UUO GET/PUT, ou être traitée à part ? J'ai tendance à penser qu'elle devrait être traitée qua interruption du processus utilisateur, tout à fait indépendamment de la question de la transmission de données sur la liaison. Certains de nos travaux actuels sur le moniteur du PDP-10 se prêteraient assez facilement à une implémentation comme véritable interruption.