Résumé

  • Les RFC 1001 et 1002 confient l’enregistrement et la découverte des noms au NetBIOS Name Server (NBNS), tandis qu’un NetBIOS Datagram Distribution Server (NBDD) prend en charge la distribution des datagrammes de groupe.
  • Pour les nœuds P et M, une réponse positive du NBDD décrit sa volonté de relayer ; elle ne prouve pas que tous les destinataires ont reçu le datagramme. La norme admet aussi une distribution partielle ou refusée.

Sur un réseau local fondé sur la diffusion, l’émetteur peut viser un groupe sans convertir chaque membre en destination séparée. Dès que ce service traverse des réseaux routés, deux questions se détachent : qui connaît les membres du groupe et qui réplique le datagramme vers eux ? Les RFC 1001 et RFC 1002, publiées comme propositions en mars 1987, attribuent ces tâches à deux rôles logiques. Le point historique tient à leur séparation : un serveur de noms pouvait identifier les détenteurs d’un nom sans devenir, pour autant, le serveur qui distribuait le trafic.

Les textes distinguent les nœuds B, P et M. Le modèle B s’appuie sur une aire de diffusion ; P désigne une infrastructure point à point ; M combine des caractéristiques des deux. Pour un nœud P ou M, le datagramme destiné à un nom unique part directement vers l’adresse découverte. Un nom de groupe, ou le nom de diffusion NetBIOS, suit une autre voie : l’émetteur envoie le datagramme en unicast à un NBDD, chargé de le relayer aux nœuds associés au nom de destination. La diffusion IP n’est donc pas supposée fonctionner partout dans ce parcours.

Dans l’architecture, le NBNS et le NBDD sont deux entités distinctes, même si un même équipement peut assurer les deux rôles. S’ils sont séparés, la RFC 1001 permet un échange privé d’informations de nom entre eux, sans en spécifier le protocole. Ce détail crée une dépendance importante : le relais doit disposer d’informations suffisantes sur les détenteurs du groupe, mais le texte ne transforme pas cet échange privé en mécanisme interopérable ni en registre de résultat visible par l’émetteur.

Avant l’envoi, un nœud P ou M peut interroger le NBDD pour savoir s’il distribuera le datagramme à un nom donné. Une réponse positive signifie que le serveur annonce son intention de relayer. Une réponse négative ouvre une solution de repli : demander au NBNS la liste des détenteurs, puis envoyer un datagramme unicast à chacun d’eux. La requête est facultative. La RFC 1002 permet aussi d’envoyer directement le datagramme, au risque que le NBDD le supprime. Ces parcours expriment des choix de contrôle ; ils ne constituent pas des confirmations de livraison.

C’est après la requête que la limite probatoire apparaît. La RFC 1001 autorise le NBDD à achever la distribution, à ne l’achever qu’en partie ou à la refuser. Elle précise qu’au-delà de la requête, aucun retour n’indique à l’émetteur si le datagramme a été relayé. Une réponse positive sur la capacité du serveur n’est donc pas un reçu de diffusion. La spécification ne fournit ni reçu par destinataire ni preuve que chaque membre a vu le paquet. L’enregistrement d’un nom, pas plus qu’une réponse favorable, ne suffit à établir ce résultat.

Le contexte du multicast demande lui aussi une formulation précise. La RFC 1001 décrit un environnement où l’on ne pouvait pas présumer que chaque réseau et chaque nœud disposait d’une diffusion ou d’un multicast Internet utilisable ; son annexe esquisse une intégration avec Internet Group Multicasting. Cela ne signifie pas que le multicast IP n’avait jamais été proposé : la RFC 988, publiée en juillet 1986, avait déjà décrit plusieurs niveaux de prise en charge du multicast hôte. La conclusion plus étroite est que le dispositif NetBIOS ne pouvait pas compter sur un service multicast universel.

Les deux RFC se présentent comme des propositions de norme. Elles décrivent une conception, pas le déploiement par un réseau déterminé, l’uniformité des implémentations ou la réception effective par les applications. La RFC 1001 laisse également les activités des nœuds B hors du champ de vision des serveurs de soutien NBNS/NBDD et ne demande pas à ces serveurs de faire pont vers eux. Les rôles sont définis plus nettement que la preuve d’un résultat de bout en bout.

Le périmètre distingue aussi cet article de la RFC 1088, consacrée à la dérivation locale d’un nom NetBIOS à partir d’une adresse IP et à la table des noms ; associer un nom à une adresse et distribuer un datagramme de groupe répondent à deux questions différentes. Cette distinction dépasse NetBIOS : découvrir un ensemble de destinations, confier le relais à un serveur, transmettre des paquets et constater leur réception sont des événements différents. Dans la proposition de 1987, les échanges de contrôle renseignent les premiers choix ; ils ne rendent pas la remise complète observable par l’émetteur.