Teilschreibvorgänge: den Pufferoffset vorrücken, statt die gesamte Nutzlast erneut zu senden

Worum es geht

Das Linux-write-Manual besagt, dass ein erfolgreicher Aufruf weniger Bytes übertragen kann als angefordert. Der Rückgabewert teilt der aufrufenden Seite mit, wie viel Fortschritt stattgefunden hat, und ein späterer Aufruf kann mehr übertragen oder fehlschlagen. Erfolg bedeutet daher nicht, dass ein gesamter Anwendungspuffer verbraucht wurde, und er belegt auch keine dauerhafte Speicherung. Linux write manual

Warum es wichtig ist

Ein Agent könnte nach einem kurzen Schreibvorgang den ursprünglichen Puffer erneut versuchen und dabei das bereits gesendete Präfix duplizieren. Der massgebliche Zustand ist das noch nicht gesendete Suffix. Diesen Zustand über gewöhnlichen Fortschritt, Unterbrechung, Backpressure und endgültigen Fehlschlag hinweg explizit machen, statt alle Ergebnisse in einen generischen Wiederholungsversuch zu übersetzen.

So wird es angewendet

• Den aktuellen Offset und die insgesamt vorgesehene Bytezahl mitführen. Bei einem positiven Rückgabewert genau um den gemeldeten Betrag vorrücken und beim nächsten Mal nur das verbleibende Suffix anbieten.
• Einen endgültigen Fehler von einem Would-Block-Ergebnis an einem nicht blockierenden Deskriptor unterscheiden. Den ausstehenden Puffer erhalten und über den gewählten Bereitschaftsmechanismus fortsetzen, statt in einer Busy-Loop zu warten.
• Für null Fortschritt eine explizite Strategie festlegen, damit eine Schleife nicht unbegrenzt weiterläuft. Fristen und Abbruch beobachtbar halten, solange Ausgabe noch aussteht.
• Eine kontrollierte Writer-Fixtur vorschlagen, die jeweils nur einen Teil jedes Puffers akzeptiert und dann Backpressure oder einen Fehlschlag auslöst. Die exakte resultierende Byte-Sequenz prüfen, nicht nur die Anzahl der Aufrufe.
• Für ein höherstufiges Protokoll festlegen, was eine teilweise übertragene Nachricht nach einem Fehlschlag bedeutet. Sie nicht automatisch auf einer neuen Verbindung erneut senden, ohne die Wiederherstellungsregel dieses Protokolls zu beachten.

Stolpersteine

Eine Schreibschleife löst die lokale Byte-Buchführung, nicht die Zustellung der Anwendung genau einmal. Dateidauerhaftigkeit und die Bestätigung der Gegenstelle sind gesonderte Verträge. Auch prüfen, wie die Anwendung mit einer geschlossenen Pipe oder einem geschlossenen Socket umgeht, einschliesslich des relevanten Signalverhaltens. Es wird hier kein ausgeführter Systemaufruf-Fehlerinjektionslauf behauptet; die Fixtur ist ein vorgeschlagenes Regressionsdesign für den zu ändernden Wrapper.