EOF-ის დამუშავება Python SOCKS-ის წაკითხვის ციკლში

ციკლს სურს SOCKS-ის პასუხის რვა ბაიტი. მან სამი მიიღო. შემდეგი წაკითხვა აბრუნებს b''-ს, ციკლი მას ამატებს, ამოწმებს სიგრძეს და უსასრულოდ ცდილობს ხელახლა.

ეს EOF-ის დამუშავების შეცდომაა და არა ნელი პროქსი, რომელსაც უფრო გრძელი დროის ლიმიტი სჭირდება. ჩვეულებრივი ნაკადური სოკეტის მიღებისას ცარიელი ბაიტების სტრიქონი ნიშნავს, რომ წყვილი გათიშულია. დარჩენილი ხუთი ბაიტი ამ კავშირზე არ მოვა.

ზუსტი წაკითხვის დამხმარეს სამი განსხვავებული შედეგი სჭირდება: არაცარიელი ნაწილების დაგროვება, EOF-ზე წარუმატებლობა საჭირო სიგრძემდე და დროის ლიმიტის ან სხვა სოკეტის შეცდომის გადაცემა. ეს შემთხვევები არ უნდა გაერთიანდეს ერთ ზოგად განმეორების ციკლში.

ოპერაციამდე დააყენეთ სოკეტის განზრახული დროის ლიმიტი და წაიკითხეთ პროქსის პროტოკოლით განსაზღვრული ველების სიგრძეები. ერთ მიღებას შეუძლია დააბრუნოს პასუხის მხოლოდ ნაწილი. პირიქით, დიდი ფიქსირებული ბუფერის მოთხოვნა არ ხდის ყოველ SOCKS მისამართს ასეთი სიგრძის.

ნუ შეაკეთებთ დამოკიდებულებას ძველი MSG_WAITALL ფრაგმენტის მის წყაროში ჩასმით და ვარაუდით, რომ ის ფარავს EOF-ს, სიგნალებსა და პლატფორმის ქცევას. ამჯობინეთ შენარჩუნებული იმპლემენტაციის მხარდაჭერილი შესწორება, ან როცა პარსერი თქვენი კოდია, განზრახ განახორციელეთ დამხმარის კონტრაქტი.

შეინახეთ რამდენი ბაიტი იყო მოსალოდნელი და მიღებული, სერთიფიკატების დატვირთვების ჩაწერის გარეშე. „EOF რვა პასუხის ბაიტიდან სამის შემდეგ“ ბევრად უკეთ ხსნის გატეხილ გაცვლას, ვიდრე „პროქსი ისევ გაიჭედა“.