Odczytaj osiem bajtów, potem przekaż tunel SOCKS4

Żądanie połączenia SOCKS4 kończy się powodzeniem, ale aplikacja nigdy nie widzi powitania otwierającego serwer. Jedno z miejsc do sprawdzenia to pierwszy odczyt łącznika. Odczyt szesnastu bajtów jest zbyt duży dla ośmiobajtowej odpowiedzi SOCKS4.

Kod wyniku 0x5a wskazuje, że żądanie zostało zaakceptowane. SOCKS4a zmienia sposób, w jaki żądanie przenosi nazwę hosta; nie zamienia odpowiedzi w szesnaście bajtów.

Po odpowiedzi ten sam strumień TCP przenosi protokół celu. Serwer pocztowy może natychmiast wysłać swoje powitanie. Dlatego odczyt zużywający szesnaście dostępnych bajtów może zabrać pełną odpowiedź proxy oraz pierwsze osiem bajtów tego powitania. Jeśli nic jeszcze nie następuje, zbyt duży blokujący odczyt może zamiast tego dodać zbędne oczekiwanie.

Dokładna długość to obowiązek parsera

Jednorazowe zażądanie ośmiu bajtów nie jest wystarczającym dowodem, że osiem bajtów dotarło. Odczyty strumienia mogą zwrócić mniej. Zbierz dokładnie długość odpowiedzi w terminie, zatrzymaj się przy zamkniętym lub nieudanym strumieniu, sprawdź odpowiedź i zostaw kolejne bajty aplikacji.

Jeśli łącznik używa większego buforowanego odczytu, zachowaj wszystko po granicy i przekaż następnemu konsumentowi. Wyrzucenie nadmiaru to ta sama utrata danych przy innej wielkości odczytu.

SOCKS5 potrzebuje własnego parsera. Długość adresu jego odpowiedzi może się różnić w zależności od typu adresu. Zastąpienie każdego odczytu proxy stałym odczytem ośmiu bajtów naprawiłoby jeden protokół, psując inny.