Socket.SendTimeout nu limitează o încercare de conexiune proxy

Un verificator de proxy setează SendTimeout = 200, apelează Connect și așteaptă mult mai mult decât era de așteptat. Timeout-ul este legat de o operație la care verificatorul nu a ajuns încă.

Socket.SendTimeout controlează trimiterile sincrone. Nu oferă unei încercări de conexiune sincrone un termen de 200 ms. Adăugarea unei pauze înainte de Connect adaugă doar o altă întârziere.

Anulați operația care așteaptă

Pe o țintă .NET modernă care oferă supraîncărcarea anulabilă, un test asincron își poate aplica bugetul la stabilirea conexiunii:

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

Fragmentul aparține unei metode async, gazda și portul proxy fiind furnizate de apelant; un candidat public dintr-o listă de proxy-uri poate furniza cele două intrări. Tratați anularea separat de o eroare de socket dacă verificatorul raportează motivele eșecului. Eliberarea clientului împiedică și acumularea de socketuri de către testele finalizate.

Codul .NET Framework mai vechi nu are toate supraîncărcările moderne. Folosiți o configurație de conexiune asincronă acceptată și închideți explicit socketul când abandonați încercarea. Doar oprirea așteptării dumneavoastră nu dovedește că o operație subiacentă s-a oprit.

Rezultatul verde este tot un rezultat mic

O conexiune TCP reușită dovedește că acest client a ajuns la un punct final care ascultă. Nu a negociat SOCKS, nu s-a autentificat la un proxy HTTP, nu a deschis CONNECT și nu a primit răspunsul dorit al site-ului.

Oferiți acelor etape ulterioare propria tratare limitată sau treceți prin ele un termen global intenționat. Altfel, cronometrul de conexiune reparat poate funcționa perfect în timp ce verificatorul petrece încă un minut așteptând un handshake proxy.