Изучение решений для уведомления клиентов WPF с сервера

У меня есть проект, требующий уведомления рабочих столов WPF, когда что-то происходит на сервере. Кроме того, уведомление для клиентов WPF не будет транслироваться (отправлено каждому клиенту), оно должно быть отправлено конкретным клиентам.

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

У меня никогда не было этого требования раньше, и я исследую решения. Моя первая мысль заключалась в использовании SignalR с .NET-клиентом. Я еще не работал с SignalR, но похоже, что это может быть решение. Я знаю, что это абстракция по длительным опросам, Server-Sent Events и WebSockets, в зависимости от того, что доступно.

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

Ответ 1

Это можно сделать довольно легко с WCF и дуплексными контрактами. Вы можете определить операции, которые клиент может выполнять на сервере (например, любой веб-сервис), а также вы можете определять операции, которые сервер может выполнять на клиенте (т.е. Обратный веб-сервис). Код мудрый, они оба просто вызовы метода. Клиент имеет методы, которые вызывают операции на сервере, а также должен предоставлять объект, который реализует контракт обратного вызова, который является интерфейсом, который может вызывать сервер, и клиент должен обеспечить реализацию. Вся сериализация/десериализация данных и сообщений и всех сетевых операций низкого уровня обрабатывается WCF, поэтому вам не придется беспокоиться об этом.

WCF поддерживает дуплексные контракты с использованием двух привязок (или "протоколов" ):

WSDualHttpBinding - Это связано с двумя HTTP-прослушивателями на основе SOAP, один на сервере и один на клиенте. Когда клиент хочет связаться с сервером, он выполняет HTTP-запрос на сервер. Когда сервер хочет связаться с клиентом, он выполняет HTTP-запрос клиенту. Преимущество такого подхода заключается в том, что любое сетевое соединение мимолетно и не поддерживается открытым (как и в большинстве HTTP-соединений), и поэтому оно может поддерживать большое количество или одновременных клиентов. Основным недостатком является то, что он, вероятно, не будет работать с большинством клиентских компьютеров через Интернет, поскольку они обычно находятся за NAT (без проблем для связи между серверами через Интернет или любого рода связи внутри интрасети или локальной сети), Для получения дополнительной информации см. Мой другой ответ.
NetTcpBinding - это в основном открывает сокет от клиента к серверу и держит его открытым на время сессия. Это позволяет осуществлять двустороннюю связь даже через NAT, но поскольку соединения должны быть открыты, это в некоторой степени зависит от сервера и, следовательно, сможет поддерживать меньше одновременных пользователей (но, вероятно, в большинстве случаев их еще больше, чем достаточно). Это мой предпочтительный способ делать дуплексные контракты на WCF, так как он легче работать и более надежен.

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

Каким бы способом вы ни выбрали, вы сможете совершать почти мгновенную связь в обоих направлениях (конечно, разрешено латентность сети). Я не вижу необходимости в SignalR, когда у вас есть такая богатая, мощная и простая в использовании пользовательская инфраструктура, такая как WCF. Если вы были ограничены запуском в браузере, тогда SignalR будет иметь смысл. Поскольку вы работаете в .NET, он просто вводит ненужное трение.

Ответ 2

Точка технологий, таких как SignalR, должна удовлетворять спрос на связь в реальном времени между серверами и веб-клиентами. Они используют WebSockets и откатываются от более старых/хакерских механизмов связи для старых веб-браузеров.

Если ваша среда будет локальной сетью и вашим клиентом .NET-приложение, вы можете использовать TCPServer и несколько TCPClients. Когда на вашем веб-сервере отправляется сообщение об обновлении/сообщении, сообщите свой TCPServer (возможно, поместив сообщение на шину сообщения, которое он прослушивает), который может информировать подключенного клиента (клиентов). Веб-технологии в реальном времени - отличный способ сделать это, но это действительно зависит от ваших текущих требований и ваших планов на будущее:

Вы хотите попробовать SignalR. Если да, то это сработает, и вам, вероятно, будет очень весело. Это может также быть полезно для будущих проектов и быть хорошей струной в вашем поклонении. Если нет, то подход TCPClient и TCPServer может быть суперпростым и быстрым.
У вас есть требование, чтобы другие типы веб-клиентов могли получать уведомления в будущем? - да, SignalR или еще один более зрелый самостоятельная веб-технология в реальном времени могла бы стать лучшим решением. Нет - TCPServer/Client
Планируете ли вы распространять данные за пределами вашей локальной сети? Да - самостоятельная версия или событие размещенное решение с библиотеками .NET могут быть способы, поскольку они устраняют служебные расходы на обслуживание (Отказ от ответственности: я работаю для Pusher, которые предлагают услугу как это). No-self hosting или TCPServer/Client.
Насколько важна скорость? Если это действительно имеет значение, то самым быстрым вариантом будет соединение с TCP без каких-либо накладных расходов. Вторым лучшим вариантом будут WebSockets, затем потоковая передача HTTP, а затем HTTP Long-Polling.

Примечание. Хотя я говорю, что TCPServer/Client может быть самым простым подходом, я бы хотел подчеркнуть, что он также может не быть. WebSockets - действительно захватывающая технология и во многих отношениях более доступная, чем технология TCPClient, поэтому она может стать доминирующей технологией для двунаправленной связи между любым сервером и клиентом.

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

Ответ 3

Вы должны заглянуть в WebSync из Frozen Mountain. Я использовал его в прошлом с отличными результатами. Он делает все, что вам нужно. Они даже предлагают размещенную услугу "WebSync on Demand". Они также предлагают бесплатный продукт (но до 10 одновременных пользователей). Это коммерческий продукт. Если вы не хотите делать всю сантехнику, WebSync предлагает вам готовые к использованию api, вы можете просто начать использовать и быстро идти. Я слышал/читал о SignalR, еще не использовал его, но SignalR, похоже, находится в альфа/бета, тогда как WebSync очень зрелый.

Ответ 4

Я также оценивал легкий вес, но простой способ передавать события клиентам WPF с использованием паба/вспомогательной службы. Я не нуждался в гарантированной доставке сообщений, поэтому такие решения, как MassTransit или NServiceBus, казались слишком тяжелыми, так как они требуют, чтобы очереди были доступны (MSMQ или иначе). У меня также было требование, чтобы решение было доступно как .NET 4.0 Профиль клиента.

Одно решение, построенное на WCF, которое, кажется, работает nvents. Я не уверен, что этот проект все еще активен. Он прост в использовании, и базовая реализация (WCF) хорошо абстрагируется. Не требуется отлаженная конфигурация.

Другое решение, с которым я столкнулся в Per Brage Blog, использует SignalR с реактивными расширениями. Я не пробовал его реализацию и не уверен, нужен ли ему полный профиль, но он хорошо читается!

Ответ 5

Этот вопрос интересен.

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

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

Причина использования полностью отдельной веб-службы объясняется тем, что для всех наших существующих соединений необходимы соединения, которые должны быть установлены и удалены при каждом вызове. С помощью веб-службы уведомлений подключения должны поддерживаться до тех пор, пока выполняются клиенты.

Мне жаль, что я не мог больше помочь, так как мы сами разрабатываем такую систему. Я также заинтересован в получении обратной связи по этому вопросу.

Ответ 6

Вы можете создать службу wcf, где клиенты wpf регистрируют их при запуске. Затем каждый wpf мог связываться с сервером msmq или rabbitmq, где они будут опроса собственной очереди, созданной на основе имени клиента/уникального идентификатора. На стороне сервера вы можете иметь службу, которая будет передавать данные в очереди, поскольку данные доступны на основе условий, установленных для каждого клиента.