Protocoles de connexion initiale
Nous souhaitons avancer deux points concernant des protocoles de connexion initiale (IPC) particuliers. Premièrement, l'IPC décrit dans NEW/RFC #66 -- sa généralité et une reformulation de cet ICP. Deuxièmement, une proposition de variante d'ICP utilisant fondamentalement la même logique que NWG/RFC #66.
I. NWG/RFC #66
La seule erreur technique de cet IPC est que, tel que le montre le schéma, le serveur comme l'utilisateur envoient tous les messages avant que les connexions ne soient établies, ce qui est incompatible avec le document réseau n° 1. Cela peut facilement être corrigé, comme le montrera la reformulation ci-dessous.
En termes de généralité, tout IPC adopté comme norme devrait s'appliquer à davantage de situations qu'un processus appelant un Logger. Autrement dit, certains processus de service du réseau qui se raccordent directement à un processus utilisateur, indépendamment de l'action du Logger, pourraient peut-être utiliser un IPC standard. Ainsi, comme le montre ce qui suit, le champ de nom de processus du socket du serveur devrait être un paramètre, la valeur zéro constituant un cas particulier pour les Loggers.
Reformulation de NWG/RFC #66 (en reprenant la même formulation là où cela convient)
- Pour engager le contact, le processus utilisateur attache un socket de réception (US) et demande la connexion au processus SERV socket #1 dans l'hôte serveur. (SERV = 0 pour un ICP vers le Logger.) En conséquence, le NCP utilisateur envoie :
1 4 3 1 1
+-----+---------------------+---------------+-----+-----+
| RTS | US | SERV | 1 | P |
+-----+---------------------+---------------+-----+-----+
sur le lien 1, où P est le lien de réception.
- Le processus serveur (SERV) peut décider de refuser l'appel, auquel cas il ferme la connexion. S'il accepte l'appel, le processus serveur achève la connexion (par un appel système INIT, donc un STR).
1 3 1 4
+-----+----------------+-----+--------------------+
| STR | SERV | 1 | US |
+-----+----------------+-----+--------------------+
- Lorsque la connexion est achevée, le processus utilisateur alloue une quantité nominale d'espace à la connexion, ce qui amène le NCP à envoyer :
1 1 4
+-----+-----+--------------------+
| ALL | P | SPACE |
+-----+-----+--------------------+
où SPACE est la quantité.
-
Le processus serveur sélectionne alors la paire de sockets qu'il souhaite attribuer à cet utilisateur. Il envoie exactement un nombre pair de 32 bits sur la connexion. Ce nombre pair de 32 bits (SS) est le socket de réception dans l'hôte serveur. Ce socket et le socket immédiatement supérieur sont réservés au processus utilisateur.
-
Il ferme ensuite la connexion. Le NCP serveur envoie (étape 4) :
4
+---------------------+
| SS |
+---------------------+
sur le lien P, et (étape 5) :
1 3 1 4
+-----+----------------+-----+--------------------+
| CLS | SERV | 1 | US |
+-----+----------------+-----+--------------------+
sur le lien de contrôle (qui est répercuté par le NCP utilisateur).
- Maintenant que le serveur et l'utilisateur connaissent tous deux la paire de sockets distants de la connexion duplex, des <STR, RTS> peuvent être échangés.
Le serveur envoie à l'utilisateur
1 4 4
+-----+--------------------+--------------------+
| STR | SS + 1 | US |
+-----+--------------------+--------------------+---+
| RTS | SS | SS + 1 | Q |
+-----+--------------------+--------------------+---+
où Q est le lien de réception du serveur.
L'utilisateur envoie au serveur
1 4 4
+-----+--------------------+--------------------+
| STR | US + 1 | SS |
+-----+--------------------+--------------------+---+
| RTS | US | SS + 1 | R |
+-----+--------------------+--------------------+---+
où R est le lien de réception de l'utilisateur.
Des ALLocates peuvent alors être envoyés et la transmission commencée.
II. Une variante de NWG/RFC #66
Cette variante réduit le nombre de messages réseau et élimine la duplication du transfert d'informations.
Les étapes 3 et 4 ci-dessus sont supprimées. Le processus utilisateur n'est pas informé directement du socket du serveur qui lui sera attribué. Toutefois, le processus utilisateur écoutera sur les sockets US et US + 1 les appels provenant de SERV après l'étape 5 ci-dessus. Il peut rejeter tout appel parasite. En acceptant les appels provenant de SERV, la connexion est établie.
La séquence d'exemple suivante illustre cet ICP. (La notation est celle donnée ci-dessus).
- Utilisateur --> Serveur
1 4 3 1 1
+-----+--------------------+----------------+-----+-----+
| RTS | US | SERV | 1 | P |
+-----+--------------------+----------------+-----+-----+
- Serveur --> Utilisateur
Si accepté :
1 3 1 4
+-----+----------------+-----+---------------------+
| STR | SERV | 1 | US |
+-----+----------------+-----+---------------------+
| CLS | SERV | 1 | US |
+-----+----------------+-----+---------------------+
Si rejeté :
1 3 1 4
+-----+----------------+-----+---------------------+
| CLS | SERV | 1 | US |
+-----+----------------+-----+---------------------+
-
Si accepté, l'utilisateur écoute sur US et US + 1.
-
Serveur --> Utilisateur
1 4 4
+-----+--------------------+---------------------+
| STR | SS + 1 | US |
+-----+--------------------+---------------------+---+
| RTS | SS | US + 1 | Q |
+-----+--------------------+---------------------+---+
- L'utilisateur accepte les appels, d'où :
Utilisateur --> Expéditeur
1 4 4
+-----+---------------------+--------------------+
| STR | US + 1 | SS + 1 |
+-----+---------------------+--------------------+---+
| RTS | US + 1 | SS | R |
+-----+---------------------+--------------------+---+
et la connexion est établie.
Cela réduit de deux le nombre de messages réseau et ne transmet qu'une seule fois, via RTS et STR, les informations concernant les sockets du serveur.