Ограничения на соединение и передовые методы связи SignalR/Websockets

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

Я прочитал всю литературу по IIS/ASP.NET относительно "параллельных подключений к Websocket" и как настроить различные значения. Однако, когда речь идет о веб-сайтах, каково определение "одновременный"? Если я открыл websocket и его сидение без дела, то это "использование" соединения? Делают ли простаивающие веб-сайты подсчетом в отношении итогов использования соединений или они учитываются только при отправке/получении сообщения?

Я ожидаю, что в один момент откроется очень большое (100 000 000) количество веб-сайтов, однако будет отправлено очень мало сообщений, возможно, несколько минут, и они всегда будут сервером- > клиентом (и один, конкретный клиент, а не широковещательная передача). Должно ли/быть это соглашение привести меня к какому-либо конкретному пути реализации?

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

Ответы

Ответ 1

однако, когда речь идет о websockets, каково определение "Одновременно"? Если я открываю веб-узел и его свободное место, что "использование" соединения? Делать незадействованные веб-карты подсчитывать подключение или подсчитывается только тогда, когда сообщение отправлено/получено?

Правильно, свободное время ожидания сеанса связи не потребляет много ресурсов за пределами TCP-авитов и, возможно, пинг/понг на уровне протокола и/или приложения, если ваш сервер их поддерживает. Что еще более важно, поскольку Websockets являются ориентированными на соединение, вы можете удерживать некоторое состояние, связанное с соединением (пользовательский объект, пользовательские данные и т.д.)

Я ожидаю, что у вас будет очень высокое (100 000 000) количество веб-сайтов открываться в любой момент времени, однако будет отправлено очень мало сообщений, возможно, несколько минут, и они всегда будут server- > client (и к одному, конкретному клиенту, а не к широковещательной передаче). Должно ли это договоренность привела меня к какому-либо конкретному пути реализации?

Да, к маршруту, не использующему SignalR: SignalR Scale-out (проверьте раздел ограничений). Используйте WebSockets напрямую и реализуйте свой собственный сервер обмена сообщениями с помощью фреймворка, который позволяет использовать интеллектуальную маршрутизацию, например RabbitMQ. Вы не хотите использовать объединительную плату, которая в основном делает "разветвление" для всех узлов, особенно если данные для каждого пользователя.

SignalR - это polyfill, временная структура до тех пор, пока не будут широко поддерживаться WebSockets... и это уже произошло. Также забыл упомянуть, что WebSockets доступны с сервера Windows 2012 и далее:)