Een lus wil acht bytes van een SOCKS-antwoord. Hij heeft er drie ontvangen. De volgende lezing geeft b'' terug, en de lus voegt het toe, controleert de lengte en probeert eindeloos opnieuw.

Dat is een EOF-afhandelingsfout, geen trage proxy die een langere time-out nodig heeft. Bij een normale ontvangst via een stream-socket betekent een lege bytestring dat de tegenpartij de verbinding heeft verbroken. De resterende vijf bytes komen niet over die verbinding aan.

Een helper voor exact lezen heeft drie verschillende uitkomsten nodig: niet-lege stukken verzamelen, falen op EOF vóór de vereiste lengte, en een time-out of andere socketfout doorgeven. Die gevallen mogen niet samenvallen in één generieke herhaal-lus.

Stel de bedoelde time-out van de socket in vóór de bewerking en lees de veldlengtes die het proxy-protocol voorschrijft. Eén ontvangst kan slechts een deel van een antwoord teruggeven. Omgekeerd maakt het vragen om een grote vaste buffer niet dat elk SOCKS-adres die lengte heeft.

Repareer een afhankelijkheid niet door een oud MSG_WAITALL-fragment in de bron te plakken en aan te nemen dat het EOF, signalen en platformgedrag dekt. Geef de voorkeur aan de ondersteunde oplossing van de onderhouden implementatie, of implementeer het contract van de helper bewust wanneer de parser jouw code is.

Bewaar hoeveel bytes verwacht en ontvangen zijn, zonder inloggegevens-ladingen te loggen. ‘EOF na drie van acht antwoordbytes’ verklaart de kapotte uitwisseling veel beter dan ‘proxy hangt weer’.

Gerelateerde artikelen