Múltiples conexiones de websocket

Question

¿Hay alguna ventaja de tener dos conexiones distintas de websocket con el mismo servidor del mismo cliente? Para mí, esto parece una mala elección de diseño, pero ¿hay alguna razón por la cual/donde debería funcionar mejor?

Answer 1

Hay varias razones por las que podría quieren hacer eso, pero que probablemente no son demasiado comunes (al menos por ahora):

• tanto ha cifrado y datos sin cifrar que está enviando/recepción (por ejemplo, algunos de los datos son voluminosos pero no sensibles).
• Tiene datos de transmisión y datos sensibles a la latencia: imagine un juego interactivo que de vez en cuando tiene videos transmitidos dentro del juego. No desea que los flujos de medios grandes retrasen la recepción de mensajes de juego normales sensibles a la latencia.
• Tiene texto (por ejemplo, mensajes de control JSON) y datos binarios (matrices o blobs tipados) y no quiere molestarse en agregar su propia capa de protocolo para distinguirlo, ya que WebSockets ya lo hace por usted.
• Tiene múltiples sub-protocolos WebSocket (la configuración opcional después del URI) que admite y la página quiere acceder a más de uno (cada conexión WebSocket está limitada a un solo sub protocolo).
• Tiene varios servicios WebSocket diferentes detrás del mismo servidor web y puerto. La forma en que el cliente elija por conexión puede depender de la ruta URI, el esquema URI (ws o wss), el sub protocolo, o quizás incluso el primer mensaje de cliente a servidor.

Estoy seguro de que hay otras razones, pero eso es todo lo que puedo pensar en la parte superior de mi cabeza.

Answer 2

Actualmente estoy buscando una solución para tener dos conexiones al mismo websocket. Mi razón:

• me escribió un caso de prueba en QUnit y quiero para simular varios clientes y comprobar los diferentes clientes para las respuestas correctas

Answer 3

he encontrado que puede hacer que la lógica de clientes mucho más simple cuando se solo se suscriben a actualizaciones de ciertos objetos administrados por el servidor. En lugar de diseñar un protocolo de suscripción personalizado para un solo canal, puede simplemente abrir un socket para cada elemento.

Digamos que usted obtuvo una colección de elementos a través de una API REST en

http://myserver/api/some-elements 

Usted puede suscribirse a las actualizaciones de un solo elemento utilizando una URL toma de la siguiente manera:

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

Por supuesto, uno puede argumentar que esto no escala para páginas complejas. Sin embargo, para aplicaciones pequeñas y simples, puede hacer su vida mucho más fácil.