Zusammenfassung

  • STOP_SENDING zeigt das Desinteresse des Empfängers an einer eingehenden Stream-Richtung, nicht das Ignorieren früherer Bytes.
  • RESET_STREAM beendet nur die Senderichtung des Peers; final size erfasst verbrauchten Flow-Control-Kredit, nicht erledigte oder rückgängig gemachte Arbeit.
  • Transportfakten müssen von Annahme durch die Anwendung, Stornierungsbestätigung, dauerhaften Effekten, Ausgleich und Endergebnis getrennt bleiben.

Ein Client kann in einen Timeout laufen, keine Antwort mehr benötigen und STOP_SENDING mit einem Anwendung-Fehlercode senden. Das ist ein klarer Transportvorgang. Er fordert den Peer auf, in einer Richtung eines QUIC-Streams nicht weiterzusenden. Daraus folgt aber nicht, dass ein entfernter Auftrag, Job oder Vorgang storniert wurde. Der Zustand übertragener Bytes und der Zustand einer Geschäftsoperation gehören verschiedenen Zustandsmaschinen an.

RFC 9000 erlaubt einer Anwendung, die kein Interesse mehr an empfangenen Stream-Daten hat, das Lesen abzubrechen. Befindet sich der empfangende Teil in Recv oder Size Known, soll der Transport STOP_SENDING senden, um das Ende der Gegenrichtung anzustoßen. Die entscheidende Einschränkung ist ausdrücklich: Das Frame garantiert nicht, dass eingehende Daten ignoriert werden. Frühere STREAM-Bytes können bereits eingetroffen, an die Anwendung übergeben oder verarbeitet worden sein. STREAM-Bytes, die nach STOP_SENDING eintreffen, zählen weiterhin zur Flow-Control des Streams und der Verbindung, auch wenn der Transport sie beim Eingang verwirft.

Die Antwort des Peers ist ein eigener Zustandsübergang. Befindet sich sein sendender Teil in Ready oder Send, muss er RESET_STREAM senden. In Data Sent darf er warten, bis ausstehende Daten bestätigt oder als verloren eingestuft wurden. Bei Verlust soll er RESET_STREAM senden, statt diese Daten erneut zu übertragen. Der Peer soll den Anwendungscode von STOP_SENDING übernehmen, kann aber einen anderen Code wählen. Deshalb gehören die beiden Fehlercode-Beobachtungen getrennt in den Nachweis.

Die Richtung ist die maßgebliche Grenze. RESET_STREAM beendet abrupt nur den sendenden Teil. Bei einem bidirektionalen Stream bleibt die Gegenrichtung unabhängig. Wer beide Richtungen beenden will, kann RESET_STREAM für die eigene Senderichtung und STOP_SENDING für die andere einsetzen. Das schließt weder die Verbindung noch beweist es das Ende eines Anfrage-Antwort-Paars oder eines Geschäftsprozesses.

final size ist ein Flow-Control-Fakt. Er bezeichnet die Datenmenge, die Flow-Control-Kredit auf Verbindungsebene verbraucht. Sobald bekannt, kann sie sich nicht mehr ändern, unabhängig davon, ob der Stream normal endet oder zurückgesetzt wird. Sie sagt nicht, wie viel Anwendungsarbeit erledigt wurde, ob der entfernte Vorgang angenommen oder ein Effekt rückgängig gemacht wurde. Nach RESET_STREAM werden STREAM-Frames in dieser Richtung nicht mehr gesendet oder erneut gesendet. Das beschreibt das Transportverhalten, nicht die Wiederherstellung eines Anwendungszustands.

Auch Zuverlässigkeit hat hier eine enge Bedeutung. QUIC sendet ein verlorenes Paket nicht als Ganzes erneut, sondern überträgt benötigte Informationen in neuen Frames. RESET_STREAM wird bis zur Bestätigung oder bis zur Bestätigung aller Stream-Daten gesendet. STOP_SENDING wird gesendet, bis der empfangende Teil Data Recvd oder Reset Recvd erreicht. Empfang und Bestätigung zeigen Fortschritt in der QUIC-Zustandsmaschine. Sie beweisen nicht, dass frühere Bytes ungenutzt blieben, Arbeit abgebrochen, Effekte zurückgerollt oder Ausgleichsmaßnahmen erfolgreich waren.

Der Nachweis sollte Verbindungsidentität, stream ID, Initiator, Streamtyp und betroffene Richtung erfassen. Separat gehören die lokale Leseentscheidung, STOP_SENDING-Sendungen und Wiederholungen, ihre Anwendungscodes, der Empfang von RESET_STREAM samt eigenem Code, final size, Flow-Control-Abrechnung und spätere STREAM-Bytes hinein. Für entfernte Annahme oder Verarbeitung, Stornierungsannahme oder -ablehnung, dauerhafte Effekte, Rückabwicklung, Ausgleich und Endergebnis braucht es zusätzliche Anwendungsevidenz.

Damit bleibt auch die Abgrenzung zu benachbarten Themen erhalten. TR-045 behandelt ACK und Paketverarbeitung; TR-046 die Berechtigung durch Flow-Control; TR-052 DATAGRAM-Grenzen und fehlende Zustellgarantien; TR-053 CONNECTION_CLOSE und das Ende des Transportzustands. STOP_SENDING ist eine gezielte Aufforderung, eine Stream-Richtung zu beenden, während die Verbindung weiterbestehen kann.