Есть ли какие-либо преимущества наличия двух разных подключений websocket к одному и тому же серверу от одного и того же клиента? Для меня это кажется плохим выбором дизайна, но есть ли причина, почему/где он должен работать лучше?
Несколько соединений в сети.
Ответ 1
Есть несколько причин, почему вы можете это сделать, но они, вероятно, не слишком распространены (по крайней мере, пока):
- У вас есть как зашифрованные, так и незашифрованные данные, которые вы отправляете/принимаете (например, некоторые из данных являются громоздкими, но не чувствительными).
- У вас есть как потоковые данные, так и данные, чувствительные к задержкам: представьте себе интерактивную игру, которая иногда транслирует видео в игре. Вы не хотите, чтобы большие медиапотоки задерживали получение чувствительных к латентности нормальных игровых сообщений.
- У вас есть как текстовые (например, управляющие сообщения JSON), так и двоичные данные (типизированные массивы или капли), и вы не хотите беспокоиться о добавлении своего собственного уровня протокола, чтобы отличить его, поскольку WebSockets уже делает это для вас.
- У вас есть несколько суб-протоколов WebSocket (дополнительный параметр после URI), которые вы поддерживаете, и страница хочет получить доступ к более чем одному (каждое подключение к WebSocket ограничено одним под-протоколом).
- У вас есть несколько разных служб WebSocket, расположенных за одним и тем же веб-сервером и портом. Способ, который клиент выбирает для каждого соединения, может зависеть от пути URI, схемы URI (ws или wss), суб-протокола или, возможно, даже первого сообщения от клиента к серверу.
Я уверен, что есть и другие причины, но все, что я могу придумать с головы.
Ответ 2
В настоящее время я ищу решение для двух соединений с одним и тем же веб-узлом. Моя причина:
- Я написал тестовый пример в QUnit и хочу имитировать несколько клиентов и проверить разные клиенты для правильных ответов
Ответ 3
Я обнаружил, что он может сделать клиентскую логику намного проще, когда вы только подписываетесь на обновления определенных объектов, управляемых сервером. Вместо того, чтобы разрабатывать собственный протокол подписки для одного канала, вы можете просто открыть сокет для каждого элемента.
Скажем, вы получили коллекцию элементов через REST API в
http://myserver/api/some-elements
Вы можете подписаться на обновления одного элемента, используя такой URL-адрес сокета:
ws://myserver/api/some-elements/42/updates
Конечно, можно утверждать, что это не масштабируется для сложных страниц. Однако для небольших и простых приложений это может сделать вашу жизнь намного легче.