Cilpa vēlas astoņus SOCKS atbildes baitus. Tā ir saņēmusi trīs. Nākamā lasīšana atgriež b'', cilpa to pievieno, pārbauda garumu un mēģina vēlreiz bezgalīgi.

Tā ir EOF apstrādes kļūda, nevis lēns starpniekserveris, kuram vajadzīgs garāks taimauts. Parastā straumes ligzdas saņemšanā tukša baitu virkne nozīmē, ka otrā puse ir atvienojusies. Atlikušie pieci baiti pa šo savienojumu nenāks.

Precīzas lasīšanas palīgam vajadzīgi trīs atšķirīgi iznākumi: uzkrāt ne-tukšus fragmentus, neizdoties pie EOF pirms nepieciešamā garuma un nodot tālāk taimautu vai citu ligzdas kļūdu. Šiem gadījumiem nevajadzētu saplūst vienā vispārīgā atkārtošanas cilpā.

Pirms darbības iestatiet paredzēto ligzdas taimautu un lasiet lauka garumus, ko nosaka starpniekservera protokols. Viena saņemšana var atgriezt tikai daļu atbildes. Pretēji, liela fiksēta bufera pieprasīšana nepadara katru SOCKS adresi tādā garumā.

Nelabojiet atkarību, ielīmējot vecu MSG_WAITALL fragmentu tās pirmkodā un pieņemot, ka tas aptver EOF, signālus un platformas uzvedību. Dodiet priekšroku uzturētās implementācijas atbalstītajam labojumam vai, ja parsētājs ir jūsu kods, apzināti ieviests palīga līgumu.

Saglabājiet, cik baitu tika gaidīts un saņemts, bez akreditācijas datu ierakstīšanas žurnālā. “EOF pēc trim no astoņiem atbildes baitiem” izskaidro sabojāto apmaiņu daudz labāk nekā “starpniekserveris atkal iespruda”.

Saistītie raksti