Здравствуйте, Kemm, Вы писали:
K>Здравствуйте, Anokhov, Вы писали:
VDB>>>Да, и еще. То, что connect() происходит в блокирующем режиме — так и задумано?
A>>Не совсем 
но, насколько я понимаю, fcntl надо вызывать сразу после connect?
K>А как тогда connect() может не заблокироваться, если сокет не переведен в неблокирующий режим? 8)) Как раз наоборот -- сразу после создания клиентского сокета.
Верно.
A>>В общем мой вариант, описанный выше, работает, с одной доработкой. Я &readset очищаю и заполняю каждый раз в цикле перед вызовом Select заново. Нигде в документации я не смог найти, почему так. Но по тестам у меня получилось, что Select после того, как срабатывает, очищает &readset? Или может он удаляет из него все дескрипторы, которые не сработали? Подскажите, что в действительности происходит?
K>Кстати, да. Я не обратил внимания на работу с fd_set. В мане же написано:
K>On return, select() replaces the given descriptor sets with subsets consisting of those descriptors that are ready for the requested operation.
K>Иначе бы FD_ISSET() и не работал бы. 8)) Поэтому обычно все обнуляется и заполняется заново.
Мало того, я бы еще для бОльшей переносимости (если это нужно), и значение тайм-аута советовал бы заново заполнять.
Не все реализации оставляют его неизменным.
Здравствуйте, _kostet_, Вы писали:
__>UAnokhov wrote:
__>Про UDP я и не говорил.
А ведь согласитесь, это был бы максимально простой вариант.
И в условиях локальной сети — достаточно надежный.
Vladimir D Belousov wrote:
>
> А ведь согласитесь, это был бы максимально простой вариант.
> И в условиях локальной сети — достаточно надежный.
> --
Да возможно еще и более дешевый и быстрый. Но мне почему то показалось, что с
самого начала шла речь о TCP. Тем не менее, что выберет автор его личное дело,
но сути сильно не поменяет.
Posted via RSDN NNTP Server 2.0 beta
VDB>А ведь согласитесь, это был бы максимально простой вариант.
VDB>И в условиях локальной сети — достаточно надежный.
В условиях локальной сети было бы вообще все намного проще
и, что более важно, в локалке все гораздо надежднее в плане оборудования...
Но у меня задача собрать с машин в интернете данные, так что тут только TCP...
А>Мало того, я бы еще для бОльшей переносимости (если это нужно), и значение тайм-аута советовал бы заново заполнять.
А>Не все реализации оставляют его неизменным.
ОК, буду обновлять.
Всем спасибо. Работает в общем
Здравствуйте, Anokhov, Вы писали:
VDB>>А ведь согласитесь, это был бы максимально простой вариант.
VDB>>И в условиях локальной сети — достаточно надежный.
A>В условиях локальной сети было бы вообще все намного проще и, что более важно, в локалке все гораздо надежднее в плане оборудования...
A>Но у меня задача собрать с машин в интернете данные, так что тут только TCP...
Ну тогда немного нас ввели в заблуждение — в самом первом вопросе было "Нужно в один момент получить с более, чем 100 машин некоторые данные ...", а сбор не через локалку или высокоскоростную выделенку — очень с натяжкой можно назвать "одномоментным". Просто была попытка уйти от сканирования (терпеть не могу), разгрузить канал, разгрузить сервер и т.д. Вопрос, можно сказать, закрыт.
