Socket.SendTimeout не абмяжоўвае спробу злучэння праз проксі

Абмяжуйце праверку порта проксі на этапе ўсталявання злучэння, а не задавайце тайм-аўт, які дзейнічае толькі на адпраўку даных.

Правяральнік проксі задае SendTimeout = 200, выклікае Connect і чакае значна даўжэй, чым чакалася. Тайм-аўт прывязаны да аперацыі, да якой правяральнік яшчэ не дайшоў.

Socket.SendTimeout кіруе сінхроннай адпраўкай. Ён не дае сінхроннай спробе злучэння тэрмін 200 ms. Сон перад Connect толькі дадае чарговую затрымку.

Скасуйце аперацыю, якая чакае

На сучаснай мэце .NET, якая прапануе overload з падтрымкай скасавання, асінхронная праверка можа ўжыць свой бюджэт на ўсталяванне злучэння:

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

Фрагмент належыць у async-метад, а хост і порт проксі падае той, хто выклікае; публічны кандыдат са спіса проксі можа даць гэтыя два ўваходныя значэнні. Апрацоўвайце скасаванне асобна ад памылкі сокета, калі правяральнік паведамляе прычыны няўдачы. Вызваленне кліента таксама не дае завершаным праверкам назапашваць сокеты.

Стары код .NET Framework не мае ўсіх сучасных overload. Выкарыстоўвайце падтрымліваныя асінхронныя налады злучэння і яўна закрывайце сокет, калі адмаўляецеся ад спробы. Проста спыніць сваё чаканне не даказвае, што базавая аперацыя спынілася.

Зялёны вынік — усё яшчэ малы вынік

Паспяховае TCP-злучэнне даказвае, што гэты кліент дасягнуў пункта, які слухае. Яно не дамовілася пра SOCKS, не прайшло аўтэнтыфікацыю на HTTP-проксі, не адкрыла CONNECT і не атрымала патрэбны адказ сайта.

Дайце гэтым познім этапам уласную абмежаваную апрацоўку або правядзіце праз іх наўмысны агульны тэрмін. Інакш выпраўлены таймер злучэння можа працаваць бездакорна, пакуль правяральнік марнуе яшчэ хвіліну на чаканне рукапаціску проксі.

Падобныя артыкулы