Résumé

  • La RFC 3082 permet à un user agent de s’abonner aux changements de service au lieu d’interroger sans cesse le réseau, avec deux conceptions selon la présence ou non de Directory Agents.
  • Après la disparition d’un DA, les service agents déjà avertis peuvent continuer d’émettre. Un nouveau service agent, lui, peut ne jamais recevoir l’abonnement : la continuité des anciennes notifications ne prouve donc pas que la couverture des nouveaux services a survécu.

Une requête n’est pas un flux

Le Service Location Protocol était fondé sur une logique à la demande : les service agents (SA) publiaient des services et les user agents (UA) les recherchaient lorsqu’ils en avaient besoin. Une application qui voulait voir immédiatement chaque apparition ou disparition devait donc interroger le réseau périodiquement. Publiée en mars 2001 comme protocole expérimental, la RFC 3082 proposait un flux d’événements pour éviter cette répétition. Elle ne constitue pas une norme Internet.

Passer d’une requête à l’écoute semble simple, jusqu’à la question du nouvel arrivant : qui lui indique qu’un UA écoute ? La RFC distingue les petits réseaux sans Directory Agent (DA) des réseaux plus grands où les DA administrent les abonnements. Ces deux topologies ne placent pas la même mémoire au même endroit.

Deux topologies, deux compromis

Sans DA, les SA diffusent leur enregistrement et leur désenregistrement en multicast IP — ou en broadcast IPv4 si le multicast est indisponible. Les UA reçoivent largement et filtrent eux-mêmes par type de service et portée. Aucun intermédiaire n’a besoin d’informer les nouveaux SA des abonnements ; en contrepartie, les récepteurs doivent traiter des annonces qui ne les concernent pas et le périmètre multicast compte.

Avec des DA, un UA joint une extension Subscribe à une requête de service. Le DA renvoie des groupes multicast NotifyAt correspondant au type de service et aux portées demandées. Il peut informer les SA déjà présents par une annonce DAAdvert. Lorsqu’un nouveau SA correspondant s’enregistre, son accusé SrvAck peut lui transmettre la même instruction. Le DA émet aussi un avis de désenregistrement lorsqu’une annonce expire sans arrêt ordonné. Les SA restent les principaux émetteurs des événements : le DA n’est pas un relais central de tout le flux.

Cette répartition évite qu’un seul agent supporte toute la charge, mais elle répartit aussi l’état. Le DA conserve les abonnements ; les SA déjà informés retiennent les groupes ; le UA rejoint ces groupes ; l’allocation et le bail d’adresse multicast forment encore un autre état. Pour limiter les annonces NotifyAt en double, le DA attend un délai aléatoire uniforme de zéro à trois secondes et écoute celles des autres DA. Ce mécanisme supprime les doublons : il ne réplique pas la table d’abonnements.

Ce qui disparaît, et ce qui continue

La section 10 décrit une panne partielle. Quand un DA disparaît de façon imprévue, les abonnements des UA qu’il détenait sont perdus. Les UA continuent pourtant à recevoir les notifications des SA existants, qui ont déjà reçu NotifyAt. En revanche, un nouveau SA ne sera pas informé de l’abonnement, sauf si un autre DA détient aussi cette information.

Le UA peut ne découvrir un DA de remplacement qu’à l’occasion d’une requête active. Un service peut donc s’enregistrer après la disparition de l’ancien DA mais avant que le UA ait découvert un remplaçant et renouvelé son abonnement. Le flux paraît vivant parce que les anciens services continuent d’apparaître ; le nouvel arrivant peut, lui, ne jamais y figurer.

La reprise prévue protège d’abord les émetteurs connus. Ils continuent jusqu’à l’expiration de l’abonnement ; s’il n’existe aucun autre DA, ils ignorent cette échéance et poursuivent leurs annonces jusqu’à la découverte d’un nouveau DA. Après s’y être enregistré, le SrvAck indique au SA si le UA a renouvelé son abonnement. Mais la RFC reconnaît une fenêtre résiduelle : les SA démarrant entre le redémarrage du DA et le renouvellement de l’abonnement par le UA ne sont toujours pas informés. Le UA qui veut recevoir l’avis de chaque nouveau service devrait s’abonner auprès de chaque nouveau DA qui prend en charge ses portées. Plusieurs machines ne donnent pas automatiquement une redondance d’état.

Une notification n’est pas un service accompli

Le reste du protocole impose la même prudence. Les annonces multicast sont répétées pendant quinze secondes avec un recul exponentiel. La RFC dit que cela augmente la probabilité qu’un message arrive, pas que sa livraison est garantie ou conservée dans un journal rejouable. Une liste d’attributs peut dépasser la taille UDP ; le bit de débordement signale alors qu’un UA pourra interroger ensuite le SA ou le DA pour compléter les informations.

Les blocs d’authentification décrits par la RFC permettent de vérifier une annonce, mais ne prouvent ni sa réception par chaque écouteur, ni la joignabilité actuelle de l’endpoint, ni le succès d’une opération applicative.

Il faut donc séparer l’abonnement du UA, l’état de portée et de type enregistré au DA, l’instruction NotifyAt reçue par un SA, l’adhésion au groupe multicast, l’émission de l’événement, sa réception, l’éventuelle requête de complément et l’échange de service lui-même. La spécification relie certaines étapes ; elle n’en fait pas un reçu de bout en bout.

Il n’y a pas de contradiction entre les deux parties du titre. La RFC 3082 ne dit pas que la disparition d’un DA coupe toutes les notifications : les SA existants peuvent continuer et un autre DA peut conserver une couverture. Elle dit quelque chose de plus précis : la continuité des émetteurs déjà informés n’équivaut pas à la couverture des émetteurs qui arrivent ensuite. Remplacer le polling par un flux déplace l’endroit où le réseau doit mémoriser qui écoute, et la reprise doit restaurer cette mémoire.

Sources

Texte et historique : RFC 3082, notice de l’éditeur RFC, historique Datatracker, RFC 2608 : SLPv2, RFC 2119, RFC 2373, RFC 2730 et RFC 2908. Repères éditoriaux seulement, sans valeur de preuve sur SLP : Lu Heng, Running-Code Primacy et On Reality Layers.