ഒരു C struct മോശം SOCKS അഭ്യർത്ഥന എന്തുകൊണ്ട് ഉണ്ടാക്കാം
കമ്പൈലർ ലേഔട്ടിനെ വയർ ഫോർമാറ്റായി കണക്കാക്കാതെ വ്യക്തമായ ഫീൽഡ് വീതി, ബൈറ്റ് ക്രമം, സ്ട്രീം I/O എന്നിവ പരിശോധിക്കുക.
സാധുവായ പ്രോക്സി വിലാസം കൈകൊണ്ട് എഴുതിയ SOCKS സന്ദേശത്തെ സാധുവാക്കുന്നില്ല. C അല്ലെങ്കിൽ C++ struct അയക്കുന്നത് പ്രോട്ടോക്കോൾ ഒരിക്കലും ആവശ്യപ്പെടാത്ത പാഡിംഗോ ഹോസ്റ്റ് ക്രമത്തിലുള്ള പൂർണ്ണസംഖ്യകളോ അയക്കാം.
SOCKS5 ഡൊമെയ്ൻ-നാമ CONNECT അഭ്യർത്ഥനയ്ക്ക്, രീതി ചർച്ചയ്ക്കും തിരഞ്ഞെടുത്ത ഏതെങ്കിലും പ്രാമാണീകരണത്തിനും ശേഷം ഈ ക്രമം വ്യക്തമായി സീരിയലൈസ് ചെയ്യുക:
- പതിപ്പ്, കമാൻഡ്, റിസർവ് ചെയ്ത ബൈറ്റ്, വിലാസ തരം
- ഡൊമെയ്ൻ നീളവും ഡൊമെയ്ൻ ബൈറ്റുകളും
- നെറ്റ്വർക്ക് ബൈറ്റ് ക്രമത്തിൽ രണ്ട്-ബൈറ്റ് ലക്ഷ്യ പോർട്ട്
വിലാസ നീളങ്ങൾ SOCKS പതിപ്പിനെയും വിലാസ തരത്തെയും ആശ്രയിച്ചിരിക്കുന്നു. നിശ്ചിത വീതിയുള്ള സംഖ്യാ ഫീൽഡുകൾക്ക് അവയുടെ നിർദ്ദിഷ്ട പ്രാതിനിധ്യം വേണം; ഡൊമെയ്ൻ സ്ട്രിംഗുകൾക്ക് സ്വന്തം നീള എൻകോഡിംഗ് ഉണ്ട്. C സ്ട്രിംഗ് ടെർമിനേറ്റർ വയർ സന്ദേശത്തിൽ പൂജ്യം ചേർക്കാനുള്ള പൊതു നിർദ്ദേശമല്ല.
| നടപ്പാക്കലിലെ കുറുക്കുവഴി | പരിശോധിക്കേണ്ട പ്രശ്നം |
|---|---|
| 8-ബിറ്റ് പോയിന്റർ വഴി 32-ബിറ്റ് മൂല്യം നൽകുന്നത് | അത് നാല് ബൈറ്റുകളും പുറത്തുവിടുന്നില്ല |
| ഒരു ബഫർ വലിയ പൂർണ്ണസംഖ്യ പോയിന്ററായി കാസ്റ്റ് ചെയ്യുന്നത് | അലൈൻമെന്റും ബൈറ്റ് ക്രമവും ഇപ്പോഴും കൈകാര്യം ചെയ്യണം |
| ഒരു വായനയോ എഴുത്തോ ഒരു സന്ദേശമാണെന്ന് അനുമാനിക്കുന്നത് | TCP-ക്ക് പ്രോട്ടോക്കോൾ ക്രമത്തിന്റെ ഒരു ഭാഗം മാത്രം കൈമാറാനാകും |
ഓരോ ഫീൽഡും ഉദ്ദേശിച്ച ലക്ഷ്യവുമായി താരതമ്യം ചെയ്ത് ഭാഗിക I/O കൈകാര്യം ചെയ്യുക. രണ്ട് ബൈറ്റുകൾ ലഭിച്ചാൽ മുഴുവൻ മറുപടിയും എത്തിയെന്ന് തെളിയുന്നില്ല. ആ അതിരുകൾ പരിശോധിക്കുന്നത് വികലമായ അഭ്യർത്ഥനയെ ശരിയായി വിവരിച്ച കണക്ഷൻ നിരസിക്കുന്ന സർവറിൽ നിന്ന് വേർതിരിക്കാം.