Как бы вы уведомляли клиентов об измененных данных на сервере, используя .Net 2.0?

Question

Представьте себе клиентское приложение WinForms, которое отображает довольно сложные вычисленные данные, извлеченные из серверного приложения с .Net Remoting через HTTPChannel.
Поскольку клиентское приложение может работать весь рабочий день, мне нужен метод, чтобы уведомить клиента о наличии новых данных, чтобы пользователь мог начать перезагрузку данных, когда ему это необходимо.
В настоящее время я использую удаленные .Net события, сериализирую событие для клиента и затем перебрасываю событие на стороне клиента.

Я не очень доволен этой настройкой и планирую переопределить ее.
Для меня важно:

• .Net 2.0 основанная технология
• простота использования
• низкая сложность
• достаточно надежный, чтобы выдержать перезапуск сервера или клиента, все еще работоспособный

Когда вы ограничиваетесь .Net 2.0, как бы вы реализовали такую ​​функцию? Какие технологии / библиотеки вы бы использовали?
Я ищу вдохновение для решения этой проблемы.

Edit:

Клиент и сервер существуют в одной организации, обычно это локальная сеть, возможно, ситуация с WAN / VPN.
Этот механизм должен только информировать клиента о наличии новых данных. Я хотел бы продолжить удаленное взаимодействие для получения фактических данных клиенту, так как это работает довольно хорошо. MSMQ поставляется с Windows, не так ли? Так что все должно быть в порядке, но я открыт для любой альтернативы.

Answer 1

Я реализовал аналогичный механизм уведомлений, используя MSMQ. Клиентский компьютер открывает локальную общедоступную очередь, а затем сообщает серверу имя своей очереди. Когда происходят изменения, сервер помещает уведомления во все очереди клиентов, о которых ему сообщают. Таким образом, клиент будет знать, что данные готовы, даже если они не выполнялись во время отправки уведомления.

Единственным недостатком является то, что для клиентов требуется MSMQ, поэтому это может не сработать, если у вас нет такого контроля над компьютерами вашего клиента.

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

Также в этом отношении, если серверу не удается доставить сообщения клиенту измеренное количество раз в течение измеренного периода времени, тогда объекты поддержки уведомляются, оповещения об ошибках выходят, а очередь клиента удаляется из список направлений. Когда я говорю «измеренный», я имею в виду частоту / продолжительность, которая имеет смысл для настройки. В моем случае это было 5 попыток с 5-минутными интервалами между попытками.

Может также иметь смысл периодически обновлять подписку на уведомления для клиента. Если обновление не происходит, в конечном итоге очередь клиента удаляется из списка адресатов с помощью процесса «грумера» в службе.

Answer 2

Если вы не можете найти ничего встроенного и предполагая, что знаете адрес всех клиентов, вы можете отправить им сообщение UDP при изменении данных. Используя UdpClient, это очень просто. Датаграмма даже не должна содержать никаких данных, если клиентское приложение может предположить, что любые UDP-данные на определенном порту означают, что ему необходимо получить новые данные с сервера.

При необходимости вы можете даже сделать этот пакет широковещательным (если вы не знаете, кто такие клиенты и находятся в одной подсети с сервером), если сервер не слишком болтлив.

Какое бы решение вы ни выбрали, я бы настоятельно рекомендовал вам не проводить опрос клиентов. Это создаст много ненужного сетевого трафика и все равно не будет работать так хорошо.

Answer 3

Я бы обычно использовал таймер пользовательского интерфейса на клиенте, чтобы периодически подключаться к серверу, чтобы увидеть, есть ли новые или обновленные данные. (Предполагая, что у вас есть механизм для определения наличия новых данных, таких как отметки времени для новых строк, отметки времени файла или таблица с датами, рассчитанными последним, и т. Д.)

Таким образом, сервер не должен знать о клиентах. Клиенты могут проверить на досуге и т. Д.

Answer 4

Звучит так, как будто вам нужно реализовать решение на основе очереди сообщений. Простота реализации, может выдержать перезагрузки, а технология является зрелой как на сервере (MSMQ, MGQSeries), так и на клиенте (System.Messaging)