Обновления сервера SignalR и заинтересованность клиента в подмножестве обновлений

Во многих примерах, которые я видел, таких как приложение StockTicker, предполагается, что все клиенты будут заинтересованы в обновлении цен на все акции...

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

Буду ли я:

  1. транслировать все обновления всем клиентам и позволить клиентам определять, «нужно ли им» в клиентском методе?
  2. регистрировать с каждым клиентским соединением «предметы интереса» и поддерживать где-то таблицу клиентских соединений, итеративно транслируя всем клиентам, которые выразили этот интерес?
  3. Создать группу SignalR для каждой акции (например) и зарегистрировать клиентов для каждой конкретной группы акций, «представляющей интерес», и транслировать только определенной группе во время обновления связанной акции?
  4. что-то еще мне не хватает...

Чтобы сделать этот вопрос менее субъективным, какие подводные камни есть у каждого из приведенных выше сценариев (а не «какой из них вам больше нравится?»)?

Спасибо банде.


person Novox    schedule 06.05.2014    source источник


Ответы (1)


"Буду ли я:"

  1. «рассылать все обновления всем клиентам и позволять клиентам определять, «нужно ли им» в клиентском методе?»

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

  2. «регистрировать с каждым клиентским соединением «предметы интереса» и поддерживать где-то таблицу клиентских соединений, итеративно транслируя всем клиентам, которые выразили этот интерес?»

    Это похоже на концепцию групп SignalR, но итеративная широковещательная рассылка отдельным клиентам обычно не так эффективна, как широковещательная рассылка группе. В первую очередь это связано с тем, что SignalR должен публиковать только одно сообщение на своей шине для групповой широковещательной рассылки.

    Тем не менее, вы можете захотеть вести «таблицу клиентских подключений», содержащую «предметы интереса» для каждого клиента, даже если вы в конечном итоге используете встроенные функции групп SignalR. SignalR позволяет вам только добавлять/удалять клиентов в/из группы и транслировать в группу, поэтому, если вы хотите узнать, кто в настоящее время находится в группе, вам придется отслеживать это самостоятельно.

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

  3. «Создать группу SignalR для каждой акции (например) и зарегистрировать клиентов для каждой конкретной группы акций, «представляющих интерес», и транслировать только определенной группе во время обновления связанной акции?»

    Это был бы мой выбор. Группы естественным образом выравниваются по «предметам интереса». Учитывая ваш сценарий, я не вижу особых недостатков, особенно если вы также поддерживаете свою собственную «таблицу подключения клиентов».

  4. "что-то еще я упускаю..."

    Я думаю, вы рассмотрели три основных варианта.

person halter73    schedule 06.05.2014
comment
Если я выберу групповой маршрут, насколько я понимаю, если группа не существует, SignalR может отправлять ей все без исключения (что меня устраивает). Это правильно? Существует ли верхняя граница количества групп, которые могут существовать одновременно? - person Novox; 07.05.2014