Welche Garantien gibt es für das Leeren der TCP-Sendepuffer, wenn überhaupt, wenn dieGefriersubsystemfriert eine Kontrollgruppe ein?
Betrachten Sie das folgende Szenario: Server A, der in einer Kontrollgruppe läuft, sendet Daten über TCP an Server B. Der TCP-Socket ist so konfiguriert, dass er Naggles Algorithmus verwendet (die TCP_NODELAYOption ist nicht gesetzt). Daher sendblockiert das Senden von Daten über den Socket nicht für das ACK von Server B, sondern kehrt zurück, nachdem die zu sendenden Daten in den TCP-Sendepuffer kopiert wurden. Danach, aber bevor die Daten an Server B gesendet wurden, wird die Kontrollgruppe eingefroren.
Was passiert mit den Daten im TCP-Sendepuffer?
- Wartet der Freeze-Vorgang, bis alle Daten im Puffer von Server B bestätigt wurden? Was passiert, wenn der Empfangspuffer von Server B voll ist? Wartet der Freeze-Vorgang unbegrenzt auf die Bestätigung von Server B?
- Wartet das Freeze nicht auf die ACK von Server B und sendet die Daten weiter, nachdem die Kontrollgruppe aufgetaut wurde? Wenn die Verzögerung zwischen Freeze und Thaw so lang ist, dass Server B die TCP-Verbindung schließen kann, gehen die Daten im Puffer verloren.
Links zu Spezifikationen und Garantien für dieses Verhalten sind willkommen. Aber vielleicht gibt es keine Garantien, sodass es fragil wäre, sich auf eines der beiden Verhaltensweisen zu verlassen?
Der Hintergrund der Frage ist, dass ich mich frage, wie vorsichtig man sein muss, wenn man Daten über TCP auf AWS Lambda sendet (meine Annahme ist, dass AWS Lambda cgroups verwendet, um nach/vor der Verarbeitung eines Lambda-Aufrufs einzufrieren/aufzutauen). Reicht es aus, Anwendungspuffer in den TCP-Socket/TCP-Sendepuffer zu leeren? Oder muss man sicherstellen, dass Server B die Daten auf der Anwendungsebene empfangen hat, indem man beispielsweise HTTP verwendet und auf die HTTP-Antwort des Servers wartet?