Zusammenfassung

  • RFC 1429 schildert LISTSERV DISTRIBUTE als BITNET-Dienst für große Verteiler: Nach Maßgabe der Topologie sollte eine Kopie stark beanspruchte Verbindungen überqueren und erst näher am Ziel geteilt werden. Der Autor nannte für 1993 zwei bis sechs Millionen Nachrichten täglich.
  • Die Betreiberanleitung forderte ein höchstens zwei Monate altes Master nodes file, einen nahen Einstieg und die Zustimmung des Standortverwalters bei mehr als 10.000 täglichen Empfängern. Die Kapazität gehörte einer konkreten Einrichtung.

Das erstaunlichste Datum in RFC 1429 vom Februar 1993 betrifft kein Protokollfeld. Eric Thomas verlangte, dass die Master nodes file des gewählten Verteilservers nicht älter als zwei Monate war. Einige Standorte aktualisierten ihre Tabellen wegen Personalmangels nicht. Eine auf Topologie gebaute Verteilentscheidung konnte dadurch auf einer alten Beschreibung des Netzes beruhen.

Der Dienst sollte ein teures Problem lösen. Wer eine große Mailingliste mit Einzelzustellungen beschickt, schickt denselben Inhalt immer wieder über belastete Leitungen. DISTRIBUTE nahm eine Nachricht samt Empfängerliste entgegen und bündelte deren Wege, soweit das verfügbare Lagebild es erlaubte. Auf einer stark belasteten Verbindung brauchte dann nur eine Kopie zu reisen; die Verzweigung erfolgte näher an den Empfängern. Thomas gab an, der Dienst transportiere damals zwei bis sechs Millionen Nachrichten täglich. Für vernünftig angebundene BITNET-Ziele nannte er fünf bis fünfzehn Minuten als typische Umlaufzeit.

Die Abkürzung begann mit einer Standortwahl. Ein Verteiler aus Kalifornien, dessen Publikum hauptsächlich in den USA sitzt, sollte seine Sendung nicht zuerst an einen schwedischen Server geben. Ein Hochschulrechner konnte außerdem über T1-IP-Zugang verfügen und für BITNET trotzdem nur an einer 9,6-Kilobit-Mietleitung hängen. Die Bandbreite des einen Anschlusses sagte nichts über die Engstelle am anderen aus. Die RFC-Checkliste verlangte deshalb Prüfung der tatsächlichen BITNET-Anbindung und der Mailversion, insbesondere der Behandlung langer Zeilen.

Auch die Verwaltung der Last hatte einen Namen. Wer täglich mehr als 10.000 Empfänger bedienen wollte, sollte den LISTSERV-Administrator des gewählten Standorts um Erlaubnis bitten und Volumen und Adresszahl nennen. Manche Universitäten konnten große Läufe zur Hauptverkehrszeit einschränken. Andere hatten mehrere Maschinen und wollten die Arbeit gezielt verteilen. Der technische Sammeldienst verschob die Last auf eine fremde Einrichtung; deren Betreiber durfte den Einsatz planen.

Die Anfrage kam bequem per SMTP an. Dessen MAIL FROM sollte einen Menschen benennen, der reagieren konnte, falls die Anfrage den Server gar nicht erreichte. Im Mailkopf der eingereichten Anfrage sollte From dagegen spätere Zustellprobleme und Rückläufer aufnehmen. Die Einlieferungsadresse der Liste war dafür gefährlich: Rückläufer an diese Adresse konnten erneut als Beiträge verteilt werden. Verantwortlichkeit musste für beide Fehlerstellen getrennt adressiert werden.

Eine JOB-Karte, DISTRIBUTE MAIL, eine mit BSMTP gekennzeichnete Empfängerliste und der Nachrichtentext bildeten die eigentliche Aufgabe. Im Produktionsbetrieb unterdrückte ECHO=NO den Ressourcenbericht. DEBUG=YES zeigte den geplanten Versandweg ohne Zustellung; TRACE=YES berichtete beim Zustellen. Das Beispiel im RFC bündelte drei Empfänger für die Weitergabe an UGA und übergab zwei lokal. So konnte ein Betreiber vor dem großen Lauf erkennen, wohin die Arbeit nach seiner Tabelle gehen würde.

Für nahe erreichbare Internet-Ziele nannte Thomas eine typische Umlaufzeit von fünf bis zwanzig Minuten, für Ziele ohne Topologieinformation eine deutlich längere. Der Unterschied folgt aus demselben Mechanismus wie die Einsparung. Der Dienst konnte nur bündeln, was seine Karte kannte. Das kurze Ablaufdatum der Knotentabelle war daher kein bürokratischer Zusatz, sondern Teil der Geschwindigkeitsbehauptung.