websocket - tutorial - Engine.io o SockJS, ¿cuál elegir?
socket.io client (3)
He tenido problemas con Socket.io con respecto a fugas de memoria y problemas de escalado últimamente. Mi decisión de usar Socket.io se tomó hace más de un año cuando, sin duda, fue la mejor biblioteca que pude usar.
Ahora que Socket.io causa muchos problemas, pasé un tiempo buscando alternativas que estuvieron disponibles mientras tanto y creo que tanto Engine.io como SockJS son generalmente adecuados para mí. Sin embargo, en mi opinión, ambos tienen algunas desventajas y no estoy seguro de cuál elegir.
Engine.io es básicamente la versión liviana perfecta de Socket.io que no contiene todas las características que no necesito de todos modos. Ya he escrito mi propia lógica de reconexión y latido para Socket.io, porque no estaba satisfecho con las lógicas predeterminadas y nunca tuve la intención de usar las habitaciones u otras características que ofrece Socket.io.
Pero, en mi opinión, la principal desventaja de Engine.io es la forma en que se establecen las conexiones. Los clientes comienzan con un jsonp-sondeo más lento y se actualizan si admiten mejores transportes. El hecho de que los clientes que soportan websockets de forma nativa (número cada vez mayor) tienen una desventaja en forma de un procedimiento de conexión más largo e inestable sobre aquellos clientes que utilizan navegadores desactualizados, contradice mi percepción de cómo debería manejarse.
SockJS, por otro lado, maneja las conexiones exactamente como me gustaría. Por lo que he leído, parece bastante estable, mientras que Engine.io tiene algunos problemas en este momento.
Mi aplicación se ejecuta detrás de un enrutador Nginx en un solo dominio, por lo tanto, no necesito la funcionalidad de dominio cruzado que SockJS ofrece. Sin embargo, al proporcionar esta funcionalidad, SockJS no expone los datos de las cookies del cliente. Hasta el momento, tenía una autorización de 2 factores con Socket.io a través de la cookie AND token de cadena de consulta y esto no sería posible con SockJS (con Engine.io lo haría).
He leído prácticamente todo lo que se puede consultar, y los pros y los contras de ambos, pero parece que no se está debatiendo o publicando mucho hasta el momento, especialmente sobre Engine.io (aquí solo hay 8 preguntas etiquetadas con engine.io).
¿Cuál de las 2 bibliotecas prefiere y por qué motivo? ¿Los usas en producción?
¿Cuál será probablemente mantenido más activamente y podría tener una gran ventaja sobre el otro en el futuro?
¿Has mirado a Primus ? Ofrece los requisitos de cookies que menciona, admite todas las major bibliotecas disponibles en tiempo real / websocket y es un proyecto bastante activo. Para mí, también parece que el bloqueo de un proveedor podría ser una preocupación para usted y Primus se encargaría de eso.
El hecho de que utilice un sistema de complemento también debería a) facilitar la ampliación si es necesario yb) tener un complemento de la comunidad que ya haga lo que necesita.
¿Cuál de las 2 bibliotecas prefiere y por qué motivo? ¿Los usas en producción?
Solo he usado SockJS a través de la API Vert.x y fue para un proyecto interno que consideraría ''producción'', pero no como una aplicación de consumo de cara a la producción. Dicho eso, funcionó muy bien.
¿Cuál será probablemente mantenido más activamente y podría tener una gran ventaja sobre el otro en el futuro?
Solo mirando el historial de Engine.io de Engine.io y SockJS , y el hecho de que Auttomatic esté apoyando a Engine.io, me inclino a pensar que será más estable, por un período de tiempo más largo, pero por supuesto es discutible. Ver los problemas de Engine.io y SockJS es otro buen lugar para evaluar, pero dado que ambos están divididos en varios repositorios, se debe tomar con un grano de sal. No estoy seguro de dónde / cómo Automattic está utilizando Engine / Socket.io, pero si está en WordPress.com o uno de sus complementos, tiene pruebas sustanciales de producción a escala.
editar: cambiar la respuesta para reflejar el soporte de cookies confirmado por el autor de Primus en los comentarios a continuación
Me gustaría redirigirlo a este hilo de discusión (bastante detallado) sobre SockJS y Engine.io
https://groups.google.com/forum/#!topic/sockjs/WSIdcY14ciI
Básicamente,
SockJS detecta los transportes de trabajo antes de marcar la conexión como abierta. Engine.io inmediatamente abrirá la conexión y la actualizará más tarde.
flash , uno de los retrocesos de Engine.io (y no presente en SockJS) se carga lentamente y en entornos detrás de proxies tarda 3 segundos para el tiempo de espera.
SockJS no usa flash y, por lo tanto, no necesita evitar este problema.
SockJS hace la actualización al inicio. Después de eso tienes una experiencia consistente. Envía lo que envía, recibe lo que recibe.
Además, por lo que puedo decir, la biblioteca engine.io-client (del lado del cliente) de engine.io no admite builds de requirejs, por lo que ese es otro punto negativo. (SockJS construye perfectamente).
También puedes considerar node-walve . Completo WebSocket básico. Muy eficiente ya que se basa completamente en la transmisión.
Ejemplo de cómo usar:
walve.createServer(function(wsocket) {
wsocket.on(''incoming'', function(incoming) {
incoming.pipe(process.stdout, { end: false });
});
}).listen(server);
Puede que no sea la mejor opción si no te sientes seguro en el entorno del nodojs (por ejemplo, extendiendo prototipos para azúcar API), contribuyendo al proyecto (aunque el código es más legible como socket.io).