Les åtte byte og overlever deretter SOCKS4-tunnelen
Unngå å svelgje helsinga frå målet eller vente på byte som ikkje finst, ved å parse den faste SOCKS4-svargrensa.
SOCKS4-tilkoplingsførespurnaden lukkast, men programmet ser aldri opningshelsinga til tenaren. Eit stad å sjå er den første lesinga til koplinga. Ei lesing på seksten byte er for stor for eit SOCKS4-svar på åtte byte.
| Svarfelt | Byte |
|---|---|
| Felt for svarversjon | 1 |
| Resultatkode | 1 |
| Portfelt | 2 |
| Adressefelt | 4 |
Resultatkoden 0x5a viser at førespurnaden vart innvilga. SOCKS4a endrar korleis førespurnaden ber eit vertsnamn; det gjer ikkje svaret til seksten byte.
Etter svaret ber den same TCP-straumen protokollen til målet. Ein e-posttenar kan sende helsinga si med det same. Ei lesing som brukar seksten tilgjengelege byte, kan difor ta heile proxy-svaret pluss dei første åtte byta av den helsinga. Viss ingenting følgjer enno, kan ei for stor blokkerande lesing i staden leggje til ei unødvendig venting.
Nøyaktig lengd er ansvaret til parsaren
Å be om åtte byte éin gong er ikkje tilstrekkeleg prov for at åtte byte har kome. Straumlesingar kan gje mindre attende. Samle nøyaktig lengda på svaret innan ein frist, stogg ved ein stengd eller mislukka straum, gransk svaret, og lat dei neste byta vere att for programmet.
Viss koplinga brukar ei større bufra lesing, ta vare på alt etter grensa og send det vidare til neste brukar. Å kaste overskotet er det same datatapet med ein annan lesestorleik.
SOCKS5 treng sin eigen parsar. Lengda på svaradressa kan variere etter adresstypen. Å byta ut kvar proxy-lesing med ei fast lesing på åtte byte ville rette éin protokoll og øydeleggje ein annan.