Socket.SendTimeout не обмежує спробу з'єднання через проксі

Обмежте перевірку порту проксі під час встановлення з'єднання, а не задавайте тайм-аут, що діє лише на надсилання даних.

Перевіряч проксі задає SendTimeout = 200, викликає Connect і чекає значно довше, ніж очікувалося. Тайм-аут прив'язаний до операції, до якої перевіряч ще не дійшов.

Socket.SendTimeout керує синхронним надсиланням. Він не дає синхронній спробі з'єднання 200-мілісекундного строку. Сон перед Connect лише додає ще одну затримку.

Скасуйте операцію, що чекає

На сучасній платформі .NET із скасовуваним перевантаженням асинхронна перевірка може застосувати свій бюджет до встановлення з'єднання:

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

Фрагмент належить до async-методу, а хост і порт проксі надає викликач; публічний кандидат зі списку проксі може дати ці два входи. Обробляйте скасування окремо від помилки сокета, якщо перевіряч повідомляє причини невдачі. Звільнення клієнта також не дає завершеним перевіркам накопичувати сокети.

Старий код .NET Framework не має всіх сучасних перевантажень. Використовуйте підтримувану асинхронну схему з'єднання та явно закривайте сокет, коли відмовляєтеся від спроби. Просте зупинення вашого очікування не доводить, що основна операція зупинилася.

Зелений результат — усе ще малий результат

Успішне TCP-з'єднання доводить, що цей клієнт досяг кінцевої точки, яка слухає. Воно не узгодило SOCKS, не автентифікувалося на HTTP-проксі, не відкрило CONNECT і не отримало потрібної відповіді сайту.

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

Схожі статті