Un verificador de proxy defineix SendTimeout = 200, crida Connect i espera molt més del que caldria. El timeout està lligat a una operació a la qual el verificador encara no ha arribat.

Socket.SendTimeout controla els enviaments sincrònics. No dona a un intent de connexió sincrònic un termini de 200 ms. Afegir una espera abans de Connect només afegeix un altre retard.

Cancel·leu l'operació que està esperant

En un objectiu .NET modern que ofereix la sobrecàrrega cancel·lable, una prova asíncrona pot aplicar el seu pressupost a l'establiment de la connexió:

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

El fragment pertany a un mètode asíncron, amb l'amfitrió i el port del proxy proporcionats pel cridador; un candidat públic d'una llista de proxies pot proporcionar aquestes dues entrades. Tracteu la cancel·lació per separat d'un error de socket si el verificador informa de motius de fallada. Alliberar el client també evita que les proves completades acumulin sockets.

El codi antic de .NET Framework no té totes les sobrecàrregues modernes. Feu servir una disposició de connexió asíncrona compatible i tanqueu explícitament el socket quan abandoneu l'intent. Aturar només la vostra espera no demostra que una operació subjacent s'hagi aturat.

El resultat verd encara és un resultat petit

Una connexió TCP correcta demostra que aquest client ha arribat a un punt final que escolta. No ha negociat SOCKS, no s'ha autenticat en un proxy HTTP, no ha obert CONNECT ni ha rebut la resposta del lloc web desitjada.

Doneu a aquestes etapes posteriors el seu propi tractament limitat, o feu-hi passar un termini global intencionat. En cas contrari, el temporitzador de connexió reparat pot funcionar perfectament mentre el verificador passa un altre minut esperant un handshake de proxy.

Articles relacionats