Прачытайце восем байтаў, потым перадайце тунель SOCKS4
Пазбягайце паглынання прывітання прызначэння або чакання неіснуючых байтаў, разбіраючы фіксаваную мяжу адказу SOCKS4.
Запыт злучэння SOCKS4 паспяхова выконваецца, але праграма ніколі не бачыць пачатковага прывітання сервера. Адно з месцаў, дзе варта паглядзець, — першае чытанне канэктара. Чытанне шаснаццаці байтаў занадта вялікае для адказу SOCKS4 памерам восем байтаў.
| Поле адказу | Байты |
|---|---|
| Поле версіі адказу | 1 |
| Код выніку | 1 |
| Поле порта | 2 |
| Поле адраса | 4 |
Код выніку 0x5a паказвае, што запыт задаволены. SOCKS4a змяняе тое, як запыт перадае імя хаста; ён не робіць адказ шаснаццаццю байтамі.
Пасля адказу той самы паток TCP перадае пратакол прызначэння. Паштовы сервер можа адправіць сваё прывітанне адразу. Такім чынам, чытанне, якое спажывае шаснаццаць даступных байтаў, можа забраць поўны адказ проксі разам з першымі васьмю байтамі гэтага прывітання. Калі далей пакуль нічога не ідзе, завялікае блакуючае чытанне можа замест гэтага дадаць непатрэбнае чаканне.
Дакладная даўжыня — абавязак парсера
Аднаразовы запыт васьмі байтаў не дастатковы доказ таго, што восем байтаў прыйшлі. Чытанні патоку могуць вярнуць менш. Збірайце дакладна даўжыню адказу ў межах дэдлайна, спыняйцеся пры закрытым або памылковым патоку, правярайце адказ і пакідайце наступныя байты праграме.
Калі канэктар выкарыстоўвае большае буферызаванае чытанне, захоўвайце ўсё пасля мяжы і перадавайце наступнаму спажыўцу. Адкіданне лішку — гэта тая ж страта даных пры іншым памеры чытання.
SOCKS5 патрабуе ўласнага парсера. Даўжыня яго адраса адказу можа быць рознай у залежнасці ад тыпу адраса. Замена кожнага чытання проксі фіксаваным чытаннем васьмі байтаў выправіла б адзін пратакол, але зламала б іншы.