Socket.SendTimeout avgrensar ikkje eit proxy-tilkoplingsforsøk

Ein proxy-sjekkar set SendTimeout = 200, kallar Connect og ventar mykje lenger enn venta. Timeouten heng på ein operasjon som sjekkaren enno ikkje har nådd.

Socket.SendTimeout styrer synkrone sendingar. Det gir ikkje eit synkront tilkoplingsforsøk ein frist på 200 ms. Å leggje inn ein pause før Connect legg berre til endå ei forseinking.

Avbryt operasjonen som ventar

På eit moderne .NET-mål som tilbyr den avbrytbare overloaden, kan ein 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øyrer heime i ein async-metode, med proxy-vert og -port levert av den som kallar; ein offentleg kandidat frå ei proxy-liste kan levere desse to inndata. Handsame avbryting separat frå ein socket-feil viss sjekkaren rapporterer feilårsaker. Å avhende klienten hindrar også fullførte testar i å samle opp socketar.

Eldre .NET Framework-kode har ikkje alle moderne overloads. Bruk eit støtta asynkront tilkoplingsarrangement og lukk socketen eksplisitt når du forlèt forsøket. Berre å stoppe ventinga di beviser ikkje at ein underliggjande operasjon har stoppa.

Det grøne resultatet er framleis eit lite resultat

Ein vellukka TCP-tilkopling beviser at denne klienten nådde eit lyttande endepunkt. Han har ikkje forhandla SOCKS, autentisert mot ein HTTP-proxy, opna CONNECT eller motteke det ønska nettsvaret.

Gi dei seinare trinna si eiga avgrensa handsaming, eller før ein medviten samla frist gjennom dei. Elles kan den reparerte tilkoplingstimaren fungere perfekt medan sjekkaren brukar eitt minutt til på å vente på eit proxy-handtrykk.