Здравствуйте!
Помогите определиться с выбором. Стоит следующая задача.
Нужно написать агента и монитор. Агент будет установлен приблизительно на 100 компьютеров.
Монитор на 10 компьютеров. Агент по запросу монитора будет передавать последнему некоторую информацию
о работе компьютера. Каждый из 10 мониторов должен иметь возможность получать эту информацию от каждого
из 100 агентов. Хотелось бы для этих целей использовать Remoting. Но в этом случае придется устанавливать
и поддерживать огромное количество соединений. Возможно использовать Remoting или лучше использовать UDP
протокол или существует какая-нибудь другая реализация? Спасибо за любой совет?

Здравствуйте, Dan123, Вы писали:

Возможно использовать Remoting или лучше использовать UDP
D>протокол или существует какая-нибудь другая реализация? Спасибо за любой совет?

У меня стоит щяс подобная задача. Я использую для етого протокол TCP/IP так как нужна гарантия того, что данные переданы. И еще одно, у меня не монитор запрашивает у клиента, он только "слушает", а клиенты сами к ниму конектятся. Использую сокеты.

Y>У меня стоит щяс подобная задача. Я использую для етого протокол TCP/IP так как нужна гарантия того, что данные переданы. И еще одно, у меня не монитор запрашивает у клиента, он только "слушает", а клиенты сами к ниму конектятся. Использую сокеты.

Т.е. когда клиенту нужно передать данные он устанавливает соединение, передает данные и затем закрывает соединение. Так?
А с какой периодичностью клиент конектится к монитору?

В одном проекте ранее был использован Remoting для случая когда несколько клиентов подключаются к серверу. Но в текущей задаче все-таки клиенты будут работать одновременно с несколькими мониторами и передавать конкретному монитору только ту информацию, которую в данный момент он хочет получать от клиента. Т.е. нужна двухсторонняя связь. Как это реализовать пока даже представить не могу.

Кажется, вам сюда:
http://msdn.microsoft.com/ru-ru/library/system.net.peertopeer.aspx

Или, если важна сохранность данных, заведите базу-коллектор (или сервис-коллектор, если веб): пусть мониторы сыпят туда данные, агенты считывают. Дёшево и сердито.

Здравствуйте, Dan123, Вы писали:

D>Возможно использовать Remoting или лучше использовать UDP
D>протокол или существует какая-нибудь другая реализация? Спасибо за любой совет?

MSMQ

Здравствуйте, Dan123, Вы писали:

D>Помогите определиться с выбором. Стоит следующая задача.
D>Нужно написать агента и монитор. Агент будет установлен приблизительно на 100 компьютеров.
D>Монитор на 10 компьютеров. Агент по запросу монитора будет передавать последнему некоторую информацию
D>о работе компьютера. Каждый из 10 мониторов должен иметь возможность получать эту информацию от каждого
D>из 100 агентов.

Траффик-то у вас какой? Сколь велика информация, обновляется ли она у вас целиком, или большая часть незменна а обновляются лишь небольшие кусочки, как часто надо ее запрашивать?

D>Хотелось бы для этих целей использовать Remoting.

Я бы постарался без нужды не использовать ни с чем не совместимые мелкософтовские протоколы. Вот захочется вам спортировать агента на линух или мак, куда вы пойдете со своим ремутингом?

D>Но в этом случае придется устанавливать и поддерживать огромное количество соединений.

Несколько десятков или даже сотен соединений по нынешним временам далеко не "огромное количество".

Огромное — это когда у вас количество соединений измеряется десятками тысяч.

Pzz>Траффик-то у вас какой? Сколь велика информация, обновляется ли она у вас целиком, или большая часть незменна а обновляются лишь небольшие кусочки, как часто надо ее запрашивать?

Объем данных будет от 100 до 300 килобайт. Агент будет передавать эти данные монитору с периодичностью раз в минуту. Если с агентом будет работать несколько мониторов, значит агент будет передавать эту информацию раз в минуту сразу нескольким мониторам. Причем монитор должен сообщить агенту какой набор данных он должен от него получить.
Но в любом случае этот набор данных будет не более 300 килобайт. В моем понятии это выглядит так: Монитор шлет агенту команду "пришли мне такую то информацию", после чего ждет от него ответа. После получения ответа обрабатывает информацию и переходит к опросу следующего агента. Т.е. каждый монитор раз в минуту опрашивает всех агентов.

Здравствуйте, Dan123, Вы писали:

D>Здравствуйте!
D>Помогите определиться с выбором. Стоит следующая задача.
D>Нужно написать агента и монитор. Агент будет установлен приблизительно на 100 компьютеров.
D>Монитор на 10 компьютеров. Агент по запросу монитора будет передавать последнему некоторую информацию
D>о работе компьютера. Каждый из 10 мониторов должен иметь возможность получать эту информацию от каждого
D>из 100 агентов. Хотелось бы для этих целей использовать Remoting. Но в этом случае придется устанавливать
D>и поддерживать огромное количество соединений. Возможно использовать Remoting или лучше использовать UDP
D>протокол или существует какая-нибудь другая реализация? Спасибо за любой совет?

Доброе ...

SNMP?

--

Здравствуйте, Dan123, Вы писали:

Pzz>>Траффик-то у вас какой? Сколь велика информация, обновляется ли она у вас целиком, или большая часть незменна а обновляются лишь небольшие кусочки, как часто надо ее запрашивать?

D>Объем данных будет от 100 до 300 килобайт. Агент будет передавать эти данные монитору с периодичностью раз в минуту. Если с агентом будет работать несколько мониторов, значит агент будет передавать эту информацию раз в минуту сразу нескольким мониторам. Причем монитор должен сообщить агенту какой набор данных он должен от него получить.

А ширина сетевых каналов какая?

Компьютеру не сложно передать куда-то 300 килобайт, и если бы дело было только в этом, я бы посоветовал не париться, и просто использовать HTTP. Но у вас 100 агентов, в общей сложности получается 300 * 100 / 60 = полмега в секунду. Для 100-мегабитного ethernet'а это пустяки, а для какого-нибудь ADSL-модема может оказаться на пределе возможности.

D>Но в любом случае этот набор данных будет не более 300 килобайт. В моем понятии это выглядит так: Монитор шлет агенту команду "пришли мне такую то информацию", после чего ждет от него ответа. После получения ответа обрабатывает информацию и переходит к опросу следующего агента. Т.е. каждый монитор раз в минуту опрашивает всех агентов.

А как монитор находит агентов? Кто-то честно забивает руками 100 адресов в табличку и поддерживает ее аккуратность при изменениях конфигурации?

Здравствуйте, Аноним, Вы писали:

А>SNMP?

А вы его пробовали, прежде чем советовать?

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, Аноним, Вы писали:

А>>SNMP?

Pzz>А вы его пробовали, прежде чем советовать?

Доброе ...
Пробовали ... а вы?

--

Pzz>Компьютеру не сложно передать куда-то 300 килобайт, и если бы дело было только в этом, я бы посоветовал не париться, и просто использовать HTTP. Но у вас 100 агентов, в общей сложности получается 300 * 100 / 60 = полмега в секунду. Для 100-мегабитного ethernet'а это пустяки, а для какого-нибудь ADSL-модема может оказаться на пределе возможности.

100-мегабитный ethernet


Pzz>А как монитор находит агентов? Кто-то честно забивает руками 100 адресов в табличку и поддерживает ее аккуратность при изменениях конфигурации?

Есть мысль для добавления адресов агентов использовать широковещательный запрос по UDP. т.е. в мониторе открывается форма для добавления агентов, в этот момент
монитор делает широковещательный запрос и отображает всех откликнувшихся агентов. Далее напротив нужных агентов ставим галочки и жмем OK, чтобы запомнить
имена компьютеров в сети. В случае изменения имени компьютера придется конечно в ручную удалить компьютер со старым наименованием из списка и повторить
процедуру добавления заново. Возможно, что я совсем не правильно себе все это представляю, поскольку эта тема для полностью нова, поэтому буду очень признателен если объясните как лучше все это реализовать.

А>SNMP?

Не совсем понимаю как использовать SNMP. Насколько я знаю этот протокол используется как протокол управления сетями связи и в нем есть предопределенные операции для работы
агента с менеджером. Мне же нужно написать и использовать своего агента.

Здравствуйте, Dan123, Вы писали:

D>Не совсем понимаю как использовать SNMP. Насколько я знаю этот протокол используется как протокол управления сетями связи и в нем есть предопределенные операции для работы
D>агента с менеджером. Мне же нужно написать и использовать своего агента.

Доброе ...
SNMP можно использовать как для управления, так и для мониторинга (насколько я понял — вам как раз нужен мониторинг).
Идея использования проста: поднимаете агента на хосте (в windows уже имеется snmp агент, который может предоставлять информацию о дисковом пространстве, цпу, памяти и т.д.). Если правильно ошибаюсь — к агенту можно подкрутить другой источник данных (ваш самописный агент) — который будет выдавать информацию, специфичную для вашего приложения. Поднимаете менеджера, который и будет дергать ваших агентов с заданной периодичностью и процессить полученную информацию — сохранять, генерить алармы второго уровня и т.д. При этом в качестве менеджера может выступать любое приложение, умеющее общаться по snmp.

--

Думаю, для начала определитесь с протоколом.

Если все будет находиться в локальной сети и данные будут однотипны (и замечательно если будут помещаться в один кадр Ethernet), то Вам вполне подойдет протокол Ethenet, и не зачем использовать более "дорогие" протоколы более высокого уровня.

Если данные должны передаваться хотябы через один маршрутизатор, то нужно переходить на более высокий уровень, скорее всего (из-за универсальности) это будет IP. Сам по себе IP использовать неудобно (и не за чем изобретать велосипед), выбирайте протоко более высокого уровня. Если данных очень мало (пара байт) то наилучшим образом подходит протокол ICMP. Если данных многова-то, то либо TCP, либо UDP. Если строго нужна гарантированная доставка и не допускается потеря пакетов, да еще и при этом информация не помещается в один пакет TCP — то выбирайте TCP. Если не нужна абсолютная гарантия доставки данных, или данных ооочень много (типа потокового видео), то выбирайте UDP.
почитайте об этих протоколах, чтобы лучше понять как они работают их различия и где они находятся в семиуровневой модели OSI.
После того как выбрали протокол, имеет смысл поискать протокол более высого уровня или готовое решение по его использованию. В случае с TCP это вполне может быть ремоутинг.

Также посмотрите на SNMP (более высокого уровня), который использует различные протоколы (ICMP, TCP, UDP) в зависимости от передаваемой информации.

И на этом же шаге подумайте как будет все взаимодействовать. Нужна ли Вам информация по запросу, или достаточно с определенной переодичностью. Информацию о местонахождении серверов (мониторов) можно размещать с помощью других протоколов, например DNS или DHCP сервер вполне с этим справится.

Вариант схемы:
при загрузке каждый агент получает список всех мониторов и опеващает их о своем наличии и включении (ICMP или SNMP), при необходимости монитор обращается к агенту — "дай информацию" к агентам, к которым может обратиться (ICMP или SNMP), агент передает информацию монитору (ICMP, TCP, UDP или SNMP).

Более подробно о том что выбрать только после уточнения задачи. После этого можно думать как проще всего это реализовать.

И посмотрите в сторону обычного Web Service, неплохо масштабируется, быстро пишется клиент ... (После того как определились что именно Вам нужно)

Спасибо за развернутый ответ.

C> Информацию о местонахождении серверов (мониторов) можно размещать с помощью других протоколов, например DNS или DHCP сервер вполне с этим справится.

Есть вероятность, что мониторы будут мониторить не все 100 агентов одновременно, а разные группы агентов. Причем один агент может входить в разные группы.
Как мне кажется, в данном случае агенты должны выступать в качестве серверов, а мониторы подключаться к ним по мере надобности. Нормально будет, если
каждый из 100 агентов разместит информацию о своем местонахождении используя для этого DNS или DHCP?
Смысл такой. Монитор запускается в режиме настройки. В этом режиме монитор видит абсолютно всех агентов находящихся в сети. Далее выбираем только те агенты, которые
должен контролировать данный монитор, сохраняем это в настройках и переводим монитор в режим работы. После этого монитор работает только с теми агентами, которые мы ему указали.

Как-то сложно получается.

В моем примере реализации каждый агент сообщает о своем присутствии при включении (можно реализовать "сердцебиение", каждый час, например, после загрузки сервиса). Это не напрягает сеть. Каждый монитор "знает" о каждом агенте, но работает и запрашивает информацию только с теми, с кем разрешено.

Подумайте над слкдующими вопросами:
— заносить информацию в DNS или DHCP будете автоматически или ручками
— можно ли дать расширенные права агентам? безопасность нарушать нельзя!
— как собираетесь администрировать те же 10 мониторов? По идее нужна общая оснастка
— посмотрите как реализованы оснастки в Win Server 2008 R2 и Windows 7 (MMC)
— каким образом будете распространять агентов? (тоже ручками)

C>Подумайте над слкдующими вопросами:
C>- заносить информацию в DNS или DHCP будете автоматически или ручками
Я хотел это реализовать просто при помощи широковещательного запроса.
Теперь попробую разобраться с DNS или DHCP. Но все-равно пока вариант с широковещательным запросом мне пока больше нравится.
Как я себе это представляю. Запустил я монитор в режиме настройки. При запуске в этом режиме монитор делает широковещательный запрос, чтобы агенты ему указали где они находятся. Плюс также могу вручную указать расположение агента по IP адресу или названию компьютера в сети. Потом запоминаю где находятся агенты и дальше с ними монитор
работает например с использованием Remoting. Стоит ли мне все-таки заморачиваться с DNS или DHCP? или такой вариант вполне приемлем?

C>- можно ли дать расширенные права агентам? безопасность нарушать нельзя!
Что подразумевается под расширенными правами?

C>- как собираетесь администрировать те же 10 мониторов? По идее нужна общая оснастка
На счет общей оснастки задумывался, но пока подходит вариант локального администрирования.

C>- каким образом будете распространять агентов? (тоже ручками)
Двумя вариантами. 1) Ручками. 2)Удаленно из монитора.

Согласен, по хорошему надо делать общую оснастку при помощи которой удаленно распространять и администрировать как агентов, так и мониторы.
Но это будет потом. Пока устраивает и такой вариант.

Здравствуйте, Clevelus, Вы писали:

C>Если все будет находиться в локальной сети и данные будут однотипны (и замечательно если будут помещаться в один кадр Ethernet), то Вам вполне подойдет протокол Ethenet, и не зачем использовать более "дорогие" протоколы более высокого уровня.

Вы издеваетесь над человеком? Как вы это себе представляете, интересно? В венде не так просто послать и принять "сырой" ethernet'овский пакет.

C>Если данные должны передаваться хотябы через один маршрутизатор, то нужно переходить на более высокий уровень, скорее всего (из-за универсальности) это будет IP. Сам по себе IP использовать неудобно (и не за чем изобретать велосипед), выбирайте протоко более высокого уровня. Если данных очень мало (пара байт) то наилучшим образом подходит протокол ICMP.

Зачем давать бессмысленные советы? Вы сами-то пробовали использовать ICMP в качестве транспорта?

C>Если данных многова-то, то либо TCP, либо UDP. Если строго нужна гарантированная доставка и не допускается потеря пакетов, да еще и при этом информация не помещается в один пакет TCP — то выбирайте TCP. Если не нужна абсолютная гарантия доставки данных, или данных ооочень много (типа потокового видео), то выбирайте UDP.

Потоковое видео засовывают в UDP не потому, что данных очень много, а потому, что как раз "абсолютная гарантия доставки" не нужна, но нужно при этом чтобы то, что будет доставлено, приехало таки за конечное время. TCP в случае потерь пакетов может застрять, и это время никак нельзя ограничить.

C>почитайте об этих протоколах, чтобы лучше понять как они работают их различия и где они находятся в семиуровневой модели OSI.

TCP/IP очень с большой натяжкой укладывается в семиуровневую модель OSI.

C>Также посмотрите на SNMP (более высокого уровня), который использует различные протоколы (ICMP, TCP, UDP) в зависимости от передаваемой информации.

SNMP не использует ICMP и по-моему не использует TCP (за последние версии SNMP не поручусь), а использует только UDP.