Блог

Меня попросили изучить выполнимость задачи, касающейся.NET PUSH. Теперь я сузился до использования двух вариантов

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

Текущая реализация выполняется с помощью опроса сервера каждые 15 минут. Хотя это работает нормально, все же есть некоторые недостатки, такие как A — загрузка сервера B — Задержка обновления для пользователя (поскольку обновление для отражения на клиентском компьютере будет напрямую зависеть от интервала, с которым опросы клиента, независимо от того, когда новости были фактически обновлены)

Итак, мы решили улучшить систему, чтобы использовать механизм server push, и я нахожу следующий механизм подходящим

Программирование A — Socket:

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

Сервер принимает соединение и сохраняет его открытым. Класс ServerSocket подписывается на обновления категории и выполняет то же самое. Объект TcpListener, созданный для клиентов, сопоставляется объекту dictionary с идентификатором пользователя, например: Dictionary.

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

B — WCF:

Второй метод, о котором я мог подумать, заключался в использовании функции обратного вызова WCF, поскольку она обеспечивает двустороннюю поддержку. Таким образом, мы по-прежнему подписываемся на сервер для обновлений категорий, на которые подписался пользователь loggedin. Если происходит какое-либо обновление категории, мы вызываем соответствующий экземпляр, используя тот же механизм словаря, например dictionaryobject[Clientid].Callback();

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

Спасибо вам за ваш вклад, ребята,

Srikanth

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

Я бы сказал, что вам следует использовать WCF, если скорость отправки сообщений клиентам не имеет большого значения. Реализация «немного» проще, чем работа с сокетами. Я начал сначала как WCF, но я не был доволен скоростью (что очень важно в моем случае).

Реализация сокетов также упрощается в .NET 4.5, но больше работы по подключению клиентов, размещению, передаче, чем в WCF. Однако это быстрее, и вы передаете байты, которые вам нужно передать, только ничего лишнего.

Я надеюсь, что это поможет.

Спасибо, что поделились. Я уже реализовал компонент с использованием WCF ниже приведены причины, по которым я выбрал WCF вместо программирования сокетов.

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

2) NETTCPBINDING использует TCP в качестве среды передачи и, следовательно, был более или менее одинаково быстрым, как сокеты.

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

Один из моих коллег также предположил, что мы могли бы использовать BIZTALK с шаблоном публикации / подписки для достижения функциональности. Платформа BizTalk уже оптимизирована для операций аналогичного характера. В любом случае я остановился на WCF, поскольку он казался более подходящим.

Спасибо