Socket.SendTimeout begrænser ikke et proxy-forbindelsesforsøg
Begræns proxy-porttesten ved forbindelsesopbygningen i stedet for at sætte en timeout, der kun gælder for at sende data.
En proxy-tjekker sætter SendTimeout = 200, kalder Connect og venter meget længere end forventet. Timeouten hænger på en handling, som tjekkeren endnu ikke er nået til.
Socket.SendTimeout styrer synkrone sends. Den giver ikke et synkront forbindelsesforsøg en frist på 200 ms. At tilføje en søvn før Connect tilføjer blot endnu en forsinkelse.
Annuller den handling, der venter
På et moderne .NET-mål med det annullerbare overload kan en asynkron test anvende sit budget på forbindelsesopbygningen:
using var budget = new CancellationTokenSource(TimeSpan.FromSeconds(2));
using var client = new TcpClient();
await client.ConnectAsync(proxyHost, proxyPort, budget.Token);Fragmentet hører til i en async-metode, hvor proxy-vært og -port leveres af kalderen; en offentlig kandidat fra en proxy-liste kan levere de to input. Håndtér annullering adskilt fra en socket-fejl, hvis tjekkeren rapporterer fejlårsager. At dispose klienten forhindrer også færdige tests i at samle sockets.
Ældre .NET Framework-kode har ikke alle moderne overloads. Brug en understøttet asynkron forbindelsesopstilling, og luk socketen eksplicit, når du opgiver forsøget. At stoppe din venten alene beviser ikke, at en underliggende handling er stoppet.
Det grønne resultat er stadig et lille resultat
En vellykket TCP-forbindelse beviser, at denne klient nåede et lyttende endepunkt. Den har ikke forhandlet SOCKS, autentificeret sig til en HTTP-proxy, åbnet CONNECT eller modtaget det ønskede websteds svar.
Giv de senere faser deres egen afgrænsede håndtering, eller før en bevidst samlet deadline igennem dem. Ellers kan den reparerede forbindelsestimer fungere perfekt, mens tjekkeren bruger endnu et minut på at vente på et proxy-handshake.