Notificaciones de progreso del servicio HTTP / REST

Question

Estoy trabajando en una aplicación web que envía tareas a un sistema maestro / trabajador que aglutina las tareas a cualquiera de una serie de instancias de trabajo. El maestro de la cola de trabajo se ejecuta como un proceso separado (en una máquina completamente diferente) y las tareas se envían al maestro a través de solicitudes HTTP / REST. Una vez que las tareas se envían a la cola de trabajo, las aplicaciones cliente pueden enviar otra solicitud HTTP para obtener información sobre el estado de las tareas.

Para mi aplicación web, me gustaría que proporcione algún tipo de vista de barra de progreso que le dé al usuario alguna indicación de qué tan avanzado ha avanzado el procesamiento de la tarea. La forma obvia de implementar esto sería un widget de medidor de progreso AJAX que sondea periódicamente la cola de trabajo para conocer el estado de las tareas que se han enviado. Mi pregunta es, ¿hay una mejor manera de lograr esto sin las encuestas frecuentes?

He considerado que la aplicación web del cliente abra un socket del servidor en el que pueda escuchar las notificaciones del maestro de trabajo. Otro pensamiento similar que he tenido es usar XMPP o un protocolo similar para las notificaciones de estado. (Por supuesto, el sistema maestro / trabajador necesitaría actualizarse para proporcionar notificaciones de cualquier manera, pero soy dueño del código para eso, así que puedo hacer las actualizaciones necesarias yo mismo).

¿Alguna idea sobre la mejor manera de configurar un sistema de notificación como este? ¿Vale la pena el esfuerzo adicional involucrado, o es la solución de sondeo simple el camino a seguir?

Answer 1

Supongo que depende de algunos factores

• Qué tan precisa puede ser la retroalimentación (1 por ciento, 5 por ciento, 50 por ciento). La retroalimentación precisa hace que valga la pena buscar algún tipo de barra de progreso y empuje de estilo cometa. Si solo puedes decir "Ocupado ... espera ... casi allí ... hecho" entonces un simple ajax "estamos ahí todavía" la encuesta es ciertamente más fácil de codificar.
• Qué tan oportuno el cliente debe ver el mensaje Hecho
• Cuánto tiempo lleva cada tarea (1 segundo, 10 segundos, 10 minutos)
  1 segundo hace que sea un poco discutible. 10 segundos hacen que valga la pena. 10 minutos significa que es mejor sugerirle al usuario que tome un descanso para tomar café :-)
• ¿Cuántas solicitudes concurrentes habrá
  A menos que tenga un "especial" servidor, los sistemas de estilo de inserción en vivo tienden a comer conexiones y se maximizará bastante rápido. Tener que lanzar más servidores web para obtener una barra de progreso elegante podría dañar el presupuesto.

Tengo un código de muestra en 871184 que muestra una mano enrollada " marco para siempre " que parece funcionar bien Sin embargo, el proyecto que desarrollé para eso no es tan difícil, las operaciones toman unos segundos y podemos dar un porcentaje bastante preciso. El código usa asp.net y jquery, pero las técnicas generales funcionarán con cualquier servidor y framework javascript.

editar como John señala, el informe de estado probablemente no sea el trabajo del servicio RESTful. Pero no hay nada que diga que no puede abrir un iframe en el cliente que se conecta a una página en el servidor que sondea el servicio. La teoría dice que el servidor y el servicio al menos estarán más cerca uno del otro :-)

Answer 2

Sondeo

El cliente sigue sondeando el servidor para obtener el estado de la respuesta.

Pros

• Ser realmente RESTful significa almacenable en caché y escalable.

Contras

• No es la mejor capacidad de respuesta si no desea sondear demasiado su servidor.

---

Conexión persistente

El servidor no cierra su conexión HTTP con el cliente hasta que se completa la respuesta. El servidor puede enviar el estado intermedio a través de esta conexión usando HTTP multiparts.

Comet es el marco más famoso para implementar este comportamiento.

Pros

• Mejor capacidad de respuesta, notificaciones casi en tiempo real desde el servidor.

Contras

• El límite de conexión está limitado en un servidor web, mantener una conexión abierta durante demasiado tiempo podría, en el mejor de los casos, cargar su servidor, en el peor de los casos abrir el servidor a ataques de Denegación de Servicio.

---

Cliente como servidor

Haga que el servidor publique actualizaciones de estado y la respuesta al cliente como si fuera otra aplicación RESTful.

Pros

• Lo mejor de todos los mundos, no se desperdician recursos esperando la respuesta, ya sea en el servidor o en el lado del cliente.

Contras

• Necesita un servidor HTTP completo y una pila de aplicaciones web en el cliente
• Cortafuegos y enrutadores con su predeterminado "no hay conexiones entrantes en absoluto" se interpondrá en el camino.

---

¡Siéntase libre de editar para agregar sus pensamientos o un nuevo método!

Answer 3

Mi opinión es seguir con la solución de sondeo, pero es posible que le interese este artículo de Wikipedia sobre HTTP Empuje tecnologías.

Answer 4

REST depende de HTTP, que es un protocolo de solicitud / respuesta. No creo que vaya a obtener un servidor HTTP puro que vuelva a llamar al cliente con estado.

Además, los informes de estado no son el trabajo del servicio. Depende del cliente decidir cuándo o si desea que se informe el estado.

Answer 5

Busque Comet . Realiza una única solicitud al servidor y el servidor bloquea y mantiene la conexión abierta hasta que se produce una actualización en el estado. Una vez que eso sucede, la respuesta se envía y se confirma. El navegador recibe esta respuesta, la maneja e inmediatamente vuelve a solicitar la misma URL. El efecto es el de los eventos que se envían al navegador. Hay ventajas y desventajas y puede que no sea apropiado para todos los casos de uso, pero proporcionaría las actualizaciones de estado más oportunas.

Answer 6

También podría usar un iframe de actualización automática, pero la llamada AJAX es mucho mejor. No creo que haya otra manera.

PD: Si abriera un socket desde el cliente, eso no cambiaría mucho: el navegador PHP mostraría la página como todavía "cargando", lo que no es muy fácil de usar. (suponiendo que empuje o vacíe el búfer para mostrar otras cosas antes)