Socket.SendTimeout beperkt geen proxy-verbindingspoging

Een proxy-checker stelt SendTimeout = 200 in, roept Connect aan en wacht veel langer dan verwacht. De timeout hangt aan een bewerking die de checker nog niet heeft bereikt.

Socket.SendTimeout regelt synchrone verzendingen. Het geeft een synchrone verbindingspoging geen termijn van 200 ms. Een slaap vóór Connect toevoegen voegt alleen nog een vertraging toe.

Breek de bewerking af die wacht

Op een modern .NET-doel dat de annuleerbare overload biedt, kan een asynchrone test zijn budget toepassen op het opzetten van de verbinding:

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

Het fragment hoort in een async-methode, waarbij de proxy-host en -poort door de aanroeper worden geleverd; een openbare kandidaat uit een proxylijst kan die twee invoer leveren. Behandel annulering apart van een socketfout als de checker faalredenen meldt. Het vrijgeven van de client voorkomt ook dat voltooide tests sockets opstapelen.

Oudere .NET Framework-code heeft niet elke moderne overload. Gebruik een ondersteunde asynchrone verbindingsopzet en sluit de socket expliciet wanneer je de poging opgeeft. Alleen je wachttijd stoppen bewijst niet dat een onderliggende bewerking is gestopt.

Het groene resultaat is nog steeds een klein resultaat

Een geslaagde TCP-verbinding bewijst dat deze client een luisterend eindpunt heeft bereikt. Hij heeft geen SOCKS onderhandeld, zich niet geauthenticeerd bij een HTTP-proxy, CONNECT niet geopend en niet de gewenste website-reactie ontvangen.

Geef die latere fasen hun eigen begrensde afhandeling, of voer er een bewuste algehele deadline door. Anders kan de gerepareerde verbindingstimer perfect werken terwijl de checker nog een minuut besteedt aan wachten op een proxy-handshake.