Résumé

  • Dans RFC 3528, un agent d’annuaire amélioré pour le maillage peut renvoyer SrvAck à l’agent de service avant d’avoir transmis l’inscription, de manière asynchrone, aux autres agents d’annuaire. L’acceptation locale et la convergence du maillage sont donc deux faits distincts.
  • Une preuve exploitable doit conserver l’identité et l’autorisation de l’émetteur, la décision locale, le transfert vers chaque pair, l’anti-entropie, la visibilité des requêtes, la durée de vie, l’accessibilité du service et le résultat applicatif. Aucun de ces étages n’hérite automatiquement du premier reçu.

Le scénario ressemble à une fédération de guichets. Un déposant remet une fiche à l’un d’eux et reçoit un accusé. Le guichet a bien enregistré la fiche. Il ne peut pourtant pas certifier, dans le même geste, que tous les autres guichets l’ont déjà classée, qu’ils la restitueront à la prochaine demande ou que l’adresse inscrite répond.

RFC 3528, publié en avril 2003 comme protocole Experimental, apporte au protocole SLPv2 un maillage complet par portée entre agents d’annuaire, une transmission directe et un mécanisme d’anti-entropie. Il ne masque pas le décalage entre réception et diffusion : il l’organise.

Le premier accusé appartient au premier guichet

Un Service Agent dépose une inscription auprès d’un Directory Agent. Celui qui accepte la mise à jour devient l’accept DA. S’il est compatible mSLP, il peut ensuite acheminer cette information vers ses pairs qui desservent les mêmes portées.

L’enchaînement n’est pas une transaction distribuée. La transmission directe est asynchrone, et l’agent qui accepte peut répondre à l’agent de service avant d’envoyer le Srv(De)Reg à un autre agent d’annuaire. Le reçu affirme donc qu’un traitement local a abouti.

Cette limite protège la disponibilité du dépôt. Si l’accusé dépendait de chaque pair, une seule panne ou lenteur étendrait son effet à tous les producteurs d’inscriptions. La bonne conception ne consiste pas à nier cette indépendance, mais à nommer correctement le reçu.

Le journal doit conserver l’agent accepteur, l’identité authentifiée de l’émetteur, les portées, l’empreinte du contenu, la décision d’autorisation et le type causal de SrvAck. Il ne doit pas remplacer ces faits par une phrase plus ambitieuse comme « publié partout ».

Une connexion fiable n’abolit pas l’attente

Deux agents pairs maintiennent une connexion persistante, fiable et ordonnée pour l’ensemble de leurs portées communes. Cette propriété est utile : sur une connexion active, les messages ne deviennent pas une suite indifférenciée et désordonnée.

Mais « fiable » ne signifie pas « déjà livré ». La connexion peut tomber, la file peut progresser, la reconnaissance d’un pair peut changer et un échange de rattrapage peut devenir nécessaire. La qualité du transport ne transforme pas une future émission en réception passée.

Après la synchronisation initiale, l’agent accepteur transmet directement les nouvelles mises à jour à chacun de ses pairs concernés, jusqu’à une défaillance. Le modèle est à un saut : le pair ne relaie pas la même inscription dans une chaîne sans contrôle.

Les messages reçus d’un pair ne réclament d’ailleurs pas chacun un nouvel accusé applicatif, puisque la connexion apporte déjà ses garanties de transport. Cette économie ne doit pas être lue à l’envers : le SrvAck remis au Service Agent n’est pas l’accusé silencieux de tous les pairs.

Chaque origine garde son ordre propre

L’identifiant d’acceptation associe l’URL de l’agent accepteur et une estampille qu’il fait croître de façon monotone. Les mises à jour issues du même agent peuvent ainsi être propagées dans l’ordre de leur acceptation.

Le maillage ne possède pas pour autant une horloge totale. Deux agents accepteurs peuvent produire des mises à jour dont l’ordre relatif de propagation est libre. Leurs estampilles ne deviennent pas comparables par magie, car elles décrivent deux flux d’origine.

Une autre valeur, l’estampille de version attribuée par le Service Agent maillé, sert à départager les versions d’une même inscription. Le temps d’arrivée chez un pair ne suffit pas : une ancienne version retardée peut atteindre le destinataire après la plus récente.

Il faut donc garder trois axes. La version choisit l’état logique le plus récent. L’identifiant d’acceptation situe l’entrée et l’ordre dans un flux d’origine. L’observation d’une requête dit ce qu’un catalogue particulier voyait à un instant. Les fusionner retire précisément les indices nécessaires quand les réponses divergent.

Le protocole suppose qu’un seul agent de service modifie chaque inscription. Une plateforme qui autorise plusieurs auteurs ajoute son propre problème de concurrence; elle doit aussi ajouter une règle d’autorité et de résolution, au lieu de l’attribuer à RFC 3528.

Le vecteur de synthèse mesure une frontière de réception

Pour rattraper les écarts, chaque agent peut résumer ce qu’il a reçu. Le vecteur associe à chaque agent accepteur connu la dernière estampille d’acceptation observée. Plusieurs histoires ordonnées sont ainsi condensées en plusieurs frontières.

Un pair demande alors les états postérieurs à ces frontières. Dans une anti-entropie complète, les origines absentes de la requête sont également couvertes. Dans une requête sélective, seules les origines énumérées sont interrogées.

Cette nuance empêche une conclusion trop large. Une réconciliation sélective peut réussir parfaitement sans rien vérifier sur une origine omise. L’étiquette « synchronisé » doit donc indiquer la portée exacte de la demande.

Après l’envoi des états demandés, classés par identifiant d’acceptation, un SrvAck marque la fin du traitement de la demande d’anti-entropie. Ce reçu ne porte pas sur le même événement que l’accusé du dépôt initial. Même forme, objet différent.

Le vecteur ne garantit pas davantage la véracité d’un service. Il ne prouve ni que toutes les inscriptions sont encore valides, ni que chaque requête les retourne, ni que les adresses répondent. Il décrit ce qui a été reçu depuis plusieurs origines.

Le rattrapage transporte aussi l’âge

Une inscription envoyée pendant la récupération conserve sa durée de vie restante. Elle ne repart pas avec une durée complète. Sans cette règle, chaque réconciliation pourrait prolonger artificiellement une annonce périmée.

La suppression possède un état intermédiaire encore plus révélateur. Une désinscription est conservée comme état supprimé afin qu’une ancienne inscription, arrivée en retard, ne ressuscite pas le service. Cette pierre tombale disparaît lorsque l’inscription atteint son expiration.

« Suppression acceptée », « pierre tombale reçue par les pairs » et « état physiquement purgé » sont donc trois événements. Ils n’impliquent pas que tous les observateurs ont cessé de voir la fiche au même instant.

La preuve doit joindre l’identité de l’inscription, sa version, l’identifiant d’acceptation, le drapeau de suppression, le temps restant, le chemin de rattrapage et des observations de requête. Un statut sans lieu ni date efface la topologie qui lui donne son sens.

La portée fixe la fédération pertinente

Le maillage est défini par portée. Tous les agents maillés qui desservent une même portée forment un maillage complet; une connexion peut véhiculer les inscriptions de plusieurs portées partagées.

Un agent de service n’a pas nécessairement besoin de déposer chez tous. Il peut choisir assez d’agents pour que l’union de leurs portées couvre les siennes, puis compter sur la propagation. Cette optimisation renforce l’importance du suivi par pair.

Une acceptation sous une portée ne dit rien des agents qui n’en font pas partie. Un User Agent peut aussi choisir un autre catalogue ou formuler une requête sous une portée différente. Sa réponse ne contredit pas le reçu local; elle révèle un autre périmètre.

Le maillage complet vise la simplicité et la fiabilité, mais le RFC indique un ordre de grandeur de quelques dizaines d’agents ou moins, pas une extension sans limite. Il s’agit d’une caractéristique de conception, non d’une mesure d’un réseau actuel.

Scinder une portée en deux modifie les obligations d’inscription. Un service auparavant présent sous le parent peut devoir être inscrit sous les deux enfants. Une taxonomie d’exploitation n’est donc pas une simple étiquette éditoriale : elle peut changer la distribution et les résultats de recherche.

L’autorité d’écrire reste une décision de sécurité

mSLP réutilise l’authentification de SLPv2. Un MDA devrait authentifier ses pairs avant le peering, authentifier les MSA avant d’accepter et de diffuser leurs mises à jour, et un MSA devrait authentifier le MDA auquel il confie son état.

Ces décisions ne se remplacent pas. Une connexion TCP ordonnée ne certifie pas l’appartenance au maillage. Une signature techniquement valide ne décide pas à elle seule que sa clé peut publier ce service sous cette portée. Un message correctement formé ne prouve pas l’exactitude de ce qu’il annonce.

La compromission d’un seul MDA peut toucher tous les autres, puisque l’état se propage. Le mécanisme de disponibilité devient alors un multiplicateur de l’erreur d’autorité.

SLPv2 reconnaît aussi que le démarrage sans configuration de sécurité préalable peut exiger une forme de confiance aveugle. La distribution des clés et la politique de vérification restent donc des conditions du déploiement.

Le registre IANA attribue aujourd’hui l’identifiant d’extension SLPv2 0x0006 à Mesh-enhancement et renvoie à RFC 3528. Il garantit le sens public du numéro, pas l’implémentation, l’activation, la convergence ou la sécurité d’un système.

Être trouvé n’est pas encore fonctionner

L’écriture et la lecture suivent des chemins différents. L’agent de service écrit auprès d’un annuaire; l’utilisateur interroge plus tard un annuaire choisi selon ses propres règles de découverte et de portée.

La visibilité doit être mesurée depuis ces points de lecture. Le reçu de requête conserve l’identité de l’agent interrogé, les portées, le filtre, l’empreinte de la réponse, la version, le temps restant et l’heure d’observation.

Même une réponse correcte demeure une annonce. Elle ne prouve pas que le réseau mène à l’adresse, que le protocole applicatif répond, que l’utilisateur est autorisé ou que l’opération attendue réussit.

La chaîne continue donc par la résolution d’adresse éventuelle, la connexion, le dialogue propre au service, son contrôle de santé et le résultat pour l’utilisateur. L’annuaire indique où chercher; il ne remplace pas ce qui doit être trouvé.

Construire une chaîne au lieu d’un voyant

Le premier bloc documente les identités et pouvoirs : version du protocole, statut du RFC, définition des portées, identité de l’émetteur, justificatif, règle d’autorisation et décision. Il les lie à l’empreinte de la charge, à la version, à l’agent accepteur et à l’identifiant d’acceptation.

Le SrvAck initial reste un reçu local. Des reçus séparés décrivent ensuite chaque transmission, chaque pair authentifié, chaque portée commune et chaque frontière de synthèse. L’anti-entropie enregistre son caractère complet ou sélectif, le vecteur fourni, les états renvoyés et son propre accusé final.

Les observations de requête et de service ferment la chaîne. Chaque équipe atteste son domaine : les annuaires la réplication, la sécurité l’autorité, les propriétaires du service sa santé et les responsables applicatifs le résultat.

Un voyant global reste possible, à condition qu’il révèle la définition de son vert. « Accepté ici » est une information utile. Sous l’intitulé « disponible partout », la même couleur devient une déclaration sans preuve.

Limite des éléments probants

Cet Article ne vise aucun logiciel, fournisseur, opérateur, maillage, agent, service, terminal, inscription, déploiement, incident, panne, attaque ou résultat client. Il ne mesure ni adoption, ni taille de topologie, ni délai de propagation, ni disponibilité actuelle.

RFC 3528 est présenté comme un protocole Experimental d’avril 2003 et non comme une norme Internet. Les valeurs par défaut de 200 secondes pour le keepalive et 300 secondes pour le délai d’expiration proviennent du document; elles ne prouvent aucun réglage ni délai réel.

Les métadonnées et registres identifient des documents et des valeurs assignées. Ils ne certifient pas le comportement d’un code en exécution.

Les notes de Heng Lu sur l’autorité et le code en fonctionnement sont un angle éditorial déclaré. Elles invitent à borner un reçu à l’acte observé, sans établir l’intention de l’IETF ni un fait de déploiement.

La conclusion demeure précise : l’acceptation locale, la convergence, la visibilité et le résultat du service peuvent diverger sans rendre faux le premier accusé.

Sources