Несколько соединений с сетевыми соединениями

Question

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

Answer 1

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

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

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

Answer 2

Я в настоящее время ищут решение, связанное с двумя соединениями с одним и тем же веб-сайтом. Моя причина:

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

Answer 3

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

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

http://myserver/api/some-elements 

Вы можете подписаться на обновления одного элемента с помощью торцевого URL вроде этого:

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

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