Эффективное управление подключениями SignalR

[@GREGOR_812]

Расскажите, пожалуйста, поподробнее, почему Redis — плохая идея? Вроде как это решение идёт в коробке, ну или почти в коробке с SignalR

[@aesamson]

Redis хорошо справляется с синхронизацией вызовов исходящих от хаба, и это рекомендуемый способ синхронизации.

Однако для хранения списка подключений по каждому клиенту Redis неудобен:

1. В процессе работы приходится делать выборки как по клиенту, так и по группе. Отсюда двоякость ключей. Это неудобно.
2. Нет простой и надежной стратегии управления жизненным циклом записи: с одной стороны записи должны протухать, с другой стороны мы не должны удалять записи, по которым есть живое соединение, но нет активности.
3. Достаточно много операций записи одновременно с операциями чтения, придётся бороться с коллизиями.

[@GREGOR_812]

Спасибо! Жду продолжения, интересны способы горизонтального масштабирования SignalR без применения Redis)

[@spbsmile]

Добрый день! У меня пара вопросов, возможно глупых.

1) У меня mvc проект, не spa. Хочу использовать в нем signalr. Подключение клиента к хабу идет от js.

$.connection.hub.start().done(function() {

Если один и тот же пользователь будет переключаться, бегать по меню сайта, то будет каждый раз вызываться $.connection.hub.start().done(function() {. Это нормально? Тут нет оверхада? А если пользователей много…

2) Были ли у вас проблемы с протуханием, когда signalr перестает работать, и как вы их решали? p.s Юзер закрыл ноут, через день открыл — а signalr отвалился.

[@aesamson]

Добрый вечер,

Давайте обо всем по порядку.
Когда устанавливается соединение, оно занимает ресурсы системы. Это память и открытые порты. В случае если соединение часто рвется, то эти ресурсы будут удерживаться определенное время. На это время влияют как настройки системы, так и настройки сервера SignalR. И если память не критичный ресурс, то ресурс портов весьма ограничен — их всего 2^16 на каждый ip адрес. Поскольку клиенты подключаются к одному адресу, в случае использования reverse proxy, этот лимит не выглядит таким уж и большим. Проблема тем более усугубится в случае постоянных обрывов соединения со стороны клиента.

Что бы избежать этой ситуации, необходимо корректно завершать соединения со стороны клиента или по-возможности снизить значения KeepAliveInterval и ClientTimeoutInterval.

По поводу протухания — возможно при закрытии ноута обрывается связь с сервером, в таком случае в соответствии со значением параметра ClientTimeoutInterval связь будет принудительно разорвана. Клиент при этом получит уведомление на onclose.