Апрацоўка EOF у цыкле чытання SOCKS на Python
Апрацоўвайце EOF явна ў цыкле дакладнага чытання SOCKS, замест таго каб лічыць зачыненае злучэнне тайм-аўтам, які ніколі не настане.
Цыкл хоча восем байтаў адказу SOCKS. Ён атрымаў тры. Наступнае чытанне вяртае b'', і цыкл далучае яго, правярае даўжыню і зноў спрабуе бясконца.
Гэта памылка апрацоўкі EOF, а не павольны проксі, якому патрэбны даўжэйшы тайм-аўт. Для звычайнага прыёму праз патокавы сокет пусты радок байтаў азначае, што суразмоўца адключыўся. Астатнія пяць байтаў не прыйдуць праз гэтае злучэнне.
Дапаможніку дакладнага чытання патрэбны тры розныя вынікі: назапашваць непустыя фрагменты, памыляцца на EOF да патрэбнай даўжыні і перадаваць тайм-аўт або іншую памылку сокета. Гэтыя выпадкі не павінны злівацца ў адзін агульны цыкл паўтораў.
Усталюйце меркаваны тайм-аўт сокета перад аперацыяй і чытайце даўжыні палёў, вызначаныя пратаколам проксі. Адзін прыём можа вярнуць толькі частку адказу. І наадварот, запыт вялікага фіксаванага буфера не робіць кожны адрас SOCKS такой даўжыні.
Не рамантуйце залежнасць, устаўляючы стары фрагмент MSG_WAITALL у яе крынічнік і мяркуючы, што ён пакрывае EOF, сігналы і паводзіны платформы. Аддайце перавагу падтрыманаму выпраўленню ў рэалізацыі, якая падтрымліваецца, або свядома рэалізуйце кантракт дапаможніка, калі парсер — ваш код.
Захоўвайце, колькі байтаў чакалася і было атрымана, не запісваючы карысную нагрузку ўліковых даных. «EOF пасля трох з васьмі байтаў адказу» тлумачыць зламаны абмен значна лепш, чым «проксі зноў завіс».