കാത്തിരിക്കുന്ന ബൈറ്റുകൾ ഒഴിവാക്കിയ ശേഷം 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 റിലേയ്ക്ക് മുകളിൽ നിലനിർത്തുക.