Résumé

  • Dans RFC 2024, l’annuaire indiquait où un nœud DLSw pensait pouvoir atteindre une adresse MAC ou un nom NetBIOS ; il ne déclarait pas un circuit actif.
  • Les tables de transport et de circuit, les crédits de cadence et les motifs de déconnexion répondaient chacun à une question distincte.

« La ressource est-elle joignable ? » paraît être une question unique. RFC 2024 y répondait pourtant par une chaîne de preuves. L’annuaire désignait un emplacement. La table de transport pouvait montrer que deux pairs DLSw avaient échangé leurs capacités. La table des circuits suivait le chemin d’une station terminale. Les compteurs de cadence disaient combien de messages pouvaient être envoyés avant d’attendre. Lire une de ces réponses comme la somme des autres revenait à effacer le mécanisme observé.

L’annuaire exprimait une croyance locale

Pour chaque adresse MAC ou nom NetBIOS, un pointeur de localisation pouvait mener vers une interface locale, une connexion configurée, une connexion opérationnelle, une référence nulle ou une table propre au constructeur. Le statut — inconnu, joignable ou non joignable — décrivait ce que DLSw croyait à cet instant au sujet de l’accès par cet emplacement.

Les exemples statiques restent prudents. Une entrée pouvait commencer avec un statut inconnu. Une même ressource distante pouvait être associée à plusieurs partenaires. L’ordre des choix n’était pas garanti et, à spécificité égale, l’arbitrage entre une connaissance statique et dynamique pouvait dépendre de l’implémentation. Après un échec, une entrée non joignable pouvait surtout empêcher de relancer immédiatement une recherche.

L’annuaire orientait donc la recherche. Il ne prouvait ni que le pair retenu était connecté, ni que l’établissement du circuit avait commencé, ni que la station répondait.

« Connecté » qualifiait le transport

La connexion de transport passait notamment par connexion en cours, échange initial de capacités, connecté, mise au repos, déconnexion en cours et déconnecté. Dans ce vocabulaire, connecté signifiait que les pairs avaient déterminé leurs capacités et pouvaient recevoir les messages d’établissement de circuit. Ce n’était pas un certificat de service de bout en bout.

Le lien entre configuration et exploitation devait lui aussi être daté. dlswTConnOperConfigIndex renvoyait vers la ligne de configuration, mais valait zéro si celle-ci avait été supprimée. Une modification intervenue après l’ouverture de la connexion ne décrivait pas nécessairement tous les paramètres négociés auparavant. L’heure de connexion et la dernière modification de configuration faisaient donc partie de la preuve.

Une ligne opérationnelle pouvait rester visible après la déconnexion pour conserver statistiques et motif de panne, sans durée de rétention imposée. Les capacités reçues du partenaire pouvaient ainsi demeurer lisibles dans une ligne historique. Leur présence n’établissait pas la disponibilité actuelle.

Le circuit commençait après la découverte

RFC 2024 distinguait deux temps : les explorateurs localisaient d’abord la ressource, puis commençait l’établissement du circuit. La table des circuits n’ajoutait une ligne qu’au second temps. Elle possédait sa propre suite d’états. Le seul état modifiable était disconnectPending ; aucun ordre de rétablissement n’était offert, car les stations terminales pilotaient la création du circuit.

Les motifs de déconnexion et les pointeurs vers les MIB LLC ou SDLC sous-jacentes aidaient l’enquête. Certaines statistiques de trafic exigeaient de suivre ces pointeurs. Il s’agissait d’indices coordonnés, pas d’un diagnostic causal autonome.

Les unités de cadence avaient une portée tout aussi étroite : elles indiquaient combien de messages SSP cadencés une extrémité était autorisée à émettre avant de s’arrêter. Zéro pouvait aussi signifier que la cadence n’était pas utilisée. Une fenêtre de crédit ne comptait ni les messages effectivement livrés, ni le travail applicatif accompli.

Une notification marquait un passage

Les notifications de montée du transport ou du circuit pouvaient être émises lors de l’entrée dans l’état connecté. Leur émission était configurable, donc désactivable. Une notification reçue attestait un passage observé localement et la livraison de cette notification ; elle ne garantissait ni la permanence de l’état, ni l’accord du pair, ni l’absence d’une déconnexion ultérieure. Son absence ne démontrait pas l’absence d’événement.

L’heure et le motif de déconnexion, ainsi que l’indicateur de circuits actifs, affinaient l’analyse. Ce dernier signalait que des utilisateurs pouvaient avoir été touchés ; il ne les dénombrait pas et ne mesurait pas la perte métier. RFC 2166 a ensuite ajouté à RFC 1795 des motifs HALT généraux proches de ces catégories. Les anciens pairs pouvaient les omettre et le détail constructeur varier. L’indice devenait meilleur, pas infaillible.

Plusieurs nœuds pouvaient détenir les morceaux

RFC 2024 prévenait qu’une vue complète pouvait nécessiter l’interrogation de plusieurs nœuds DLSw. Pour éviter les doublons, certaines informations étaient définies comme reçues du partenaire. Le protocole ne permettait pas non plus de relier sûrement l’adresse de transport gérée d’un pair à son adresse de gestion.

Chaque ligne constituait donc un témoignage local et borné. La distinction proposée par Heng Lu entre un enregistrement et la réalité qu’il décrit éclaire utilement ce dessin : un enregistrement peut être exact sans épuiser l’état du système. C’est ici une grille d’analyse contemporaine, pas une intention attribuée aux auteurs du RFC.

La discipline opérationnelle consiste à conserver les jointures. L’annuaire étaye la localisation enregistrée ; la table de transport, l’état et le moment de la négociation ; la table des circuits, le chemin des stations ; les MIB sous-jacentes, les indices de couche locale. Comparées entre pairs, ces preuves expliquent le service. Réduites à une seule pastille verte, elles le caricaturent.

Sources