Zusammenfassung

  • RFC 1001 und RFC 1002 trennen die Registrierung und Suche von Namen durch den NetBIOS Name Server (NBNS) von der Verteilung von Gruppendatagrammen durch einen NetBIOS Datagram Distribution Server (NBDD).
  • Für P- und M-Knoten bedeutet eine positive NBDD-Antwort nur, dass der Server die Weiterleitung zusagt. Die Spezifikation lässt eine teilweise Verteilung oder Ablehnung zu und liefert dem Absender keinen Empfangsnachweis für jedes Mitglied.

In einem lokalen Netz mit Broadcast kann ein Absender eine Gruppe adressieren, ohne jedes Mitglied als einzelnes Ziel aufzulisten. Sobald dieser Dienst über geroutete Netze hinweg funktionieren soll, stellen sich zwei getrennte Fragen: Wer kennt die Mitglieder, und wer vervielfältigt das Datagramm für sie? Die im März 1987 vorgeschlagenen RFC 1001 und RFC 1002 beantworten sie mit zwei logischen Rollen. Der historische Kern liegt in dieser Trennung: Ein Namensserver kann die Inhaber eines Namens auffindbar machen, ohne deshalb den Verkehr an sie zu verteilen.

Die Dokumente unterscheiden B-, P- und M-Knoten. B-Knoten arbeiten in einem Broadcast-Bereich; P-Knoten stützen sich auf Punkt-zu-Punkt-Infrastruktur; M-Knoten verbinden Eigenschaften beider Modelle. Im P/M-Pfad geht ein Datagramm für einen eindeutigen Namen direkt an die ermittelte IP-Adresse. Bei einem Gruppennamen oder dem NetBIOS-Broadcast-Namen sendet der Ursprung dagegen per Unicast an einen NBDD. Dieser soll das Datagramm an die zum Zielnamen gehörenden Knoten weiterleiten. Der Pfad setzt nicht voraus, dass IP-Broadcast über alle Netzabschnitte hinweg verfügbar ist.

NBNS und NBDD sind getrennte logische Instanzen, auch wenn ein Gerät beide Funktionen ausführen darf. Sind sie getrennt, erlaubt RFC 1001 einen privaten Austausch von Namensinformationen, legt dessen Protokoll aber nicht fest. Damit entsteht eine Abhängigkeit: Der Verteiler muss den Gruppennamen mit seinen Empfängern verknüpfen können. Der Standard macht aus dem privaten Austausch jedoch weder ein interoperables Verfahren noch einen für den Absender sichtbaren Ergebnisnachweis.

Ein P- oder M-Knoten kann den NBDD vor dem Senden fragen, ob er für einen bestimmten Zielnamen verteilen wird. Eine positive Antwort besagt, dass der Server die Weiterleitung ankündigt. Bei einer negativen Antwort kann der Absender vom NBNS die Liste der Namensinhaber anfordern und jedem einzeln ein Unicast-Datagramm schicken. Die Anfrage ist freiwillig. RFC 1002 erlaubt auch das sofortige Senden; dabei kann der NBDD das Datagramm verwerfen. Das sind alternative Steuerungswege, keine Bestätigungen einer bereits abgeschlossenen Zustellung.

Die Beweisgrenze liegt hinter der Anfrage. RFC 1001 erlaubt dem NBDD, die Verteilung vollständig, nur teilweise oder gar nicht auszuführen. Außerhalb der Anfrage gibt es laut RFC keine Rückmeldung an den Absender, ob ein Datagramm weitergeleitet wurde. Eine positive Auskunft über die Fähigkeit oder Bereitschaft des Servers ist daher kein Zustellbeleg für den Fan-out. Die Spezifikation kennt keinen Empfangsnachweis je Ziel und belegt nicht, dass jeder registrierte Gruppenname auch alle Mitglieder erreicht.

Auch den Multicast-Kontext sollte man präzise formulieren. RFC 1001 geht von einer Umgebung aus, in der eine Implementierung nicht auf Broadcast oder Multicast im gesamten Internet zählen konnte; ein Anhang skizziert daneben die Einbindung von Internet Group Multicasting. Das bedeutet nicht, dass IP-Multicast zuvor nicht vorgeschlagen worden war. Die im Juli 1986 veröffentlichte RFC 988 beschrieb bereits IP-Host-Multicast mit mehreren Unterstützungsstufen. Der engere Befund lautet: Der NetBIOS-Entwurf konnte keine allgemeine Multicast-Verfügbarkeit voraussetzen.

RFC 1001 und RFC 1002 bezeichnen sich als Proposed Standards. Sie dokumentieren einen Entwurf, nicht dessen Einsatz in einem bestimmten Netz, einheitliches Verhalten aller Implementierungen oder den Empfang jedes Datagramms durch Anwendungen. RFC 1001 hält außerdem die Aktivitäten von B-Knoten außerhalb der Sicht der NBNS/NBDD-Unterstützungsserver und definiert diese nicht als Brücken zu B-Knoten. Die Zuständigkeiten sind klarer beschrieben als der Nachweis eines Ende-zu-Ende-Ergebnisses.

Der Zuschnitt grenzt diesen Beitrag auch von RFC 1088 ab, in der es um die lokale Ableitung eines NetBIOS-Namens aus einer IP-Adresse und eine lokale Namenstabelle geht: Namenszuordnung und Verteilung eines Gruppendatagramms beantworten verschiedene Fragen. Die Unterscheidung reicht über NetBIOS hinaus: eine Zielmenge entdecken, einem Relay die Verteilung an diese Menge überlassen, Pakete weiterleiten und ihren Empfang feststellen sind verschiedene Vorgänge. Im Entwurf von 1987 beschrieben die Steuerungsnachrichten die frühen Entscheidungen, nicht das vollständige Zustellergebnis aus Sicht des Absenders.