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