Socket.SendTimeout არ ზღუდავს პროქსისთან დაკავშირების ცდას

პროქსის შემმოწმებელი აყენებს SendTimeout = 200-ს, იძახებს Connect-ს და გაცილებით მეტხანს ელოდება, ვიდრე მოსალოდნელი იყო. timeout მიბმულია ოპერაციაზე, რომელსაც შემმოწმებელი ჯერ არ მიუღწევია.

Socket.SendTimeout მართავს სინქრონულ გაგზავნებს. ის სინქრონულ კავშირის ცდას 200 ms ვადას არ აძლევს. Connect-მდე ძილის დამატება მხოლოდ კიდევ ერთ შეყოვნებას მატებს.

გააუქმეთ მოლოდინში მყოფი ოპერაცია

თანამედროვე .NET სამიზნეზე, რომელიც გთავაზობთ გაუქმებად overload-ს, ასინქრონულ შემოწმებას შეუძლია თავისი ბიუჯეტი კავშირის დამყარებაზე გამოიყენოს:

using var budget = new CancellationTokenSource(TimeSpan.FromSeconds(2));
using var client = new TcpClient();
await client.ConnectAsync(proxyHost, proxyPort, budget.Token);

ფრაგმენტი async მეთოდს ეკუთვნის, პროქსის ჰოსტი და პორტი გამომძახებელს მიაწვდის; საჯარო კანდიდატს პროქსების სიიდან შეუძლია ეს ორი შემავალი მოგვცეს. თუ შემმოწმებელი წარუმატებლობის მიზეზებს აცხადებს, გაუქმება socket-ის შეცდომისგან ცალკე დაამუშავეთ. კლიენტის გათავისუფლება ასევე ხელს უშლის დასრულებულ შემოწმებებს socket-ების დაგროვებაში.

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

მწვანე შედეგი მაინც პატარა შედეგია

წარმატებული TCP კავშირი ამტკიცებს, რომ ეს კლიენტი მსმენელ ბოლო წერტილამდე მივიდა. მას არ უწარმოებია მოლაპარაკება SOCKS-ზე, არ აუღია ავტორიზაცია HTTP პროქსიზე, არ გაუხსნია CONNECT და არ მიუღია სასურველი ვებსაიტის პასუხი.

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