Pętla chce ośmiu bajtów odpowiedzi SOCKS. Otrzymała trzy. Następny odczyt zwraca b'', a pętla dołącza go, sprawdza długość i ponawia próbę w nieskończoność.

To błąd obsługi EOF, a nie wolny proxy, który potrzebuje dłuższego limitu czasu. Przy normalnym odbiorze przez gniazdo strumieniowe pusty ciąg bajtów oznacza, że druga strona się rozłączyła. Pozostałe pięć bajtów nie dotrze tym połączeniem.

Pomocnik dokładnego odczytu potrzebuje trzech różnych wyników: gromadzenia niepustych fragmentów, porażki na EOF przed wymaganą długością oraz przekazania limitu czasu lub innego błędu gniazda. Te przypadki nie powinny się zlewać w jedną ogólną pętlę ponowień.

Ustaw zamierzony limit czasu gniazda przed operacją i czytaj długości pól określone przez protokół proxy. Pojedynczy odbiór może zwrócić tylko część odpowiedzi. I odwrotnie, żądanie dużego stałego bufora nie sprawia, że każdy adres SOCKS ma taką długość.

Nie naprawiaj zależności, wklejając stary fragment MSG_WAITALL do jej źródła i zakładając, że obejmuje EOF, sygnały i zachowanie platformy. Preferuj obsługiwaną poprawkę utrzymywanego wdrożenia albo świadomie zaimplementuj kontrakt pomocnika, gdy parser jest twoim kodem.

Zachowaj informację, ile bajtów oczekiwano i odebrano, bez rejestrowania ładunków poświadczeń. „EOF po trzech z ośmiu bajtów odpowiedzi” wyjaśnia zepsutą wymianę znacznie lepiej niż „proxy znowu się zawiesił”.

Powiązane artykuły