Zusammenfassung

  • RFC 977 ließ Leser gezielt Artikel aus einer zentralen, lokal betriebenen Datenbank abrufen. So musste nicht jede Arbeitsstation eine vollständige Kopie der Sammlung vorhalten.
  • Kantor und Lapsley trennten diesen Lesezugriff vom Austausch zwischen Newsservern. Zwischengeschaltete Cache-Server wurden angeregt, ihre Betriebsweise aber ausdrücklich nicht spezifiziert.
  • Der Text formuliert eine erwartete Speicherersparnis, liefert jedoch weder Messwerte noch einen Nachweis flächendeckender Nutzung. Ein gemeinsamer lokaler Bestand machte Usenet nicht zu einem global zentralen Archiv.

Nicht jeder Arbeitsplatz braucht das Archiv

RFC 977 beginnt bei einer überschaubaren Betriebsfrage: Mehrere Rechner sind über ein lokales Netz verbunden, doch manche Arbeitsstationen haben nur wenig Plattenspeicher. Soll jede Maschine sämtliche Nachrichten speichern, auch wenn ihre Nutzer die meisten davon nie lesen? Brian Kantor von UC San Diego und Phil Lapsley von UC Berkeley beantworteten diese Frage im Februar 1986 mit einem Client-Server-Modell.

Ein Newsserver verwaltet die Artikelsammlung und ihre Indexdateien. Ein Leser auf einem anderen Rechner verbindet sich über TCP und ruft nur die gewünschten Inhalte ab. Indexierung, Querverweise und das Ablaufen alter Nachrichten gehören zum gemeinsamen Speicher. Anzeige, Navigation und die konkrete Nutzung bleiben beim Client, der die örtliche Umgebung des Lesers kennt.

Der Ansatz betrifft Plattenplatz und Verschiedenartigkeit der Rechner zugleich. RFC 977 erwartet für größere Rechnergruppen weniger doppelte Kopien und einen Zugang für Arbeitsstationen mit begrenztem Speicher. Außerdem soll eine TCP-Verbindung vielfältige Hardware und Betriebssysteme erreichen, ohne ein überall gleiches Netzdateisystem vorauszusetzen. Die gemeinsame Schnittstelle ist das Protokoll, nicht die Art, wie jeder Rechner seine Dateien organisiert.

„Zentral“ meint hier den Server für ein lokales Cluster oder eine Institution. Der Text entwirft keine einzige Maschine, die alle Usenet-Beiträge weltweit hält. Eine Universität kann ihren Lesebestand bündeln und zugleich Nachrichten mit anderen Hosts austauschen.

Lesen und Weitergeben sind zwei Wege

NNTP sollte auch Hosts unterstützen, die eigene Kopien der Nachrichten benötigen. RFC 977 beschreibt dafür einen anderen Ablauf als die Anfrage eines Lesers an den lokalen Server. Ein Host kann Nachbarn nach neuen Gruppen und Artikeln fragen, die gewünschten Beiträge auswählen und mitteilen, welche er schon besitzt. Übertragen werden sollen die gewünschten Artikel, die am Ziel noch fehlen.

Damit hat „gemeinsam“ zwei Bedeutungen. Innerhalb eines lokalen Netzes teilen Leser einen Speicher, anstatt jede Sammlung zu vervielfältigen. Zwischen Hosts stimmen Peers ab, welche Artikel von einem Standort zum nächsten wandern. Der erste Weg bündelt den Lesezugriff; der zweite erhält die Verteilung zwischen selbständigen Newsservern. Wer NNTP nur als Zentralisierung beschreibt, lässt diese zweite Funktion verschwinden.

Auch der Serverauftrag bleibt eng. RFC 977 bezeichnet den Dienst als Schnittstelle zwischen Programmen und der Newsdatenbank. Benutzerinteraktion und Darstellung überlässt er den Clients. Das Protokoll regelt, wie ein Rechner über TCP anfragt, nicht wie jede Anwendung Nachrichten sortiert oder anzeigt.

Der Cache blieb außerhalb der Spezifikation

Für größere Umgebungen schlagen Kantor und Lapsley einen zwischengeschalteten „Slave“-Server vor. Er könnte Leseanfragen vermitteln und kürzlich abgerufene Artikel lokal zwischenspeichern. Ein Client könnte zuerst diesen lokalen Dienst versuchen; bei dessen Ausfall könnte die Installation den Zugriff verweigern oder den zentralen Host ansprechen.

Die Passage erkennt damit eine Folge des gemeinsamen Speichers: Ein Ausfall betrifft mehrere Leser, sofern es keinen lokalen Weg gibt. RFC 977 stellt jedoch ausdrücklich klar, dass der Betrieb solcher Slave-Server nicht spezifiziert wird. Es gibt keine fertige Umschaltregel und keine Garantie, dass Cache-Inhalte frisch sind. Aktualisierung, Rückfall und Wiederanlauf bleiben Aufgabe des jeweiligen Betreibers.

Der Aufwand verschiebt sich zum Dienst

Die beabsichtigte Ersparnis besteht darin, nicht jede Arbeitsstation mit der vollständigen Sammlung zu füllen. Der Speicherbedarf wird dadurch nicht beseitigt, sondern zum Newsserver verlagert. Dort liegen außerdem Indizes und Regeln für das Ablaufen alter Beiträge. Die Arbeitsplätze benötigen weniger lokalen Platz; der Betreiber trägt mehr Verantwortung für Kapazität und Verfügbarkeit.

Das ist eine Folgerung aus der beschriebenen Architektur, kein gemessener historischer Effekt. RFC 977 hält die Einsparung in großen Rechnergruppen für sinnvoll, veröffentlicht aber keine Zahlen zu freiem Plattenplatz, installierten Servern, Auslastung oder Nutzererfahrung. Die dokumentierte Begründung ist kein Nutzungsnachweis.

Auch die Verfügbarkeit konzentriert sich. Wenn viele Leser denselben Host nutzen, sind dessen Ausfall, verzögerte Indizes und Ablaufeinstellungen für mehrere sichtbar. Lokale Caches könnten diese Abhängigkeit lockern, doch gerade ihr Betrieb blieb ungeregelt. Weniger lokale Kopien bedeuten also einen gemeinsam genutzten Dienst, dessen Kapazität, Aktualität und Wiederherstellung geplant werden müssen.

Zwei Funktionen entwickeln sich weiter

RFC 3977 erklärte RFC 977 im Oktober 2006 für überholt und ersetzte ihn mit Klarstellungen und erweiterten Grundfunktionen. Auch die spätere Einführung beschreibt Leser, die Artikel aus einer zentralen Datenbank abrufen. RFC 4644 aus demselben Monat standardisierte mit CHECK und TAKETHIS die asynchrone Übertragung zwischen Servern.

Diese Dokumente belegen nicht, wie ein bestimmter Betreiber NNTP einsetzte. Sie zeigen aber, dass zwei zusammenhängende Aufgaben weiterentwickelt wurden: Leser greifen auf einen Bestand zu, während Server Artikelkopien untereinander übertragen. Beides gehört zum Protokoll, ist aber nicht derselbe Vorgang.

Kantors Anteil bleibt gemeinsam dokumentiert

Ein Nachruf von UC San Diego hält fest, dass Kantor 47 Jahre an der Universität arbeitete, als Postmaster tätig war, Nameserver betrieb und an der Netzwerk-Infrastruktur mitwirkte. Die Universität schreibt ihm den Entwurf von NNTP zu. RFC 977 nennt für die konkrete technische Veröffentlichung Kantor und Lapsley als gemeinsame Autoren. Die Biografie verbindet das Protokoll mit langjährigem Netzbetrieb; der RFC wahrt die Zusammenarbeit.

Der bleibende Punkt des Entwurfs ist die klare Aufteilung: ein lokaler Lesebestand, Clients für die nutzerspezifische Darstellung und ein eigener Austausch zwischen Hosts. Das kann die Platten kleiner Rechner entlasten, konzentriert aber Speicher, Indexierung, Ablauf und Verfügbarkeit auf den gemeinsamen Dienst. Die Quellen erklären Zweck und Mechanismus, nicht die tatsächlichen Einsparungen oder die Verbreitung.

Quellen