TCP-halfsluiting doorgeven nadat de wachtende bytes zijn weggeschreven
Verwerk EOF in een TCP-proxy zonder gebufferde gegevens te verliezen of het antwoord in de andere richting af te kappen.
De client is klaar met verzenden, de proxy ziet EOF en het antwoord verdwijnt. Beide proxy-sockets meteen sluiten kan precies die volgorde veroorzaken. In een TCP-relay betekent een ordelijk einde in één richting niet dat de andere richting klaar is.
Denk aan een client die een verzoek stuurt, zijn verzendzijde sluit en op het antwoord wacht:
client -- request, then FIN --> proxy --> service
client <-------- reply ------- proxy <-- service
De proxy heeft twee TCP-verbindingen en twee onafhankelijk bewegende bytestromen. Hij moet de aanduiding van het einde van de invoer doorgeven, nadat hij de bytes die eraan voorafgaan heeft doorgegeven.
Leeg de wachtrij voordat EOF wordt doorgegeven
Bij een ontvangst van niet-nul grootte op een TCP-stroom betekent een terugkeer van nul een ordelijk einde van die inkomende stroom. Markeer die leesrichting als voltooid. Stop met wachten op meer invoer ervan, maar behoud bytes die al in de wachtrij staan voor de tegenoverliggende socket.
Zodra de wachtrij van client naar dienst leeg is, roep shutdown(service_socket, SHUT_WR) aan op een POSIX-socket. Dat beëindigt verdere overdracht naar de dienst terwijl de richting van dienst naar client beschikbaar blijft. Wanneer de dienst zijn antwoord afrondt, pas dan de gespiegelde bewerking toe nadat de antwoordwachtrij leeg is.
Het sluiten van de descriptoren hoort bij het punt waarop beide richtingen en hun wachtende buffers klaar zijn, of waarop een fout of annulering beëindiging vereist. Houd een begrensde time-out aan voor een peer die zijn resterende helft nooit voltooit.
Gereedheid is een uitnodiging om te lezen
Een leesbare socket kan gegevens of een EOF-toestand hebben. Roep recv aan en interpreteer het resultaat. Positieve aantallen zijn door te geven bytes; nul is het richtingseinde. Op een niet-blokkerende socket betekent EAGAIN of EWOULDBLOCK dat er op dit moment geen verdere invoer is, terwijl EINTR opnieuw proberen kan vereisen. Geen van beide is dezelfde gebeurtenis als EOF.
Zoek niet naar een FIN-vlag in de teruggegeven bytebuffer. TCP levert een geordende bytestroom aan deze API; pakketgrenzen en het FIN-segment zijn geen gewone applicatielading.
Dit is de levenscyclus van een ruwe bytetunnel. Een HTTP-proxy die berichten parseert, moet nog steeds HTTP-framing respecteren, en een TLS-beëindigende proxy heeft ook een TLS-afsluitprotocol. Houd die protocolbeslissingen boven de gerichte TCP-relay.