Прочетете осем байта, после предайте тунела SOCKS4
Избегнете поглъщането на поздрава на дестинацията или чакането на несъществуващи байтове, като анализирате фиксираната граница на отговора SOCKS4.
Заявката за връзка SOCKS4 успява, но приложението така и не вижда началния поздрав на сървъра. Едно място за проверка е първото четене на конектора. Четене от шестнадесет байта е твърде голямо за отговор SOCKS4 от осем байта.
| Поле на отговора | Байтове |
|---|---|
| Поле за версия на отговора | 1 |
| Код на резултата | 1 |
| Поле за порт | 2 |
| Поле за адрес | 4 |
Кодът на резултата 0x5a показва, че заявката е разрешена. SOCKS4a променя начина, по който заявката носи име на хост; той не превръща отговора в шестнадесет байта.
След отговора същият TCP поток носи протокола на дестинацията. Пощенски сървър може да изпрати поздрава си веднага. Затова четене, което изразходва шестнадесет налични байта, може да вземе пълния отговор на проксито плюс първите осем байта от този поздрав. Ако все още нищо не следва, прекалено голямото блокиращо четене може вместо това да добави ненужно изчакване.
Точната дължина е отговорност на парсера
Еднократното искане на осем байта не е достатъчно доказателство, че осем байта са пристигнали. Четенията от поток могат да върнат по-малко. Събирайте точно дължината на отговора в рамките на краен срок, спирайте при затворен или неуспешен поток, прегледайте отговора и оставете следващите байтове за приложението.
Ако конекторът използва по-голямо буферирано четене, запазете всичко след границата и го подайте на следващия потребител. Изхвърлянето на излишъка е същата загуба на данни с различен размер на четене.
SOCKS5 се нуждае от свой собствен парсер. Адресът в отговора му може да има различна дължина според типа адрес. Замяната на всяко прокси четене с фиксирано четене от осем байта би поправила един протокол, но би счупила друг.