EOF-ի մշակում Python SOCKS կարդալու ցիկլում

Ցիկլը ուզում է SOCKS պատասխանի ութ բայթ։ Ստացել է երեքը։ Հաջորդ կարդալը վերադարձնում է b'', ցիկլը ավելացնում է այն, ստուգում երկարությունը և անվերջ նորից փորձում։

Սա EOF-ի մշակման սխալ է, ոչ թե դանդաղ պրոքսի, որը ավելի երկար ժամկետ է պահանջում։ Սովորական հոսքային սոքեթի ընդունման ժամանակ դատարկ բայթային տողը նշանակում է, որ զույգը անջատվել է։ Մնացած հինգ բայթերը այդ կապով չեն հասնի։

Ճշգրիտ կարդալու օգնականին պետք է երեք տարբեր արդյունք՝ կուտակել ոչ դատարկ մասերը, ձախողվել EOF-ի վրա պահանջվող երկարությունից առաջ և փոխանցել ժամկետ կամ այլ սոքեթի սխալ։ Այդ դեպքերը չպետք է միաձուլվեն մեկ ընդհանուր կրկնափորձի ցիկլի մեջ։

Սահմանեք սոքեթի նախատեսված ժամկետը գործողությունից առաջ և կարդացեք պրոքսի արձանագրության սահմանած դաշտերի երկարությունները։ Մեկ ընդունումը կարող է վերադարձնել պատասխանի միայն մի մասը։ Հակառակը, մեծ ֆիքսված բուֆեր պահանջելը չի դարձնում յուրաքանչյուր SOCKS հասցե այդ երկարության։

Մի՛ վերանորոգեք կախվածությունը՝ հին MSG_WAITALL հատվածը տեղադրելով դրա աղբյուրում և ենթադրելով, որ այն ծածկում է EOF-ը, ազդանշանները և հարթակի վարքը։ Նախընտրեք պահպանվող իրականացման աջակցվող ուղղումը, կամ երբ վերլուծիչը ձեր կոդն է, դիտավորյալ իրականացրեք օգնականի պայմանագիրը։

Պահեք, թե քանի բայթ էր սպասվում և քանիսը ստացվեց, առանց հավատարմագրերի բեռնվածքների գրանցման։ «EOF ութ պատասխան բայթերից երեքից հետո» շատ ավելի լավ է բացատրում կոտրված փոխանակումը, քան «պրոքսին նորից կախվեց»։