Zusammenfassung

  • RFC 966 entwarf eine Adresse für eine Hostgruppe, deren Mitglieder beitreten, austreten oder zeitweise ganz fehlen konnten.
  • Auch ein Nichtmitglied durfte die offene Gruppe anschreiben. Eine gesendete Anfrage bewies weder aktuelle Mitgliedschaft noch erfolgte Zustellung oder Dienstleistung.

Ein Arbeitsplatzrechner ohne Festplatte braucht zum Start einen Server. Ist nur dessen alte Adresse gespeichert, kann der noch nicht gestartete Client die Adresse des Nachfolgers gerade nicht selbst erfragen. Nach jedem Serverwechsel müssten die Betreiber viele Clients einzeln berichtigen. Ein Broadcast an sämtliche Hosts belastet dagegen auch diejenigen, die nicht helfen können. Steve Deering und David Cheriton beschrieben im Dezember 1985 mit RFC 966 einen anderen Adressaten: die Gruppe der Rechner, die eine bestimmte Funktion erfüllen können. Das Dokument bat um Diskussion eines Modells; es war kein Nachweis eines flächendeckenden Betriebs.

Die Autoren nannten zwei Gründe für Multicast. Mehrere Empfänger mit einem Datagramm zu erreichen, ist der sichtbare. Der zweite war die verteilte Bindung eines Dienstwunsches an den jeweils geeigneten Rechner. Eine bekannte Adresse konnte für Namens- oder Bootserver stehen, obwohl die konkreten Hosts wechselten. Im Beispiel fragt ein Client eine Dateiservergruppe nach einem Namen; der Server, der ihn erkennt, antwortet anschließend direkt. Das ist eine Entwurfsszene und keine Messung der Erfolgsrate.

Eine Hostgruppe durfte sogar leer sein. Ein Rechner konnte mehreren Gruppen angehören; für kurzlebige Anwendungen waren temporäre Gruppen vorgesehen. Nach dem Austritt des letzten Mitglieds sollte eine solche Gruppe enden. CreateGroup, JoinGroup und LeaveGroup machten diese Veränderungen ausdrücklich zu Operationen. Ein dauerhafter Gruppenbezeichner bezeichnete damit eine mögliche Funktion, nicht eine ständig besetzte Maschinenliste.

Das Wort offen hatte einen präzisen Sinn: Der Absender brauchte nicht selbst Gruppenmitglied zu sein. Sonst hätte der nach einem Bootserver suchende Rechner der Servergruppe beitreten müssen, um eine Frage zu stellen. RFC 966 beschrieb daneben Schlüssel, mit denen die Mitgliedschaft beschränkt werden konnte. Mitglied werden, ein Datagramm senden und eine Anwendungsanfrage bewilligt bekommen sind verschiedene Berechtigungen. Aus einer erreichbaren Gruppenadresse folgt kein Anspruch auf den Dienst.

Die Entlastung des Clients erzeugte Arbeit im Netz. Gateways sollten festhalten, auf welchen Netzen Gruppenmitglieder saßen, und Änderungen weitergeben. Die Autoren räumten ein, dass die Konsistenz dieser verteilten Mitgliedschaftsdatensätze ungelöst blieb. Sie forderten als Ziel eine „Coverage“, bei der wiederholte Sendungen kein Mitglied systematisch übergehen; Fehlermeldungen betrachteten sie dennoch nur als Hinweise. Wer an eine Gruppe sendete, bekam dadurch keine Quittung jedes Empfängers.

RFC 988 löste den Vorschlag 1986 ab und formulierte die Trennung deutlich: Bei einer permanenten Gruppe ist die Adresse permanent, nicht ihre Besetzung. RFC 1112 bekräftigte 1989, dass Best-Effort-Multicast weder intakte Ankunft bei allen noch gleiche Reihenfolge garantiert. Diese Folge von Originaltexten belegt eine beständige Architekturidee, nicht die universelle Einführung jedes Details des Papiers von 1985.

Die historische Verschiebung liegt im Verhältnis von Funktion und Träger. Der Client durfte wissen, wonach er fragte, ohne zu wissen, welcher Host antworten würde. Das machte Dienste beweglicher. Es machte Mitgliedschaft, Weiterleitung und tatsächliche Antwort aber nicht zu ein und demselben Beleg.

Originalquellen und Grenzen

Grundlage sind RFC 966, RFC 988, RFC 1112 sowie der frühere Broadcast-Vorschlag RFC 919. Die Texte nennen keine erste produktive Einführung, Verbreitungsquote oder verifizierte Verfügbarkeit eines einzelnen Dienstes.