In proxy-kontrôleur set SendTimeout = 200, ropt Connect oan en wachtet folle langer as ferwachte. De timeout hinget oan in operaasje dy't de kontrôleur noch net berikt hat.

Socket.SendTimeout regelet synchrone ferstjoeringen. It jout in synchrone ferbiningstaspraak gjin deadline fan 200 ms. In sliep foar Connect taheakje foeget allinnich noch in fertraging ta.

Annulearje de operaasje dy't wachtet

Op in modern .NET-doel dat de annulearbere overload leveret, kin in asynchrone test syn budzjet tapasse op it opbouwen fan 'e ferbining:

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

It fragmint heart yn in async-metoad, mei de proxy-host en -poart levere troch de oanropper; in iepenbier kandidaat út in proxylist kin dy twa ynfier leverje. Behandel annulearring los fan in socket-flater as de kontrôleur redenen foar mislearring meldt. It frijlitten fan de klint foarkomt ek dat foltôge tests sockets opgarje.

Aldere .NET Framework-koade hat net elke moderne overload. Brûk in stipe asynchrone ferbiningsregeling en slút de socket eksplisyt as jo de taspraak opjouwe. Allinnich jo wachtsjen stopje bewiist net dat in ûnderlizzende operaasje stoppe is.

It griene resultaat is noch altyd in lyts resultaat

In slagge TCP-ferbining bewiist dat dizze klint in harkjend einpunt berikt hat. It hat gjin SOCKS ûnderhannele, him net autentisearre by in HTTP-proxy, CONNECT net iepene en hat it winske antwurd fan 'e webside net krigen.

Jou dy lettere fazen har eigen beheinde ôfhanneling, of bring dêr in bewust algemiene deadline trochhinne. Oars kin de reparearre ferbiningstimer perfekt wurkje wylst de kontrôleur noch in minút trochbringt mei wachtsjen op in proxy-handshake.

Relatearre artikelen