Zusammenfassung

  • Jede RPC-Nachricht der Version 2 beginnt mit einer 32 Bit breiten XID; die Antwort übernimmt den Wert des Aufrufs. Das ordnet eine Antwort zu und kann einen Vergleichsschlüssel für eine mögliche Wiederholung liefern, ist aber weder eine Sequenznummer noch ein Ausführungsbeleg.
  • NFS machte die fehlende Erinnerung sichtbar. Kurzlebige Duplicate-Request-Caches begrenzten Wiederholungsschäden nur bis zu Absturz oder Verdrängung; NFSv4.1 verband begrenzte Slots mit Sequenzständen und gespeicherten Antworten und machte damit die Kosten stärkerer Einmaligkeitszusagen ausdrücklich.

Ein Timeout ließ zwei Vergangenheiten offen

Ein Client bittet einen Dateidienst, einen Namen zu entfernen. Der Server kann den Auftrag vollständig ausführen, bevor die Antwort verloren geht. Ebenso kann schon der Aufruf auf dem Hinweg verschwinden. Beim Client endet beides gleich: Die Uhr läuft ab, eine Antwort fehlt.

Die naheliegende Wiederholung ist deshalb zugleich ein Fortschrittsversuch und ein Risiko. Im ersten Verlauf wiederholt sie eine bereits wirksame Operation; im zweiten bringt sie den Auftrag zum ersten Mal zum Server. Der Timeout enthält kein Bit, das diese Verläufe trennt.

Die frühen RPC-Dokumente machten aus der Unsicherheit kein heimliches Transportversprechen. RFC 1050 vom April 1988 erklärte, dass RPC selbst keine Zuverlässigkeit bereitstellt. RFC 1057, der Nachfolger vom Juni, hielt für UDP fest: Bleibt auch nach einer erneuten Übertragung die Antwort aus, ist die Zahl der Ausführungen unbekannt. Kommt eine Antwort, ist wenigstens eine Ausführung belegt.

Das Problem liegt zwischen Zustellung und Wirkung. Ein Paket kann vor der Verarbeitung verloren gehen, eine Antwort erst nach einer Zustandsänderung oder eine Verbindung genau zwischen Commit und Empfang abbrechen. Von außen ist Stille kein Ausführungsprotokoll.

Die XID löste zunächst nur die Zuordnung

In RPC Version 2 beginnt CALL wie REPLY mit einer vorzeichenlosen 32-Bit-XID. Die Antwort kopiert die XID des zugehörigen Aufrufs. Ein Client mit mehreren offenen Anforderungen kann deshalb erkennen, welcher lokale Wartende das eintreffende Ergebnis erhalten soll.

Diese Eigenschaft ist wichtig und bewusst schmal. RFC 5531 erlaubt der Dienstseite, XIDs auf Gleichheit zu prüfen, um mögliche Retransmissions zu entdecken. Sie darf den Wert aber nicht als Sequenznummer deuten. Eine größere Zahl ist nicht standardmäßig neuer, ein Abstand beschreibt keine ausgelassenen Aufträge, und der Zahlenraum trägt weder eine Serverepoche noch eine Aufbewahrungsdauer.

Auch die Wiederverwendung blieb eine Verhaltensfrage. Der Client kann beim erneuten Senden die frühere XID verwenden. Der Server kann diese XID zusammen mit ausreichendem Kontext erinnern und einen zweiten Aufruf nicht erneut ausführen. Treffen beide Entscheidungen auf noch vorhandene Erinnerung, entsteht ein gewisses Execute-at-most-once-Verhalten. Der Integer allein erzeugt es nicht.

Vergibt der Client für den Retry einen neuen Wert, gibt es für den Gleichheitsvergleich keine Verbindung. Hat der Server den alten Eintrag verloren, ist dieselbe XID ebenso wirkungslos. Wird ein Wert später erneut vergeben, kann ein Vergleich ohne Client-, Programm-, Prozedur- und Epochengrenze sogar zwei verschiedene Vorgänge verwechseln.

Zuverlässiger Transport verschob nur die Grenze

Die RPC-Spezifikationen RFC 1831 und RFC 5531 formulieren für eine empfangene Antwort über einen zuverlässigen Transport eine Exactly-once-Schlussfolgerung in ihrem Austauschmodell. Daraus folgt jedoch keine dauerhafte Transaktionsgarantie über jeden Verbindungsabbruch hinweg.

Ohne Antwort bleibt auch dort offen, ob der Dienst tätig wurde. Nach Serverabsturz, automatischem Reconnect oder einem Retry auf einer neuen Verbindung muss die Anwendung wieder entscheiden, wie viel frühere Ausführungsgeschichte noch vorhanden ist. Ein Transport kann Bytes innerhalb seines Vertrags ordnen und zustellen; er kann keinen verlorenen Anwendungsspeicher rekonstruieren.

Die XID war außerdem nie ein Authentisierungsbeleg. Credentials und Verifier liegen in eigenen RPC-Feldern. Eine passende Nummer beweist weder die Identität des Auftraggebers noch gleiche Argumente, Autorisierung, stabile Speicherung oder genau eine Zustandsänderung. Sie sagt, welche CALL-Nachricht eine REPLY-Nachricht beansprucht zu beantworten.

NFS setzte die Ungewissheit in Dateisystemzustand um

Das frühe Network File System wollte die Serverseite möglichst zustandslos halten. RFC 1094 beschrieb den Vorteil: Nach Server- oder Netzfehlern konnte der Client weiter versuchen, statt zunächst einen umfangreichen Dialogzustand wiederaufzubauen.

Die Operationen wurden dafür möglichst idempotent gestaltet. Eine wiederholte Leseoperation oder dieselbe Schreiboperation auf denselben Bereich kann zum beabsichtigten gleichen Ergebnis führen. Das Dokument kennzeichnete dennoch mehrere Operationen als möglicherweise nicht idempotent. Ein bereits entfernter Name kann nicht ein zweites Mal unter denselben Voraussetzungen entfernt werden; ein erfolgreich umbenannter Quellname steht dem wiederholten RENAME nicht mehr zur Verfügung.

RFC 1813 machte die Gefahr für NFSv3 greifbarer. Eine erneute, nicht idempotente Anforderung konnte ein anderes Ergebnis liefern oder sogar zwischenzeitliche Arbeit zerstören. Ein wiederholtes Kürzen konnte etwa Daten beseitigen, die nach der ersten Ausführung geschrieben worden waren. Auch eine verbindungsorientierte Übertragung beseitigte diese Möglichkeit nicht, wenn eine Verbindung abbrach und der Client nach ihrem Neuaufbau den unbekannt beendeten Auftrag erneut sandte.

Zustandslosigkeit bedeutete also nicht, dass Dateien oder Wirkungen ohne Geschichte waren. Sie verringerte den verpflichtenden Gesprächszustand. Die Kosten erschienen dafür in den Eigenschaften einzelner Operationen und in zusätzlicher Erinnerung am Ausführungsort.

Der Duplicate-Request-Cache kaufte eine Frist

Viele NFSv3-Server führten einen Cache kürzlich bearbeiteter Anforderungen. Nach Abschluss blieb der Status der ersten Ausführung erhalten. Erkannte der Server dieselbe Anforderung erneut, gab er das gespeicherte Ergebnis zurück, statt die Wirkung noch einmal anzuwenden.

Das war keine bloße Beschleunigung. Der Cache bewahrte diejenige Evidenz, die für eine korrekte Replay-Entscheidung nötig war. Doch RFC 1813 beschrieb seine Grenzen ausdrücklich. Typischerweise lag der Inhalt im RAM und verschwand bei einem Absturz. Zudem war der Speicher endlich. Während einer langen Netzpartition konnte ein Eintrag verdrängt werden, bevor die erste Antwort den Client erreichte. Der spätere Retry sah dann wie ein neuer Auftrag aus.

Die XID hatte dabei nicht ihre Aufgabe verfehlt. Verfallen war der lokale Kontext, der Gleichheit eine Folge gegeben hatte. Wer den Wert pauschal einen dauerhaften Idempotency Key nennt, verschweigt die entscheidenden Bedingungen: Welche Gegenstelle und Prozedur bildeten den Suchraum? Wann durfte ein Ergebnis entfallen? Wurde der Zustand bei Failover geteilt? Überlebte er eine neue Boot-Epoche?

NFSv3 nutzte für EXCLUSIVE CREATE deshalb eine operationsspezifische stärkere Spur. Ein Verifier wurde mit dem erzeugten Objekt verbunden, weil der übliche flüchtige Duplicate-Cache für die verlangte Bedeutung nicht genügte. Das machte nicht jede RPC-XID dauerhaft; es legte zusätzliche Evidenz dort ab, wo genau diese Operation sie brauchte.

Slots machten die Erinnerung berechenbar

NFSv4.1 änderte nicht den 32-Bit-XID-Raum, sondern begrenzte die Arbeit, deren Antworten zugleich bewacht werden mussten. RFC 5661 führte Sessions ein; die heutige Beschreibung in RFC 8881 ordnet jeder Session eine ausgehandelte Zahl von Slots zu. Zu einem Slot gehören ein Sequenzstand und eine gespeicherte Antwort.

Der Requester wählt einen freien Slot. Eine neue Nutzung erhöht dessen Sequence ID; ein Retry des laufenden Auftrags wiederholt denselben Stand. Damit kann der Replier drei Fälle auseinanderhalten: den erwarteten neuen Auftrag, die Wiederholung des aktuellen Auftrags und einen unpassend geordneten Wert. Ist die erste Ausführung beendet, bekommt die Wiederholung die zwischengespeicherte Antwort statt einer zweiten Ausführung.

Der Slot liefert die fehlende Ressourcenbegrenzung. Seine ausgehandelte Zahl begrenzt gleichzeitig ausstehende Aufträge und die Menge der Antworten, die der Server bereithalten muss. Der nächste Sequenzstand zeigt zugleich, dass der Client das vorherige Ergebnis hinter sich gelassen hat und der Eintrag ersetzt werden kann.

RFC 8881 stellt dem das unstrukturierte XID-Feld gegenüber. RPC-Aufrufe dürfen außerhalb einer Zahlenfolge abgeschlossen werden, und eine undurchsichtige 32-Bit-Kennung sagt dem Server nicht, wie viele Ergebnisse noch benötigt werden. Alle möglichen Antworten unbegrenzt zu behalten wäre kein ausführbarer Vertrag. Die Slottabelle macht aus offener Historie eine endliche Obhutspflicht.

Auch Exactly-once hatte eine Wiederherstellungsgrenze

Ein flüchtiger Reply-Cache kann nach einem Neustart nicht über vergessene Aufträge aussagen. Vollständige Exactly-once Semantics über diesen Fehler hinweg verlangen nach RFC 8881 persistentem Cache- und Recovery-Zustand. Eine Implementierung mit RAM-Zustand kann gewöhnliche Wiederholungen korrekt bedienen und trotzdem keine Aussage über die Zeit vor ihrem Absturz tragen.

Sessions ersetzten die XID nicht. Die RPC-Schicht nutzt sie weiterhin zur Antwortzuordnung, auch bei Vorgängen außerhalb des normalen SEQUENCE-Pfads. Slot, Sequence ID und Reply-Cache ergänzten eine engere Zustandsmaschine für den Bereich, in dem NFS eine stärkere Zusage benötigte.

Die Entwicklung bestand deshalb nicht aus einer immer mächtigeren Nummer. Erst ordnete eine Nummer Nachrichten zu. Dann machte ein Cache Gleichheit für eine kurze Zeit handlungswirksam. Schließlich begrenzte eine Session die Zahl der Ergebnisse, die für eine stärkere Behauptung aufzubewahren waren. Persistenz bestimmte, welche Fehlergrenze diese Behauptung überschreiten durfte.

Was dieselbe Zahl nicht entscheiden konnte

Eine gleiche XID beweist keine gleichen Argumente, keinen gleichen Principal, keine gleiche Serverinstanz und keine gemeinsame Boot-Epoche. Ein Cache-Miss beweist nicht, dass eine Anforderung neu ist. Ein Cache-Hit beweist nicht, dass ihre Wirkung dauerhaft geschrieben wurde. Selbst Idempotenz schützt nicht vor jeder Reihenfolge: RFC 8881 zeigt, wie ein verspäteter älterer WRITE einen späteren überschreiben kann.

Die vertretbare Aussage ist kleiner. XID liefert laufenden Gegenstellen ein gemeinsames Vergleichszeichen. Einmalige Ausführung wird erst dann zu einer belastbaren Systemeigenschaft, wenn der Ausführer Zeichen, Arbeit, Ergebnis, Geltungsbereich und Wiederherstellungszustand lange genug miteinander verbindet.

Quellen und Evidenzgrenzen

Die RPC-Grundlagen und ihre Wiederholungssemantik stehen in RFC 1050, 1057, 1831 und 5531. Das zustandsarme NFS-Ziel beschreibt RFC 1094, Duplicate-Cache und seine Grenzen RFC 1813. Die NFSv4.1-Session entstand in RFC 5661; RFC 8881 enthält die aktuelle Spezifikation. Diese Quellen belegen Entwurf und dokumentierte Fehlermodelle, nicht heutige Cachegrößen, Persistenzrichtlinien, Verbreitung oder Konformität einzelner Produkte.