Legu ok bajtojn, poste transdonu la SOCKS4-tunelon
Evitu engluti la saluton de la celo aŭ atendi neekzistantajn bajtojn per analizo de la fiksa limo de la SOCKS4-respondo.
La peto pri SOCKS4-konekto sukcesas, sed la aplikaĵo neniam vidas la malferman saluton de la servilo. Unu loko por rigardi estas la unua legado de la konektilo. Legado de dek ses bajtoj estas tro granda por okbajta SOCKS4-respondo.
| Kampo de la respondo | Bajtoj |
|---|---|
| Kampo de responda versio | 1 |
| Rezulta kodo | 1 |
| Kampo de pordo | 2 |
| Kampo de adreso | 4 |
La rezulta kodo 0x5a montras, ke la peto estis aprobita. SOCKS4a ŝanĝas kiel la peto portas gastigantan nomon; ĝi ne faras la respondon dek ses bajtojn.
Post la respondo, la sama TCP-fluo portas la protokolon de la celo. Poŝta servilo povas tuj sendi sian saluton. Do legado, kiu konsumas dek ses disponeblajn bajtojn, povas preni la kompletan prokuran respondon plus la unuajn ok bajtojn de tiu saluto. Se ankoraŭ nenio sekvas, trogranda blokanta legado povas anstataŭe aldoni nenecesan atendon.
Ekzakta longo estas respondeco de la analizilo
Peti ok bajtojn unufoje ne estas sufiĉa pruvo, ke ok bajtoj alvenis. Fluaj legadoj povas redoni malpli. Kolektu ekzakte la longon de la respondo ene de templimo, haltu ĉe fermita aŭ malsukcesa fluo, ekzamenu la respondon, kaj lasu la sekvajn bajtojn al la aplikaĵo.
Se la konektilo uzas pli grandan bufran legadon, konservu ĉion post la limo kaj transdonu ĝin al la sekva konsumanto. Forĵeti la surpluson estas la sama datumperdo kun alia lega grandeco.
SOCKS5 bezonas sian propran analizilon. La adreso de ĝia respondo povas havi malsamajn longojn laŭ la adresa tipo. Anstataŭigi ĉiun prokuran legadon per fiksa legado de ok bajtoj riparus unu protokolon dum ĝi rompus alian.