Несколько веб-сокетов

Question

Есть ли какие-либо преимущества наличия двух разных подключений веб-сокетов к одному и тому же серверу от одного и того же клиента?Мне кажется, это плохой выбор дизайна, но есть ли причина, почему / где он должен работать лучше?

Answer 1

Есть несколько причин, по которым вы могли бы хотеть это сделать, но они, вероятно, не слишком распространены (по крайней мере, пока):

• У вас есть как зашифрованные, так и незашифрованные данные, которые вы отправляете / получаете (например, некоторые данные громоздки, но не конфиденциальны).
• У вас есть как потоковые данные, так и данные, чувствительные к задержке: представьте интерактивную игру, в которой время от времени потоковое видео транслируется внутри игры. Вы не хотите, чтобы большие медиапотоки задерживали получение чувствительных к задержке обычных игровых сообщений.
• У вас есть как текстовые (например, управляющие сообщения JSON), так и двоичные данные (типизированные массивы или большие двоичные объекты), и вы не хотите беспокоиться о добавлении собственного уровня протокола, чтобы отличить его, поскольку WebSockets уже делает это за вас.
• У вас есть несколько подпротоколов WebSocket (необязательный параметр после URI), которые вы поддерживаете, и странице требуется доступ более чем к одному (каждое соединение WebSocket ограничено одним подпротоколом).
• У вас есть несколько разных сервисов WebSocket, расположенных за одним и тем же веб-сервером и портом. То, как клиент выбирает соединение, может зависеть от пути URI, схемы URI (ws или wss), суб-протокола или, возможно, даже первого сообщения от клиента к серверу.

Я уверен, что есть и другие причины, но это все, что я могу придумать из головы.

Answer 2

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

Допустим, вы получили коллекцию элементов через REST API на

http://myserver/api/some-elements

Вы можете подписаться на обновления одного элемента, используя URL-адрес сокета, например:

ws://myserver/api/some-elements/42/updates

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

Answer 3

В настоящее время я ищу решение для двух соединений с одним и тем же веб-сокетом. Моя причина:

• Я написал тестовый пример в QUnit и хочу смоделировать несколько клиентов и проверить правильность ответов на разных клиентах