Wie ein Rechner die Cronus-Rundrufe ins nächste Netz trug

Zusammenfassung

• Cronus musste Ressourcen auf anderen LANs finden, obwohl seine lokalen Suchrufe dort nicht ankamen. Ein Hostprozess wählte die nötigen Nachrichten aus; ein zweiter sendete sie am Ziel erneut aus.
• Die Betreiber des Systems konnten die Empfängerliste ändern, ohne Gateways anderer Stellen umzubauen. Dafür weckte jedes eintreffende UDP-Paket den Filterprozess auf einem gemeinsam genutzten Rechner.

Die Suche nach einem Dienst beginnt oft, bevor dessen Adresse bekannt ist. Innerhalb eines LAN konnte Cronus dafür einen Rundruf verwenden. In einem anderen Netz kam die Frage nicht an, obwohl die beiden Netze über Gateways verbunden waren. Für die Betreiber wurde daraus mehr als ein Problem der Paketweiterleitung: Sollten sie bei jeder Änderung des Versuchssystems die Verantwortlichen des anderen Netzes einbeziehen müssen?

Die Entwickler von Cronus hielten genau diese Abhängigkeit für einen Nachteil. Gateways konnten von einer anderen Organisation betrieben werden als derjenigen, die Cronus konfigurierte. Eine Änderung am Versuchssystem würde dann zusätzliche Abstimmung verlangen.

Es ging dabei um eine Grundfunktion des Systems. Cronus nutzte die Rundrufe sowohl zur Ressourcensuche als auch zur Abfrage des Serverzustands. Ein Host, der über das Netz erreichbar, für diese Fragen aber unsichtbar war, konnte aus Sicht des Suchmechanismus nicht wie ein normaler Teilnehmer wirken. Der RFC berichtet keinen konkreten Ausfall; er erklärt, warum die Entwickler diese Lücke als Konstruktionsproblem behandelten und die Verantwortung für ihre Behebung nicht an die Infrastruktur abgeben wollten.

Ken Lebowitz und David Mankins von BBN Laboratories machten diesen organisatorischen Punkt in RFC 947 vom Juni 1985 ausdrücklich zum Bestandteil ihrer technischen Abwägung. Ihr verteiltes Betriebssystem sollte Dienste auf unterschiedlichen Rechnertypen zusammenbringen, auch wenn die beteiligten Rechner auf mehreren lokalen Netzen standen.

Cronus nutzte TCP und UDP. Um Ressourcen zu finden oder den Zustand mehrerer Server abzufragen, setzte es auch Broadcasts ein: Rundrufe, die die Hosts im lokalen Netz erreichten. Der Absender musste dafür nicht vorab jeden möglichen Antwortgeber kennen. Der Vorteil endete jedoch am physischen Netz. Eine lokale Aussendung erreichte auf diesem Weg keine Rechner in einem entfernten LAN.

Dabei benötigte Cronus meist nur einen Teil der Empfänger. Multicast wäre passender gewesen, schrieben die Autoren, stand aber in manchen ihrer Netzimplementierungen nicht zur Verfügung. Die ersten Hilfsprogramme verwendeten deshalb Broadcast. Schon RFC 919 von 1984 hatte dessen Preis erläutert: Jeder Host, der einen Rundruf hört, muss sich zumindest ein wenig damit beschäftigen.

Eine Datei bestimmte die Reichweite

Die gewählte Lösung bestand aus zwei Prozessen. Ein Weiterleiter auf einem Host suchte passende lokale UDP-Broadcasts heraus, zunächst anhand der von Cronus benutzten Ports. Er verpackte sie in eine Nachricht an einen Repeater im entfernten Netz. Dieser sendete das Paket dort erneut als Broadcast aus und behielt die ursprüngliche Quelladresse bei.

Beim Start las der Weiterleiter eine Datei mit Repeater-Adressen und Auswahlregeln. Für unterschiedliche Ziele konnten unterschiedliche Pakete vorgesehen sein. Der Prozess baute TCP-Verbindungen auf und versuchte fehlgeschlagene Verbindungen regelmäßig erneut. Die Datei durfte auch gewöhnliche Hosts nennen; an diese ging ein UDP-Datagramm direkt, ohne erneute Aussendung an deren ganzes LAN.

Eine Erweiterung der Gateways hätte ebenfalls Listen entfernter Empfänger benötigt. Die Entwickler wollten dafür aber weder zusätzliche Steuerungsfunktionen voraussetzen noch davon abhängen, dass sämtliche Gerätehersteller die Funktion anboten. Die Auswahl der relevanten Nachrichten sollte zudem nahe genug an der Anwendung liegen. Zusammen mit der möglichen Trennung der Betreiber sprach dies für einen eigenen Dienst auf Hosts.

Auch eine Unterbringung im Cronus-Kernel wurde erwogen. Nach Darstellung der Autoren hätten dabei alle Teilnehmer die Adressen der anderen kennen müssen, oder die Lösung wäre auf Cronus beschränkt geblieben. Ein eigenständiger Repeater ließ sich gesondert konfigurieren und kam auch für andere Broadcast-Anwendungen infrage.

Was der VAX dafür tun musste

Die Quelladresse unverändert weiterzugeben erforderte einen Eingriff in die BBN-Implementierung von TCP/IP. Privilegierte Prozesse mussten IP-Pakete mit der Quelladresse eines anderen Hosts senden dürfen. Die beschriebene Lösung hatte damit eine konkrete Voraussetzung im verwendeten Netzwerkcode.

Die Adresse half außerdem, Rückkopplungen einzudämmen. Der Weiterleiter verband sich nicht mit einem Repeater im eigenen LAN. Er leitete auch keine Pakete weiter, deren Quelladresse außerhalb seines LAN lag. So sollten erneut ausgesendete Nachrichten nicht wieder zurücklaufen. Eine Prüfung der Identität des Absenders war damit nicht gegeben.

Die Autoren berichteten von zwei Ethernets, zwischen denen zwei weitere LANs lagen. Die Nachrichten mussten mindestens zwei Gateways passieren. Ein VAX mit 4.2BSD UNIX und BBN-Netzwerksoftware betrieb den Dienst, der nach ihrer Darstellung seit einigen Monaten für ihre Zwecke gut funktionierte. Diese Aussage betrifft den beschriebenen Aufbau.

Derselbe Aufbau zeigte die Belastung. Da ein Programm im Benutzerraum die Pakete auswählte, musste der Weiterleitungsprozess für jedes UDP-Paket aufwachen, das den Host erreichte. Auch ein später verworfenes Paket hatte dann bereits Arbeit verursacht. Die Autoren bezeichneten den Mehraufwand auf den gemeinsam genutzten Hosts als beträchtlich, lieferten jedoch keine Messreihe.

Sie diskutierten, nur die Filterung in den Systemkernel zu verschieben und Konfiguration sowie Wiederholung im Benutzerraum zu belassen. Als weitere Möglichkeit planten sie einen spezialisierten Dienst auf einem bereits vorhandenen Mikrocomputer mit Echtzeitsystem. Ob diese Änderungen umgesetzt wurden, steht nicht in der RFC.

Der Versuch vergrößerte somit den Bereich, den Cronus mit seinen Rundrufen erreichen konnte. Zugleich machte er sichtbar, was die Betreiber dafür übernahmen: eine laufende Auswahl- und Weiterleitungsaufgabe. Die zusätzliche Entscheidungsfreiheit hatte einen Rechner, auf dem sie ausgeführt werden musste. Der RFC 922 behandelt den zeitgenössischen IP-Broadcast mit Subnetzen. Der spätere RFC 1112 spezifizierte IP-Multicast, belegt aber keine Ablösung dieser Cronus-Installation.