O buclă vrea opt octeți dintr-un răspuns SOCKS. A primit trei. Următoarea citire returnează b'', iar bucla îl adaugă, verifică lungimea și încearcă din nou la nesfârșit.

Aceasta este o eroare de gestionare a EOF, nu un proxy lent care are nevoie de un timeout mai lung. La o recepție normală printr-un socket de flux, un șir de octeți gol înseamnă că partenerul s-a deconectat. Cei cinci octeți rămași nu vor sosi pe acea conexiune.

Un helper de citire exactă are nevoie de trei rezultate distincte: acumularea fragmentelor nevide, eșecul la EOF înainte de lungimea necesară și propagarea unui timeout sau a altei erori de socket. Aceste cazuri nu ar trebui să se contopească într-o singură buclă generică de reîncercare.

Setați timeout-ul dorit al socketului înainte de operație și citiți lungimile de câmp specificate de protocolul proxy-ului. O singură recepție poate returna doar o parte a unui răspuns. Invers, cererea unui buffer fix mare nu face ca fiecare adresă SOCKS să aibă acea lungime.

Nu reparați o dependență lipind un fragment vechi MSG_WAITALL în codul său sursă și presupunând că acoperă EOF, semnalele și comportamentul platformei. Preferați corecția acceptată a implementării întreținute sau implementați deliberat contractul helperului atunci când parserul este codul dumneavoastră.

Păstrați câți octeți erau așteptați și câți au fost primiți, fără a înregistra payload-uri de acreditări. „EOF după trei din opt octeți de răspuns” explică mult mai bine schimbul rupt decât „proxy-ul s-a blocat din nou”.

Articole similare