Socket.SendTimeout beperk nie 'n proxy-verbindingspoging nie

'n Proxy-kontroleerder stel SendTimeout = 200, roep Connect en wag baie langer as wat verwag is. Die timeout hang aan 'n bewerking wat die kontroleerder nog nie bereik het nie.

Socket.SendTimeout beheer sinchroniese stuur. Dit gee nie aan 'n sinchroniese verbindingspoging 'n sperdatum van 200 ms nie. 'n Slaap voor Connect voeg net nog 'n vertraging by.

Kanselleer die bewerking wat wag

Op 'n moderne .NET-teiken met die kanselleerbare oorlaai kan 'n asinchrone toets sy begroting op die verbindingopbou toepas:

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

Die fragment hoort in 'n asinchrone metode, met die proxy-gasheer en -poort deur die oproeper verskaf; 'n openbare kandidaat uit 'n proxy-lys kan daardie twee insette lewer. Hanteer kansellasie apart van 'n socket-fout as die kontroleerder redes vir mislukking rapporteer. Om die kliënt te vernietig verhoed ook dat voltooide toetse sockets opbou.

Ouer .NET Framework-kode het nie elke moderne oorlaai nie. Gebruik 'n ondersteunde asinchrone verbindingsreëling en sluit die socket uitdruklik wanneer jy die poging laat vaar. Om net jou wag te stop, bewys nie dat 'n onderliggende bewerking gestop het nie.

Die groen resultaat is steeds 'n klein resultaat

'n Suksesvolle TCP-verbinding bewys dat hierdie kliënt 'n luisterende eindpunt bereik het. Dit het nie SOCKS beding, by 'n HTTP-proxy geauthentiseer, CONNECT geopen of die verlangde webwerfrespons ontvang nie.

Gee daardie latere fases hul eie begrensde hantering, of dra 'n doelbewuste algehele sperdatum daardeur. Anders kan die herstelde verbindingstimer perfek werk terwyl die kontroleerder nog 'n minuut spandeer om op 'n proxy-handdruk te wag.