SOCKS4 കണക്ഷൻ അഭ്യർത്ഥന വിജയിക്കുന്നു, പക്ഷേ അപ്ലിക്കേഷൻ സെർവറിന്റെ ആവുന്ന അഭിവാദ്യം ഒരിക്കലും കാണുന്നില്ല. നോക്കേണ്ട ഒരു സ്ഥലം കണക്ടറിന്റെ ആദ്യ വായനയാണ്. പതിനാറ് ബൈറ്റ് വായന എട്ട് ബൈറ്റ് SOCKS4 പ്രതികരണത്തിന് വളരെ വലുതാണ്.

പ്രതികരണ ഫീൽഡ്ബൈറ്റ്
പ്രതികരണ പതിപ്പ് ഫീൽഡ്1
ഫല കോഡ്1
പോർട്ട് ഫീൽഡ്2
വിലാസ ഫീൽഡ്4

ഫല കോഡ് 0x5a അഭ്യർത്ഥന അനുവദിക്കപ്പെട്ടു എന്ന് കാണിക്കുന്നു. SOCKS4a അഭ്യർത്ഥന ഹോസ്റ്റ്നെയിം എങ്ങനെ വഹിക്കുന്നു എന്ന് മാറ്റുന്നു; അത് പ്രതികരണത്തെ പതിനാറ് ബൈറ്റ് ആക്കുന്നില്ല.

പ്രതികരണത്തിന് ശേഷം അതേ TCP സ്ട്രീം ലക്ഷ്യത്തിന്റെ പ്രോട്ടോക്കോൾ വഹിക്കുന്നു. ഒരു മെയിൽ സെർവർ അതിന്റെ അഭിവാദ്യം ഉടൻ അയച്ചേക്കാം. അതിനാൽ ലഭ്യമായ പതിനാറ് ബൈറ്റ് ഉപയോഗിക്കുന്ന വായന പൂർണ്ണ പ്രോക്സി പ്രതികരണത്തോടൊപ്പം ആ അഭിവാദ്യത്തിന്റെ ആദ്യ എട്ട് ബൈറ്റും എടുത്തേക്കാം. ഇപ്പോഴും ഒന്നും പിന്തുടരുന്നില്ലെങ്കിൽ, വളരെ വലിയ ബ്ലോക്കിംഗ് വായന പകരം അനാവശ്യമായ കാത്തിരിപ്പ് ചേർത്തേക്കാം.

കൃത്യമായ നീളം പാഴ്സറിന്റെ ഉത്തരവാദിത്തമാണ്

ഒരിക്കൽ എട്ട് ബൈറ്റ് ആവശ്യപ്പെടുന്നത് എട്ട് ബൈറ്റ് എത്തി എന്നതിന് മതിയായ തെളിവല്ല. സ്ട്രീം വായനകൾ കുറവ് നൽകിയേക്കാം. ഒരു സമയപരിധിക്കുള്ളിൽ പ്രതികരണത്തിന്റെ നീളം കൃത്യമായി ശേഖരിക്കുക, അടച്ചതോ പരാജയപ്പെട്ടതോ ആയ സ്ട്രീമിൽ നിർത്തുക, പ്രതികരണം പരിശോധിക്കുക, തുടർന്നുള്ള ബൈറ്റുകൾ അപ്ലിക്കേഷന് നൽകുക.

കണക്ടർ വലിയ ബഫർ വായന ഉപയോഗിക്കുന്നെങ്കിൽ അതിർത്തിക്ക് ശേഷമുള്ളതെല്ലാം സൂക്ഷിച്ച് അടുത്ത ഉപഭോക്താവിന് കൈമാറുക. അധികമുള്ളത് കളയുന്നത് വ്യത്യസ്ത വായന വലിപ്പത്തോടെയുള്ള അതേ ഡാറ്റ നഷ്ടമാണ്.

SOCKS5-ന് സ്വന്തം പാഴ്സർ വേണം. അതിന്റെ പ്രതികരണ വിലാസത്തിന്റെ നീളം വിലാസ തരം അനുസരിച്ച് വ്യത്യാസപ്പെടാം. ഓരോ പ്രോക്സി വായനയും സ്ഥിരമായ എട്ട് ബൈറ്റ് വായന കൊണ്ട് മാറ്റുന്നത് ഒരു പ്രോട്ടോക്കോൾ നന്നാക്കി മറ്റൊന്ന് തകർക്കും.

അനുബന്ധ ലേഖനങ്ങൾ