Zusammenfassung

  • IHAVE bot zunächst nur einen Message-ID an. Der Empfänger konnte einen bekannten Artikel ablehnen, einen späteren Versuch verlangen oder den vollständigen Körper anfordern.
  • Die Anforderung des Körpers war noch keine endgültige Annahme. Nach der Prüfung konnte der Server Erfolg, vorübergehendes Scheitern oder Ablehnung melden; auch Erfolg bewies keine dauerhafte Aufbewahrung.
  • CHECK und TAKETHIS machten dieselben Entscheidungen parallelisierbar. Sie optimierten die Leitung, nicht die Zuständigkeit für den fremden Speicher.

Ein Zustandsautomat mit zwei Prüfstellen

Der Sender bietet drei Kennungen an. Beim ersten Message-ID findet der Empfänger einen Historieneintrag. Beim zweiten ist eine Entscheidung vorübergehend nicht möglich. Beim dritten fordert er den Artikel an. Damit entstehen vor jedem Körper bereits drei saubere Zustände: nicht senden, später erneut anbieten, jetzt senden.

Nach dem dritten Körper folgt eine zweite Verzweigung. Erst jetzt sind Gruppen, Distribution, Header, Länge und tatsächliche Bytes bekannt. Der Empfänger kann annehmen, einen temporären Fehler melden oder endgültig ablehnen. Die erste Prüfstelle spart Übertragung; die zweite schützt die lokale Aufnahme.

Das ist mehr als eine Befehlsfolge. Es ist eine Aussage darüber, welches Wissen zu welchem Zeitpunkt verfügbar ist. Ein Betriebsmodell, das beide Prüfstellen zu einem Feld „angenommen“ zusammenzieht, verliert Ursache und Zuständigkeit.

Duplikatunterdrückung vor NNTP

RFC 1036 beschreibt die älteren Steuernachrichten ihave und sendme. Ein System kündigte die Message-IDs seiner Artikel an, das andere forderte fehlende Exemplare an. Mehrere IDs ließen sich bündeln, weil die einzelne Ankündigung beinahe so teuer sein konnte wie ein kurzer Artikel.

In einem Store-and-forward-Netz war das eine harte Kostenfrage. Langsame oder nur zeitweise verfügbare Verbindungen sollten keinen vollständigen Körper übertragen, den die Gegenstelle längst besaß. Die lokale Historie wurde als verteilter Duplikatfilter genutzt, ohne dass alle Server ein gemeinsames Inventar führen mussten.

Die Kennung konnte aber nur die Identitätsfrage stellen. Ob der Artikel zur lokalen Gruppen- und Distributionspolitik passte, ließ sich erst am vollständigen Objekt entscheiden. Daraus entstand die Notwendigkeit zweier verschiedener Antworten.

Die Übergänge von RFC 977

RFC 977 definierte IHAVE mit einer ersten Antwortgruppe. 335 fordert den Körper an, 435 erklärt ihn für unerwünscht, und 436 verlangt einen späteren Versuch. Erst nach 335 sendet der Client den vollständigen Artikel.

Danach folgt die zweite Antwortgruppe. 235 bestätigt die Übertragung, 436 zeigt einen temporären Fehler, 437 lehnt ohne erneuten Versuch ab. Als Gründe nennt die Spezifikation unter anderem unerwünschte Gruppen oder Distributionen, Speichermangel, übermäßige Länge und beschädigte Header.

Bemerkenswert ist, dass 436 an beiden Prüfstellen auftreten kann. Ohne die Position des Codes ist nicht einmal klar, ob der Körper übertragen wurde. Ein korrekter Ereignisdatensatz muss daher Phase, Kennung, Körperfingerabdruck und Antwort gemeinsam halten.

Keine Antwort ist kein impliziter Übergang

RFC 3977 hält an der Zweistufigkeit fest und untersagt das Pipelining von IHAVE. Der Client wartet auf die erste Antwort, sendet gegebenenfalls den Körper und wartet auf die zweite. Bleibt eine erwartete Antwort aus, gilt der Vorgang als vorübergehend gescheitert.

Damit bekommt ein Verbindungsabbruch eine sichere Bedeutung. Der Sender darf erneut anbieten, weil er den Endzustand nicht kennt. Der Empfänger soll wiederholte Angebote desselben Arguments oder Artikels erkennen, damit die Wiederholung nicht unnötig dupliziert.

Die Norm trennt außerdem Transit über IHAVE von der Einspeisung über POST. Ein Transitserver urteilt über eine bereits geformte Nachricht innerhalb einer Peering-Beziehung. Er übernimmt damit weder globale Autorenschaftsprüfung noch eine Verpflichtung zur universellen Weitergabe.

Erfolg endete an einer definierten Grenze

Schon RFC 977 weist darauf hin, dass ein Server nach 235 später einen Mangel entdecken und den Artikel still verwerfen kann. Der Code beweist den positiven Abschluss der NNTP-Übertragung, nicht die ewige Existenz einer Kopie.

RFC 4644 lässt dieselbe Grenze im Streaming bestehen. Auch nach einem positiven 239 für TAKETHIS kann spätere Verarbeitung zur Löschung führen. Dauerhafte Verwahrung muss deshalb durch spätere Beobachtung belegt werden: Spool-Präsenz, Leserzugriff oder Angebot an den nächsten Peer.

Gesendete Bytes, bestätigte Übertragung, gespeicherter Artikel und weitergeleiteter Artikel sind vier Beweisstufen. Ein positiver Code darf die nachfolgenden Stufen nicht rückwirkend erzeugen.

Streaming entkoppelte die Warteschlangen

Auf Leitungen mit hoher Laufzeit verschwendete das serielle IHAVE Kapazität. RFC 4644 führte CHECK ein, um das Interesse an einem Message-ID abzufragen, und TAKETHIS, um den Körper mit endgültiger Antwort zu übertragen. Viele Prüfungen und Sendungen konnten gleichzeitig offen sein.

Die Antwort auf CHECK blieb jedoch beratend. Der Empfänger durfte nicht davon ausgehen, dass der Client ihr stets folgt. Standortpolitik oder eine adaptive Strategie konnten TAKETHIS auch ohne vorheriges CHECK zulassen. Die endgültige Prüfung des Körpers blieb in jedem Fall beim Empfänger.

Der Zustandsautomat erhielt also mehr Parallelität, aber keinen neuen Eigentümer. Aus einer seriellen Folge wurden überlappende Vorgänge; aus lokaler Politik wurde kein Befehl des Senders.

Die Peering-Regel lag außerhalb des Automaten

RFC 5537 ordnet die Verfahren in die Netnews-Architektur ein. Die alten ihave- und sendme-Steuernachrichten waren im Internet weitgehend überholt, blieben aber in manchen UUCP-Umgebungen in Gebrauch. Moderne Standorte vereinbarten, welche Artikel sie über welches Verfahren austauschen.

Diese Vereinbarung bestimmte Hierarchien, Distributionen und Filter. Ein Message-ID transportierte sie nicht, und 335 erzeugte sie nicht. Das Protokoll modellierte eine einzelne Übergabe innerhalb einer umfassenderen Beziehung.

Historisch zeigt IHAVE, wie eine verteilte Infrastruktur zugleich sparsamer und genauer werden konnte. Die Gegenstelle musste nicht jeden Körper ungefragt aufnehmen. Der Sender erhielt unterscheidbare Gründe für Nichtübertragung und Scheitern. Und beide Seiten behielten die Zuständigkeit für ihre eigenen Bestände.

Quellen