Несколько соединений/концентраторов signalR на вашем веб-сайте

Если у меня есть несколько страниц, которые могут использовать несколько классов-концентраторов, каков наилучший способ управлять этим?

Например:

Плохо ли переходить на другую страницу на сайте и, по сути, "заново" открывать соединение с тем же классом концентратора, который был открыт на предыдущей странице?
Правильно ли я считаю, что открытие нескольких соединений концентраторов на странице - это нормально, поскольку все они объединены в одном соединении, даже если это разные классы концентраторов?

Ответ 1

У вас может быть несколько концентраторов, которые используют одно соединение на вашем сайте. SignalR 2.0 был обновлен для обработки нескольких концентраторов над одним сигнальным соединением без потери производительности.

Официальные документы: http://www.asp.net/signalr/overview/signalr-20/hubs-api/hubs-api-guide-server#multiplehubs

Все клиенты будут использовать тот же URL-адрес, чтобы установить соединение SignalR с вашей службой ( "/signalr" или ваш собственный URL, если вы указали один), и это соединение используется для всех концентраторов, определенных службой.

нет разницы в производительности для нескольких концентраторов по сравнению с определением всех функциональных возможностей концентратора в одном классе.

Ответ 2

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

Когда вы запускаете концентратор, он дает вашему клиенту идентификатор, который остается неизменным для этого концентратора (кто-то может подтвердить с помощью примера) на нескольких страницах.
Не плохо открыть соединение с тем же центром. Возможно, вы используете метод на стороне клиента hub.start, работающий на всех страницах, однако, если один его клиент открывает несколько окон или переходит с одной страницы на другую, у вас будет такой же идентификатор соединения на этом хабе, чтобы вы могли поддерживать связь. Если это было несколько концентраторов, то вы должны управлять концентраторами, а также идентификаторами соединений. Таким образом, этот вопрос звучит так: "Разве плохо, когда несколько интернет-провайдеров обслуживают мое интернет-соединение для разных сайтов". Вы можете получить их, но это перебор. Один интернет-провайдер может обслуживать все страницы для вас.
Несколько хабов на одной странице не идеальны, но они будут работать. Опять же, ответ требует немного контекста для проблемы, но в целом вы можете различать различные запросы на один и тот же идентификатор соединения через группы или используя другой подход, основанный на параметрах. Наличие двух концентраторов на одной странице может потребовать больше ресурсов (необходимо проверить это), чем использование параметров или групп для разделения различных областей обмена сообщениями.

Пример:

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

Мое решение:

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

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

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

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

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

Ответ 3

SignalR Core - НЕ ВОЗМОЖНО

К сожалению, это невозможно в новой версии Core для SignalR.

https://github.com/aspnet/SignalR/issues/456

https://github.com/aspnet/SignalR/issues/955

Примечания: проблемы с iOS и самозаверяющими сертификатами

На iOS существует ограничение на ЧЕТЫРЕ соединения на сервер.

Теперь для веб-сокетов нет этого ограничения (я думаю, что это может быть 32, но не уверен). Однако я использую самозаверяющий сертификат, который имеет все виды проблем в Safari - так что он фактически сводится к длительному опросу (и это не очевидно, что это так).

Итак, я закончил с этими связями:

1 - Угловая /Webpack горячая перезагрузка
2 - вызовы Web API
3 - хаб номер один
4 - Концентратор номер два
5 - # & # & # $ & # $ &

Так что, если бы у меня было ТОЛЬКО три хаба, вся страница Safari была бы заблокирована синей полосой. Даже вызовы веб-API были заблокированы.

Примечание: с HTTP/2 этот предел исчез, но вам, вероятно, лучше ограничиться одним концентратором, особенно если вы используете горячую перезагрузку. Плюс настройка HTTP/2 в разработке не обязательно тривиальная задача.

Так как исправить?

Сначала (временно) настройте концентратор на прием только веб-сокетов. Это даст вам ошибку в Safari (убедитесь, что ошибки обнаруживаются и отображаются в диалоговом окне предупреждения).

routes.MapHub<SignalRHub>("/rt", options =>
{
     // when run in debug mode only WebSockets are allowed
     if (Debugger.IsAttached) {
        options.Transports = Microsoft.AspNetCore.Http.Connections.HttpTransportType.WebSockets;
     }
});

Теперь вы сможете подтвердить исправление - запустить в режиме отладки или удалить "если".

Проблема с iOS в том, что даже если вы принимаете самозаверяющий сертификат для трафика https - и получаете в браузере симпатичный маленький символ "блокировки" - это не относится к протоколу wss :. Таким образом, соединения не могут быть обновлены до wss, поэтому они блокируются максимум до 4.

Решение № 1

Если вы можете получить все в один хаб, это будет проще :-)

Я также понял, что множественные концентраторы усложняют логику переподключения, если соединение потеряно. Один хаб просто делает это проще. Если вы не будете осторожны, вы увидите 3 диалоговых окна с надписью "Соединение потеряно. Повторить попытку? Я переключаюсь на один хаб только из-за этого.

В то время как я ненавижу смешивать все, частичные классы помогают, и у меня все равно нет многих методов SignalR.

Решение № 2

Это относится только к отладке и предполагает, что вы используете сертификат https, который вы подписали самостоятельно.

Вместо этого используйте что-то вроде letsencrypt или Cloudflare argo tunnel, чтобы получить публично доверенный сертификат. Safari полностью доверяет этому, поэтому ваши подключения будут обновлены до реальных веб-сокетов.

Решение № 3

Создайте самоподписанный ROOT-сертификат (CA), а затем сгенерируйте SSL-сертификаты с именем домена из него.

Это было сложнее, чем я себе представлял. В итоге оказалось, что мне не хватает Subject Type=CA в моем корневом сертификате - что требует iOS. Без этого "расширения" он будет устанавливать ваш корневой сертификат в качестве профиля, но не позволит вам выбрать его для SSL.

После установки корневого сертификата Safari будет отлично работать с веб-сокетами.

Решение № 4

Используйте только http. Это не вариант для меня, потому что я использую определенные API, такие как Facebook/Google/Payment, и они требуют https.

Заметки

Важно: теперь рассмотрим производство. Поймите, что веб-сокеты могут быть недоступны по разным причинам, поэтому, если у вас есть 4 концентратора, подключенных на iOS, это все равно может привести к блокировке. Ты живешь опасно.

Лучше использовать один хаб в первую очередь. НО также лучше установить ваш сертификат правильно, чтобы iOS работала с веб-сокетами.

Как создать и установить самоподписанные сертификаты X.509 в Windows 10 без участия пользователя?