Сервер Push против клиента Pull для топологии агент-сервер

Question

Мне нужно создать систему, состоящую из 2 компонентов:

• Один сервер, который обрабатывает и хранит данные. Также периодически отправляет обновления агентам

• Несколько агентов, установленных на удаленных конечных точках. Они собирают данные в (часто, но не всегда) долгосрочных операциях, и эти данные должны попасть на сервер

Я использую C # .NET, и в идеале я хочу использовать совместимый со стандартами метод связи (т. Е. Тот, который теоретически может работать и с Java, поскольку в будущем мы также можем использовать агенты Java). Есть ли альтернативы веб-сервисам? Какие у меня варианты?

На мой взгляд, у меня есть 3 варианта использования веб-сервисов, и я сделал следующие наблюдения:

• Клиент тянуть
  • На агенте не требуется открытого порта, поскольку он действует как клиент
  • Нужно будет опросить сервер на наличие обновлений
• Сервер push
  • Открыть порт у агента, так как он действует как сервер
  • Сервер должен опрашивать агентов для получения результатов
• Hybrid
  • Открыть порт у агента, так как он действует как и клиент и сервер
  • Нет опроса; сервер выдает обновления при необходимости, клиент отправляет результаты, когда они доступны

«Гибрид» (где агентами являются как клиентские , так и серверы, кажется очевидным выбором - но это приложение обычно устанавливается в корпоративных и правительственных средах, и я обеспокоен тем, что они могут иметь открытие порта у агента. Я слишком много на этом зацикливаюсь?

Есть ли другие плюсы и минусы, которые я пропустил?

Answer 1

Наши друзья по http://www.infrastructures.org клянутся механизмами, основанными на извлечении: http://www.infrastructures.org/papers/bootstrap/bootstrap.html

Основная причина, по которой они предпочитают подтягивание клиента по сравнению с нажатием на сервер, заключается в том, что клиенты могут не работать, а клиентыдолжен (в общем) применять все операции, выполняемые серверами.Если этот критерий не важен в вашем случае, возможно, их вывод не будет вашим выводом, но я думаю, что стоит прочитать раздел «Push vs Pull» их статьи, чтобы определить для себя.

Answer 2

Я бы сказал, что в наше время вы можете серьезно рассматривать только технологии вытягивания.Проблема с push-сообщениями заключается в том, что клиенты часто скрыты за устройствами сетевого адреса (NAT), такими как беспроводные маршрутизаторы, широкополосные модемы или межсетевые экраны компании, и они чаще всего недоступны с сервера.

Выполнение исходящих соединений («телефон-дом»), особенно на хорошо известных портах, таких как HTTP / HTTPS, в основном можно считать «возможным» даже в большинстве ограниченных сетей.

Answer 3

ИМХО, я считаю, что ваш лучший вариант - это вариант извлечения .., который может удовлетворить ваши основные системные требования следующим образом:

Первая часть: данные должны попасть на сервер, что, очевидно, может быть сделано черезвызов веб-метода, который отправляет эти данные в качестве параметра

2-я часть: (сервер периодически отправляет обновления агентам): вы все равно можете сделать это, что клиент (обычный) извлекает какую-то веб-службуметод, который «запрашивает» обновления с момента последнего запроса (своего рода метка времени s, чтобы получить пропущенные обновления)

Гибридный метод мне кажется немного странным, учитывая, что я считаю агента агентомчасть системы, которая, вероятно, может довольно часто переходить в автономный режим, что будет делать сервер в случае сбоя?обычно это сложный вопрос / решение, особенно если вы не уверены, что это «отключение» или сбой системы / сети и т. д.

Answer 4

Если вы используете какой-либо сервер обмена сообщениями (JMS для Java, не уверен в C #), тогда ваш сервер обмена сообщениями - единственный сервер, которому нужно открыть порт, и вы можете иметь двустороннюю связь от своего агента к серверу обмена сообщениями ис сервера на сервер обмена сообщениями.Это позволит вам выполнить гибридную модель, не открывая порт на агентском сервере.