Socket.SendTimeout(e)k ez du proxy konexio-saiakera mugatzen

Proxy egiaztatzaile batek SendTimeout = 200 ezartzen du, Connect deitzen du eta espero baino askoz gehiago itxaroten du. Timeout-a egiaztatzaileak oraindik iritsi ez den eragiketa bati lotuta dago.

Socket.SendTimeout(e)k bidalketa sinkronoak kontrolatzen ditu. Ez dio konexio-saiakera sinkrono bati 200 ms-ko eperik ematen. Connect aurretik lo egiteak atzerapen bat gehiago baino ez du gehitzen.

Ezeztatu itxaroten ari den eragiketa

Overload ezeztagarria eskaintzen duen .NET helburu moderno batean, proba asinkrono batek bere aurrekontua konexioa ezartzeari aplika dakioke:

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

Zatia async metodo batean kokatzen da, proxy ostalaria eta ataka deitzaileak emanda; proxy zerrenda batetik etorritako hautagai publiko batek bi sarrera horiek eman ditzake. Ezeztatzea socket errore batetik bereiz kudeatu, egiaztatzaileak hutsegite arrazoiak ematen baditu. Bezeroa askatzeak osatutako probei socketak pilatzea ere eragozten die.

.NET Framework kode zaharrak ez ditu overload moderno guztiak. Erabili onartutako async konexio-antolamendu bat eta itxi socket-a modu esplizituan saiakerari uzten diozunean. Zure itxaronaldia soilik gelditzeak ez du frogatzen azpiko eragiketa bat gelditu denik.

Emaitza berdea emaitza txiki bat da oraindik

TCP konexio arrakastatsu batek frogatzen du bezero hau entzuten ari den amaiera-puntu batera iritsi dela. Ez du SOCKSen negoziaziorik egin, ez da HTTP proxy baten aurrean autentifikatu, ez du CONNECT ireki ez eta webgunearen nahi den erantzuna jaso.

Emaiozu etapa horiei beren kudeaketa mugatua, edo eraman horietan zehar nahita ezarritako epe orokorra. Bestela konpondutako konexio-tenporizadoreak ezin hobeto funtziona dezake egiaztatzaileak proxy handshake baten zain beste minutu bat ematen duen bitartean.