Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Предел Half-open connections. как определить в Windows XP ?  (Прочитано 17102 раз)
0 Пользователей и 1 Гость смотрят эту тему.
ksak
Гость
« : 19-08-2010 16:23 » 

Ситуация такая... Для поиска устройств в сети надо просканировать  диапазон адресов, например 10.0.0.1 - 10.0.200.255 на предмет подключения по TCP на определенный порт и получения отклика на запрос. Время отклика может достигать 1 сек.

Для решения задачи за разумное время порождаются потоки с не блокирующими сокетами для групп адресов 10.0.0.1 - 10.0.0.255, 10.0.1.1 - 10.0.1.255 и т.д.  допустим 50 шт.

Проблема в том что при отсутствии устройства сокет уходит в состояние SYN_SENT на несколько секунд и быстро достигается предел Half-open connections для Windows XP. Т.е. ситуация понятна и прозрачна.

Получается, что если открывается новый сокет - открытие проходит успешно без ошибок, только данные после этого уходят в никуда и без кода ошибки. А т.к. работа ведется через select с таймаутом 1 сек - то непонятно или нет устройства или мы заткнулись на Half-open.

Рассмотрение похожего вопроса в теме https://forum.shelek.ru/index.php/topic,6663.0.html прочитано и понятно, только ситуация есть...

И вот  вопросы к Уважаемым Знатокам:
-  Как при открытии нового сокета определить, что достигнут этот "неприятный" предел в 10 подключений?
-  Есть ли возможность закрыть состояние SYN_SENT программно или установить свой тайм-аут для этого состояния?
-  Может есть еще мысли как ситуацию разрулить?


Записан
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #1 : 19-08-2010 17:27 » 

Давай плясать от печки: какая задача? Не варианты решения, а именно сама задача: цель, желаемый результат.
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
ksak
Гость
« Ответ #2 : 19-08-2010 20:54 » 

Пробую прояснить...

В сети есть некоторое кол-во аппаратных устройств с подключенных по Ethernet со статическим IP и поддержкой одного TCP соединения на одном порту - для получения статуса и управления периферией устройства.

Цель: 
за максимально короткое время найти все работающие устройства при условии что сеть может быть 10.0.0.0/16

Желаемый результат:
ПО клиента работающее под Windows XP без применения твиков для tcpip.sys

Предполагаемый метод решения:
использование многопоточного приложения для сканирования сети на открытие  подключения на IP к порту  управления с использованием неблокирующего сокета и проверкой статуса успешного открытия сокета через 200 ms <=Т <=1000 ms. При удачном открытии - посылка запроса на получение статуса и получение ответа на основании чего делается вывод о типе устройства и его наличии на конкретном IP. При неудачном открытии сокета  за 200 ms <=Т <=1000 ms - принимается решение что на данном IP устройства нет.
Многопоточность - для разнесения по потокам сканирования отдельных сегментов (10.0.0.1 - 10.0.1.255, 10.0.0.2 - 10.0.2.255 .... 10.0.255.1 - 10.0.255.255).

Проблема:
При открытии сокетов на отсутствующий в сети IP - получаем зависание в состоянии SYN_SENT на несколько секунд.
Учитывая, что одновременно производится множество попыток открыть соединение на последовательные IP  - быстро попадаем в состояние, когда кол-во состояний SYN_SENT достигает предела

Вопрос:
Каким образом можно перед открытием сокета или в момент открытия или через время тайм-аута 200 ms <= Т <=1000 ms определить, что был достигнут предел допустимых соединений и сокет не может быть открыт по этой причине, а не потому что в сети нет  IP на который открывается сокет ? Т.е. что-то типа системного сообщения  "Достигнут предел безопасности для TCP/IP, налагаемый на количество попыток одновременных TCP-подключений"
Записан
Serg79
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #3 : 19-08-2010 21:46 » 

ksak, ты имеешь в виду системное предупреждении 4226 "Достигнут предел безопасности для TCP/IP, налагаемый  на количество попыток одновременных TCP-подключений", или что?
Записан
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #4 : 20-08-2010 03:29 » 

ksak, такое сканирование обычно выполняется ICMP Ping. Сканирование же TCP-SYN делается с целью обнаружить открытые TCP-порты на сканируемом хосте.

Многопоточность для этого не нужна (в крайнем случае, два потока - на прием и передачу): выдал свои 254 запроса и лови ответы.

Кстати, stream socket для сканирования никогда не используют. Вместо этого открывают raw socket и пакеты формируют вручную.

И...   такой инструментарий уже существует - nmap. В том числе и для винды.
http://nmap.org/download.html
« Последнее редактирование: 20-08-2010 06:03 от RXL » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
ksak
Гость
« Ответ #5 : 20-08-2010 07:07 » 

такое сканирование обычно выполняется ICMP Ping.
Сканирование же TCP-SYN делается с целью обнаружить открытые TCP-порты на сканируемом хосте.
Точно! спасибо. сейчас проверим. По идее должно резко помочь. Это снизит кол-во проверяемых хостов.

Хотя вопрос о том как получить информацию о достижении предела Half-open остается открытым...
Записан
ksak
Гость
« Ответ #6 : 20-08-2010 07:10 » 

ты имеешь в виду системное предупреждении 4226 "Достигнут предел безопасности для TCP/IP, налагаемый  на количество попыток одновременных TCP-подключений", или что?
Да, именно это сообщение в журнале.
Как получить информацию о возникновении этого события при попытке открытия нового  сокета?
Если нет других идей о проверке достижения предела Half-open ...
Записан
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #7 : 23-08-2010 15:15 » 

А нельзя мониторить время "зависания" из некоего диспетчерского потока и принудительно убивать всё, что висит более 1 секунды?
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
ksak
Гость
« Ответ #8 : 25-08-2010 08:06 » new

А нельзя мониторить время "зависания" из некоего диспетчерского потока и принудительно убивать всё, что висит более 1 секунды?
Вопрос - как убить? Все сводится к начальному вопросу....
Пока решили задачу использованием ICMP  и дальнейшее сканирование только доступных узлов.
Хотя это и не есть полностью правильно...
Записан
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines