Resumen

  • Las RFC 1001 y 1002 asignaron el registro y descubrimiento de nombres al NetBIOS Name Server (NBNS), y la distribución de datagramas de grupo a un NetBIOS Datagram Distribution Server (NBDD).
  • En la ruta de los nodos P y M, una respuesta positiva del NBDD expresaba que el servidor aceptaría reenviar; no demostraba que cada destinatario hubiese recibido el datagrama. La distribución también podía ser parcial o denegada.

En una LAN basada en difusión, el emisor puede dirigirse a un grupo sin convertir a cada integrante en un destino individual. Al llevar esa función a redes enrutadas, aparecen dos preguntas distintas: quién conoce a los miembros y quién replica el datagrama para alcanzarlos. Las RFC 1001 y RFC 1002, publicadas como propuestas en marzo de 1987, asignaron esas tareas a dos funciones lógicas. La separación es la clave histórica: un servidor podía localizar quién poseía un nombre sin ser por ello el distribuidor del tráfico.

Los documentos describen nodos B, P y M. El modelo B trabaja con un ámbito de difusión; los nodos P dependen de infraestructura punto a punto, y los M combinan aspectos de ambos. Para P y M, los datagramas dirigidos a un nombre único van directamente a la dirección descubierta. En cambio, un nombre de grupo o el nombre de difusión NetBIOS lleva al emisor a enviar el datagrama por unicast a un NBDD, que debe retransmitirlo a los nodos asociados con el nombre de destino. El diseño no presupone que una difusión IP vaya a funcionar a través de todos los segmentos.

NBNS y NBDD son entidades lógicas separadas, aunque un mismo equipo puede cumplir ambos papeles. Si operan por separado, la RFC 1001 permite que intercambien información de nombres mediante un protocolo privado que la propia RFC no define. Así surge una dependencia: el distribuidor necesita relacionar el nombre de grupo con sus destinatarios, pero la especificación no convierte ese intercambio privado en un registro interoperable ni en una evidencia del resultado visible para el emisor.

Antes de enviar, un nodo P o M puede preguntar al NBDD si repartirá el datagrama para un nombre determinado. Una respuesta afirmativa significa que el servidor dice que lo retransmitirá. Si responde negativamente, el emisor puede pedir al NBNS la lista de propietarios y enviar un unicast individual a cada dirección. La consulta es opcional: la RFC 1002 también permite enviar de inmediato, con el riesgo de que el NBDD descarte el datagrama. Son caminos de control alternativos; ninguno equivale a una confirmación de entrega.

La limitación aparece después de la consulta. La RFC 1001 permite que el NBDD complete la distribución, la complete solo parcialmente o la rechace. También dice que, más allá de la consulta, no hay información de retorno que indique al emisor si hubo reenvío. Una respuesta positiva sobre la capacidad o disposición del servidor no es un recibo de la difusión. La especificación no aporta una constancia por destinatario ni demuestra que todos los miembros hayan recibido el paquete. Que el nombre esté registrado o que el servidor responda sí no alcanza para probarlo.

El contexto del multicast requiere precisión. La RFC 1001 plantea un entorno en el que una implementación no podía dar por supuesto que todos los nodos y redes soportaran difusión o multicast de Internet, y su apéndice bosqueja una integración con Internet Group Multicasting. Eso no quiere decir que el multicast IP no existiera como propuesta: la RFC 988, de julio de 1986, ya había planteado extensiones de multicast para hosts con distintos niveles de soporte. La conclusión acotada es que el diseño NetBIOS no podía contar con un servicio multicast universal.

Las dos RFC se presentan como propuestas de estándar. Describen una arquitectura; no prueban que una red concreta la desplegara, que todas las implementaciones se comportaran igual ni que las aplicaciones recibieran cada datagrama. La RFC 1001 también deja las actividades de los nodos B fuera de la visibilidad de los servidores de apoyo NBNS/NBDD y no exige que estos hagan de puente hacia aquellos. El texto define con más claridad las funciones que la prueba de un resultado de extremo a extremo.

El alcance también distingue este artículo de la RFC 1088, que trata la derivación local de un nombre NetBIOS a partir de una dirección IP y su tabla de nombres: asignar un nombre y distribuir un datagrama de grupo responden a preguntas distintas. La lección no pertenece solo a NetBIOS: descubrir un conjunto de destinos, encargar el reenvío a un servidor, transmitir paquetes y observar su recepción son hechos distintos. En esta propuesta de 1987, los intercambios de control daban información sobre las primeras decisiones; el emisor no recibía una confirmación completa de la entrega.