A proxyellenőrző beállítja a SendTimeout = 200 értéket, meghívja a Connect metódust, és sokkal tovább vár a vártnál. Az időtúllépés egy olyan művelethez kapcsolódik, amelyet az ellenőrző még nem ért el.

A Socket.SendTimeout a szinkron küldéseket vezérli. Nem ad 200 ms-os határidőt egy szinkron kapcsolódási kísérletnek. Ha alvást tesz a Connect elé, az csak újabb késleltetést ad hozzá.

A várakozó művelet megszakítása

Egy modern .NET-célon, amely biztosítja a megszakítható overloadot, egy aszinkron vizsgálat a kapcsolat létrehozására fordíthatja a keretét:

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

A részlet egy async metódusba való, a proxy hosztját és portját a hívó adja; egy nyilvános jelölt egy proxylistáról biztosíthatja ezt a két bemenetet. Ha az ellenőrző hibaokokat jelent, a megszakítást a socket-hibától elkülönítve kezelje. Az ügyfél felszabadítása azt is megakadályozza, hogy a befejezett vizsgálatok socketeket halmozzanak fel.

A régebbi .NET Framework-kód nem rendelkezik minden modern overloaddal. Használjon támogatott aszinkron kapcsolat-elrendezést, és a kísérlet feladásakor zárja be kifejezetten a socketet. Csupán a várakozás leállítása nem bizonyítja, hogy egy mögöttes művelet leállt.

A zöld eredmény még mindig kis eredmény

Egy sikeres TCP-kapcsolat bizonyítja, hogy ez az ügyfél elért egy figyelő végpontot. Nem tárgyalt SOCKS-ról, nem hitelesített HTTP-proxynál, nem nyitott CONNECT-et, és nem kapta meg a kívánt weboldalválaszt.

Adjon ezeknek a későbbi szakaszoknak saját korlátozott kezelést, vagy vigyen át rajtuk egy szándékos teljes határidőt. Ellenkező esetben a javított kapcsolat-időzítő tökéletesen működhet, miközben az ellenőrző még egy percet tölt egy proxy handshake-re várva.

Kapcsolódó cikkek