Прочитајте осам бајтова, затим предајте SOCKS4 тунел
Избегните гутање поздрава одредишта или чекање непостојећих бајтова анализом фиксне границе SOCKS4 одговора.
Захтев за SOCKS4 везу успева, али апликација никада не види почетни поздрав сервера. Једно место које треба проверити је прво читање конектора. Читање од шеснаест бајтова превелико је за SOCKS4 одговор од осам бајтова.
| Поље одговора | Бајтови |
|---|---|
| Поље верзије одговора | 1 |
| Код резултата | 1 |
| Поље порта | 2 |
| Поље адресе | 4 |
Код резултата 0x5a показује да је захтев одобрен. SOCKS4a мења начин на који захтев носи име хоста; он не претвара одговор у шеснаест бајтова.
Након одговора исти TCP ток носи протокол одредишта. Поштански сервер може одмах послати свој поздрав. Зато читање које потроши шеснаест доступних бајтова може узети потпун одговор проксија плус првих осам бајтова тог поздрава. Ако још ништа не следи, превелико блокирајуће читање може уместо тога додати непотребно чекање.
Тачна дужина је одговорност парсера
Тражење осам бајтова једном није довољан доказ да је осам бајтова стигло. Читања тока могу вратити мање. Прикупите тачно дужину одговора у задатом року, зауставите се на затвореном или неуспелом току, прегледајте одговор и оставите следеће бајтове апликацији.
Ако конектор користи веће баферовано читање, сачувајте све након границе и проследите следећем потрошачу. Одбацивање вишка је исти губитак података са другом величином читања.
SOCKS5 захтева сопствени парсер. Дужина његове адресе одговора може се разликовати према типу адресе. Замена сваког читања проксија фиксним читањем од осам бајтова поправила би један протокол, али би покварила други.