Socket.SendTimeout begrenser ikke et proxy-tilkoblingsforsøk

Begrens proxy-porttesten ved tilkoblingsoppsettet i stedet for å sette en timeout som bare gjelder sending av data.

En proxy-sjekker setter SendTimeout = 200, kaller Connect og venter mye lenger enn forventet. Timeouten henger på en operasjon som sjekkeren ennå ikke har nådd.

Socket.SendTimeout styrer synkrone sendinger. Den gir ikke et synkront tilkoblingsforsøk en frist på 200 ms. Å legge inn en pause før Connect legger bare til enda en forsinkelse.

Avbryt operasjonen som venter

På et moderne .NET-mål som tilbyr den avbrytbare overloaden, kan en asynkron test bruke budsjettet sitt på tilkoblingsoppsettet:

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

Fragmentet hører hjemme i en async-metode, med proxy-vert og -port levert av den som kaller; en offentlig kandidat fra en proxy-liste kan levere disse to inndataene. Håndter avbrytelse separat fra en socket-feil hvis sjekkeren rapporterer feilårsaker. Å avhende klienten hindrer også fullførte tester i å samle opp sockets.

Eldre .NET Framework-kode har ikke alle moderne overloads. Bruk et støttet asynkront tilkoblingsopplegg og lukk socketen eksplisitt når du forlater forsøket. Bare å stoppe ventingen din beviser ikke at en underliggende operasjon har stoppet.

Det grønne resultatet er fortsatt et lite resultat

En vellykket TCP-tilkobling beviser at denne klienten nådde et lyttende endepunkt. Den har ikke forhandlet SOCKS, autentisert mot en HTTP-proxy, åpnet CONNECT eller mottatt det ønskede nettstedsvaret.

Gi de senere trinnene sin egen avgrensede håndtering, eller før en bevisst samlet frist gjennom dem. Ellers kan den reparerte tilkoblingstimeren fungere perfekt mens sjekkeren bruker ett minutt til på å vente på et proxy-håndtrykk.

Relaterte artikler