Socket.SendTimeout ne limigas provon de proksea konekto
Limigu la proksejan pordan kontrolon ĉe la establado de la konekto anstataŭ agordi tempolimon kiu validas nur por sendado de datumoj.
Proksea kontrolilo agordas SendTimeout = 200, alvokas Connect kaj atendas multe pli longe ol atendite. La tempolimo estas ligita al operacio kiun la kontrolilo ankoraŭ ne atingis.
Socket.SendTimeout regas sinkronajn sendojn. Ĝi ne donas al sinkrona konekprovo limdaton de 200 ms. Aldoni dormantadon antaŭ Connect nur aldonas plian prokraston.
Nuligu la operacion kiu atendas
Sur moderna .NET-celo kiu ofertas la nuligeblan ŝarĝan varianton, nesinkrona kontrolo povas apliki sian buĝeton al la establado de la konekto:
using var budget = new CancellationTokenSource(TimeSpan.FromSeconds(2));
using var client = new TcpClient();
await client.ConnectAsync(proxyHost, proxyPort, budget.Token);La fragmento apartenas al async-metodo, kun la proksea gastiganto kaj pordo provizitaj de la alvokanto; publika kandidato el proksea listo povas provizi tiujn du enigojn. Traktu nuligon aparte de soketa eraro se la kontrolilo raportas kialojn de malsukceso. Forigi la klienton ankaŭ malhelpas finitajn kontrolojn akumuli soketojn.
Pli malnova .NET Framework-kodo ne havas ĉiun modernan varianton. Uzu subtenatan nesinkronan konekaranĝon kaj eksplicite fermu la soketon kiam vi forlasas la provon. Nur haltigi vian atendon ne pruvas ke suba operacio haltis.
La verda rezulto ankoraŭ estas malgranda rezulto
Sukcesa TCP-konekto pruvas ke ĉi tiu kliento atingis aŭskultantan finpunkton. Ĝi ne intertraktis SOCKS, ne aŭtentikigis al HTTP-proksejo, ne malfermis CONNECT nek ricevis la deziratan respondon de la retejo.
Donu al tiuj postaj etapoj propran limigitan traktadon, aŭ portu tra ili intencan tutan limdaton. Alie la riparita konekta tempigilo povas perfekte funkcii dum la kontrolilo pasigas plian minuton atendante proksejan manpremon.