Një cikël dëshiron tetë bajt të një përgjigjeje SOCKS. Ka marrë tre. Leximi tjetër kthen b'', dhe cikli e shton atë, kontrollon gjatësinë dhe provon përsëri përgjithmonë.

Ky është një defekt në trajtimin e EOF, jo një proxy i ngadaltë që ka nevojë për një afat më të gjatë. Në një pritje normale përmes një socket rryme, një varg bajtësh bosh do të thotë që pala tjetër është shkëputur. Pesë bajtët e mbetur nuk do të vijnë në atë lidhje.

Një ndihmës leximi të saktë i duhen tre rezultate të dallueshme: grumbullimi i pjesëve jo bosh, dështimi në EOF përpara gjatësisë së kërkuar dhe përcjellja e një afati ose e një gabimi tjetër socket. Këto raste nuk duhet të bashkohen në një cikël të vetëm të përgjithshëm ripërpjekjesh.

Vendos afatin e synuar të socket-it përpara veprimit dhe lexo gjatësitë e fushave që përcakton protokolli i proxy-t. Një pritje e vetme mund të kthejë vetëm një pjesë të një përgjigjeje. Në të kundërt, kërkimi i një buferi të madh fiks nuk e bën çdo adresë SOCKS me atë gjatësi.

Mos e rregullo një varësi duke ngjitur një fragment të vjetër MSG_WAITALL në burimin e saj dhe duke supozuar se mbulon EOF, sinjalet dhe sjelljen e platformës. Prefero rregullimin e mbështetur të implementimit të mirëmbajtur, ose zbato me qëllim kontratën e ndihmësit kur parseri është kodi yt.

Ruaj sa bajt priteshin dhe sa u morën, pa regjistruar ngarkesa kredencialesh. «EOF pas tre prej tetë bajtëve të përgjigjes» e shpjegon shumë më mirë shkëmbimin e prishur sesa «proxy-i ngeci përsëri».

Artikuj të ngjashëm