Slučka chce osem bajtov odpovede SOCKS. Dostala tri. Ďalšie čítanie vráti b'', slučka ho pridá, skontroluje dĺžku a skúša to znova donekonečna.

To je chyba spracovania EOF, nie pomalý proxy, ktorý potrebuje dlhší časový limit. Pri bežnom príjme cez streamový socket prázdny bajtový reťazec znamená, že partner sa odpojil. Zvyšných päť bajtov týmto spojením nedorazí.

Pomocník presného čítania potrebuje tri odlišné výsledky: zhromažďovať neprázdne časti, zlyhať na EOF pred požadovanou dĺžkou a odovzdať časový limit alebo inú chybu socketu. Tieto prípady sa nesmú zliať do jednej všeobecnej slučky opakovania.

Pred operáciou nastavte zamýšľaný časový limit socketu a čítajte dĺžky polí určené protokolom proxy. Jediný príjem môže vrátiť len časť odpovede. Naopak, požiadavka na veľký pevný buffer neznamená, že každá adresa SOCKS má takú dĺžku.

Neopravujte závislosť vložením starého úryvku MSG_WAITALL do jej zdrojového kódu a predpokladom, že pokrýva EOF, signály a správanie platformy. Uprednostnite podporovanú opravu v udržiavanom implementácii, alebo keď je parser váš kód, zámerne implementujte kontrakt pomocníka.

Zaznamenajte, koľko bajtov sa očakávalo a prijalo, bez logovania užitočných dát s prihlasovacími údajmi. „EOF po troch z ôsmich bajtov odpovede“ vysvetľuje porušenú výmenu oveľa lepšie ako „proxy zase zamrzol“.

Súvisiace články