બાકી રહેલા બાઇટ્સ ખાલી કર્યા પછી TCP હાફ-ક્લોઝ ફોરવર્ડ કરવું

ક્લાયન્ટ મોકલવાનું પૂરું કરે છે, પ્રોક્સી EOF જુએ છે, અને જવાબ અદૃશ્ય થાય છે. પ્રોક્સીના બંને સોકેટ તરત બંધ કરવાથી બરાબર એ જ ક્રમ થઈ શકે છે. TCP રિલેમાં એક દિશામાં ક્રમબદ્ધ અંત એનો અર્થ નથી કે બીજી દિશા પૂરી થઈ છે.

એવા ક્લાયન્ટનો વિચાર કરો જે વિનંતી મોકલે છે, પોતાની મોકલવાની બાજુ બંધ કરે છે અને જવાબની રાહ જુએ છે:

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

પ્રોક્સી પાસે બે TCP જોડાણો અને સ્વતંત્ર રીતે આગળ વધતા બે બાઇટ સ્ટ્રીમ છે. તેણે પોતાના પહેલાં આવતા બાઇટ્સ ફોરવર્ડ કર્યા પછી ઇનપુટના અંતનું સૂચન પણ આગળ લઈ જવું પડે છે.

EOF ફોરવર્ડ કરતા પહેલા કતાર ખાલી કરો

TCP સ્ટ્રીમ પર બિન-શૂન્ય કદની પ્રાપ્તિમાં, શૂન્યનું વળતર તે આવતા સ્ટ્રીમનો ક્રમબદ્ધ અંત દર્શાવે છે. તે વાંચનની દિશાને પૂર્ણ તરીકે ચિહ્નિત કરો. તેનાથી વધુ ઇનપુટની રાહ જોવાનું બંધ કરો, પરંતુ વિરુદ્ધ સોકેટ માટે પહેલેથી કતારબદ્ધ બાઇટ્સ રાખો.

ક્લાયન્ટ-થી-સેવા કતાર ખાલી થયા પછી, POSIX સોકેટ પર shutdown(service_socket, SHUT_WR) કૉલ કરો. તે સેવા તરફનું વધુ પ્રસારણ સમાપ્ત કરે છે જ્યારે સેવા-થી-ક્લાયન્ટ દિશા ઉપલબ્ધ રહે છે. જ્યારે સેવા તેનો જવાબ પૂરો કરે, ત્યારે જવાબની કતાર ખાલી કર્યા પછી મિરર કરેલી ક્રિયા લાગુ કરો.

ડિસ્ક્રિપ્ટર્સ બંધ કરવા એ તે બિંદુની બાબત છે જ્યાં બંને દિશાઓ અને તેમના બાકી બફર પૂરા થાય છે, અથવા જ્યાં ભૂલ કે રદ કરવાથી સમાપ્તિ જરૂરી હોય. એવા પીઅર માટે મર્યાદિત સમય મર્યાદા રાખો જે ક્યારેય તેનો બાકીનો અડધો ભાગ પૂરો કરતું નથી.

તૈયારી વાંચવાનું આમંત્રણ છે

વાંચી શકાય તેવા સોકેટમાં ડેટા કે EOF સ્થિતિ હોઈ શકે. recv કૉલ કરો અને તેના પરિણામનું અર્થઘટન કરો. ધન સંખ્યાઓ ફોરવર્ડ કરવાના બાઇટ્સ છે; શૂન્ય દિશાનો અંત છે. નોનબ્લોકિંગ સોકેટ પર, EAGAIN કે EWOULDBLOCK એટલે અત્યારે વધુ ઇનપુટ નથી, જ્યારે EINTR ફરી પ્રયાસ કરવાની જરૂર પાડી શકે. બંનેમાંથી કોઈ EOF જેવી એ જ ઘટના નથી.

પરત મળેલા બાઇટ બફરમાં FIN ફ્લેગ શોધશો નહીં. TCP આ APIને ક્રમબદ્ધ બાઇટ સ્ટ્રીમ પહોંચાડે છે; પેકેટ સીમાઓ અને FIN સેગમેન્ટ સામાન્ય એપ્લિકેશન પેલોડ નથી.

આ કાચા બાઇટ ટનલનું જીવનચક્ર છે. સંદેશાઓ પાર્સ કરતી HTTP પ્રોક્સીએ હજી પણ HTTP ફ્રેમિંગનું સન્માન કરવું પડે છે, અને TLS સમાપ્ત કરતી પ્રોક્સીમાં પણ TLS શટડાઉન પ્રોટોકોલ હોય છે. તે પ્રોટોકોલ નિર્ણયોને દિશાત્મક TCP રિલેની ઉપર રાખો.