Citește opt octeți, apoi predă tunelul SOCKS4
Evită să înghiți mesajul de salut al destinației sau să aștepți octeți inexistenți analizând limita fixă a răspunsului SOCKS4.
Cererea de conexiune SOCKS4 reușește, dar aplicația nu vede niciodată mesajul de salut inițial al serverului. Un loc de verificat este prima citire a conectorului. O citire de șaisprezece octeți este prea mare pentru un răspuns SOCKS4 de opt octeți.
| Câmpul răspunsului | Octeți |
|---|---|
| Câmpul versiunii răspunsului | 1 |
| Codul rezultatului | 1 |
| Câmpul portului | 2 |
| Câmpul adresei | 4 |
Codul rezultatului 0x5a indică faptul că cererea a fost aprobată. SOCKS4a schimbă modul în care cererea transportă un nume de gazdă; nu transformă răspunsul în șaisprezece octeți.
După răspuns, același flux TCP transportă protocolul destinației. Un server de poștă poate trimite salutul imediat. Prin urmare, o citire care consumă șaisprezece octeți disponibili poate lua răspunsul complet al proxy-ului plus primii opt octeți ai acelui salut. Dacă nu urmează încă nimic, o citire blocantă prea mare poate adăuga în schimb o așteptare inutilă.
Lungimea exactă este responsabilitatea parserului
Cererea de opt octeți o singură dată nu este o dovadă suficientă că au sosit opt octeți. Citirile de flux pot returna mai puțin. Colectează exact lungimea răspunsului într-un termen, oprește-te la un flux închis sau eșuat, inspectează răspunsul și lasă octeții următori aplicației.
Dacă conectorul folosește o citire cu buffer mai mare, păstrează tot ce urmează după limită și transmite-l următorului consumator. Aruncarea surplusului este aceeași pierdere de date cu o altă dimensiune a citirii.
SOCKS5 are nevoie de propriul parser. Adresa răspunsului său poate avea lungimi diferite în funcție de tipul adresei. Înlocuirea fiecărei citiri a proxy-ului cu o citire fixă de opt octeți ar repara un protocol, dar ar strica altul.