Posredovanje polovičnega zaprtja TCP po izpraznitvi čakajočih bajtov

Odjemalec konča s pošiljanjem, proxy vidi EOF in odgovor izgine. Takojšnje zaprtje obeh proxyjevih vtičnic lahko povzroči natanko to zaporedje. V posredovalniku TCP urejen konec v eni smeri ne pomeni, da je druga smer končana.

Pomislite na odjemalca, ki pošlje zahtevo, zapre svojo pošiljajočo stran in čaka na odgovor:

client -- request, then FIN --> proxy --> service
client <-------- reply ------- proxy <-- service

Proxy ima dve povezavi TCP in dva neodvisno gibajoča se bajtna toka. Posredovati mora naprej oznako konca vhoda, potem ko je posredoval bajte, ki ji sledijo.

Izpraznite vrsto, preden posredujete EOF

Pri prejemu velikosti, ki ni nič, na toku TCP vrnitev ničle pomeni urejen konec tega dohodnega toka. Označite to smer branja kot končano. Nehajte čakati na več vhoda iz nje, vendar obdržite bajte, ki so že v vrsti za nasprotno vtičnico.

Ko se vrsta od odjemalca do storitve izprazni, pokličite shutdown(service_socket, SHUT_WR) na vtičnici POSIX. To konča nadaljnji prenos proti storitvi, smer od storitve do odjemalca pa ostane na voljo. Ko storitev konča svoj odgovor, po izpraznitvi vrste odgovorov uporabite zrcalno operacijo.

Zaprtje opisnikov sodi v trenutek, ko sta obe smeri in njuni čakajoči medpomnilniki končani, ali ko napaka ali preklic zahtevata prekinitev. Vzdržujte omejen časovni limit za partnerja, ki nikoli ne dokonča svoje preostale polovice.

Pripravljenost je povabilo k branju

Berljiva vtičnica ima lahko podatke ali stanje EOF. Pokličite recv in razložite rezultat. Pozitivna števila so bajti za posredovanje; ničla je konec smeri. Na neblokirni vtičnici EAGAIN ali EWOULDBLOCK pomenita, da trenutno ni več vhoda, medtem ko lahko EINTR zahteva ponovni poskus. Nobeno od obeh ni isti dogodek kot EOF.

V vrnjenem medpomnilniku bajtov ne iščite zastavice FIN. TCP tej API dostavi urejen tok bajtov; meje paketov in segment FIN niso običajna aplikacijska koristna obremenitev.

To je življenjski cikel surovega bajtovnega tunela. Proxy HTTP, ki razčlenjuje sporočila, mora še vedno spoštovati okvirjanje HTTP, proxy, ki zaključi TLS, pa ima tudi protokol zaprtja TLS. Te protokolarne odločitve držite nad usmerjenim posredovalnikom TCP.