Zusammenfassung

  • Freiwillige veröffentlichten strukturierte Beschreibungen von Rechnern und Verbindungen in comp.mail.maps, aus denen pathalias Mailrouten berechnen konnte.
  • Die Karte war keine amtliche Echtzeit-Topologie: Jeder Standort ergänzte eigene Angaben, und die Genauigkeit hing davon ab, ob Betreiber Änderungen meldeten.

Eine Route konnte eine Reihe von Rechnern nennen. Zuerst musste jedoch bekannt sein, welche davon eine Nachricht weiterleiten konnten. Im Januar 1984 brachte eine Birds-of-a-Feather-Sitzung bei USENIX mehr als dreißig Freiwillige zusammen, die eine UUCP-Karte aufbauen und pflegen wollten. Eine spätere Projektgeschichte hält fest, dass pathalias bereits Routen berechnen konnte, eine vollständige Netzkarte aber fehlte. Die Beteiligten nannten ihre Initiative UUCP Project und verbreiteten regionale Aktualisierungen über die Usenet-Gruppe comp.mail.maps. Als die anfängliche USENIX-Finanzierung endete, machten Freiwillige weiter.

Die Karte war kein zentraler Router, der allen einen Weg vorschrieb. Ihre Einträge beschrieben Standorte: Rechnernamen, Organisationen, Ansprechpartner, Geräte, Verbindungen und gemeldete Kosten oder Verbindungsrhythmen. Ein reproduziertes README vom Juli 1985 erklärt, dass pathalias die gemeinsame Karte zusammen mit lokalen Path.*-Ergänzungen verarbeitete. Jeder Standort berechnete damit seine eigenen Mailwege. Das gemeinsame Dokument zeigte mögliche Zwischenstationen; lokale Daten und Betriebspraxis bestimmten, welche davon tatsächlich in die Berechnung eingingen.

Die Verbindungen unterschieden sich stark. Manche liefen über lokale Netze oder Standleitungen, andere über Ortsgespräche, Ferngespräche oder nächtliche Abrufe. Das README gab pathalias ungefähre Kosten vor, die vor allem die verstrichene Zeit und nicht nur die Übertragungsrate abbildeten. Eine langsamere, aber häufig verfügbare Verbindung konnte sinnvoller sein als eine schnelle und teure. Das war ein Betriebsmodell für Mailtransport, keine IP-Latenzmessung und keine Garantie, dass ein Ziel gerade erreichbar war.

Die Projektunterlagen begrenzten auch den Umfang der Veröffentlichung. Organisationen mit vielen internen Rechnern sollten wenige Gateways eintragen und ihre lokalen Details in einer privaten Ergänzung halten. Aufgenommen werden sollten UUCP-Hosts, die aus dem größeren Cluster erreichbar waren. Ein Eintrag war eine Koordinationshilfe für Mailprogramme und Kontaktsuche. Er bewies weder eine direkte IP-Verbindung noch einen aktuellen Dienst oder die Zugehörigkeit zum gesamten Internet.

Ein australischer Nutzerverbandsbeitrag von 1988 zeigt einen praktischen Einsatz. Seit 1986 sammelten Betreiber Angaben zu ACSnet-Knoten in aus.map, hielten sie auf einem bestimmten Rechner vor und gaben Teile davon für die weltweite UUCP-Verteilung weiter. An der University of Sydney sammelten Skripte Usenet-Beiträge, entpackten Shell-Archive und bauten einen durchsuchbaren Index. Die Karte beantwortete Fragen, die in den Netzstatusdateien fehlten: Wer betrieb einen Rechner, welches Unix lief darauf? Sie ergänzte diese Dateien, ersetzte sie aber nicht.

Die genannten 266 Einträge bezogen sich auf ACSnet und nicht auf das weltweite UUCP-Netz. Der Beitrag beschreibt die Erfassungslücken: Neue Knoten lieferten ihre Angaben nicht immer selbst, und ein stiller Rechner konnte ausgefallen oder verschwunden sein. Beziehungen für den Nachrichtenaustausch galten als besonders unsichere Kartendaten. Die gemeinsame Darstellung machte das Netz sichtbarer, beseitigte aber nicht die Unsicherheit darüber, wer den Bestand bestätigen konnte.

Im November 1990 beschrieb ein Usenet-Beitrag einen stärker automatisierten lokalen Ablauf: comp.mail.maps sammeln, Dateien entpacken, pathalias täglich per cron starten, eine lokale Routendatei erneuern und Administratoren bei Fehlern per Mail informieren. Automatisierung verkürzte die Zeit bis zur Nutzung, machte Meldungen aber nicht automatisch verlässlich. In einer Diskussion von 1987 über dynamisches Umrouten warnten Beteiligte, dass Routendatenbanken nicht rechtzeitig aktualisiert würden, um Schleifen sicher auszuschließen.

Der Erfolg bestand nicht in einer endgültigen zentralen Karte. Er lag in der Arbeitsteilung: Freiwillige sammelten Beschreibungen, Usenet transportierte Änderungen, lokale Skripte verarbeiteten sie und jeder Standort berechnete Wege unter seinen eigenen Bedingungen. So wurde ein Store-and-forward-Netz besser lesbar, ohne ein veröffentlichtes Dokument mit Betriebswissen über jede Verbindung zu verwechseln.

Quellen