Как бы вы уведомили клиентов об изменении данных на сервере с помощью .Net 2.0?
Представьте себе клиентское приложение WinForms, которое отображает довольно сложные расчетные данные, полученные из серверного приложения с помощью .Net Remoting по HTTPChannel. Поскольку клиентское приложение может работать в течение всего рабочего дня, мне нужен способ уведомить клиента о доступности новых данных, чтобы пользователь мог начать перезагрузку данных, когда ему это нужно. В настоящее время я использую удаленные события .Net, сериализуя событие для клиента, а затем повторно генерируя событие на стороне клиента.
Я не очень доволен этой настройкой и планирую реализовать ее заново. Для меня важно:
- Технология на основе .Net 2.0
- простота использования
- низкая сложность
- достаточно надежен, чтобы пережить перезапуск сервера или клиента, все еще работает
Как бы вы реализовали такую функцию, ограничившись .Net 2.0? Какие технологии / библиотеки вы бы использовали?
Я ищу вдохновение, как решить эту проблему.
Редактировать:
Клиент и сервер существуют в одной организации, обычно это локальная сеть или, возможно, WAN / VPN. Этот механизм должен только информировать клиента о наличии новых данных. Я хотел бы продолжать удаленное взаимодействие для передачи фактических данных клиенту, поскольку это работает очень хорошо. MSMQ поставляется с окнами, не так ли? Так что его можно использовать, но я открыт для любой альтернативы.
В этом случае MSMQ был бы идеальным. Его можно установить на сервере или клиенте без перезапуска. Кроме того, если AD доступен, у вас есть больше возможностей для поиска в очереди, обнаружения и т. д.
Ответы 4
Похоже, вам нужно реализовать решение на основе очереди сообщений. Легко реализовать, выдерживает перезагрузку, а технология отработана как на сервере (MSMQ, MGQSeries), так и на клиенте (System.Messaging).
Я реализовал аналогичный механизм уведомлений с помощью MSMQ. Клиентский компьютер открывает локальную общедоступную очередь, а затем сообщает серверу имя своей очереди. Когда происходят изменения, сервер отправляет уведомления во все клиентские очереди, о которых ему следует знать. Таким образом, клиент будет знать, что данные готовы, даже если они не были запущены на момент отправки уведомления.
Единственным недостатком является то, что для этого требуется MSMQ на клиентах, поэтому это может не сработать, если у вас нет такого контроля над клиентскими машинами.
Для дополнительного уровня избыточности (например, если клиентский компьютер полностью отключен и, следовательно, клиентская очередь недоступна) вы можете поставить уведомления в очередь на сервере до их рассылки клиентам. Уведомления в очередях сервера удаляются только при успешном контакте с клиентом (или, возможно, после 3 неудачных попыток и т. д.)
Также в этом отношении, если сервер не может доставить сообщения клиенту определенное количество раз в течение измеренного периода времени, то объекты поддержки уведомляются, предупреждения об ошибках уходят, а очередь клиента удаляется из списка адресатов. . Когда я говорю «измеряется», я имею в виду частоту / продолжительность, которые имеют смысл для настройки. В моем случае это было 5 попыток с 5-минутным интервалом между попытками.
Также может иметь смысл, чтобы клиент «продлевал» свою подписку на уведомления через определенные промежутки времени. Если обновления не происходит, то в конечном итоге клиентская очередь удаляется из списка адресатов «грумерным» процессом в службе.
Спасибо, я разберусь. Если клиенты публикуют свою очередь на сервере, не будет ли вероятность потери ссылок на очереди на сервере, если клиент перейдет в автономный режим без уведомления сервера?
Обычно я использую таймер пользовательского интерфейса на клиенте, чтобы периодически подключаться к серверу, чтобы узнать, есть ли новые или обновленные данные. (Предполагая, что у вас есть механизм для определения того, что у вас есть новые данные, такие как отметки времени для новых строк, отметки времени файла или таблица с последними рассчитанными датами и т. д.)
Таким образом, серверу не нужно знать о клиентах. Клиенты могут проверить на досуге и т. д.
Я получаю -1? По сути, это та же идея, что и тамберг upthread. Клиенты должны запрашивать новые данные. Связь сервера с клиентом не очень надежна. Для этого лучше подходят серверы без сохранения состояния. Дайте мне дату последнего обновления. Дай мне данные. Вы кодируете эти два, и все готово.
Если вы не можете найти ничего встроенного и предполагаете, что знаете адреса всех клиентов, вы можете отправить им UDP-сообщение при изменении данных. Используя UdpClient, это очень просто. В дейтаграмме даже нет необходимости содержать какие-либо данные, если клиентское приложение может предполагать, что любые данные UDP на определенном порту означают, что ему необходимо получить новые данные с сервера.
При необходимости вы даже можете сделать это широковещательным пакетом (если вы не знаете, кто такие клиенты, и они находятся в той же подсети, что и сервер), при условии, что сервер не слишком «болтливый».
Какое бы решение вы ни выбрали, я бы посоветовал вам избегать опросов клиентов. Это создаст много ненужного сетевого трафика и все равно не будет работать так хорошо.
Клиенты являются внутренними / внешними по отношению к вашей организации? Есть ли у вас некоторый контроль над окружающей средой, например, MSMQ? Сколько данных вы передаете?