I. Erreurs et débordement

Dans le prolongement de la discussion de la NWG/RFC #48, nous avons estimé qu'il fallait distinguer deux types d'erreurs. L'une est une véritable erreur, comme une RFC composée de deux sockets d'émission. Ce type d'erreur ne peut être généré que par un NCP défectueux. En l'absence de défauts matériels ou logiciels, ces événements ne devraient jamais se produire ; la réponse correcte à la détection d'un tel événement a été esquissée dans la description de la commande ERR de la NWG/RFC #54.

L'autre « erreur » est une condition de débordement résultant de l'épuisement de ressources système finies. Un débordement peut se produire si une RFC est reçue, mais qu'il n'y a pas de place pour créer les tables et les files d'attente requises. Ce n'est pas une véritable erreur, en ce sens que personne n'a rien fait d'incorrect (sauf peut-être les concepteurs du système, coupables de n'avoir pas prévu suffisamment d'espace de tables, etc.). De plus, une procédure de reprise peut être définie sans ambiguïté : elle consiste simplement à répéter la demande ultérieurement. Nous pensons donc qu'une condition de débordement devrait être distinguée d'une véritable erreur.

Dans la NWG/RFC #54, une condition de débordement était signalée par le renvoi d'un CLS, comme si la connexion avait été refusée. Cette séquence accomplit les fonctions nécessaires et laisse la connexion dans l'état correct, mais l'utilisateur à l'initiative de la demande est mal informé. Il est amené à croire qu'il a été refusé par le processus distant, alors qu'en réalité ce n'est pas le cas. Dans certains algorithmes, cette différence est cruciale.

Pour définir plus avant les conditions d'erreur, nous avons estimé qu'il serait utile de préciser pourquoi l'erreur a été détectée, en plus d'indiquer ce qui l'a causée. En rédigeant le programme en pseudo-Algol mentionné dans la NWG/RFC #55, nous avons distingué 9 types d'erreurs (énumérés ci-dessous). Nous aimerions donc proposer d'étendre le message ERR en ajoutant, après le code d'opération, un champ de 8 bits désignant le type d'erreur. Viendraient ensuite, comme auparavant, les champs de longueur et de texte. Nous proposons les types d'erreurs suivants ;

UNSPECIFIED ERROR
HOMOSEX (paire émission/réception invalide dans une RFC)
ILLEGAL OP CODE
ILLEGAL LEADER (type de message incorrect, etc.)
ILLEGAL COMMAND SEQUENCE
ILLEGAL SOCKET SPECIFICATION - COMMAND
ILLEGAL COMMAND LENGTH (la dernière commande du message était trop courte)
CONNECTION NOT OPEN - DATA
DATA OVERFLOW (message plus long que l'espace tampon disponible annoncé)
ILLEGAL SOCKET SPECIFICATION - DATA (le socket n'existe pas)

À la lumière des autres considérations mentionnées plus haut, nous souhaitons également proposer une commande de contrôle supplémentaire pour signifier un débordement :

        +-------------+-------------------+---------------------+
        |     OVF     |     my socket     |     your socket     |
        +-------------+-------------------+---------------------+

Le format de message est similaire à celui du message CLS, qu'il remplace dans ce contexte. Les numéros de socket font 32 bits et correspondent aux numéros de socket de la RFC qui est rejetée. La sémantique d'un OVF entrant devrait être identique à celle d'un CLS entrant ; en outre, l'utilisateur devrait être informé qu'il n'a pas été refusé, mais qu'il a plutôt épuisé les ressources de l'hôte distant.

Une alternative à la création d'une commande de contrôle distincte consisterait à exploiter la similitude entre un CLS et un OVF. On pourrait concevoir d'ajouter à la commande CLS un champ de huit bits définissant son origine. Nous pensons toutefois que cette alternative est conceptuellement inférieure et pratiquement plus difficile à mettre en œuvre.

Le débordement ne requiert pas d'examen sérieux s'il s'agit d'un événement nettement rare. Nous ne pensons pas que ce sera le cas, et nous pensons en outre que son absence constituerait une restriction inutile pour l'utilisateur.