Pročitajte osam bajtova, zatim predajte SOCKS4 tunel
Izbjegnite gutanje pozdrava odredišta ili čekanje nepostojećih bajtova analizom fiksne granice SOCKS4 odgovora.
Zahtjev za SOCKS4 vezu uspijeva, ali aplikacija nikada ne vidi početni pozdrav poslužitelja. Jedno mjesto koje treba provjeriti je prvo čitanje konektora. Čitanje od šesnaest bajtova preveliko je za SOCKS4 odgovor od osam bajtova.
| Polje odgovora | Bajtovi |
|---|---|
| Polje verzije odgovora | 1 |
| Kôd rezultata | 1 |
| Polje porta | 2 |
| Polje adrese | 4 |
Kôd rezultata 0x5a pokazuje da je zahtjev odobren. SOCKS4a mijenja način na koji zahtjev nosi ime hosta; on ne pretvara odgovor u šesnaest bajtova.
Nakon odgovora isti TCP tok nosi protokol odredišta. Poštanski poslužitelj može poslati svoj pozdrav odmah. Zato čitanje koje potroši šesnaest dostupnih bajtova može uzeti potpuni odgovor proxyja plus prvih osam bajtova tog pozdrava. Ako još ništa ne slijedi, preveliko blokirajuće čitanje može umjesto toga dodati nepotrebno čekanje.
Točna dužina odgovornost je parsera
Traženje osam bajtova jednom nije dovoljan dokaz da je osam bajtova stiglo. Čitanja toka mogu vratiti manje. Prikupite točno dužinu odgovora u zadanom roku, zaustavite se na zatvorenom ili neuspjelom toku, pregledajte odgovor i ostavite sljedeće bajtove aplikaciji.
Ako konektor koristi veće baferirano čitanje, sačuvajte sve nakon granice i proslijedite sljedećem potrošaču. Odbacivanje viška isti je gubitak podataka s drugom veličinom čitanja.
SOCKS5 treba vlastiti parser. Dužina njegove adrese odgovora može se razlikovati prema vrsti adrese. Zamjena svakog proxy čitanja fiksnim čitanjem od osam bajtova popravila bi jedan protokol, ali bi pokvarila drugi.