Si el cliente es un navegador, entonces las ÚNICAS dos formas en que un navegador estándar puede conectarse a un servidor es a través de una solicitud Ajax (por ejemplo, http) o una conexión webSocket. Entonces, si desea que un cliente reciba una notificación de algo del mundo exterior, debe usar uno de esos dos mecanismos.

Las solicitudes HTTP son transitorias. El cliente hace una solicitud de un servidor, el servidor responde. Las solicitudes HTTP son perfectas para el cliente que solicita información del servidor. No son muy buenos para que el servidor envíe información al cliente porque normalmente el cliente no está conectado. Hay trucos y soluciones en los que el cliente "sondea" al servidor en algún intervalo y tal vez incluso el servidor usa solicitudes de ejecución más largas para intentar simular un sistema de tipo "push", pero en el mejor de los casos son trucos subóptimos.

webSockets son conexiones continuas. El cliente se conecta y la conexión se mantiene durante el tiempo que ambas partes deseen. Esto le permite a cualquiera de los lados la capacidad de enviar un mensaje al otro lado cuando lo deseen. Eso significa que el servidor puede "enviar" datos al cliente cuando lo desee. Los webSockets son eficientes para las conexiones push y se recomiendan (esta es una de las cosas principales para las que fueron diseñados).

Comet es una biblioteca que se creó originalmente para usar HTTP para intentar "piratear" o "simular" la inserción antes de que se inventaran los webSockets y luego antes de que fueran ampliamente compatibles. No puedo pensar en ninguna razón por la que uno quiera usar Comet en lugar de un webSocket a menos que tenga un navegador tan antiguo que webSocket no sea compatible.

Por lo tanto, si está tratando de hacer un "empuje del servidor en tiempo real" a un navegador, entonces debe tener un socket conectado continuamente desde el cliente, lo que significa webSocket (o algo construido sobre webSocket como socket.io).

Para las aplicaciones telefónicas en las que tiene acceso al SDK del teléfono, puede usar el sistema "push" integrado en el sistema operativo para enviar algunos mensajes del servidor al cliente. Esto no es lo mismo que el canal webSocket bidireccional, pero dado que usted preguntó acerca de las "notificaciones automáticas", los servicios de inserción del sistema operativo disponibles tanto en Android como en IOS también podrían ser una opción para enviar notificaciones del servidor al cliente. Aquí hay información sobre las notificaciones de iOS y Google Cloud Messaging

A partir de 2016, también se pueden usar eventos enviados por el servidor en todos los navegadores modernos, excepto en los navegadores de Microsoft (aún no compatibles con Edge o IE) para enviar datos del servidor al cliente. Aquí hay una tabla de compatibilidad de navegadores . Los eventos enviados por el servidor utilizan una conexión HTTP de larga duración, un tipo MIME especial y un cliente compatible para poder enviar eventos del servidor al cliente en cualquier momento. A diferencia de webSockets, los eventos enviados por el servidor son unidireccionales (del servidor al cliente). Luego, un cliente usaría una llamada Ajax tradicional para poder enviar datos a un servidor (mientras que con un webSocket, los datos se pueden enviar de cualquier manera a través de la misma conexión webSocket).

Aquí hay una buena descripción de cómo funcionan los eventos enviados por el servidor: ¿Cómo funcionan realmente los eventos enviados por el servidor?

¿La aplicación de su cliente es un SPA? (aplicación de una sola página)? Es muy importante porque si no, hay que tener en cuenta que cada vez que un cliente cambie de página, se perderá la conexión con el servidor websocket. En este caso, debe administrar una cola porque si las partes interesadas envían una solicitud de multidifusión cuando un cliente está desconectado, el cliente no recibirá nada. El sondeo tampoco resolverá esta situación y es una solución excelente porque los clientes móviles (por ejemplo) con un plan de Internet típico consumirán megabytes por tráfico de "ping" inútil. Un ejemplo real de sondeo es un niño en un automóvil que le pregunta a su padre cada minuto si llegó a un destino. Entonces, ¿hay una solución sin usar spa? Sí, usando un "almacenamiento compartido" entre las partes interesadas y los clientes, y usando websocket solo para "despertar" a los clientes en línea diciendo: ¡Oye, hay algo nuevo, ve a comprobarlo!

Cada vez que un cliente abra una página, recibirá del backend también notificaciones de no lectura, tomadas del almacenamiento. Cuando una parte interesada quiere notificar algo, simplemente almacenará el mensaje de notificación en el almacenamiento compartido y enviará un "pulso" al servidor de notificación. El servidor de notificaciones enviará el "pulso" a los clientes en línea (en caso de que alguien se quede atascado leyendo una página). Si se pierde un "pulso" porque un cliente está cambiando de página no hay problema porque el cliente traerá notificaciones del almacenamiento. Cada página contendrá esta lógica: Recuperar número o notificaciones no leídas (lado del servidor) Conectarse al servidor de notificaciones después de 5 segundos (lado de javascript). Espero eso ayude.

Sugeriría que usar webSockets es una forma más eficiente en comparación con otras opciones, ¿por qué? Bueno, cuando un cliente recibe una notificación de que hay un cambio en el servidor, no es necesario crear una llamada AJAX al servidor para obtener ese cambio, se puede enviar al cliente con la misma conexión webSocket más fácilmente que AJAX. ¡Esto significa un código eficiente y una aplicación que se ejecuta más rápido!