Protocole standard pour un service NetBIOS sur un transport TCP/UDP : concepts et méthodes

Résumé
La présente RFC définit une proposition de protocole standard pour la prise en charge des services NetBIOS dans un environnement TCP/IP. Le fonctionnement en réseau local et sur internet sont tous deux pris en charge. Divers types de nœud sont définis pour s’accommoder des topologies locale et internet et permettre le fonctionnement avec ou sans l’utilisation de la diffusion IP.

La présente RFC décrit les protocoles NetBIOS sur TCP d’une manière générale, en développant les idées et techniques sous jacentes. Des spécifications se trouvent dans la RFC 1002, "Protocole standard pour un service NetBIOS sur un transport TCP/UDP : Spécifications détaillées".

Table des matières

1. Statut du présent mémoire
2. Remerciements
3. Introduction
4 Principes de conception
4.1 Préservation des services NetBIOS
4.2 Utilisation des normes existantes
4.3 Minimiser les options
4.4 Tolérer les erreurs et les perturbations
4.5 Ne pas exiger de gestion centralisée
4.6 Permettre le fonctionnement sur Internet
4.7 Minimiser l’activité de diffusion
4.8 Permettre la mise en œuvre sur les systèmes existants
4.9 Exiger seulement le minimum nécessaire pour fonctionner
4.10 Maximiser l’efficacité
4.11 Minimiser les nouvelles inventions
5 Généralités sur NetBIOS
5.1 Interface avec les programmes d’application
5.2 Service de nom
5.3 Service de session
5.4 Service de datagrammes
5.5 Fonctions diverses
5.6 Extensions non-standard
6 Facilités NetBIOS acceptées par la présente norme
7 Interfaces et définitions requises pour la prise en charge du service
8 Protocoles et services concernés
9 Domaine d’application de NetBIOS
10 Nœuds d’extrémité NetBIOS
10.1 Nœuds de diffusion (B)
10.2 Nœuds en point à point (P)
10.3 Nœuds en mode mixte (M)
11 Serveurs de soutien à NetBIOS
11.1 Nœuds de serveur de nom NetBIOS (NBNS)
11.2 Nœuds de serveur de distribution de datagrammes NetBIOS (NBDD)
11.3 Relation des nœuds NBNS et NBDD
11.4 Relations entre les serveurs de soutien NetBIOS et les nœuds B
12 Topologies
12.1 Local
12.2 Internet
13 Méthodes générales
13.1 Style d’interaction demande/réponse
13.2 Transactions
13.3 Fondations TCP et UDP
14 Représentation des noms NetBIOS
14.1 Codage de premier niveau
14.2 Codage de second niveau
15 Service de nom NetBIOS
15.1 Vue générale du service de nom NetBIOS
15.2 Transactions d’enregistrement du nom
15.3 Transactions d’interrogation de nom
15.4 Transactions de livraison de nom
15.5 Transactions de maintenance de nom
15.6 Transactions d’état d’adaptateur
16 Service de session NetBIOS
16.1 Généralités sur le service de session NetBIOS
16.2 Phase d’établissement de session
16.3 Phase de transfert de données de session
17 Service de datagrammes NetBIOS
17.1 Généralités sur le service de datagrammes NetBIOS .
17.2 Datagrammes NetBIOS par des nœuds B
17.3 Datagrammes NetBIOS sur des nœuds P et M
18 Paramètres de configuration de nœuds
19 Conformité minimale
Références
Appendice A Intégration avec la diffusion groupée internet
A-1. Protocole supplémentaire exigé dans les nœuds B et M
A-2. Contraintes
Appendice B
B-1. Modèles de mise en œuvre
B-2 Applications NetBIOS casuelles et interdites
B-3 TCP contre les KEEP-ALIVE de session
B-4 Algorithmes de reciblage
B-5 Service NBDD
B-6 Considérations pour l’application

1. Statut du présent mémoire

La présente RFC spécifie une proposition de norme pour la communauté Internet. Comme ce sujet est nouveau pour la communauté Internet, des discussions et suggestions sont spécifiquement demandées.

Prière d’envoyer les commentaires écrits à :
Karl Auerbach
Epilogue Technology Corporation
P.O. Box 5432
Redwood City, CA 94063

Prière d’envoyer les commentaires en ligne à :
Avnish Aggarwal
Internet : mtxinu!excelan!avnish@ucbvax.berkeley.edu
Usenet : ucbvax!mtxinu!excelan!avnish

La distribution du présent document n’est soumise à aucune restriction.

2. Remerciements

La présente RFC a été développée sous les auspices du Bureau des activités de l’Internet, et tout spécialement du groupe de travail pour les services de bout en bout (End-to-End Services Task Force).

Les individus suivants ont contribué au développement de la présente RFC :

Le système proposé par cette RFC ne reflète aucune mise en œuvre Netbios sur TCP existante. Cependant, sa conception incorpore des connaissances considérables obtenues à partir des mises en œuvre précédentes. Des remerciements particuliers vont aux organisations suivantes, qui nous ont fourni ces informations sans prix :

CMC/Syros, Excelan, Sytek, Ungermann-Bass.

3. Introduction

La présente RFC décrit les idées et les méthodes générales utilisées pour fournir NetBIOS sur un fondement TCP et UDP. La RFC 1002, "Protocole standard pour un service NetBIOS sur un transport TCP/UDP : Spécifications détaillées" [1] contient les descriptions détaillées des formats de paquet, des protocoles, et définit les constantes et les variables.

Le service NetBIOS est devenu le mécanisme dominant pour la mise en réseau des ordinateurs individuels. NetBIOS fournit une interface indépendante des fabricants pour les micro-ordinateurs (PC) IBM et les systèmes compatibles.

NetBIOS définit une interface logicielle et non un protocole. Il n’y a pas de norme de service NetBIOS "officielle". En pratique cependant, la version IBM PC-réseau est utilisée comme référence. Cette version est décrite dans le document IBM 6322916, "Technical Reference PC Network"[2].

Les protocoles qui prennent en charge les services NetBIOS ont été construits sur la base de divers protocoles et matériels. Même lorsqu’ils s’appuient sur des fondations identiques, différentes mises en œuvre peuvent n’être pas capables d’interopérer si elles n’utilisent pas un protocole commun. Pour permettre l’interfonctionnement NetBIOS dans l’Internet, la présente RFC définit un protocole standard pour la prise en charge des services NetBIOS utilisant TCP et UDP.

NetBIOS a généralement été confiné jusqu’à aujourd’hui aux ordinateurs individuels. Cependant, comme de plus gros ordinateurs conviennent souvent bien pour certaines applications NetBIOS, tels les serveurs de fichiers, la présente spécification a été conçue pour permettre qu’une mise en œuvre soit construite sur virtuellement tout type de système où la suite de protocole TCP/IP est disponible.

La présente norme définit un ensemble de protocoles pour la prise en charge des services NetBIOS.

Ces rotocoles sont plus qu’un simple service de communications impliquant deux entités. La présent note décrit plutôt un système réparti dans lequel de nombreuses entités jouent un rôle même si elles ne sont pas impliquées comme point d’extrémité d’une connexion NetBIOS particulière.

La présente norme ne constitue pas une contrainte ni ne détermine comment ces services sont présentés aux programmes d’application.

Néanmoins, il est prévu que sur les ordinateurs qui fonctionnent sous système d’exploitation PC-DOS et MS-DOS, l’interface NetBIOS existante sera préservée par les mises en œuvre.

NOTE : Diverses valeurs symboliques sont utilisées dans le présent document. Pour leurs définitions, se référer aux spécifications détaillées [1].

4 Principes de conception

Pour les besoins du développement de la spécification, les principes de conception suivants ont été adoptés pour guider l’effort. La plupart sont normaux dans tout effort de normalisation d’un protocole ; cependant, certains ont été affectés de priorités qui peuvent être considérées comme inhabituelles.

4.1 Préservation des services NetBIOS

En l’absence d’une norme "officielle" des services NetBIOS, on utilise la version qui se trouve dans la référence technique de réseau de micro ordinateurs d’IBM [2].

NetBIOS est le résultat d’un large corps d’applications existantes. Il est souhaitable de faire fonctionner ces applications sur des réseaux TCP et, au delà des ordinateurs individuels, de les étendre à de plus grands hôtes. Pour prendre en charge ces applications, NetBIOS sur TCP doit se conformer étroitement aux services offerts par les systèmes NetBIOS existants.

Le NetBIOS des micro ordinateurs en réseau IBM contient des caractéristiques spécifiques de la mise en œuvre. La présente norme n’essaye pas de les préserver entièrement. Il est vraisemblable que certains des logiciels existants exigent ces caractéristiques et vont échouer à fonctionner correctement sur un service NetBIOS fondé sur la présente RFC.

4.2 Utilisation des normes existantes

Le développement d’un protocole, en particulier normalisé, est un processus exigeant. Le développement de nouveaux protocoles doit être réduit au minimum.

Il est considéré comme essentiel qu’une norme existante qui fournit les fonctionnalités nécessaires avec des performances raisonnables soit toujours choisie de préférence au développement d’un nouveau protocole.

Lorsqu’un protocole standard est utilisé, il doit l’être sans changement.

4.3 Minimiser les options

La norme pour NetBIOS sur TCP devrait ne contenir que peu d’options, et si possible, aucune.

Lorsque des options sont incluses, les options devraient être conçues de telle sorte que les appareils avec des choix d’options différents puissent interopérer.

4.4 Tolérer les erreurs et les perturbations

Les réseaux NetBIOS fonctionnent normalement dans un environnement non contrôlé. Les ordinateurs viennent en ligne à des moments arbitraires. Les ordinateurs quittent le réseau sans en avertir leurs homologues. Le logiciel est souvent utilisé par des usagers qui ne sont pas familiers des réseaux et peuvent perturber de façon aléatoire des réglages de configuration.

En dépit de ce chaos, les réseaux NetBIOS fonctionnent. NetBIOS sur TCP doit aussi être capable de bien fonctionner dans cet environnement.

Un fonctionnement robuste ne signifie pas nécessairement que le réseau est à l’épreuve de toutes les perturbations. Un réseau NetBIOS normal peut être perturbé par certains types de comportement, par inadvertance ou malveillance.

4.5 Ne pas exiger de gestion centralisée

NetBIOS sur TCP devrait être capable de fonctionner, si on le désire, sans gestion centralisée au delà de ce qui est normalement exigé d’un réseau fondé sur TCP.

4.6 Permettre le fonctionnement sur Internet

La norme proposée reconnaît le besoin de fonctionnement de NetBIOS à travers un ensemble de réseaux interconnectés par des relais (passerelles) de niveau réseau (IP).

Cependant, la norme suppose que cette forme de fonctionnement sera moins fréquente que sur le LAN ponté MAC local.

4.7 Minimiser l’activité de diffusion

La norme présuppose que les seuls services de diffusion sont ceux pris en charge par UDP. Les capacités de diffusion groupée ne sont supposées disponibles sous aucune forme.

En dépit de la disponibilité de capacités de diffusion, la norme reconnaît que certaines administrations peuvent souhaiter éviter des activités lourdes de diffusion. Par exemple, une administration peut souhaiter éviter que des hôtes isolés non participants ne subissent le fardeau de la réception et l’élimination des diffusions NetBIOS.

4.8 Permettre la mise en œuvre sur les systèmes existants

Il devrait être possible de mettre en œuvre le protocole NetBIOS sur TCP sur les systèmes d’exploitation courants, tels que Unix(tm) et VAX/VMS(tm), sans efforts disproportionnés.

Les protocoles NetBIOS ne devraient pas exiger de services normalement indisponibles sur les mises en œuvre TCP/UDP/IP actuellement existantes.

4.9 Exiger seulement le minimum nécessaire pour fonctionner

La définition du protocole ne devrait spécifier que l’ensemble minimal des protocoles requis pour l’interopération. Cependant, des éléments de protocole additionnels peuvent être définis pour améliorer l’efficacité. Ces derniers éléments peuvent être générés en option pour l’envoyeur, bien qu’ils doivent être acceptés par tous les receveurs.

4.10 Maximiser l’efficacité

Pour être utile, un protocole doit faire son travail rapidement.

4.11 Minimiser les nouvelles inventions

Lorsqu’un protocole existant n’est pas capable de prendre en charge une fonction nécessaire, mais qu’avec quelques petites modifications, il le pourrait, ce protocole devrait être utilisé. Il semble qu’il est plus facile de les réaliser que de développer de nouveaux protocoles ; de plus, il est estimé que c’est plus conforme à l’intérêt général de l’Internet.

5 Généralités sur NetBIOS

La présente section décrit les services NetBIOS. Dans un but d’information générale, le lecteur peut choisir de sauter cette section.

NetBIOS a été conçu pour l’utilisation par des groupes de micro ordinateurs partageant un support de diffusion. Les services de connexion (session) et sans connexion (datagramme) sont fournis, et la diffusion ainsi que la diffusion groupée sont prises en charge. Les participants sont identifiés par le nom. L’allocation des noms est répartie et très dynamique.

Les applications NetBIOS emploient les mécanismes de NetBIOS pour localiser les ressources, établir les connexions, envoyer et recevoir des données avec une application homologue, et mettre un terme aux connexions. Pour les besoins de l’exposé, ces mécanismes seront appelés collectivement le service NetBIOS.

Ce service peut être mis en œuvre de nombreuses façons différentes. Une des premières mises en œuvre était pour les ordinateurs individuels fonctionnant sous les systèmes d’exploitation PC-DOS et MS-DOS. Il est possible de mettre en œuvre NetBIOS au sein d’autres systèmes d’exploitation, ou comme des processus qui sont eux-mêmes simplement des programmes d’application pour autant que le système d’exploitation de l’hôte soit concerné.

La spécification NetBIOS, publiée par IBM sous le titre "Technical Reference PC Network"[2] définit l’interface et les services disponibles pour l’utilisateur de NetBIOS. Les protocoles exposés dans ce document n’appartiennent qu’au réseau de PC d’IBM et ne sont pas applicables en général aux autres réseaux.

5.1 Interface avec les programmes d’application

NetBIOS sur les ordinateurs individuels inclut à la fois un ensemble de services et une interface de programme exacte avec ces services. NetBIOS sur d’autres systèmes d’ordinateurs peut présenter les services NetBIOS à des programmes utilisant d’autres interfaces. Excepté sur les ordinateurs individuels, aucune norme claire n’a émergé pour une interface de logiciel NetBIOS.

5.2 Service de nom

Les ressources NetBIOS sont référencées par le nom . Les informations d’adresse de niveau inférieur ne sont pas disponibles pour les applications NetBIOS. Une application, représentant une ressource, enregistre un ou plusieurs noms qu’elle souhaite utiliser.

L’espace de nom est plat et utilise seize caractères alphanumériques. Les noms ne peuvent pas commencer par un astérisque (*).

L’enregistrement est une enchère pour l’utilisation d’un nom. L’enchère peut être pour la propriété exclusive (unique) ou partagée (en groupe). Chaque application est en compétition avec les autres applications en temps réel. Une permission implicite est accordée à une station lorsqu’elle ne reçoit pas d’objections. C’est-à-dire qu’une enchère est faite et l’application attend pendant un certain temps. Si aucune objection n’est reçue, la station suppose qu’elle a la permission.

Un nom unique devrait être détenu seulement par une station à la fois. Cependant, des duplications ("conflits de nom") peuvent survenir du fait d’erreurs.

Toutes les instances d’un nom de groupe sont équivalentes.

Une application qui fait référence à un nom ne sait généralement pas (ou ne s’en soucie pas) si le nom est enregistré comme nom unique ou nom de groupe.

Une fonction explicite de suppression de nom est spécifiée, de sorte que les applications puissent retirer un nom. Une suppression implicite de nom survient lorsque une station cesse de fonctionner. Dans le cas des ordinateurs individuels, la suppression implicite des noms survient fréquemment.

Les primitives du service de nom sont :

1) Ajouter un nom (Add Name)
L’application demanderesse veut l’utilisation exclusive du nom.

2) Ajouter un nom de groupe (Add Group Name)
L’application demanderesse veut partager l’utilisation du nom avec d’autres applications.

3) Supprimer le nom (Delete Name)
L’application n’exige plus l’utilisation du nom. Il est important de noter que l’utilisation normale de NetBIOS est par des ordinateurs individuels fonctionnant de façon indépendante. Une façon courante d’arrêter l’utilisation d’un PC est de couper l’alimentation ; dans ce cas, le mécanisme de récupération fourni par la fonction de suppression du nom n’est pas utilisé. Comme cela arrive fréquemment, le service réseau doit prendre en charge ce comportement.

5.3 Service de session

Une session est un échange fiable de messages, conduit entre une paire d’applications NetBIOS. Les sessions sont bidirectionnelles, en séquence, et fiables. Les données sont organisées en messages. Chaque message peut aller d’une taille de 0 à 131 071 octets. Aucune capacité d’accélérer les données ou de données urgentes n’est présente.

Plusieurs sessions peuvent exister entre toute paire de noms appelants et appelés.

Les parties à une connexion ont accès aux noms d’appelant et d’appelé.

La spécification NetBIOS ne définit pas comment une demande de connexion à un nom partagé (de groupe) se résout en une session. L’hypothèse habituelle est qu’une session peut être établie avec n’importe lequel des propriétaires du nom de groupe appelé.

Un service important fourni aux applications NetBIOS est la détection des échecs de sessions. La perte d’une session est rapportée à une application via toutes les demandes de service en cours pour cette session. Par exemple, si l’application a seulement une primitive de réception NetBIOS en cours et que la session se termine, la réception en cours va s’interrompre avec une indication de terminaison.

Les primitives du service de session sont :

1) Appel (Call)
Initie une session avec un processus qui écoute sous le nom spécifié. L’entité appelante doit indiquer à la fois un nom appelant (correctement enregistré chez l’appelant) et un nom appelé.

2) Écoute (Listen)
Accepter une session de la part d’un appelant. La primitive écoute peut être contrainte d’accepter un appel entrant de la part d’un appelant désigné. Autrement, un appel de n’importe quel appelant peut être accepté.

3) Raccroche (Hang Up)
Termine une session en douceur. Toutes les données en instance sont transférées avant l’achèvement de la session.

4) Envoi (Send)
Transmet un message. Une temporisation peut avoir lieu. L’expiration de temporisation de toute session force la terminaison brutale de la session. Une primitive "chaîne envoyée" est exigée par l’interface logicielle NetBIOS de PC pour permettre qu’un seul message soit collecté de morceaux répartis dans diverses mémoires tampon. Chaîne envoyée est un détail d’interface qui n’affecte pas le protocole.

5) Recevoir (Receive)
Reçoit les données. Une temporisation peut survenir. L’expiration de temporisation sur une réception de session termine seulement la réception, et non la session, bien que les données soient perdues.

La primitive Recevoir peut être mise en œuvre avec des variantes, telles que "Recevoir tout", qui est requise par l’interface logicielle NetBIOS de PC. Recevoir tout est un détail d’interface qui n’affecte pas le protocole.

6) État de session (Session Status)
Obtient des informations sur toutes les sessions du demandeur, sous le nom spécifié. Aucune activité réseau n’est impliquée.

5.4 Service de datagrammes

Le service de datagrammes est non fiable, non séquencé et sans connexion. Les datagrammes sont envoyés sous un nom correctement enregistré auprès de l’envoyeur.

Les datagrammes peuvent être envoyés à un nom spécifique ou peuvent être explicitement diffusés.

Les datagrammes envoyés à un nom exclusif sont reçus, s’ils le sont par le détenteur de ce nom. Les datagrammes envoyés à un nom de groupe sont diffusés en groupe à tous les détenteurs de ce nom. Le programme d’application expéditeur ne peut pas distinguer entre un nom de groupe et un nom unique et doit donc agir comme si tous les datagrammes non en diffusion étaient en diffusion groupée.

Comme avec le service de session, le receveur du datagramme est tenu au courant des noms d’envoi et de réception.

Les primitives du service de datagrammes sont :

1) Envoi de datagramme (Send Datagram)
Envoie un datagramme non fiable à une application qui est associée au nom spécifié. Le nom peut être unique ou de groupe ; l’envoyeur n’est pas au courant de la différence. Si le nom appartient à un groupe, chaque membre va recevoir le datagramme.

2) Envoi d’un datagramme de diffusion (Send Broadcast Datagram)
Envoie un datagramme non fiable à toute application qui affiche un Recevoir les datagrammes en diffusion.

3) Recevoir les datagrammes (Receive Datagram)
Reçoit un datagramme envoyé d’un nom d’origine spécifié au nom spécifié. Si le nom d’origine est un astérisque, le datagramme peut alors avoir été généré sous n’importe quel nom.

Note : Un datagramme en arrivée sera délivré à tous les Recevoir les datagrammes en cours qui ont des spécifications de source et de destination correspondant à celles du datagramme. En d’autres termes, si un programme (ou groupe de programmes) produit une série de Recevoir les datagrammes identiques, un datagramme causera l’achèvement de toute la série.

4) Recevoir les datagrammes en diffusion (Receive Broadcast Datagram)
Reçoit un datagramme envoyé comme diffusion.

Si il y a plusieurs opérations de Recevoir les datagrammes en diffusion en instance, toutes seront satisfaites par le même datagramme reçu.

5.5 Fonctions diverses

Les fonctions suivantes sont présentes pour contrôler le fonctionnement de l’interface matérielle avec le réseau. Ces fonctions dépendent généralement de la mise en œuvre.

1) Rétablir (Reset)
Initialise l’adaptateur de réseau local.

2) Annuler (Cancel)
Interrompt une demande NetBIOS. L’annulation réussie d’une opération Envoi (ou Chaîne envoyée) terminera la session associée

3) État de l’adaptateur (Adapter Status)
Obtient des informations sur l’adaptateur de réseau local ou d’un adaptateur distant.

4) Délier (Unlink)
Pour une utilisation avec la charge de programme distant (RPL, Remote Program Load). Délier redirige le disque d’amorçage du PC vers le disque local. Voir la spécification NetBIOS pour des détails complémentaires concernant RPL et l’opération Unlink (voir la page 2-35 de [2]).

5) Charge de programme distant (Remote Program Load)
Charge de programme distant (RPL) n’est pas une fonction NetBIOS. C’est une application NetBIOS définie par IBM dans sa spécification NetBIOS (voir les pages 2-80 à 2-82 de [2]).

5.6 Extensions non standard

La mise en œuvre d’anneau à jetons d’IBM de NetBIOS a ajouté au moins une nouvelle capacité d’utilisateur :

1) Trouver le nom (Find Name)
Cette fonction détermine si un nom donné a été enregistré sur le réseau.

6 Facilités NetBIOS acceptées par la présente norme

Le protocole spécifié par la présente norme permet à une mise en œuvre de fournir tous les services NetBIOS décrits dans le document IBM "Technical Reference PC Network"[2].

Les facilités NetBIOS suivantes sortent du domaine d’application de la présente spécification. C’est l’affaire des mises en œuvre locales et elles n’ont pas d’impact sur l’interopérabilité :
- RESET
- SESSION STATUS
- UNLINK
- RPL (Remote Program Load)

7 Interfaces et définitions requises pour la prise en charge du service

Les protocoles décrits dans la présente RFC exigent les interfaces de service pour :
- TCP [3,4]
- UDP [5]

Les conventions d’ordre des octets et d’adressage (y compris les adresses à utiliser pour les diffusions et diffusions groupées) sont définies dans la plus récente version de Numéros alloués [6].

Des définitions et contraintes supplémentaires figurent dans :
- IP [7]
- Sous-réseaux Internet [8, 9, 10]

8 Protocoles et services concernés

La conception des protocoles décrits dans la présente RFC permet l’incorporation future des protocoles et services suivants. Cependant, avant que cela puisse survenir, certaines extensions aux protocoles définis dans la présente RFC ou à ceux dont la liste figure ci-dessus pourraient être requises.

- Service de nom de domaine [11, 12, 13, 14]
- Diffusion groupée sur Internet [15, 16]

9 Domaine d’application de NetBIOS

Le "domaine d’application de NetBIOS" est la population des ordinateurs parmi lesquels est connu un nom NetBIOS enregistré. Les opérations de datagramme en diffusion et diffusion groupée NetBIOS doivent couvrir la totalité du domaine d’application de NetBIOS.

Un internet peut prendre en charge plusieurs domaines d’application NetBIOS, qui ne se recoupent pas.

Chaque domaine d’application NetBIOS a un "identifiant de domaine d’application". Cet identifiant est une chaîne de caractères satisfaisant aux exigences du système de noms de domaine pour les noms de domaines.

NOTE : Chaque mise en œuvre de NetBIOS sur TCP doit fournir des mécanismes pour la gestion du ou des identifiants de domaine d’application à utiliser.

Le contrôle des identifiants de domaine d’application implique l’exigence de capacités d’interface NetBIOS supplémentaires. Celles-ci peuvent être fournies par des extensions à l’interface de service d’utilisateur ou d’autres moyens (tels que des paramètres de configuration de nœud). La nature de ces extensions ne fait pas partie de la présente spécification.

10 Nœuds d’extrémité NetBIOS

Les nœuds d’extrémité prennent en charge les interfaces de service NetBIOS et contiennent les applications.

Trois types de nœuds d’extrémité sont pris en compte par la présente norme :
- Nœuds de diffusion ("B", Broadcast)
- Nœuds en point à point ("P")
- Nœuds en mode mixte ("M")

Une adresse IP peut être associée à une seule instance de l’un des trois types ci-dessus.

N’ayant pas de tableaux préchargés de correspondance nom/adresse, les participants NetBIOS sont confrontés à la tâche de résolution dynamique d’une référence en une autre. Cela peut être réalisé avec des communications en diffusion ou par l’entremise d’un point à point.

Les nœuds B utilisent la diffusion de réseau local pour effectuer un rendez-vous avec un ou plusieurs receveurs. Les nœuds P et M utilisent le serveur de nom NetBIOS (NBNS) et le serveur de distribution de datagrammes NetBIOS (NBDD) dans ce même but.

Les nœuds d’extrémité peuvent être combinés dans diverses topologies. Quelle que soit la façon dont ils sont combinés, le fonctionnement des nœuds B, P, et M n’est pas altérée.

NOTE : Il est recommandé que l’administration d’un domaine d’application NetBIOS évite d’utiliser les nœuds M et B au sein du même domaine d’application. Un domaine d’application NetBIOS devrait contenir seulement des nœuds B ou seulement des nœuds P et M.

10.1 Nœuds de diffusion (B)

Les nœuds de diffusion (ou "B") communiquent en utilisant un mélange de datagrammes UDP (à la fois diffusés et dirigés) et de connexions TCP. Les nœuds B peuvent interopérer librement les uns avec les autres au sein d’une zone de diffusion. Une zone de diffusion est un seul "LAN B" à MAC ponté . (Voir à l’Appendice A un exposé sur l’utilisation de la diffusion groupée sur Internet comme moyen d’étendre une zone de diffusion au delà d’un seul LAN B.)

10.2 Nœuds en point à point (P)

Les nœuds en point à point (ou "P") communiquent en utilisant seulement des datagrammes UDP dirigés et des sessions TCP. Les nœuds P ne génèrent ni n’écoutent de paquets UDP en diffusion. Les nœuds P offrent cependant des services de diffusion et de diffusion groupée de niveau NetBIOS en utilisant les capacités fournies par le NBNS et le NBDD.

Les nœuds P s’appuient sur le nom NetBIOS et les serveurs de distribution de datagrammes. Ces serveurs peuvent être locaux ou distants ; les nœud P fonctionnent de la même façon dans les deux cas.

10.3 Nœuds en mode mixte (M)

Les nœuds en mode mixte (ou "M") sont des nœuds P auxquels ont été données certaines caractéristiques de nœud B. Les nœuds M utilisent à la fois la diffusion et l’envoi individuel. La diffusion est utilisée pour améliorer les temps de réponse dans l’hypothèse que la plupart des ressources résident sur le support de diffusion local plutôt que quelque part sur un internet.

Les nœuds M s’appuient sur les serveurs NBNS et NBDD. Cependant, les nœuds M peuvent continuer en fonctionnement limité si ces serveurs sont temporairement indisponibles.

11 Serveurs de soutien à NetBIOS

Deux types de serveurs de soutien sont prévus dans la présente norme :
- les nœuds de serveurs de nom NetBIOS ou "NBNS"
- les nœuds de distribution de datagrammes NetBIOS ou "NBDD"

Les nœuds NBNS et NBDD sont invisibles aux applications NetBIOS et font partie du mécanisme NetBIOS sous jacent.

Les serveurs de nom et de distribution de datagramme NetBIOS sont le point focal de l’activité de nom et de datagramme pour les nœuds P et M.

Il est permis aussi bien aux serveurs de nom (NBNS) et aux serveurs de distribution de datagrammes (NBDD) de déplacer une partie de leur fonctionnement aux nœuds d’extrémité P ou M qui demandent un service.

Comme l’allocation des responsabilités est dynamique, et comme les nœuds P et M doivent être prêts à fonctionner même si le serveur NetBIOS délègue le contrôle autant qu’il est possible, le système s’accommode naturellement des améliorations de la fonction de serveur NetBIOS. Par exemple, à mesure que se répand la diffusion groupée sur Internet, de nouvelles mises en œuvre de NBDD peuvent choisir d’assurer la pleine responsabilité de la distribution des datagrammes NetBIOS.

L’interopérabilité entre différentes mises en œuvre est assurée en imposant l’exigence que les mises en œuvre de point d’extrémité soient capables d’accepter la gamme complète des réponses légales provenant du NBNS ou du NBDD.

11.1 Nœuds de serveur de nom NetBIOS (NBNS)

Le NBNS est conçu pour permettre une grande souplesse avec une responsabilité graduée dans la précision de la gestion des noms NetBIOS. D’un côté, le NBNS peut choisir de ne pas accepter la responsabilité complète, lui laissant le rôle de feuille d’enregistrement sur laquelle les nœuds P et M inscrivent (et suppriment) librement les informations de nom/adresse sans validation par le NBNS. Autrement, le NBNS peut choisir de gérer et valider complètement les noms. Le degré de responsabilité que le NBNS assume est affirmé par le NBNS chaque fois qu’un nom est revendiqué par un mécanisme simple. Si le NBNS ne devait pas affirmer le plein contrôle, il retournerait suffisamment d’informations au nœud demandeur pour que celui-ci puisse se confronter à tout autre compétiteur pour la détention du nom.

Cette capacité à déplacer la responsabilité de la gestion des noms NetBIOS entre le NBNS et les nœuds P et M permet à un administrateur (ou fabricant) de réseau de faire un compromis entre les caractéristiques de simplicité, de sécurité, et de délai du NBNS.

Un seul NBNS peut être mis en œuvre comme une entité répartie, comme le service de nom de domaine. Cependant, la présente RFC ne cherche pas à définir les communications internes qui devraient être utilisées.

11.1.1 Relations du NBNS avec le système de nom de domaine

La conception du NBNS essaye de s’aligner sur celle du système de nom de domaine d’un certain nombre de façons.

D’abord, les noms NetBIOS sont codés dans une forme acceptable pour le système de nom de domaine.

Ensuite, un identifiant de domaine d’application est ajouté à chaque nom NetBIOS. Cet identifiant satisfait aux restrictions du jeu de caractères du système de domaine et commence par un point. Cela fait du nom NetBIOS, en conjonction avec son identifiant de domaine d’application, un nom de système de domaine valide.

Troisièmement, le mécanisme de responsabilité négociée permet d’utiliser le NBNS comme une simple feuille d’enregistrement sur laquelle sont inscrites des paires (nom, adresse). Ce mécanisme est parallèle au service d’interrogation du système de domaine existant.

La présente RFC exige cependant que le NBNS fournisse des services au-delà de ceux fournis par le système de nom de domaine actuel. Il a été fait une tentative pour regrouper tous les services supplémentaires requis en un ensemble de transactions qui suivent les styles d’interaction et de formats de paquet du système de nom de domaine.

Les zones dans lesquelles le service de nom de domaine est à étendre pour qu’il puisse être utilisé comme un NBNS sont :
- l’ajout dynamique des entrées
- la mise à jour dynamique des données d’entrée
- la prise en charge de plusieurs instances d’entrées (un groupe)
- la prise en charge de valeurs de durée de vie d’entrées et la capacité à accepter des messages de rafraîchissement pour redémarrer la période de durée de vie.
- de nouveaux attributs d’entrées.

11.2 Nœuds de serveur de distribution de datagrammes NetBIOS (NBDD)

L’internet ne prend pas encore en charge la diffusion ou la diffusion groupée. Le NBDD étend le service de distribution de datagramme NetBIOS à cet environnement.

Le NBDD peut choisir d’achever, d’achever partiellement, ou de refuser totalement de servir la demande d’un nœud de distribuer un datagramme NetBIOS. Un nœud d’extrémité peut demander à un NBDD de déterminer si le NBDD va délivrer un datagramme à un nom NetBIOS spécifique.

Le concept de NetBIOS sur TCP conduit par lui-même à l’utilisation de la diffusion groupée sur Internet. Voir les précisions à l’Appendice A.

11.3 Relation des nœuds NBNS et NBDD

La présente RFC définit les NBNS et les NBDD comme des entités distinctes, séparées.

En l’absence des informations de nom NetBIOS, un serveur de distribution de datagrammes NetBIOS doit envoyer une copie à chaque nœud d’extrémité au sein du domaine d’application NetBIOS.

Une mise en œuvre peut choisir de construire des nœuds NBNS et NBDD qui ont un protocole privé pour l’échange des informations de nom NetBIOS. Autrement, un NBNS et un NBDD peuvent être mis en œuvre au sein du même appareil.

NOTE : Les mises en œuvre qui contiennent des protocoles NBNS-NBDD privés ou des fonctions NBNS-NBDD combinées doivent être clairement identifiés.

11.4 Relations entre les serveurs de soutien NetBIOS et les nœuds B

Comme défini dans la présente RFC, ni les nœuds NBNS ni les nœuds NBDD n’interagissent avec les nœuds B. Les serveurs NetBIOS n’écoutent pas le trafic de diffusion sur les zones de diffusion auxquelles ils peuvent être attachés. Pas plus que les serveurs de soutien NetBIOS ne sont même au courant des activités des nœuds B ou des noms revendiqués ou utilisés par les nœuds B.

Il est possible d’étendre à la fois le NBNS et le NBDD de sorte qu’ils participent aux activités du nœud B et agissent comme pont pour les nœuds P et M. Cependant, de telles extensions sortent du domaine d’application de la présente spécification.

12 Topologies

Les nœuds B, P, M, NBNS, et NBDD peuvent être combinés de diverses façons pour former d’utiles environnements NetBIOS. La présente section décrit certaines de ces combinaisons.

Il y a trois classes de fonctionnement :

- Classe 0 : nœuds B seulement.

- Classe 1 : nœuds P seulement.

- Classe 2 : nœuds P et M ensemble.

Dans les schémas qui suivent, tout nœud P peut être remplacé par un nœud M. Les effets d’un tel remplacement seront mentionnés avec chacun des exemples qui suivent.

12.1 Local

Un domaine d’application NetBIOS fonctionne localement quand toutes les entités sont au sein de la même zone de diffusion.

12.1.1 N œuds B seulement

Le fonctionnement local avec seulement des nœuds B est le mode de fonctionnement de base. L’enregistrement des noms et les procédures de découverte utilisent les mécanismes de diffusion. Le domaine d’application NetBIOS est limité par l’extension de la zone de diffusion. Cette configuration n’exige pas de serveur de soutien NetBIOS.

12.1.2 N œuds P seulement

Cette configuration sera normalement utilisée lorsque l’administrateur de réseau désire éliminer NetBIOS comme source d’activité de diffusion.

Cette configuration fonctionne de la même façon que si il y avait un internet et elle n’est citée ici que comme moyen pratique de réduire l’utilisation de la diffusion.

Le remplacement d’un ou plusieurs nœuds P par des nœuds M n’affectera pas le fonctionnement des autres nœuds P et M. Les nœuds P et M seront capables d’interagir les uns avec les autres. Comme les nœuds M utilisent la diffusion, l’activité globale de diffusion va augmenter.

12.1.3 N œuds B et P mêlés

Les nœuds B et P n’interagissent pas les uns avec les autres. Le remplacement des nœuds P par des nœuds M permettra aux B et aux M d’interagir.

NOTE : Les nœuds B et les nœuds M peuvent être entremêlés sur une zone locale de diffusion. Les nœuds B et M ne devraient pas être entremêlés dans un environnement d’internet.

12.2 Internet

12.2.1 Nœuds P seulement

Les nœuds P peuvent être éparpillés dans les diverses localisations d’un interréseau.

Ils ont besoin d’un NBNS et d’un NBDD pour respectivement le nom NetBIOS et la prise en charge des datagrammes.

Le domaine d’application NetBIOS est déterminé par l’identifiant de domaine d’application NetBIOS (nom de domaine) utilisé par les divers nœuds P (et M). Un internet peut contenir de nombreux domaines d’application NetBIOS.

Tout nœud P peut être remplacé par un nœud M sans perte de fonction sur aucun nœud. Cependant, l’activité de diffusion sera augmentée dans la zone de diffusion à laquelle le n œud M est rattaché.

12.2.2 Nœuds M et P mêlés

Les nœuds M et P peuvent être mélangés. Lors de la localisation des noms NetBIOS, les nœuds M tendront à trouver les noms détenus par les autres nœuds M sur la même zone de diffusion commune de préférence aux noms détenus pas les nœuds P ou M ailleurs dans le réseau.

NOTE : Les nœuds B et M ne devraient pas être mélangés dans un environnement d’internet. Le faire permettrait que surviennent des conflits indétectés de noms NetBIOS causant des comportements imprévisibles.

13 Méthodes générales

Au-dessus des protocoles spécifiques, décrits plus loin, existent quelques méthodes générales d’interaction entre les entités.

13.1 Style d’interaction demande/réponse

La plupart des interactions entre les entités consistent en flux de demandes dans une direction et en flux de réponses qui en résultent dans la direction opposée.

Dans ces situations où les interactions surviennent sur des transports non fiables (c’est à dire UDP) ou quand une demande est en diffusion, il ne peut pas y avoir un verrouillage strict ou une relation biunivoque entre demandes et réponses.

En aucun cas, cependant, il n’y a plus d’une réponse générée pour une demande reçue. Alors qu’une réponse est en cours, l’entité qui répond peut envoyer un ou plusieurs accusés de réception d’attente.

13.1.1 Retransmission des demandes

UDP est un mécanisme de livraison non fiable dans lequel les paquets peuvent être perdus, reçus hors de la séquence d’émission, dupliqués, et la livraison peut être significativement retardée. Comme les protocoles NetBIOS font une grosse utilisation d’UDP, ils ont compensé son manque de fiabilité par des mécanismes supplémentaires.

Chaque paquet NetBIOS contient toutes les informations nécessaires pour le traiter. Aucun des protocoles n’utilise plusieurs paquets UDP pour porter une seule demande ou réponse. Si plus d’informations sont nécessaires que ce qui tiendrait dans un seul paquet UDP, par exemple, quand un nœud de type P veut obtenir d’un serveur NetBIOS tous les détenteurs d’un nom de groupe, il utilise une connexion TCP. Par conséquent, les protocoles NetBIOS n’échoueront pas à cause de la livraison de paquets UDP hors séquence.

Pour surmonter la perte d’un paquet de demande ou de réponse, chaque opération de demande va retransmettre la demande si une réponse n’est pas reçue dans un délai spécifié.

Les opérations de protocole sensibles à la réussite des paquets de réponse, comme la détection des conflits de noms, sont protégées contre la duplication des paquets parce qu’elles ignorent les paquets successifs qui portent les mêmes informations NetBIOS. Comme aucun état n’est associé à une demande sur le nœud de celui qui répond, il envoie simplement la réponse appropriée chaque fois qu’arrive un paquet de demande. Par conséquent, les paquets de demande dupliqués ou retardés n’ont pas d’impact.

Pour toutes les demandes, si un paquet de réponse est retardé trop longtemps, un autre paquet de demande sera transmis. Un second paquet de réponse envoyé en réponse au second paquet de demande est équivalent à un paquet dupliqué. Les protocoles vont donc ignorer le second paquet reçu. Si la livraison d’une réponse est retardée jusqu’après la fin de l’opération de réponse, réussite ou échec, le paquet de réponse est ignoré.

13.1.2 Demandes sans réponses : instructions

Certains types de demande n’ont pas de réponse correspondante. Ces demandes sont appelées "instructions". En général, une "instruction" est une demande impérative ; le nœud qui la reçoit est censé obéir. Cependant, comme les instructions sont sans confirmation, elles ne sont utilisées que dans des situations où, au plus, des dommages limités résulteraient de la perte du paquet d’instructions.

Les paquets d’instructions ne sont pas retransmis.

13.2 Transactions

Les interactions entre une paire d’entités sont groupées en "transactions". Ces transactions comprennent une ou plusieurs paires de demande/réponse.

13.2.1 Identifiant de transaction

Comme plusieurs transactions simultanées peuvent être en cours entre une paire d’entités, un "identifiant de transaction" est utilisé.

Celui qui est à l’origine d’une transaction choisit un identifiant (ID) univoque pour lui. L’identifiant de transaction est réfléchi en va et vient à chaque interaction au sein de la transaction. Les partenaires à la transaction doivent faire correspondre réponses et demandes en comparant l’identifiant de transaction et l’adresse IP du partenaire à la transaction. Si aucune demande correspondante ne peut être trouvée, la réponse doit être éliminée.

Un nouvel identifiant de transaction devrait être utilisé pour chaque transaction. Un simple compteur de transaction de 16 bits devrait être un générateur d’identifiants adéquat. Il n’est probablement pas nécessaire de rechercher l’espace d’identifiant de transaction en instance pour filtrer les duplications : il est extrêmement peu vraisemblable qu’aucune transaction ait une durée de vie qui dépasse une toute petite fraction du cycle périodique d’un compteur normal. L’utilisation des adresses IP en conjonction avec l’identifiant de transaction réduit encore la possibilité de dommages pour le cas où des identifiants de transaction seraient prématurément réutilisés.

13.3 Fondations TCP et UDP

La présente version des protocoles NetBIOS sur TCP utilise UDP pour de nombreuses interactions. La présente RFC pourra être étendue à l’avenir pour permettre que surviennent de telles interactions sur des connexions TCP (peut-être pour accroître l’efficacité lorsque plusieurs interactions surviennent dans un court laps de temps ou quand du trafic de datagrammes NetBIOS révèle qu’une application est en train d’utiliser les datagrammes NetBIOS pour la prise en charge d’un service orienté connexion.)

14 Représentation des noms NetBIOS

Les noms NetBIOS tels que vus à travers l’interface client avec NetBIOS sont longs d’exactement 16 octets. Au sein des protocoles NetBIOS sur TCP, on utilise une représentation plus longue.

Il y a deux niveaux de codage. Le premier niveau transpose un nom NetBIOS en un nom du système de domaines. Le second niveau transpose le nom du système de domaines en une représentation "compressée" requise pour l’interaction avec le système de nom de domaine.

Sauf dans un paquet, la représentation de second niveau est la seule représentation de nom NetBIOS utilisée dans les formats de paquet NetBIOS sur TCP. L’exception est le champ RDATA d’un paquet de réponse d’état de nœud.

14.1 Codage de premier ni veau

La représentation de premier niveau comporte deux parties :
- le nom NetBIOS
- l’identifiant de domaine d’application NetBIOS

Le nom NetBIOS de 16 octets est transposé en un champ de 32 octets de large à l’aide d’un codage biaisé réversible, semi-ASCII. Chaque demi octet du nom NetBIOS est codé en un octet du champ de 32 octets. La première moitié de l’octet est codée dans le premier octet, la seconde moitié dans le second octet, etc.

Chaque demi octet de quatre bits du nom NetBIOS est traité comme un nombre binaire de 8 bits, ajusté à droite, bourré avec des zéros. Ce nombre est ajouté à la valeur du caractère ASCII 'A' (hexadécimal 41). Le nombre de 8 bits résultant est mémorisé dans l’octet approprié. Le diagramme suivant montre cette procédure :

Ce codage a pour résultat qu’un nom NetBIOS est représenté comme une séquence de 32 caractères ASCII majuscules de l’ensemble {A,B,C...N,O,P}.

L’identifiant de domaine d’application NetBIOS est un nom de domaine valide (sans point en tête).

Un point ASCII (2E hexadécimal) et l’identifiant de domaine d’application sont ajoutés à la forme codée du nom NetBIOS, le résultat formant un nom de domaine valide.

Par exemple, le nom NetBIOS "The NetBIOS name" dans le domaine d’application NetBIOS "SCOPE.ID.COM" serait représenté au niveau un par la chaîne de caractères ASCII :

FEGHGFCAEOGFHEECEJEPFDCAHEGBGNGF.SCOPE.ID.COM

14.2 Codage de second niveau

Le codage de premier niveau doit être réduit en codage de second niveau. Ceci est effectué conformément aux règles définies à la page 31 de la RFC 883 [12] au paragraphe sur la "représentation et compression des noms de domaine". Voir aussi le paragraphe intitulé "Formats des noms" dans les Spécifications détaillées [1].

15 Service de nom NetBIOS

Avant qu’un nom puisse être utilisé, il doit être enregistré par un nœud. Une fois acquis, le nom doit être défendu contre un enregistrement contradictoire par d’autres nœuds. Avant de construire une session NetBIOS ou d’envoyer un datagramme NetBIOS, le ou les détenteurs du nom doivent être localisés.

Le service de nom NetBIOS est la collection des procédures à travers lesquelles les nœuds acquièrent, défendent, et localisent les détenteurs des noms NetBIOS.

Les procédures du service de nom sont différentes selon que le nœud d’extrémité est du type B, P, ou M.

15.1 Vue générale du service de nom NetBIOS

15.1.1 Enregistrement de nom (revendication)

Chaque nœud NetBIOS peut posséder plus d’un nom. Les noms sont acquis de façon dynamique grâce aux procédures d’enregistrement (revendication de nom).

Chaque nœud a un nom permanent unique. Ce nom, comme tout autre nom, doit être explicitement enregistré par tous les types de nœud d’extrémité.

Un nom peut être unique (exclusif) ou de groupe (non exclusif). Un nom unique peut être possédé par un seul nœud ; un nom de groupe peut être possédé par un nombre quelconque de nœuds. Un nom cesse d’exister lorsqu’il n’est plus possédé par un seul nœud. Aucune qualité intrinsèque d’un nom ne détermine ses caractéristiques : celles-ci sont établies au moment de l’enregistrement.

Chaque nœud entretient les informations d’état pour chaque nom qu’il a enregistré. Ces informations comportent :
- si le nom est un nom de groupe ou un nom unique
- si le nom est "en conflit"
- si le nom est en cours de suppression

Les nœuds B effectuent l’enregistrement du nom en diffusant des demandes de revendication, invitant à une défense de la part de tout nœud déjà détenteur du nom.

Les nœuds P effectuent l’enregistrement du nom par l’intermédiaire du NBNS.

Les nœuds M enregistrent les noms grâce à une diffusion initiale, comme les nœuds B, puis, en l’absence d’objection, en suivant les mêmes procédures que les nœuds P. En d’autres termes, l’action de diffusion peut terminer la tentative, mais n’est pas suffisante pour confirmer l’enregistrement.

15.1.2 Interrogation du nom (découverte)

L’interrogation du nom (appelée aussi "résolution" ou "découverte") est la procédure par laquelle la ou les adresses IP associées à un nom NetBIOS sont découvertes. L’interrogation du nom est requise durant les opérations suivantes :

Durant l’établissement de session, les noms appelant et appelé doivent être spécifiés. Le nom appelant doit exister sur le nœud qui envoie l’appel (qui envoie un CALL). Le nom appelé doit exister sur un nœud qui a précédemment envoyé un LISTEN. Chaque nom peut être un nom unique ou un nom de groupe.

Lorsqu’un datagramme dirigé est envoyé, des noms de source et de destination doivent être spécifiés. Si le nom de destination est un nom de groupe, un datagramme est envoyé à tous les membres de ce groupe.

Différents types de nœud d’extrémité effectuent une résolution du nom en utilisant différentes techniques, mais avec les mêmes formats de paquet :
- les nœuds B sollicitent les informations de nom en diffusant une demande.
- les nœuds P demandent au NBNS.
- les nœuds M diffusent une demande. Si cela ne fournit pas les informations désirées, une enquête est envoyée au NBNS.

15.1.3 Libération du nom

Les noms NetBIOS peuvent être libérés explicitement ou silencieusement par un nœud d’extrémité.

La libération silencieuse survient normalement lorsqu’un nœud d’extrémité échoue ou est coupé. La plupart des mécanismes décrits ci-après sont présents pour détecter la libération silencieuse du nom.

15.1.3.1 Libération explicite

Les nœuds B libèrent explicitement un nom en diffusant une notice.

Les nœuds P envoient une notification à leur NBNS.

Les nœuds M diffusent une notice et informent leur NBNS de soutien.

15.1.3.2 Durée de vie et rafraîchissement du nom

Les noms détenus par un NBNS reçoivent une durée de vie pendant l’enregistrement du nom. Le NBNS considèrera qu’un nom a été livré en silence si le nœud d’extrémité échoue à envoyer un message de rafraîchissement de nom au NBNS avant l’expiration de la durée de vie. Un rafraîchissement redémarre l’horloge de durée de vie.

NOTE : Les développeurs doivent être conscients du compromis à établir entre la précision de la base de données et la redondance internet qu’introduit le mécanisme de rafraîchissement. La période de durée de vie devrait être réglée en conséquence.

Pour les noms de groupe, chaque nœud d’extrémité doit envoyer des messages de rafraîchissement. Un nœud qui manque à le faire sera considéré comme ayant libéré silencieusement le nom et sera sorti du groupe.

La période de durée de vie est établie par un simple mécanisme de négociation durant l’enregistrement du nom. Dans la demande d’enregistrement du nom, le nœud d’extrémité propose une valeur de durée de vie ou demande une durée de vie infinie. Le NBNS place une durée de vie réelle dans la réponse à l’enregistrement du nom. Le NBNS est toujours autorisé à répondre par une période réelle infinie. Si le nœud d’extrémité a proposé une durée de vie infinie, le NBNS peut répondre par toute période définie. Si le nœud d’extrémité a proposé une période définie, le NBNS peut répondre par toute période définie supérieure ou égale à celle proposée.

Cette négociation des temps de rafraîchissement donne au NBNS le moyen de désactiver ou d’activer l’activité de rafraîchissement. Les nœuds d’extrémité peuvent établir une période minimum de cycle de rafraîchissement.

Les mises en œuvre de NBNS qui sont complètement fiables peuvent désactiver le rafraîchissement.

15.1.3.3 Mise en cause du nom

Pour détecter si un nœud a libéré silencieusement sa revendication sur un nom, il est nécessaire de mettre en cause occasionnellement la propriété actuelle de ce nœud. Si le nœud défend le nom, il lui est permis de continuer à la posséder. Autrement, on suppose que le nœud a libéré le nom.

Une mise en cause de nom peut être produite par un NBNS ou par un nœud P ou M. Une mise en cause peut être dirigée vers tout type de nœud d’extrémité : B, P, ou M.

15.1.3.4 Effacement de nom de groupe

Les groupes NetBIOS peuvent contenir un nombre de membres quelconque. Le temps pour mettre en cause tous les membres pourrait être assez long.

Pour éviter de longs délais lorsque des noms sont revendiqués à travers un NBNS, on a adopté une heuristique optimiste. Il est supposé qu’il va toujours y avoir un nœud qui va défendre un nom de groupe. Par conséquent, il est recommandé que le NBNS rejette immédiatement une demande revendiquant un nom unique lorsqu’il existe déjà un groupe avec le même nom. Le NBNS ne retournera jamais une adresse IP (en réponse à Demande d’enregistrement de nom) lorsque un nom de groupe existe.

Un NBNS considèrera qu’un groupe a progressivement cessé son existence lorsque le dernier membre restant manque à envoyer à temps un message de rafraîchissement ou libère explicitement le nom.

15.1.3.5 Conflit de nom

Un conflit de nom existe lorsque un nom unique a été revendiqué par plus d’un nœud sur un réseau NetBIOS. Les nœuds B, M, et NBNS peuvent détecter un conflit de nom. Le mécanisme de détection utilisé par les nœuds B et M n’est actif que durant la découverte de nom. Le NBNS peut détecter un conflit à tout moment lorsqu’il vérifie la cohérence de sa base de données de noms.

Les nœuds B et M détectent le conflit en examinant les réponses reçues à une demande d’interrogation de nom diffusée. La première réponse est considérée comme une autorisation. Toute réponse ultérieure non cohérente représente un conflit.

Les réponses suivantes sont non cohérentes avec la réponse d’autorisation lorsque :
les réponses suivantes ont le même identifiant de transaction que la demande d’interrogation du nom, et
les réponses suivantes ne sont pas un duplicata de la réponse d’autorisation, et que : soit
la caractéristique groupe/unique de la réponse d’autorisation est "unique", soit
la caractéristique groupe/unique de la réponse suivante est "unique".

La période pendant laquelle les nœuds B et M examinent les réponses est limitée par un temporisateur de conflit, CONFLICT_TIMER. La précision ou la durée de ce temporisateur n’a pas un caractère crucial : le système NetBIOS continuera de fonctionner même avec la persistance de conflits de nom.

Les conditions de conflit sont signalées par l’envoi d’une NAME CONFLICT DEMAND (instruction de conflit de nom) au nœud possesseur d’un nom en cause. Rien n’est envoyé au nœud qui est à l’origine de la réponse d’autorisation.

Tout nœud d’extrémité qui reçoit une NAME CONFLICT DEMAND est invité à mettre à jour son "tableau local de nom" pour refléter que le nom est en conflit. (Le "tableau local de nom" contient sur chaque nœud les noms dont l’enregistrement a été réussi par ce nœud.)

Remarquer que ce sont seulement les nœud qui reçoivent le message de conflit de nom qui placent une marque de conflit à côté d’un nom.

Logiquement, un nom marqué n’existe pas sur ce nœud. Cela signifie que le nœud ne devrait pas défendre le nom (pour les besoins de la revendication de nom), ne devrait pas répondre à une demande de découverte de nom pour ce nom, ni envoyer de messages de rafraîchissement pour ce nom. De plus, il ne peut plus être utilisé par ce nœud pour tout établissement de session ou envoi ou réception de datagrammes. Les sessions existantes ne sont pas affectées au moment où un nom est marqué comme étant en conflit.

La seule fonction d’utilisateur valide contre un nom marqué est DELETE NAME (supprimer le nom). Toute autre fonction d’utilisateur NetBIOS retournera immédiatement un code d’erreur "CONFLIT DE NOM".

15.1.4 Adapter l’état

Un nœud d’extrémité, ou le NBNS, peut demander à tout autre nœud d’extrémité une collecte d’informations sur l’état NetBIOS de ce nœud. Cet état comporte, entre autres choses, une liste des noms que le nœud croit détenir. L’état retourné est filtré pour ne contenir que les noms qui ont le même identifiant de domaine d’application NetBIOS que le nom du demandeur.

Lors de la demande d’état d’un nœud, le demandeur identifie le nœud cible par le nom NetBIOS. Une transaction d’interrogation de nom peut être nécessaire pour acquérir l’adresse IP pour le nom. Les informations de nom qui sont en mémoire cache locale peuvent être utilisées à la place de la transaction d’interrogation. Le nœud demandeur envoie une NODE STATUS REQUEST (demande d’état de nœud). En réponse, le nœud de réception envoie une NODE STATUS RESPONSE (réponse d’état de nœud) contenant son tableau de noms local et diverses statistiques.

La quantité d’états qui peuvent être retournés est limitée par la taille d’un paquet UDP. Cependant, c’est suffisant pour le paquet Réponse d’état de nœud normal.

15.1.5 Interaction entre nœud d’extrémité et NBNS

Il y a certaines caractéristiques des interactions entre nœud d’extrémité et NBNS qui sont communes et sont indépendantes de tout type de transaction particulier.

15.1.5.1 UDP, TCP, et troncature

Pour toutes les transactions entre un nœud d’extrémité et un NBNS, UDP ou TCP peuvent être utilisés comme transport. Si le NBNS reçoit une demande fondée sur UDP, il va répondre en utilisant UDP. Si la quantité d’informations excède ce qui tient dans un paquet UDP, la réponse contiendra un "fanion de troncature". Dans cette situation, le nœud d’extrémité peut ouvrir une connexion TCP avec le NBNS, répéter la demande, et recevoir une réponse complète, non tronquée.

15.1.5.2 WACK NBNS

Pendant qu’une demande de service de nom est en cours, le NBNS peut produire un WAIT FOR ACKNOWLEDGEMENT RESPONSE (WACK, attente de réponse d’accusé de réception) pour assurer au nœud d’extrémité client que le NBNS est toujours opérationnel et travaille toujours sur la demande.

15.1.5.3 Redirection NBNS

Il est permis au NBNS, parce qu’il suit les styles d’interaction du système de nom de domaines, de rediriger un client sur un autre NBNS.

15.1.6 NBNS sécurisé contre NBNS non sécurisé

Un NBNS peut être mis en œuvre de deux façons : le NBNS peut surveiller, et participer à l’activité de nom pour assurer la cohérence. Ce pourrait être un style NBNS "sécurisé". Autrement, un NBNS peut être mis en œuvre comme étant essentiellement un "bulletin d’enregistrement" sur lequel les informations de nom sont inscrites et la responsabilité de la cohérence est déléguée aux nœuds d’extrémité. Ceci serait un style de NBNS "non sécurisé".

15.1.7 Cohérence de la base de données du NBNS

Même dans un domaine d’application NetBIOS qui fonctionne correctement, le NBNS et sa communauté de nœuds d’extrémité peut à l’occasion perdre la synchronisation par rapport au véritable état des enregistrements de nom.

Cela peut survenir si le NBNS a une défaillance et perd tout ou partie de sa base de données.

De façon plus courante, un nœud P ou M peut être éteint (oubliant ainsi les noms qu’il a enregistré) et ensuite rallumé.

Finalement, des erreurs peuvent survenir, ou une mise en œuvre peut être incorrecte.

Diverses approches ont été incorporées dans les protocoles NetBIOS sur TCP pour minimiser l’impact de ces problèmes.

1. Le NBNS (ou tout autre nœud) peut "mettre au défi" (en utilisant une Demande d’interrogation du nom) un nœud d’extrémité de vérifier qu’il possède réellement un nom.

Un tel défi peut survenir à tout moment. Chaque nœud d’extrémité doit être prêt à faire une réponse à temps.

Le manque à répondre amène le NBNS à considérer que le nœud d’extrémité a libéré le nom en question.

(Si UDP est utilisé comme transport sous-jacent, le défi, comme toutes les autres demandes, doit être retransmis un certain nombre de fois en l’absence de réponse.)

2. Le NBNS (ou tout autre nœud) peut demander (en utilisant la Demande d’état de nœud) qu’un nœud d’extrémité livre son tableau de noms tout entier.

Ceci peut survenir à tout moment. Chaque nœud d’extrémité doit être prêt à faire une réponse à temps.

Le manque à répondre permet (mais n’exige pas) que le NBNS considère que le nœud d’extrémité est défaillant et libère tous les noms pour lesquels il avait des revendications (Comme pour le défi, sur un transport UDP, la demande doit être retransmise en l’absence de réponse.)

3. Le NBNS peut révoquer l’utilisation d’un nom par un nœud P ou M en envoyant une Demande de conflit de nom ou une Demande de libération de nom au nœud.

Le nœud d’extrémité qui reçoit peut continuer les sessions existantes qui utilisent ce nom, mais doit autrement cesser d’utiliser ce nom. Si le NBNS a placé le nom en conflit, le nom ne peut être réacquis que par suppression et réclamation ultérieure. Si le NBNS a demandé que le nom soit libéré, le nœud peut tenter de réacquérir le nom sans effectuer d’abord une transaction de libération de nom.

4. Le NBNS peut imposer une "durée de vie" à chaque nom qu’il enregistre. Le mode d’enregistrement est tenu au courant de cette valeur de durée pendant la procédure d’enregistrement de nom.

Les NBNS simples ou fiables peuvent imposer une durée de vie infinie.

5. Si un nœud d’extrémité détient des noms qui ont des valeurs finies de durée de vie, il doit alors envoyer périodiquement un rapport d’état au NBNS. Chaque nom est rapporté en utilisant le paquet NAME REFRESH REQUEST (demande de rafraîchissement de nom).

Ces rapports d’état font redémarrer les temporisateurs aussi bien du NBNS et que du nœud qui fait rapport. Cependant, les seuls temporisateurs qui sont redémarrés sont ceux associés au nom qui se trouve dans le rapport d’état. Les temporisateurs sur les autres noms ne sont pas affectés.

Le NBNS peut considérer qu’un nœud a libéré tout nom qui n’a pas été rafraîchi pendant un certain nombre de multiples de la durée de vie du nom.

Un NBNS au bon comportement produirait cependant un défi, ou demanderait une liste des noms au nœud d’extrémité qui ne fait pas de rapport avant de supprimer son ou ses noms. L’absence de réponse, ou de nom dans une réponse, confirmera au NBNS la décision de supprimer un nom.

6. L’absence de rapport peut amener le NBNS à penser que le nœud d’extrémité est défaillant. De même, la réception d’informations largement divergentes de ce que croit le NBNS au sujet du nœud, peut amener le NBNS à considérer que le nœud d’extrémité a été redémarré.

Le NBNS peut analyser la situation avec des défis ou des demandes de liste des noms.

7. Un NBNS très prudent a toute liberté pour interroger les nœuds (en envoyant des paquets Demande d’interrogation du nom ou Demande d’état de nœud) pour vérifier que leur état de nom est le même que celui enregistré dans le NBNS.

NOTE : Une telle activité d’interrogation, si elle est utilisée par une mise en œuvre, devrait être gardée à un très bas niveau et activée seulement pendant des périodes où le NBNS a des raisons de suspecter que sa base d’informations est inappropriée.

8. Les nœuds P et M peuvent détecter des informations de nom incorrectes à l’établissement de session.

Si des informations incorrectes sont trouvées, le NBNS est informé via une NAME RELEASE REQUEST (demande de libération de nom) générée par le nœud d’extrémité qui détecte l’erreur.

15.1.8 Mise en mémoire cache de nom

Un nœud d’extrémité peut conserver en mémoire cache locale les entrées de traduction des noms NetBIOS en adresses IP.

Toutes les entrées de mémoire cache devraient être nettoyées de façon périodique.

De plus, un nœud devrait vider toutes les informations de mémoire cache associées à une adresse IP si le nœud reçoit des informations indiquant qu’il pourrait y avoir une possibilité de problème avec le nœud à cette adresse IP. Par exemple, si une DEMANDE DE CONFLIT DE NŒUD est envoyée à un nœud, toutes les informations en mémoire cache sur ce nœud devraient être vidées au sein du nœud d’envoi.

15.2 Transactions d’enregistrement du nom

15.2.1 Enregistrement du nom par les nœuds B

Une transaction de revendication de nom initiée par un nœud B est diffusée dans toute la zone de diffusion. La demande NAME REGISTRATION REQUEST sera entendue par tous les nœuds B et M dans la zone. Chaque nœud examine la revendication pour voir si elle est cohérente avec les noms qu’il possède. Si il y a une incohérence, une réponse NEGATIVE NAME REGISTRATION RESPONSE (réponse négative d’enregistrement de nom) est envoyée en envoi individuel au demandeur. Le nœud demandeur obtient la possession du nom (ou l’adhésion au groupe) si, et seulement si, aucune Réponse négative d’enregistrement de nom n’est reçue dans le délai de la temporisation de revendication de nom, CONFLICT_TIMER. (Voir la valeur de ce temporisateur dans "Constantes et variables définies" dans la spécification détaillée.)

Un nœud B proclame sa nouvelle possession en diffusant un message NAME OVERWRITE DEMAND (instruction de substitution de nom).

La demande d’enregistrement de nom, comme toutes les demandes, doit être répétée si aucune réponse n’est reçue dans le délai BCAST_REQ_RETRY_TIMEOUT. La transmission de la demande est tentée BCAST_REQ_RETRY_COUNT fois.

15.2.2 Enregistrement du nom par les nœuds P

Un enregistrement de nom peut se faire de diverses façons selon que le nom à enregistrer est ou non nouveau pour le NBNS. Si le nom est connu du NBNS, des défis peuvent être envoyés aux détenteurs précédents.

15.2.2.1 Nouveau nom, ou nouveau membre du groupe

Le diagramme ci-dessous montre la séquence des événements lorsqu’un nœud d’extrémité enregistre un nom qui est nouveau pour le NBNS. (Le diagramme omet les WACK, les redirections de NBNS, et les retransmissions de demandes.)

La même interaction surviendra si le nom à enregistrer est un nom de groupe et que le groupe existe déjà. Le NBNS ajoutera celui qui s’enregistre à l’ensemble des membres du groupe.

L’interaction est assez simple : le nœud d’extrémité envoie une Demande d’enregistrement de nom, le NBNS répond par une Réponse positive d’enregistrement de nom.

15.2.2.2 Nom existant et propriétaire toujours actif

Le diagramme qui suit montre les interactions quand est faite une tentative d’enregistrement d’un nom unique, le NBNS est au courant de l’existence d’un détenteur, et ce détenteur existant est toujours actif.

Le diagramme a deux côtés. Le côté gauche montre comment un NBNS non sécurisé traiterait la question. L’activité du NBNS sécurisé est montrée sur le côté droit.

Un NBNS non sécurisé répondra à la Demande d’enregistrement de nom par une Réponse d’enregistrement de mise en cause de nœud d’extrémité. Cette réponse demande au nœud d’extrémité de produire une transaction de mise en cause contre le nœud indiqué dans la réponse. Dans ce cas, le nœud précédent se défendra contre la mise en cause et le nœud d’extrémité qui veut enregistrer va simplement abandonner la tentative d’enregistrement sans autre interaction avec le NBNS.

Un NBNS sécurisé va s’abstenir de répondre à la Demande d’enregistrement de nom jusqu’à ce que le NBNS ait lui-même mis en cause le ou les précédents détenteurs du nom. Dans ce cas, le NBNS trouvera que le nom est encore défendu et va en conséquence retourner une Réponse négative d’enregistrement de nom à celui qui veut l’enregistrer.

Du fait du délai potentiel nécessaire au NBNS sécurisé pour effectuer la ou les mises en cause, il est vraisemblable qu’un WACK sera envoyé par le NBNS à celui qui veut enregistrer.

Bien que cela ne soit pas montré sur le diagramme, un NBNS non sécurisé va envoyer une Réponse négative d’enregistrement de nom à une demande d’enregistrer un nom unique lorsqu’il existe déjà un groupe du même nom. Un NBNS sécurisé peut choisir d’interroger (ou de mettre en cause) les membres du groupe pour déterminer s’il reste des membres actifs. Cela peut imposer une lourde charge au réseau. Il est recommandé que les noms de groupe soient autorisés à s’effacer par le mécanisme de rafraîchissement du nom.

15.2.2.3 Nom existant et propriétaire inactif

Le diagramme ci-après montre les interactions lorsque est faite une tentative d’enregistrement d’un nom unique. Le NBNS est au courant de l’existence d’un possesseur et que ce possesseur existant n’est plus actif.

Un NBNS non sécurisé va répondre à la Demande d’enregistrement de nom par une Réponse d’enregistrement de mise en cause de nœud d’extrémité. Cette réponse demande au nœud d’extrémité de produire une transaction de mise en cause contre le nœud indiqué dans la réponse. Dans ce cas, le nœud précédent ne se défendra pas contre la mise en cause. Celui qui veut enregistrer va informer le NBNS au moyen d’une Demande de substitution de nom. Le NBNS va remplacer les informations de nom précédentes de sa base de données par les informations contenues dans la demande de substitution.

Un NBNS sécurisé s’abstiendra de répondre à la Demande d’enregistrement de nom jusqu’à ce qu’il ait lui-même mis en cause le ou les détenteurs précédents du nom. Dans ce cas, le NBNS trouve que le nom n’est pas défendu et retourne par conséquent une Réponse positive d’enregistrement de nom à celui qui enregistre.

Du fait du délai potentiel nécessaire au NBNS sécurisé pour faire la mise en cause, il est vraisemblable qu’un WACK sera envoyé par le NBNS à celui qui enregistre.

Un NBNS sécurisé va immédiatement envoyer une Réponse négative d’enregistrement de nom en réponse à toute Demande de substitution de nom qu’il pourrait recevoir.

15.2.3 Enregistrement du nom par les nœuds M

Un nœud M commence une opération de revendication de nom comme si le nœud était un nœud B : il diffuse une Demande d’enregistrement de nom et écoute les Réponses négatives d’enregistrement de nom. Toute Réponse négative d’enregistrement de nom empêche le nœud M d’obtenir le nom et termine l’opération de revendication.

Si, cependant, le nœud M ne reçoit aucune Réponse négative d’enregistrement de nom, il doit continuer la procédure de revendication comme si le nœud M était un nœud P.

C’est seulement si les deux revendications de nom ont été couronnées de succès que le nœud M acquiert le nom.

Le diagramme suivant illustre l’enregistrement de nom d’un nœud M :

15.3 Transactions d’interrogation de nom

Les transactions d’interrogation du nom sont initiées par les nœuds d’extrémité pour obtenir la ou les adresses IP et les autres attributs associés à un nom NetBIOS.

15.3.1 Interrogation par les nœuds B

Le diagramme suivant montre comment font les nœuds B pour découvrir qui possède un nom.

La moitié gauche du diagramme illustre ce qui arrive si il n’y a pas de détenteur du nom. Dans ce cas, aucune réponse n’est reçue à la diffusion du ou des Demandes d’interrogation du nom.

La moitié droite montre un envoi individuel de Réponse positive d’interrogation du nom par un détenteur de nom en réponse à la demande diffusée. Un détenteur de nom fera sa réponse à chaque Demande d’interrogation du nom qu’il entend. Et chaque détenteur agit de cette façon. Et donc, le nœud qui envoie la demande peut recevoir de nombreuses réponses, certaines dupliquées, et de la part de nombreux nœuds.

L’interrogation du nom est généralement, mais pas nécessairement, un prélude à un établissement de session NetBIOS ou à une transmission de datagramme NetBIOS. Cependant, une interrogation de nom peut être utilisée pour d’autres fins.

Un nœud B peut choisir de construire une liste des membres d’un groupe pour un usage ultérieur (par exemple, pour l’établissement de session) en collectant et sauvegardant les réponses.

15.3.2 Interrogation par les nœuds P

Un NBNS répond aux interrogations provenant d’un nœud P par une liste des adresses IP et autres informations pour chacun des détenteurs du nom. Si il y a plusieurs détenteurs (c’est à dire, si le nom est un nom de groupe), le NBNS charge autant de réponses dans la réponse qu’il en tient dans un paquet UDP. Un fanion de troncature indique si il reste des informations de détenteur supplémentaires. Toutes les informations peuvent être obtenues en répétant l’interrogation sur une connexion TCP.

Le NBNS n’est pas obligé à un ordre particulier de sa liste de réponses.

Le diagramme suivant montre ce qui arrive si le NBNS n’a pas d’information sur le nom :

Le diagramme suivant illustre les interactions entre le nœud d’extrémité et le NBNS quand le NBNS n’a pas d’information sur le nom. Ce diagramme montre aussi la retransmission de la demande par le nœud d’extrémité en l’absence d’une réponse à temps. Les WACK (ou les réponses temporaires intermédiaires) envoyés par le NBNS au nœud d’extrémité sont également indiqués :

Le diagramme suivant illustre la redirection de NBNS. À réception d’une Demande d’interrogation du nom, le NBNS redirige le client sur un autre NBNS. Le client répète la demande au nouveau NBNS et obtient une réponse. Le diagramme montre cette réponse comme une Réponse positive d’interrogation du nom. Cependant, toute réponse légale du NBNS peut survenir en fonctionnement réel.

Le diagramme suivant montre comment un nœud P ou M dit au NBNS que celui-ci a fourni des informations incorrectes. Cette procédure peut commencer après la réception d’un paquet Erreur de datagramme ou qu’une tentative d’établissement de session a découvert que le nom NetBIOS n’existe pas à la destination, dont l’adresse IP avait été obtenue du NBNS durant une transaction d’interrogation de nom précédente. Le NBNS, dans le cas présent un NBNS sécurisé, produit des interrogations pour vérifier si les informations sont, en fait, incorrectes. Le NBNS clôt la transaction en envoyant une Réponse positive ou négative de libération de nom, selon le résultat de la vérification.

15.3.3 Interrogation par les nœuds M

L’interrogation de nom de nœud M suit le schéma du nœud B. En l’absence de résultats adéquats, le nœud M continue alors en effectuant une interrogation de type nœud P. C’est ce qui est montré dans le diagramme ci-après :

15.3.4 Acquisition de liste d’adhésion au groupe

On peut acquérir la totalité des membres d’un groupe par l’envoi d’une Demande d’interrogation du nom au NBNS. Le NBNS va répondre par une Réponse positive d’interrogation du nom ou une Réponse négative d’interrogation du nom. Une réponse négative termine la procédure et indique qu’il n’y a plus de membre dans le groupe.

Si la réponse positive a le bit de troncature à zéro, la réponse contient alors la liste entière des membres du groupe. Si le bit de troncature est mis (à un), toute cette procédure doit être répétée, mais en utilisant TCP plutôt que UDP comme moyen.

15.4 Transactions de libération de nom

15.4.1 Libération par les nœuds B

Une Instruction de libération de nom contient les informations suivantes :
- nom NetBIOS
- domaine d’application du nom NetBIOS
- type de nom : unique ou de groupe
- adresse IP du nœud qui libère le nom
- identifiant de transaction

15.4.2. Libération par les nœuds P

Une Demande de libération de nom contient les informations suivantes :
- nom NetBIOS
- domaine d’application du nom NetBIOS
- type de nom : unique ou de groupe
- adresse IP du nœud qui libère le nom
- identifiant de transaction

Une Réponse de libération de nom contient les informations suivantes :
- nom NetBIOS
- domaine d’application du nom NetBIOS
- type de nom : unique ou de groupe
- adresse IP du nœud qui libère le nom
- identifiant de transaction
- résultat :
- Oui : le nom a été libéré
- Non : le nom n’a pas été libéré, un code de cause est fourni.

15.4.3 Libération par les nœuds M

La procédure de libération de nom du nœud M est une combinaison des procédures de libération de nom du nœud P et du nœud B. Le nœud M effectue d’abord la procédure de libération P. Si la procédure P échoue, la procédure de libération ne continue pas, elle échoue. Si et seulement si la procédure P réussit, alors le nœud M diffuse l’Instruction de libération de nom à la zone de diffusion, la procédure B.

NOTE : Un nœud M effectue normalement une opération de style B et ensuite une opération de style P. Dans ce cas cependant, l’opération de style P vient en premier.

Le diagramme suivant illustre la procédure de libération de nom de nœud M :

15.5 Transactions de maintenance de nom

15.5.1 Rafraîchissement de nom

Les transactions de rafraîchissement de nom sont utilisées pour traiter les situations suivantes :

a) Un nœud NBNS a besoin de détecter si un nœud P ou M s’est éteint "en silence", de sorte que les noms détenus par ce nœud peuvent être purgés de la base de données.

b) Si le NBNS s’éteint, il doit être capable de reconstruire la base de données quand il revient.

c) Si le réseau doit subir une partition, le NBNS doit être capable de mettre à jour sa base de données quand le réseau se reconnecte.

Chaque nœud P ou M est responsable de l’envoi périodique de Demande de rafraîchissement de nom pour chaque nom qu’il a enregistré. Chaque paquet de rafraîchissement contient un seul nom qui a été enregistré avec succès par ce nœud. L’intervalle entre de tels paquets est négocié entre le nœud d’extrémité et le serveur NBNS au moment où le nom est initialement revendiqué. Au moment de la revendication du nom, un nœud d’extrémité va suggérer une valeur de temps de rafraîchissement. Le nœud NBNS peut modifier cette valeur dans le paquet de réponse. Un nœud NBNS peut aussi choisir de dire au nœud d’extrémité de n’envoyer aucun paquet de rafraîchissement en utilisant la valeur de temporisation "infini" dans le paquet de réponse. La valeur de temporisation retournée par le NBNS est la temporisation de rafraîchissement réelle que le nœud d’extrémité doit utiliser.

Quand un nœud envoie une Demande de rafraîchissement de nom, il doit être prêt à recevoir une réponse négative. Cela va arriver, par exemple, si le NBNS découvre que le nom a déjà été alloué à un autre nœud. Si une telle réponse est reçue, le nœud d’extrémité devrait marquer le nom comme étant en conflit. Une telle entrée devrait être traitée de la même façon que si un conflit de nom avait été détecté contre le nom. Le diagramme suivant illustre le rafraîchissement de nom :

15.5.2 Mise en cause de nom

La mise en cause du nom est faite par l’envoi d’une Demande d’interrogation du nom à un nœud d’extrémité de tout type. Si une Réponse positive d’interrogation du nom est retournée, alors ce nœud possède encore le nom. Si une Réponse négative d’interrogation du nom est reçue ou si aucune réponse n’est reçue, on peut supposer que le nœud d’extrémité ne possède plus le nom.

La mise en cause de nom peut être effectuée par le nœud NBNS, ou par un nœud d’extrémité. Lorsque un nœud d’extrémité envoie un paquet de revendication de nom, le nœud NBNS peut mettre en cause l’opération. Le nœud NBNS peut cependant choisir d’exiger que le nœud d’extrémité fasse la mise en cause. Dans ce cas, le NBNS enverra un paquet Réponse de mise en cause de nœud d’extrémité au nœud d’extrémité qui devrait alors procéder à la mise en cause du détenteur supposé.

Noter que la procédure de mise en cause de nom envoie un paquet Demande d’interrogation du nom normale au nœud d’extrémité. Cela n’exige pas un paquet particulier. Le seul nouveau paquet introduit est la Réponse de mise en cause de nœud d’extrémité qui est envoyée par un nœud NBNS quand le NBNS veut que le nœud d’extrémité effectue l’opération de mise en cause.

15.5.3 Supprimer le conflit de nom

Il est possible durant une demande de rafraîchissement provenant d’un nœud M ou P qu’un NBNS détecte un nom en conflit. La réponse à la Demande de rafraîchissement de nom doit être une Réponse négative d’enregistrement de nom. De plus, le NBNS peut facultativement envoyer une Instruction de nom en conflit ou une Demande de libération de nom au nœud qui fait le rafraîchissement. L’Instruction de nom en conflit force le nœud à placer le nom dans l’état de conflit. Le nœud va finalement informer son utilisateur du conflit. La demande de libération de nom va forcer le nœud à chasser complètement le nom de son tableau local des noms. Elle force le nœud à chasser le nom en conflit. Cela ne cause pas la terminaison des sessions existantes qui utilisent ce nom.

Le diagramme suivant montre un NBNS qui détecte et corrige un conflit :

15.6 Transactions d’état d’adaptateur

L’état d’adaptateur est obtenu d’un nœud comme suit :

1. Effectuer une opération de découverte de nom pour obtenir les adresses IP d’un ensemble de nœuds d’extrémité.

2. Répéter jusqu’à ce que tous les nœuds d’extrémité de l’ensemble aient été utilisés :
a. Choisir un nœud d’extrémité dans l’ensemble.
b. Envoyer une Demande d’état de nœud à ce nœud d’extrémité en utilisant UDP.
c. Attendre une Réponse d’état de nœud. (Si une réponse ne parvient pas à temps, répéter l’étape "b" UCAST_REQ_RETRY_COUNT fois. Après le dernier essai, revenir à l’étape "a".)
d. Si le bit de troncature n’est pas mis à un dans la réponse, celle-ci contient l’état entier du nœud. Retourner l’état à l’utilisateur et terminer cette procédure.
e. Si le bit de troncature est mis à un dans la réponse, tout l’état n’a pas été retourné parce qu’il ne tenait pas dans le paquet de réponse. Le répondant va mettre le bit de troncature à un si la longueur du datagramme IP doit excéder MAX_DATAGRAM_LENGTH. Retourner l’état à l’usager et terminer cette procédure.

3. Retourner une erreur à l’usager, aucun état obtenu.

La répétition de l’étape 2 ci-dessus, à travers tous les nœuds de l’ensemble, est facultative.

Ci-après est donné un exemple de transaction d’une opération État d’adaptateur :

16 Service de session NetBIOS

La session de service NetBIOS commence après qu’une ou plusieurs adresses IP ont été trouvées pour le nom cible. Ces adresses peuvent avoir été acquises en utilisant les transactions d’interrogation de nom NetBIOS ou par d’autres moyens, tels qu’un tableau local de nom ou une mémoire cache.

Les transactions, paquets, et protocoles de service de session NetBIOS sont identiques pour tous les types de nœud d’extrémité. Ils n’impliquent que des communications dirigées (point à point).

16.1 Généralités sur le service de session NetBIOS

Le service de session a trois phases :

Établissement de session – c’est durant cette phase que l’adresse IP et l’accès TCP du nom appelé sont déterminés, et qu’une connexion TCP est établie avec la partie distante.

Régime permanent – c’est durant cette phase que les messages de données NetBIOS sont échangés sur la session. Les paquets Keep-alive (garder en vie) peuvent aussi être échangés si les nœuds participants sont configurés pour cela.

Clôture de session - une session est close chaque fois que l’une ou l’autre partie (à la session) clôt la session ou qu’il est déterminé que l’une des parties s’est éteinte.

16.1.1 Généralités sur la phase d’établissement de session

Un nœud d’extrémité commence l’établissement d’une session avec un autre nœud en acquérant de quelque façon (peut-être en utilisant les transactions d’interrogation de nom ou une mémoire cache locale) l’adresse IP du ou des nœuds prétendant posséder le nom de destination.

Chaque nœud d’extrémité attend les demandes de session NetBIOS entrantes en écoutant les appels TCP sur un accès de service bien connu, SSN_SRVC_TCP_PORT. Chaque connexion TCP entrante représente le début d’une tentative d’initialisation de session NetBIOS distincte. Le serveur de session NetBIOS, et non pas l’application ultime, accepte la ou les connexions TCP entrantes.

Une fois la connexion TCP ouverte, le nœud appelant envoie un paquet de demande de service de session. Ce paquet contient les informations suivantes :
- Adresse IP de l’appelant (voir la note)
- Nom NetBIOS appelant
- Adresse IP appelée (voir la note)
- Nom NetBIOS appelé

NOTE : Les adresses IP sont obtenues de l’interface de service TCP.

Lorsque le paquet de demande de service de session arrive au serveur NetBIOS, une des situations suivantes va exister :
- Il existe un NetBIOS LISTEN compatible avec l’appel entrant et il y a des ressources adéquates pour permettre à l’établissement de session de se poursuivre.
- Il existe un NetBIOS LISTEN compatible avec l’appel entrant, mais il n’y a pas les ressources adéquates pour permettre l’établissement d’une session.
- Le nom appelé existe bien sur le nœud appelé, mais il n’y a pas de NetBIOS LISTEN en cours compatible avec l’appel entrant.
- Le nom appelé n’existe pas sur le nœud appelé.

Dans tous les cas sauf le premier, une réponse de rejet est renvoyée à l’appelant sur la connexion TCP. La connexion TCP est alors close et la phase de session se termine. Un nouvel essai est de la responsabilité de l’appelant. Pour les nouveaux essais dans le cas d’un nom de groupe, l’appelant peut utiliser le membre suivant du groupe plutôt que de réessayer immédiatement la même adresse. Dans le cas d’un nom unique, l’appelant peut réessayer immédiatement la même adresse IP cible sauf si l’appelé n’existe pas sur le nœud appelé. Dans ce seul cas, le nom NetBIOS devrait subir une nouvelle résolution.

Si un LISTEN compatible existe, et si il y a des ressources adéquates, le serveur de session peut alors transformer la connexion TCP existante en session de données NetBIOS. Autrement, le serveur de session peut rediriger, ou "recibler" l’appelant sur un autre accès TCP (et adresse IP).

Si l’appelant est redirigé, l’appelant recommence l’établissement de session, mais en utilisant la nouvelle adresse IP et l’accès TCP donnés dans la réponse reciblée. Une connexion TCP est à nouveau créée, et les nœuds appelant et appelé échangent à nouveau leurs accréditifs. La partie appelée peut accepter l’appel, le rejeter, ou le rediriger.

Ce mécanisme se fonde sur la présomption que, sur les hôtes où il n’est pas possible de transférer des connexions TCP ouvertes entre les processus, l’hôte aura un serveur de session central. Les applications qui veulent recevoir des appels NetBIOS vont obtenir un numéro d’accès TCP éphémère, envoyer une ouverture TCP passive non spécifiée sur cet accès, et passer alors ces informations de numéro d’accès et de nom NetBIOS au serveur de session NetBIOS en utilisant une opération NetBIOS LISTEN. Lorsque l’appel est passé, le serveur de session va "recibler" l’appelant sur la prise TCP de l’application. L’appelant va alors passer un nouvel appel, directement à l’application. L’application est chargé d’imiter le serveur de session au moins jusqu’à la réception des accréditifs de l’appelant et d’accepter ou rejeter alors l’appel.

16.1.1.1 Réessai après reciblage

Un nœud appelant peut trouver qu’il ne peut pas établir une session avec un nœud sur lequel il a été dirigé par la procédure de reciblage. Comme le reciblage peut être incorporé, il se pose la question de savoir si l’appelant devrait commencer l’essai au point de départ initial ou revenir à un point de reciblage intermédiaire. L’appelant peut utiliser toute les méthodes. Un exposé de ces deux méthodes figure dans l’Appendice B, "Algorithmes de reciblage".

16.1.1.2 Établissement de session à un nom de groupe

L’établissement de session avec un nom de groupe requiert une considération particulière. Quand une tentative d’appel NetBIOS est faite sur un nom de groupe, la découverte du nom résultera en une liste (peut-être incomplète) des membres de ce groupe. Le nœud appelant choisit un membre de la liste et essaye de construire une session. Si il échoue, le nœud appelant peut essayer un autre membre et faire une autre tentative.

Lorsque le service de session tente d’établir une connexion avec un des membres du groupe, il n’y a aucune garantie que ce membre ait un LISTEN en instance envers ce nom de groupe, que le nœud appelé le possède, ou même que le nœud appelé soit en fonctionnement.

16.1.2 Généralités sur la phase de régime permanent

Les messages de données NetBIOS sont échangés dans le régime permanent. Les messages NetBIOS sont envoyés en ajoutant en préambule les données d’usager à l’en-tête du message et en envoyant l’en-tête et les données d’usager sur la connexion TCP. Le receveur retire l’en-tête et passe les données à l’usager NetBIOS.

Afin de détecter la défaillance d’un des nœuds ou du réseau intervenant, des paquets "garder la session en vie" peuvent être envoyés périodiquement dans le régime permanent.

Toute défaillance de la connexion TCP sous jacente, même une réinitialisation, une fin de temporisation, ou autre défaillance, implique l’échec de la session NetBIOS.

16.1.3 Généralités sur la phase de terminaison de session

Une session NetBIOS se termine normalement lorsque l’utilisateur demande que la session soit close ou quand le service de session détecte que le partenaire distant de la session a mis un terme en douceur à la connexion TCP. Une session NetBIOS se termine de façon anormale lorsque le service de session détecte une perte de connexion. La perte de connexion peut être détectée avec la fonction keep-alive (garder en vie) du service de session ou de TCP, ou sur échec d’une opération d’envoi d’un Message de session.

Lorsqu’un utilisateur demande à clore une session, le service essaye d’abord une clôture en douceur dans la bande de la connexion TCP. Si la connexion ne se ferme pas dans le délai SSN_CLOSE_TIMEOUT, la connexion TCP est interrompue. Peu importe comment la connexion TCP se termine, le service de session NetBIOS clôt toujours la session NetBIOS.

Lorsque le service de session reçoit une indication de TCP qu’une demande de clôture de connexion a été reçue, la connexion TCP et la session NetBIOS sont immédiatement fermées et l’usager est informé de la perte de la session. Toutes les données reçues jusqu’à l’indication de clôture devraient être délivrées, si possible, à l’utilisateur de la session.

16.2 Phase d’établissement de session

Tous les diagrammes qui suivent supposent qu’une opération d’interrogation de nom a été menée à bien par le nœud appelant pour le nom de celui qui écoute.

Le premier diagramme montre la séquence des événements de réseau utilisés pour réussir à établir une session sans reciblage par celui qui écoute. La connexion TCP est d’abord établie avec l’accès TCP bien connu de service de session NetBIOS, SSN_SRVC_TCP_PORT. L’appelant envoie alors un paquet Demande de session sur la connexion TCP demandant une session avec celui qui écoute. La Demande de session contient le nom de l’appelant et le nom de celui qui écoute. Celui qui écoute répond par une Réponse positive de session informant l’appelant que cette connexion TCP est acceptée comme connexion pour la phase de transfert des données de la session.

Le second diagramme montre la séquence des événements de réseau utilisés pour réussir à établir une session lorsque celui qui écoute fait le reciblage. La procédure d’établissement de session est la même qu’avec le premier diagramme jusqu’à la réponse de l’écoutant à la Demande de session. Celui qui écoute, divisé en deux sections, le processeur d’écoute et l’écoutant réel, envoie une Réponse de reciblage de session à l’appelant. Cette réponse établit que l’appel est acceptable, mais que la connexion TCP de transfert de données doit être à la nouvelle adresse IP et accès TCP. L’appelant réitère alors le processus d’établissement de session avec la nouvelle adresse IP et l’accès TCP après que la connexion TCP initiale est close. Le nouvel écoutant accepte alors cette connexion pour la phase de transfert des données avec une Réponse positive de session.

Le troisième diagramme est la séquence des événements de réseau pour une demande de session rejetée avec l’écoutant. Ce type de rejet pourrait survenir avec aussi bien un écoutant non-recibleur qu’un écoutant recibleur. Après l’établissement de la connexion TCP à SSN_SRVC_TCP_PORT, l’appelant envoie la Demande de session sur la connexion TCP. L’écoutant n’a pas d’écoute en cours pour le nom de celui qui écoute ou l’écoute NetBIOS en cours est spécifique du nom d’un autre appelant. Par conséquent, l’écoutant envoie une Réponse négative de session et clôt la connexion TCP.

Le quatrième diagramme est la séquence des événements de réseau lorsque l’établissement de session échoue avec un écoutant qui recible. Après être redirigé, et après la clôture de la connexion TCP initiale, l’appelant essaye d’établir une connexion TCP avec la nouvelle adresse IP et accès TCP. La connexion échoue parce que soit l’accès est indisponible ou que le nœud cible n’est pas actif. La condition de compétition d’accès indisponible survient si un autre appelant a déjà acquis la connexion TCP avec l’écoutant. Pour des suggestions de mise en œuvre supplémentaires, voir l’Appendice B, "Algorithmes de reciblage".

16.3 Phase de transfert de données de session

16.3.1 Encapsulation de données

Les messages NetBIOS sont échangés dans le régime permanent. Les messages sont envoyés en ajoutant en préambule les données d’utilisateur à l’en-tête de message et en envoyant l’en-tête et les données d’utilisateur sur la connexion TCP. Le receveur retire l’en-tête et délivre les données NetBIOS à l’utilisateur.

16.3.2 Maintien en vie de session

Afin de détecter un échec de nœud ou une partition du réseau, les paquets "maintien de session en vie" sont envoyés périodiquement dans le régime permanent. Un paquet de maintien de session en vie est éliminé par un nœud homologue.

Un temporisateur de maintien de session en vie est entretenu pour chaque session. Ce temporisateur est remis à zéro chaque fois que des données sont envoyées, ou reçues par l’homologue de session. Lorsque le temporisateur arrive à expiration, un paquet NetBIOS de maintien de session en vie est envoyé sur la connexion TCP. L’envoi d’un paquet de maintien en vie force les données à s’écouler sur la connexion TCP, et donc cause indirectement la détection par TCP de l’activité de la connexion.

Comme de nombreuses mises en œuvre de TCP fournissent un mécanisme parallèle TCP de "maintien en vie", le maintien en vie de session NetBIOS est une option configurable. Il est recommandé de n’utiliser le mécanisme NetBIOS de maintien en vie qu’en l’absence du maintien en vie de TCP.

Noter qu’à la différence des maintiens en vie de TCP, les maintiens de session en vie NetBIOS n’exigent pas une réponse de la part de l’homologue NetBIOS -- le fait qu’il était possible d’envoyer le maintien en vie de session NetBIOS est une indication suffisante que l’homologue, et sa connexion, sont toujours actifs.

La seule exigence pour l’interopérabilité est que quand un paquet de maintien de session en vie est reçu, il devrait être éliminé.

17 Service de datagrammes NetBIOS

17.1 Généralités sur le service de datagrammes NetBIOS

Chaque datagramme NetBIOS a une destination et une source désignées. Pour transmettre un datagramme NetBIOS, le service de datagrammes doit effectuer une opération d’interrogation de nom pour apprendre l’adresse IP et les attributs du nom de destination NetBIOS. (Ces informations peuvent être mises en mémoire cache pour éviter la redondance de l’interrogation de nom sur les datagrammes NetBIOS suivants.)

Les datagrammes NetBIOS sont portés au sein des paquets UDP. Si un datagramme NetBIOS est plus long qu’un seul paquet UDP, il peut être fragmenté en plusieurs paquets UDP.

Les nœuds d’extrémité peuvent recevoir des datagrammes NetBIOS adressés aux noms qui ne sont pas détenus par le nœud receveur. De tels datagrammes devraient être éliminés. Si le nom est unique, alors un paquet Erreur de datagramme est envoyé à la source de ce datagramme NetBIOS.

17.1.1 Envoi individuel, diffusion groupée et diffusion

Les datagrammes NetBIOS peuvent être en envoi individuel, en diffusion groupée ou en diffusion. Un datagramme NetBIOS adressé à un nom NetBIOS unique est en envoi individuel. Un datagramme NetBIOS adressé à un nom NetBIOS de groupe, qu’il y ait zéro, un, ou plusieurs membres réels, est en diffusion groupée. Un datagramme NetBIOS envoyé en utilisant la primitive NetBIOS "Envoi d’un datagramme en diffusion" est en diffusion.

17.1.2 Fragmentation des datagrammes NetBIOS

Lorsque l’en-tête et les données d’un datagramme NetBIOS excèdent la quantité maximum de données permise dans un paquet UDP, le datagramme NetBIOS doit être fragmenté avant la transmission et réassemblé à réception.

Un datagramme NetBIOS est composé des éléments de protocole suivants :
- en-tête IP de 20 octets (minimum)
- en-tête UDP de 8 octets
- en-tête de datagramme NetBIOS de 14 octets
- des données du datagramme NetBIOS.

La section des données du datagramme NetBIOS est composée de 3 parties :
- nom NetBIOS de source (255 octets maximum)
- nom NetBIOS de destination (255 octets maximum)
- données d’utilisateur NetBIOS (maximum de 512 octets)

Les deux champs de nom sont en format codé de second niveau (voir la section 14.)

La taille maximum du datagramme NetBIOS est de 1064 octets. La taille minimale maximum du datagramme IP est de 576 octets. Par conséquent, un datagramme NetBIOS peut ne pas tenir dans un seul datagramme IP. Cela rend nécessaire de permettre la fragmentation des datagrammes NetBIOS.

Sur les réseaux qui satisfont ou excèdent l’exigence minimum de longueur de datagramme IP de 576 octets, au plus deux fragments de datagramme NetBIOS seront générés. Les protocoles et formats de paquet s’accommodent de la fragmentation en trois parties ou plus.

Lorsqu’un datagramme NetBIOS est fragmenté, les en-têtes de datagramme IP, UDP et NetBIOS sont présents dans chaque fragment. La section des données du datagramme NetBIOS est partagée entre les datagrammes UDP résultants. Les sections de données des fragments du datagramme NetBIOS ne se chevauchent pas. Les seuls champs de l’en-tête du datagramme NetBIOS qui vont varier sont les champs FLAGS (fanions) et OFFSET (décalage).

Le bit FIRST dans le champ FLAGS indique si le fragment est le premier dans une séquence de fragments. Le bit MORE dans le champ FLAGS indique si d’autres fragments suivent.

Le champ OFFSET est le décalage des octets depuis le début de la section de données du datagramme NetBIOS depuis le premier octet de la section de données dans un fragment. Il est de 0 pour le premier fragment. Pour chaque fragment suivant, OFFSET est la somme des octets dans les sections de données NetBIOS de tous les fragments précédents.

Si le datagramme NetBIOS n’était pas fragmenté :
- FIRST = VRAI
- MORE = FAUX
- OFFSET = 0

Si le datagramme NetBIOS était fragmenté :

- Premier fragment :
- FIRST = VRAI
- MORE = VRAI
- OFFSET = 0

- fragments intermédiaires :
- FIRST = FAUX
- MORE = VRAI
- OFFSET = somme des données NetBIOS dans les fragments précédents

- Dernier fragment :
- FIRST = FAUX
- MORE = FAUX
- OFFSET = somme des données NetBIOS dans les fragments précédents

La position relative des fragments intermédiaires peut être assurée à partir de OFFSET.

Un NBDD doit se souvenir du nom de destination du premier fragment afin de relayer les fragments suivants d’un datagramme NetBIOS. Les informations de nom peuvent être associées aux fragments suivants grâce aux champs d’identifiant de transaction, DGM_ID, et SOURCE_IP, du paquet. Ces informations peuvent être purgées par le NBDD après le traitement du dernier fragment ou l’expiration de la durée du FRAGMENT_TO depuis la réception du premier fragment.

17.2 Datagrammes NetBIOS par des nœuds B

Pour les datagrammes NetBIOS avec une destination désignée (c’est-à-dire non diffusés), un nœud B effectue une découverte de nom pour le nom de destination avant d’envoyer le datagramme. (La découverte de nom peut être outrepassée si des informations provenant d’une découverte précédente sont détenues dans une mémoire cache.) Si le type de nom retourné par la découverte de nom est UNIQUE, le datagramme est en envoi individuel pour le seul détenteur du nom. Si le type de nom est GROUP, le datagramme est diffusé à la zone de diffusion entière en utilisant l’adresse de destination IP BROADCAST_ADDRESS.

Un nœud receveur filtre toujours les datagrammes sur la base du nom de destination. Si le nom de destination n’est pas en la possession du nœud ou si aucune opération d’usager RECEIVE DATAGRAM n’est en instance pour le nom, le datagramme est alors éliminé. Pour les datagrammes avec une destination de nom UNIQUE, si le nom n’est pas possédé par le nœud, le nœud receveur envoie alors un paquet DATAGRAM ERROR. Le paquet d’erreur provient de DGM_SRVC_UDP_PORT et est adressé à SOURCE_IP et SOURCE_PORT du mauvais datagramme. Le nœud receveur élimine les datagrammes en douceur avec un nom de destination GROUP si le nom n’est pas détenu par le nœud.

Comme les datagrammes NetBIOS n’ont pas de destination désignée, le nœud B envoie le ou les paquets DATAGRAM SERVICE à toute la zone de diffusion en utilisant l’adresse IP de destination BROADCAST_ADDRESS. Afin que les nœuds receveurs distinguent ce datagramme comme un datagramme NetBIOS en diffusion, le nom NetBIOS utilisé comme nom de destination est '*' (2A en hexadécimal) suivi par 15 octets de 00 hexadécimal. L’identifiant de domaine d’application NetBIOS est ajouté au nom avant sa conversion en codage de second niveau. Par exemple, si l’identifiant de domaine d’application est "NETBIOS.SCOPE" le nom codé de premier niveau serait alors :
CKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.NETBIOS.SCOPE

Conformément à [2], un usager ne peut pas fournir un nom NetBIOS commençant par "*".

Pour chaque nœud de la zone de diffusion qui reçoit le datagramme NetBIOS en diffusion, si des opérations d’usager RECEIVE BROADCAST DATAGRAM sont en instance, alors les données provenant du datagramme NetBIOS sont dupliquées et délivrées à chacun. Si aucune de ces opérations n’est en instance, le nœud élimine alors en silence le datagramme.

17.3 Datagrammes NetBIOS sur des nœuds P et M

Les nœuds P et M n’utilisent pas la diffusion IP pour distribuer les datagrammes NetBIOS.

Comme les nœuds B, les nœuds P et M doivent effectuer une découverte de nom ou utiliser des informations en mémoire cache pour apprendre si un nom de destination est un groupe ou un nom unique.

Les datagrammes pour des noms uniques sont en envoi individuel directement à la destination par les nœuds P et M, exactement comme ils le sont par les nœuds B.

Les datagrammes pour les noms de groupe et les datagrammes de diffusion NetBIOS sont en envoi individuel pour le NBDD. Le NBDD relaie alors les datagrammes à chacun des nœuds spécifiés par le nom de destination.

Un NBDD peut n’être pas capable d’envoyer un datagramme NetBIOS à un non-NetBIOS particulier, y compris le nom NetBIOS de diffusion ("*") défini ci-dessus. Un mécanisme d’interrogation est disponible pour que le nœud d’extrémité détermine si un NBDD va être capable de relayer un datagramme à un nom donné. Avant l’envoi d’un datagramme, ou de ses fragments, au NBDD, le nœud P ou M peut envoyer un paquet DATAGRAM QUERY REQUEST (demande d’interrogation de datagramme) au NBDD avec le DESTINATION_NAME tiré du ou des paquets DATAGRAM SERVICE. Le NBDD va répondre par une DATAGRAM POSITIVE QUERY RESPONSE (réponse positive d’interrogation de datagramme) si il va relayer les datagrammes au nom de destination spécifié. Après une réponse positive, le nœud d’extrémité envoie en individuel le datagramme au NBDD. Si le NBDD n’est pas capable de relayer un datagramme au nom de destination spécifié dans l’interrogation, un paquet DATAGRAM NEGATIVE QUERY RESPONSE (réponse négative d’interrogation de datagramme ) est retourné. Si le NBDD ne peut pas distribuer un datagramme, le nœud d’extrémité a alors l’option d’obtenir la liste des détenteurs de nom de la part du NBNS et d’envoyer directement le datagramme à chacun des détenteurs.

Un NBDD doit être capable de répondre aux paquets de Demande d’interrogation de datagramme. La réponse peut toujours être positive. Cependant, l’usage ou la mise en œuvre du mécanisme d’interrogation par un nœud P ou M est facultative. Une mise en œuvre peut toujours envoyer le datagramme NetBIOS en individuel au NBDD sans lui demander si il sera relayé. Excepté pour la facilité d’interrogation de datagramme décrite ci-dessus, un NBDD ne fournit pas d’informations en retour pour indiquer s’il a retransmis un datagramme.

18 Paramètres de configuration de nœuds

- Nœuds B :
- nom unique permanent du nœud
- si IGMP est utilisé
- adresse IP en diffusion à utiliser
- si les maintiens de session en vie NetBIOS sont nécessaires
- longueur utilisable de champ de données UDP (pour le contrôle de fragmentation)

- Nœuds P :
- nom unique permanent du nœud
- adresse IP du NBNS
- adresse IP du NBDD
- si les maintiens de session en vie NetBIOS sont nécessaires
- longueur utilisable de champ de données UDP (pour le contrôle de fragmentation)

- Nœuds M :
- nom unique permanent du nœud
- si IGMP est utilisé
- adresse IP de diffusion à utiliser
- adresse IP du NBNS
- adresse IP du NBDD
- si les maintiens de session en vie NetBIOS sont nécessaires
- longueur utilisable de champ de données UDP (pour le contrôle de fragmentation)

19 Conformité minimale

Pour assurer l’interopérabilité entre les fabricants, une mise en œuvre à conformité minimale fondée sur la présente spécification doit observer les règles suivantes :

a) Un nœud conçu pour fonctionner seulement sur une zone de diffusion doit se conformer à la spécification de nœud B.

b) Un nœud conçu pour fonctionner seulement sur un internet doit se conformer à la spécification de nœud P.

Références

[1] "Protocole standard pour un service NetBIOS sur un transport TCP/UDP : Spécifications détaillées", RFC 1002, mars 1987.

[2] IBM Corp., "IBM PC Network Technical Reference Manual", No. 6322916, première édition, septembre 1984.

[3] J. Postel (éd.), "Protocole de commande de transmission", RFC 793 (STD 7), septembre 1981.

[4] MIL-STD-1778

[5] J. Postel, "Protocole de datagramme d’utilisateur", RFC 768 (STD 6), 28 août 1980.

[6] J. Reynolds, J. Postel, "Numéros alloués", RFC 990 (rendue obsolète par la RFC 1010), novembre 1986.

[7] J. Postel, "Protocole Internet", RFC 791 (STD 5), septembre 1981.

[8] J. Mogul, "Sous-réseaux Internet", RFC 950 (STD 5), octobre 1984

[9] J. Mogul, "Diffusion des datagrammes Internet en présence de sous-réseaux", RFC 922, octobre 1984.

[10] J. Mogul, "Diffusion des datagrammes Internet", RFC 919, octobre 1984.

[11] P. Mockapetris, "Noms de domaines - Concepts et facilités", RFC 882 (rendue obsolète par la RFC 1034/1035), novembre 1983.

[12] P. Mockapetris, "Noms de domaines – Spécification et mise en œuvre", RFC 883 (rendue obsolète par la RFC 1034/1035), novembre 1983.

[13] P. Mockapetris, "Changements et observations du système des domaines", RFC 973 (rendue obsolète par la RFC 1034/1035), janvier 1986.

[14] C. Partridge, "L’acheminement de la messagerie et le système des domaines", RFC 974 (rendue obsolète par la RFC 2821), janvier 1986.

[15] S. Deering, D. Cheriton, "Groupes d’hôtes : une extension de diffusion groupée au protocole Internet", RFC 966 (rendue obsolète par la RFC 0988), décembre 1985.

[16] S. Deering, "Extensions d’hôte pour la diffusion groupée IP", RFC 988 (rendue obsolète par la RFC 1054/1112), juillet 1986.

Appendice A Intégration avec la diffusion groupée internet

Le présent appendice contient un exposé de soutien technique. Il ne fait pas partie intégrante de la spécification NetBIOS sur TCP.

Le système Netbios sur TCP décrit dans la présente RFC peut être facilement intégré dans le système de diffusion groupée Internet qui est maintenant développé pour l’Internet.

Dans le corps principal de la RFC, la notion de zone de diffusion était considérée comme étant un seul "B-LAN" à pontage MAC. Cependant, les protocoles définis vont fonctionner sur une zone de diffusion étendue qui résulte de la création d’un groupe de diffusion groupée Internet permanent.

Chaque zone de diffusion distincte devrait être fondée sur un groupe de diffusion groupée Internet permanent séparé. Cette adresse de diffusion groupée devrait être utilisée par les nœuds P et M comme leur BROADCAST_ADDRESS.

Afin de fonder les zones de diffusion sur un groupe de diffusion groupée certaines procédures supplémentaires sont nécessaires et certaines contraintes doivent être satisfaites.

A-1. Protocole supplémentaire exigé dans les nœuds B et M

Tous les nœuds B ou M fonctionnant sur une zone de diffusion fondée sur IGMP doivent avoir la prise en charge de IGMP dans leur logiciel de couche IP. Ces nœuds doivent effectuer une opération conjointe IGMP pour entrer dans le groupe IGMP avant de s’engager dans l’activité NetBIOS.

A-2. Contraintes

Les zones de diffusion peuvent se chevaucher. Pour cette raison, les nœuds d’extrémité doit être attentifs lors de l’examen des identifiants de domaine d’application NetBIOS dans tous les paquets en diffusion reçus.

Les protocoles de diffusion NetBIOS ont été conçus pour un réseau qui affiche un faible délai de transit moyen et un faible taux de perte de paquet. Une zone de diffusion fondée sur IGMP doit posséder les mêmes caractéristiques. En pratique, cela va tendre à contraindre les zones de diffusion IGMP à un champ de réseaux interconnectés par des routeurs à grande vitesse et des liaisons inter-routeurs. Il est peu vraisemblable que des zones de diffusion transcontinentales puissent afficher les caractéristiques requises.

Appendice B Considérations pour la mise en œuvre

Le présent appendice contient un exposé de soutien technique. Il ne fait pas partie intégrante de la spécification NetBIOS sur TCP.

B-1. Modèles de mise en œuvre

Il doit y avoir, sur tout système participant, une sorte de service NetBIOS pour coordonner l’accès à ce système par des applications NetBIOS.

Pour analyser l’impact de l’architecture NetBIOS sur TCP, on utilise les trois modèles suivants de la façon dont un service NetBIOS pourrait être mis en œuvre :

1. Modèle combiné service et application
Le service et l’application NetBIOS sont tous deux contenus dans un seul processus. Aucune communication inter processus n’est supposée au sein du système ; toute la communication est sur le réseau. Si plusieurs applications requièrent des accès concurrents au service NetBIOS, elles doivent se plier à ce processus monolithique.

2. Modèle à élément de noyau commun
Le service NetBIOS fait partie du système d’exploitation (peut-être comme pilote d’appareil sur un processeur frontal). Les applications NetBIOS sont des processus normaux d’application du système d’exploitation. L’élément de service NetBIOS commun contient toutes les informations, comme le nom et les tableaux d’écoute, requis par la coordination des activités des applications.

3. Modèle à élément commun non noyau
Le service NetBIOS est mis en œuvre comme processus d’application de système d’exploitation. Les applications NetBIOS sont d’autres processus d’application du système d’exploitation. Le service et les applications échangent des données via des communications interprocessus du système d’exploitation. Dans un système d’exploitation multiprocesseur (par exemple, un réseau) chaque module peut résider sur un CPU différent. Le processus de service NetBIOS contient toutes les informations partagées requises pour coordonner les activités des applications NetBIOS. Les applications peuvent encore exiger une bibliothèque de sous-programmes pour faciliter l’accès au service NetBIOS.

Pour tous ces modèles de mise en œuvre, le service TCP/IP peut être localisé dans le système d’exploitation ou partagé entre les applications NetBIOS et les processus de service NetBIOS.

B-1.1 Considérations indépendantes du modèle

Le service de nom NetBIOS associe un nom NetBIOS à un hôte. Le service de session NetBIOS lie le nom à un accès TCP spécifique pour la durée de la session.

Le service de nom n’a pas besoin d’être informé de chaque initiation et achèvement d’écoute. Comme les noms ne sont liés à aucun accès TCP dans le service de nom, le service de session peut utiliser un accès TCP différent pour chaque session établie avec le même nom local.

L’accès TCP utilisé pour la phase de transfert des données d’une session NetBIOS peut être mondialement bien connu, ou éphémère. Le choix est une question de mise en œuvre locale. Le mécanisme RETARGET (reciblage) permet de lier la session NetBIOS à une connexion TCP avec tout accès TCP, même avec un autre nœud IP.

Une mise en œuvre peut utiliser l’accès TCP mondialement bien connu du service de session pour la phase de transfert de données de la session en n’utilisant pas le mécanisme RETARGET, et en acceptant plutôt la session sur la connexion TCP initiale. Ceci peut être permis parce que l’appelant utilise toujours un accès TCP éphémère.

La complexité du mécanisme RETARGET de l’extrémité appelée n’est exigée que si une mise en œuvre particulière en a besoin. Pour de nombreux environnements de systèmes réels, comme une mise en œuvre de service NetBIOS incorporée au noyau, il ne sera pas nécessaire de recibler les appels entrants. Toutes les sessions NetBIOS peuvent plutôt être multiplexée à travers le seul accès de service de session NetBIOS bien connu. Ces mises en œuvre ne seront pas accablées par la complexité du mécanisme RETARGET, pas plus qu’il ne sera exigé des appelants qu’ils sautent à travers les boucles de reciblage.

Néanmoins, tous les appelants doivent être prêts à traiter toutes les Réponses de reciblage de session possibles.

B-1.2 Fonctionnement de service pour chaque modèle

Il est possible de construire un service NetBIOS fondé sur la présente spécification pour chacun des modèles de mise en œuvre définis ci-dessus.

Pour le modèle d’élément de noyau commun, tous les services NetBIOS, nom, datagramme, et session, sont simples. Toutes les informations sont contenues dans une seule entité et il est donc facile d’y accéder ou de les modifier. Un seul accès ou plusieurs accès peuvent être utilisés pour les sessions NetBIOS sans ajouter aucune complexité significative à la procédure d’établissement de session. La seule ombre au tableau est la quantité de redondance impliquée par l’obtention des messages NetBIOS et de fonctionnement des demandes/réponses à travers les frontières entre utilisateur et système d’exploitation.

Le modèle combiné service et application est très semblable au modèle d’élément de noyau commun en termes d’exigences pour le service NetBIOS. La difficulté majeure est la coordination interne des multiples services NetBIOS et des processus d’application existants dans un système de ce type.

Les protocoles NetBIOS de nom, datagramme et session supposent que les entités aux points d’extrémité ont le plein contrôle des divers accès TCP et UDP bien connus. Si une mise en œuvre a plusieurs entités de service NetBIOS, comme ce serait le cas, par exemple, avec plusieurs applications liées entre elles dans une bibliothèque NetBIOS, cette mise en œuvre doit alors imposer une certaine coordination interne. Autrement, l’utilisation des accès NetBIOS pourrait être périodiquement allouée

Pour la mise en œuvre normale du mode d’élément commun non-noyau, il existe trois processus NetBIOS de service permanents à l’échelle du système :
- le serveur de nom
- le serveur de datagramme
- et le serveur de session

Chaque serveur écoute les demandes provenant du réseau sur l’accès UDP ou TCP bien connu. Chaque application incorpore une petite partie du service NetBIOS, éventuellement une bibliothèque. Chaque bibliothèque de soutien NetBIOS de l’application aura besoin d’envoyer un message au serveur particulier pour demander une opération, comme d’ajouter un nom ou envoyer un datagramme ou établir une écoute.

Le modèle d’élément commun non-noyau n’exige pas qu’une connexion TCP soit passée entre les deux processus, serveur de session et application. L’opération RETARGET pour une écoute NetBIOS active pourrait être utilisée par le serveur de session pour rediriger la session vers une autre connexion TCP sur un accès alloué et possédé par la bibliothèque de soutien NetBIOS de l’application. L’application qui a un service TCP/IP incorporé ou fondé sur le noyau pourrait alors accepter la demande de connexion reciblée et la traiter indépendamment du serveur de session.

Sur Unix(tm) ou POSIX(tm), le serveur de session NetBIOS pourrait créer des sous processus pour les connexions entrantes. Les sessions ouvertes seraient passées par "fork" et "exec" au successeur comme descripteur de fichier ouvert. Cette approche est cependant très limitée. Un processus préexistant ne pourrait pas recevoir d’appel entrant. Et tous les processus d’appelé devraient être des sous processus du serveur de session.

B-2 Applications NetBIOS casuelles et interdites

Comme NetBIOS a été conçu pour fonctionner dans l’environnement de système ouvert de l’ordinateur individuel normal, il n’a pas le concept d’application privilégiée ou non privilégiée. Dans de nombreuses applications de systèmes d’exploitation multi-utilisateur ou multi-tâches, des capacités privilégiées sont allouées. Ces capacités limitent la possibilité d’acquisition et d’utilisation des ressources du système par les applications. Pour ces systèmes il est important de permettre des applications casuelles, celles avec des privilèges systèmes limités, et des applications privilégiées, avec des capacités de 'super-utilisateur' mais avec des restrictions à leur accès et leurs ressources, pour les services d’accès NetBIOS. Il est aussi important de permettre aux administrateurs de système de restreindre certaines ressources NetBIOS à des applications NetBIOS particulières. Par exemple, un serveur de fichiers fondés sur les services NetBIOS ne devrait être capable d’avoir des noms et accès TCP que pour les sessions qu’il peut utiliser.

Une application NetBIOS a besoin d’au moins deux ressources locales pour communiquer avec une autre application NetBIOS, un nom NetBIOS pour elle-même et, normalement, une session. Un service NetBIOS ne peut pas exiger que les applications NetBIOS utilisent directement des ressources système privilégiées. Par exemple, de nombreux systèmes exigent des privilèges pour utiliser les accès TCP et UDP avec des numéros inférieurs à 1024. La présente RFC exige des accès réservés pour les noms et serveurs de session d’une mise en œuvre de service NetBIOS. Elle n’exige pas que l’application ait un accès direct à ces accès réservés.

Pour le service de nom, le gestionnaire du tableau des noms local doit avoir accès à l’accès UDP réservé du service de nom NetBIOS. Il a besoin d’écouter les paquets UDP du service de nom pour défendre et définir ses noms locaux sur le réseau. Cependant, Ce gestionnaire n’a pas besoin d’être partie à l’application d’utilisateur dans un environnement système qui a des restrictions de privilèges sur les accès réservés.

Le serveur de nom interne peut exiger certains privilèges pour ajouter, supprimer, ou utiliser un certain nom, si une mise en œuvre veut la restriction. Cette restriction est indépendante du fonctionnement des protocoles du service NetBIOS et n’empêcherait pas nécessairement l’interopération de cette mise en œuvre avec une autre.

Le serveur de session est obligé de posséder un accès TCP réservé pour l’établissement de session. Cependant, l’ultime connexion TCP utilisée pour émettre et recevoir des données n’a pas à être à travers cet accès réservé. RETARGET configure la session NetBIOS pour qu’elle soit passée sur une autre connexion TCP, éventuellement à travers un accès différent à l’extrémité appelée. Cet accès peut être une ressource non privilégiée, d’une valeur supérieure à 1023. Cela facilite les applications casuelles.

Autrement, le mécanisme RETARGET permet que l’accès TCP utilisé pour l’émission et la réception des données soit un accès réservé. Par conséquent, une application qui souhaite que la maintenance de son accès soit effectuée par l’administrateur de système peut utiliser ces accès TCP restreints. Cela facilite les applications privilégiées.

Une mise en œuvre particulière peut souhaiter exiger des privilèges particuliers supplémentaires pour l’établissement de session, qui pourraient être associés à des informations internes. Cela n’a pas besoin d’être seulement fondé sur l’allocation d’accès TCP. Par exemple, un nom NetBIOS donné ne peut être utilisé pour les sessions que par des applications ayant un certain niveau de privilège système.

La décision d’utiliser des accès réservés ou non réservés ou d’ajouter un enregistrement de nom supplémentaire et autorisation d’usage est une décision de mise en œuvre purement locale. Elle n’est pas exigée par les protocoles NetBIOS spécifiés dans la présente RFC.

B-3 TCP contre les KEEP-ALIVE de session

KEEP-ALIVE est un élément de protocole utilisé pour valider l’existence d’une connexion. Un paquet est envoyé au partenaire de connexion distant pour solliciter une réponse qui montre que la connexion fonctionne toujours. Les KEEP-ALIVE de TCP sont utilisés au niveau TCP sur les connexions TCP alors que les KEEP-ALIVE de session sont utilisés sur les sessions NetBIOS. Ces opérations de protocole sont toujours transparentes pour l’utilisateur de la connexion. L’utilisateur ne sera au courant de l’opération KEEP-ALIVE que si elle échoue, et donc, si la connexion est perdue.

La spécification NetBIOS [2] exige que le service NetBIOS informe l’utilisateur de la session si une session est perdue lorsqu’elle est en état passif ou actif. Donc, si l’utilisateur de session est seulement en attente d’une opération de réception et que la session est abandonnée, le service NetBIOS doit informer l’utilisateur de la session. Il ne peut pas attendre une opération d’envoi de session avant d’informer l’utilisateur de la perte de la connexion.

Cette exigence découle de la gestion de ressources rares ou volatiles par une application NetBIOS. Si un utilisateur particulier termine une session avec une application de serveur en détruisant l’application client ou le service NetBIOS sans un raccrochage NetBIOS, l’application serveur voudra nettoyer ou libérer les ressources allouées. Si cette application serveur reçoit seulement puis envoie une réponse, elle exige que la notification de l’interruption de la session intervienne dans l’état passif.

La définition standard d’un service TCP ne peut pas détecter la perte d’une connexion dans un état passif, dans l’attente de l’arrivée d’un paquet. Certaines mises en œuvre TCP ont ajouté l’opération KEEP-ALIVE qui interopère avec les mises en œuvre sans ce dispositif. Ces mises en œuvre envoient un paquet avec un numéro de séquence invalide pour le partenaire de connexion. Le partenaire, par spécification, doit répondre par un paquet montrant le numéro de séquence correct de la connexion. Si aucune réponse n’est reçue du partenaire distant dans un certain intervalle de temps, le service TCP supposera que la connexion est perdue.

Comme de nombreuses mise en œuvre TCP n’ont pas cette fonction KEEP-ALIVE, une opération KEEP-ALIVE NetBIOS facultative a été ajoutée aux protocoles de session NetBIOS. Le KEEP-ALIVE NetBIOS utilise les propriétés de TCP pour solliciter une réponse de la part du partenaire de connexion distant. Un message de session NetBIOS appelé KEEP-ALIVE est envoyé au partenaire distant. Comme il en résulte que TCP envoie un paquet IP au partenaire distant, la connexion TCP est active. TCP va découvrir que la connexion TCP est perdue si le partenaire TCP distant n’accuse pas réception du paquet IP. Donc, le service de session NetBIOS n’envoie pas de réponse à un message de session KEEP ALIVE. Il se contente de l’éliminer. Le service de session NetBIOS qui transmet le KEEP ALIVE n’est informé que de la défaillance de la connexion TCP. Il n’attend pas un message de réponse spécifique.

Une mise en œuvre NetBIOS particulière devrait utilise les KEEP-ALIVE si elle est concernée par le maintien de la compatibilité avec la spécification d’interface NetBIOS [2]. La compatibilité est particulièrement importante si la mise en œuvre souhaite prendre en charge les applications NetBIOS existantes, qui exigent normalement la détection de perte de session sur leurs serveurs, ou des applications futures qui ont été développées pour être mises en œuvre avec la détection de perte de session.

B-4 Algorithmes de reciblage

Ce paragraphe contient deux suggestions pour les algorithmes de reciblage. On les appelle les méthodes "straight" (directe) et "stack" (pile). L’algorithme dans le corps de la RFC utilise la méthode directe. La mise en œuvre de l’un ou l’autre algorithme doit tenir compte du nombre maximum d’essais d’établissement de session. Le compte des essais est le nombre maximum d’opérations de connexions TCP admis avant le rapport d’échec.

La méthode directe force la procédure d’établissement de session à commencer un essai avant un échec de reciblage avec le nœud initial retourné de la procédure de découverte du nom. Un échec de reciblage se produit lorsqu’une tentative de connexion TCP échoue à cause d’une fin de temporisation ou de la réception d’une Réponse de session négative avec un code d’erreur spécifiant NOT LISTENING ON CALLED NAME (pas d’écoute sur le nom appelé). Sur tout autre échec, la procédure d’établissement de session devrait réessayer à partir de l’appel jusqu’à la procédure de découverte du nom.

Un minimum de deux essais, à partir du reciblage ou de l’échec de découverte du nom. Cela donnera au service de session une chance de rétablir une écoute Netbios ou, plus important, de permettre au domaine d’application NetBIOS, au service de nom local ou au NBNS, de réapprendre l’adresse IP correcte d’un nom NetBIOS.

La méthode de la pile fonctionne de la même façon que la méthode directe. Cependant, au lieu de réessayer au retour au nœud initial par la procédure de découverte du nom, elle redémarre avec l’adresse IP du dernier nœud qui a envoyé une Réponse de reciblage de session avant l’échec du reciblage. Pour limiter la méthode de la pile, chaque hôte peut être essayé seulement un maximum de deux fois.

B-5 Service NBDD

Si le NBDD ne transmet pas les datagrammes, on ne fournit alors pas les services de datagramme NetBIOS Group et Broadcast à l’utilisateur NetBIOS. Donc, on ignore la mise en œuvre de la demande d’interrogation lorsqu’on obtient une réponse négative, on acquiert la liste des membres des adresses IP et on envoie le datagramme en envoi individuel à chaque membre.

B-6 Considérations pour l’application

B-6.1 Utilisation des datagrammes NetBIOS

Certaines applications NetBIOS existantes utilisent les datagrammes NetBIOS comme fondement de leurs propres protocoles orientés connexion. Cela peut causer une activité excessive d’interrogation de nom NetBIOS et faire peser un fardeau substantiel sur le réseau, les nœuds serveurs, et autres nœuds d’extrémité. Il est recommandé d’éviter cette pratique dans les nouvelles applications.