Zusammenfassung

  • RFC 977 behandelte doppelte Artikel als verbindungsabhängige Kosten: Interaktive Rechner konnten ihren Bestand vergleichen, bevor sie den Text sendeten.
  • Derselbe RFC ließ Senden und anschließendes Verwerfen von Duplikaten auf UUCP-Verbindungen mit nur einer Transaktion zu, wenn ein Stapel schneller war.

Im Februar 1986 veröffentlichten Brian Kantor und Phil Lapsley RFC 977, den Vorschlag für das Network News Transfer Protocol. Die aufschlussreiche Idee war nicht, dass ein Transport Usenet beherrschen sollte. Was ein Duplikat kostete, hing von der Verbindung ab, über die es lief. Auf einer interaktiven Datenverbindung konnten zwei Rechner ihren Bestand vergleichen und danach entscheiden, was sie senden. Bei einer Leitung, die nur einmal täglich geöffnet wurde, konnte dieses Gespräch länger dauern als die Übertragung des Duplikats.

Die herkömmliche Verteilung, die der RFC beschreibt, arbeitete durch Weiterreichen: Jeder Standort schickte neue Artikel an seine Feeds, die sie ihrerseits weiterverbreiteten. Ein Rechner mit zwei Zulieferern konnte denselben Artikel zweimal erhalten. Bei einer geplanten oder einmaligen Übertragung konnte der Sender nicht ohne Weiteres anhalten und fragen, ob der Empfänger den Artikel schon hatte. Dieser nahm den Stapel an und entfernte Duplikate anschließend. Das kostete Zeit und Übertragungskapazität, hielt die Sitzung aber einfach.

NNTP fügte eine vorherige Abstimmung hinzu. Ein Client konnte nach neuen Gruppen fragen, die Artikelkennungen in den gewünschten Gruppen abfragen und die fehlenden Artikel anfordern. Umgekehrt konnte ein Rechner dem Nachbarn mitteilen, welche Artikel er gerade erhalten hatte. Der Server unterschied dann, was bereits in seiner Sammlung lag und was noch gesendet werden sollte. Der Artikeltext war nicht mehr der erste Beleg dafür, dass eine Nachricht die Leitung passiert hatte: Die Rechner konnten zuerst Kennungen vergleichen.

Die Entscheidung hing vom Übertragungsweg ab. RFC 977 hält fest, dass gut verbundene Rechner in einem lokalen oder anderen schnellen Netz Nachrichten mit NNTP womöglich effizienter verteilen konnten als mit traditionellen Verfahren wie UUCP. Zugleich erklärt er, weshalb UUCP-Stapel sinnvoll waren: Bei einer Verbindung mit nur einer Transaktion, besonders bei einer täglichen Sitzung, konnte das Senden aller Artikel mit anschließendem Löschen der Duplikate die Gesamtzeit verkürzen. Eine interaktive Abstimmung war nicht automatisch günstiger, nur weil sie weniger Bytes übertrug.

Der RFC beschreibt noch eine andere Nutzung, die vom Austausch zwischen Standorten zu unterscheiden ist. Eine Universität oder ein Unternehmen konnte Nachrichten in einem zentralen Spool halten und Arbeitsstationen über das lokale Netz darauf zugreifen lassen. Leser wählten Artikel aus einem gemeinsamen Speicher, statt auf jedem Rechner eine vollständige Kopie abzulegen. Ein Zwischenserver konnte kürzlich abgerufene Artikel zwischenspeichern. Das war ein Modell für lokalen Zugriff und Speicher, keine zentrale Datenbank für ganz Usenet.

RFC 850 hatte bereits das Format von USENET-Artikeln standardisiert, die Übertragungsmethoden aber bewusst offengelassen: Standorte konnten Hardware, Software und Stapelbetrieb selbst wählen. RFC 977 knüpfte an diese Vielfalt an. Er beschrieb eine zuverlässige Stream-Methode zum Abfragen, Abrufen, Veröffentlichen und Austauschen von Artikeln und erkannte zugleich den Vorteil eines anderen Transports auf unterbrochenen Leitungen an. Die Regel war bedingt: Bei tragfähiger Verbindung verhandeln; wo Stapel Zeit sparen, beim Stapel bleiben.

Diese Dokumente belegen einen Entwurf, keine allgemeine Umstellung. RFC 977 nennt weder den Anteil der Usenet-Rechner, die 1986 NNTP einsetzten, noch gemessene Bandbreiteneinsparungen oder den Erfolg jeder Implementierung bei der Vermeidung von Duplikaten. Sein engerer Beitrag: Die Artikelauswahl wurde zum Austausch zwischen Rechnern. Der Empfänger konnte angeben, was er wollte und schon besaß, bevor der Sender eine weitere Kopie übertrug.

Quellen: RFC 977, Network News Transfer Protocol; RFC 850, Format für den Austausch von USENET-Nachrichten; RFC 1036, Format für den Austausch von USENET-Nachrichten.