Perskaitykite aštuonis baitus, tada perduokite SOCKS4 tunelį
Venkite praryti paskirties serverio pasveikinimą ar laukti neegzistuojančių baitų, analizuodami fiksuotą SOCKS4 atsakymo ribą.
SOCKS4 prisijungimo užklausa pavyksta, bet programa niekada nemato serverio pradinio pasveikinimo. Viena vieta, kurią verta patikrinti, yra pirmasis jungties skaitymas. Šešiolikos baitų skaitymas yra per didelis aštuonių baitų SOCKS4 atsakymui.
| Atsakymo laukas | Baitai |
|---|---|
| Atsakymo versijos laukas | 1 |
| Rezultato kodas | 1 |
| Prievado laukas | 2 |
| Adreso laukas | 4 |
Rezultato kodas 0x5a rodo, kad užklausa buvo patenkinta. SOCKS4a pakeičia, kaip užklausa perneša pagrindinio kompiuterio vardą; jis nepaverčia atsakymo šešiolika baitų.
Po atsakymo tas pats TCP srautas perneša paskirties protokolą. Pašto serveris gali išsiųsti savo pasveikinimą iš karto. Todėl skaitymas, sunaudojantis šešiolika prieinamų baitų, gali pagriebti visą tarpinio serverio atsakymą ir pirmuosius aštuonis to pasveikinimo baitus. Jei dar nieko neseka, per didelis blokuojantis skaitymas gali vietoj to pridėti nereikalingą laukimą.
Tikslus ilgis yra analizatoriaus atsakomybė
Vienkartinis aštuonių baitų prašymas nėra pakankamas įrodymas, kad atvyko aštuoni baitai. Srauto skaitymai gali grąžinti mažiau. Surinkite tikslų atsakymo ilgį per terminą, sustokite ties uždaru ar nepavykusiu srautu, patikrinkite atsakymą ir palikite tolesnius baitus programai.
Jei jungtis naudoja didesnį buferinį skaitymą, išsaugokite viską po ribos ir perduokite kitam vartotojui. Pertekliaus išmetimas yra tas pats duomenų praradimas su kitu skaitymo dydžiu.
SOCKS5 reikia savo analizatoriaus. Jo atsakymo adreso ilgis gali skirtis pagal adreso tipą. Kiekvieno tarpinio serverio skaitymo pakeitimas fiksuotu aštuonių baitų skaitymu sutvarkytų vieną protokolą, bet sugadintų kitą.