websocket - nodejs - Lo que es mejor: puntos finales múltiples de socket web o punto final de socket web único en Java EE7
websocket php (2)
La única respuesta válida aquí es la última opción: tener múltiples puntos finales.
Ver WebSocket spec chaper 2.1.3:
La API limita el registro de MessageHandlers por sesión para que sea un MessageHandler por tipo de mensaje websocket nativo. [WSC 2.1.3-1] En otras palabras, el desarrollador solo puede registrar como máximo un MesageHandler para mensajes de texto entrantes, un MessageHandler para mensajes binarios entrantes y un MessageHandler para mensajes de pong entrantes. La implementación de websocket debe generar un error si se infringe esta restricción [WSC 2.1.3-2].
En cuanto a usar o no usar conexiones TCP múltiples: AFAIK actualmente habrá una nueva conexión para cada cliente y no hay una manera fácil de cómo forzar algo más. La multiplexación WebSocket debería resolverlo, pero no creo que ninguna implementación de WebSocket API lo respalde (podría estar equivocado ...)
Java EE 7 le permite crear nuevos puntos finales muy fácilmente a través de anotaciones. Sin embargo, me preguntaba si tener varios puntos finales para manejar cada tipo de mensaje es una buena idea o si solo tengo una fachada de punto final para todo.
Me inclino por tener una única fachada de punto final basada en la teoría de que cada punto final crea una nueva conexión de socket para el cliente. Sin embargo, esa teoría podría ser incorrecta y Web Socket podría implementarse para que use solo una conexión de socket TCP / IP sin importar cuántos extremos de conexión web estén conectados siempre que se conecten al mismo host: puerto.
Pregunto específicamente por Java EE 7, ya que puede haber otras implementaciones de servidor de socket web que pueden hacer las cosas de manera diferente.
Recién noté una ambigüedad en mi pregunta sobre los tipos de mensajes. Cuando digo tipos de mensaje me refería a diferentes tipos de mensajes de aplicaciones, no a tipos de mensajes nativos, como "binario" o "texto". Como tal, marqué @PavelBucek como la respuesta aceptada.
Sin embargo, probé un experimento con Glassfish y tuve dos puntos finales. Mis sospechas eran correctas y que hay una conexión TCP establecida por punto final conectado. Esto causaría más carga en el lado del servidor si hay más de un punto final websocket en una sola página.
Como tal, llegué a la conclusión de que solo debe haber un punto final para manejar los mensajes de la aplicación, siempre que todo sea un único tipo nativo.
Esto significa que la aplicación necesita realizar el envío en lugar de confiar en una API de nivel superior para que lo haga por nosotros.