Socket.SendTimeout begränsar inte ett proxy-anslutningsförsök

En proxy-kontroller ställer in SendTimeout = 200, anropar Connect och väntar mycket längre än väntat. Timeouten hänger på en operation som kontrollern ännu inte har nått.

Socket.SendTimeout styr synkrona sändningar. Den ger inte ett synkront anslutningsförsök en frist på 200 ms. Att lägga till en sömn före Connect lägger bara till ännu en fördröjning.

Avbryt operationen som väntar

På ett modernt .NET-mål som erbjuder den avbrytbara överlagringen kan en asynkron kontroll tillämpa sin budget på anslutningsuppbyggnaden:

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

Fragmentet hör hemma i en async-metod, med proxy-värd och -port levererade av anroparen; en offentlig kandidat från en proxylista kan leverera dessa två indata. Hantera avbrott separat från ett socket-fel om kontrollern rapporterar felorsaker. Att göra sig av med klienten hindrar också slutförda kontroller från att samla sockets.

Äldre .NET Framework-kod har inte alla moderna överlagringar. Använd ett stödt asynkront anslutningsupplägg och stäng socketen uttryckligen när du överger försöket. Att bara stoppa din väntan bevisar inte att en underliggande operation har stoppats.

Det gröna resultatet är fortfarande ett litet resultat

En lyckad TCP-anslutning bevisar att denna klient nådde en lyssnande slutpunkt. Den har inte förhandlat SOCKS, autentiserat sig mot en HTTP-proxy, öppnat CONNECT eller tagit emot den önskade webbplatsens svar.

Ge de senare stegen sin egen begränsade hantering, eller för en avsiktlig total deadline genom dem. Annars kan den reparerade anslutningstimern fungera perfekt medan kontrollern lägger ännu en minut på att vänta på ett proxy-handskakning.