ഒരു ലൂപ്പിന് SOCKS മറുപടിയുടെ എട്ട് ബൈറ്റ് വേണം. അതിന് മൂന്ന് ലഭിച്ചു. അടുത്ത വായന b'' നൽകുന്നു, ലൂപ്പ് അത് ചേർക്കുന്നു, നീളം പരിശോധിക്കുന്നു, എന്നെന്നും വീണ്ടും ശ്രമിക്കുന്നു.

ഇത് EOF കൈകാര്യം ചെയ്യുന്നതിലെ ബഗ്ഗാണ്, കൂടുതൽ ടൈംഔട്ട് ആവശ്യമുള്ള പതുക്കെയുള്ള പ്രോക്സിയല്ല. സാധാരണ സ്ട്രീം-സോക്കറ്റ് സ്വീകരണത്തിൽ, ശൂന്യമായ ബൈറ്റ് സ്ട്രിംഗ് എന്നാൽ ഇരുൾ വിച്ഛേദിച്ചു എന്നാണ്. ബാക്കിയുള്ള അഞ്ച് ബൈറ്റ് ആ കണക്ഷനിൽ വരില്ല.

കൃത്യമായ-വായന സഹായിക്ക് മൂന്ന് വ്യത്യസ്ത ഫലങ്ങൾ വേണം: ശൂന്യമല്ലാത്ത കഷണങ്ങൾ ശേഖരിക്കുക, ആവശ്യമായ നീളത്തിന് മുമ്പ് EOF-ൽ പരാജയപ്പെടുക, ടൈംഔട്ട് അല്ലെങ്കിൽ മറ്റ് സോക്കറ്റ് പിശക് കൈമാറുക. ആ കേസുകൾ ഒരു പൊതു വീണ്ടും-ശ്രമ ലൂപ്പിൽ ലയിക്കരുത്.

പ്രവർത്തനത്തിന് മുമ്പ് സോക്കറ്റിന്റെ ഉദ്ദേശിത ടൈംഔട്ട് സജ്ജമാക്കുക, പ്രോക്സി പ്രോട്ടോക്കോൾ നിർദ്ദേശിക്കുന്ന ഫീൽഡ് നീളങ്ങൾ വായിക്കുക. ഒരു സ്വീകരണം മറുപടിയുടെ ഒരു ഭാഗം മാത്രമേ നൽകൂ. നേരെമറിച്ച്, വലിയ സ്ഥിര ബഫർ ആവശ്യപ്പെടുന്നത് ഓരോ SOCKS വിലാസവും ആ നീളമാക്കുന്നില്ല.

പഴയ MSG_WAITALL സ്നിപ്പെറ്റ് അതിന്റെ സോഴ്സിൽ ഒട്ടിച്ച് EOF, സിഗ്നലുകൾ, പ്ലാറ്റ്ഫോം സ്വഭാവം എന്നിവ അത് ഉൾക്കൊള്ളുന്നു എന്ന് കരുതി ഒരു ആശ്രിതത്വം നന്നാക്കരുത്. പരിപാലിക്കുന്ന നിർവഹണത്തിന്റെ പിന്തുണയുള്ള പരിഹാരം തിരഞ്ഞെടുക്കുക, അല്ലെങ്കിൽ പാഴ്സർ നിങ്ങളുടെ കോഡാണെങ്കിൽ സഹായിയുടെ കരാർ ബോധപൂർവം നടപ്പാക്കുക.

എത്ര ബൈറ്റ് പ്രതീക്ഷിച്ചു, എത്ര ലഭിച്ചു എന്ന് സൂക്ഷിക്കുക, ക്രെഡൻഷ്യൽ പേലോഡുകൾ ലോഗ് ചെയ്യാതെ. “എട്ട് മറുപടി ബൈറ്റിൽ മൂന്നിന് ശേഷം EOF” തകർന്ന കൈമാറ്റം “പ്രോക്സി വീണ്ടും കുടുങ്ങി” എന്നതിനേക്കാൾ വളരെ നന്നായി വിശദീകരിക്കുന്നു.

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