¿Cuáles son las ventajas y desventajas de las diferentes arquitecturas de cometas?

Realmente depende de lo que quieras obtener de tu servidor Comet (programación). No puedo proporcionar una comparación específica entre el servidor Comet, pero puedo dar mi opinión sobre qué buscar.

Si la entrega de datos de Real-Time Systems es importante, elija una solución Comet que utilice un mecanismo de transporte con baja latencia. Las encuestas no son la mejor solución aquí. La mejor solución es un transporte que mantenga una conexión entre el cliente (generalmente el navegador web) y el servidor. Esto significa que en el instante en que una nueva pieza de datos está disponible para el servidor, se puede enviar al cliente conectado. Si el transporte es una solución de sondeo, habrá brechas entre los intervalos de sondeo donde los datos están obsoletos.

Las buenas soluciones de Comet en mi opinión tendrán una estrategia de conexión inteligente.

1. Intente conectarse utilizando WebSockets ya que es el tipo de conexión más eficiente en términos de sobrecarga de conexión y recursos de socket, ya que utiliza una conexión de socket único.
2. Intente establecer una conexión de transmisión HTTP entre el cliente y el servidor. Esto usará dos conexiones HTTP. La primera será una conexión persistente para permitir la entrega de datos en tiempo real y la segunda se utilizará para enviar comandos al servidor, como solicitudes de suscripción.
3. Vuelva a la opción menos eficiente de HTTP Long-Polling del servidor para actualizaciones.

El límite de 2 conexiones es un problema en navegadores antiguos y puede ser considerado. La solución más simple en mi opinión aquí es crear múltiples entradas DNS que finalmente apunten al mismo servidor. Una buena arquitectura Comet permitirá definir una estrategia de conexión de equilibrio de carga y conmutación por error, lo que permitirá solucionar fácilmente cualquier problema de límite de conexión.

Una consideración ahora es si los clientes Comet admiten conexiones entre dominios. En el pasado esto no era posible en JavaScript, pero CORS (Cross Origin Resource Sharing) lo ha hecho posible y seguro. Esto reduce la necesidad de alojar su propio servidor en su propio dominio y la necesidad de meterse con las entradas DNS.

La gestión de sesión puede ser realmente útil en términos de comprobación de sesión duplicada. Donde se puede agregar valor real es cuando se cae una conexión y luego se restablece y se puede reanudar una sesión desde donde se dejó caer. Esto significa que no es necesario volver a emitir las suscripciones realizadas. El cliente comenzará a recibir actualizaciones nuevamente en el canal / tema al que se había suscrito anteriormente.

Otras cosas a considerar fuera de mi cabeza son:

• Valor agregado en tecnologías de cliente como la reconexión, suscripción a múltiples canales / temas en una llamada API, conmutación por error configurable
• Número de conexiones simultáneas que el servidor puede manejar de manera eficiente. Cuantos más, mejor.
• Soporte para diferentes formas de enviar datos al servidor, como puntos API como REST
• Soporte de agrupamiento: la capacidad de agrupar servidores para compartir datos y permitir el escalado horizontal
• La forma en que se estructuran los datos en el servidor también puede ser muy importante según sus requisitos. ¿Está satisfecho con grandes bloques de XML (yuck) o desea suscribirse a canales / temas que se prestan a ser entregados de manera eficiente? Optaría por lo último como una mejor práctica y en realidad preferiría que una arquitectura Comet me obligara a pensar en la estructura de mis datos.