Уведомления о прогрессе от службы HTTP / REST

Question

Я работаю над веб-приложением, которое отправляет задачи в систему мастер / работник, которая группирует задачи в любой из серии рабочих экземпляров. Мастер рабочей очереди выполняется как отдельный процесс (в целом на отдельном компьютере), а задачи передаются мастеру через запросы HTTP / REST. После того, как задачи отправлены в рабочую очередь, клиентские приложения могут отправить еще один HTTP-запрос для получения информации о состоянии задач.

Для моего веб-приложения мне бы хотелось, чтобы он представлял какой-то вид индикатора выполнения, который дает пользователю некоторое представление о том, как далеко продвинулась обработка задач. Очевидным способом реализации этого может быть виджет индикатора прогресса AJAX, который периодически опрашивает рабочую очередь на предмет состояния по представленным задачам. У меня вопрос, есть ли лучший способ сделать это без частых опросов?

Я подумал, чтобы клиентское веб-приложение открывало сокет сервера, на котором оно могло прослушивать уведомления от мастера работ. Еще одна похожая мысль, которая у меня была, - это использовать XMPP или аналогичный протокол для уведомлений о состоянии. (Конечно, система master / worker должна быть обновлена ​​для предоставления уведомлений в любом случае, но я владею кодом для этого, так что могу сам выполнить любые необходимые обновления.)

Есть какие-нибудь мысли о том, как лучше настроить систему уведомлений, подобную этой? Стоит ли прилагать дополнительные усилия или это простое решение для опроса?

Answer 1

Опрос

Клиент продолжает опрашивать сервер, чтобы получить статус ответа.

Плюсы

• Быть действительно RESTful означает кешируемый и масштабируемый.

Против

• Не самая лучшая скорость отклика, если вы не хотите слишком много опрашивать ваш сервер.

---

Постоянное соединение

Сервер не закрывает свое HTTP-соединение с клиентом до тех пор, пока ответ не будет завершен. Сервер может отправлять промежуточное состояние через это соединение, используя HTTP множественные числа.

Comet - самая известная структура для реализации этого поведения.

Плюсы

• Лучшая отзывчивость, почти в режиме реального времени уведомления от сервера.

Против

• Ограничение на подключение к веб-серверу ограничено, так как длительное открытие соединения может привести к лучшей загрузке сервера, а в худшем - открыть сервер для атак отказа в обслуживании.

---

Клиент как сервер

Выполните обновления состояния сервера и ответ клиенту, как если бы это было другое приложение RESTful.

Плюсы

• Лучший из всех миров, ресурсы не тратятся впустую в ожидании ответа ни на сервере, ни на стороне клиента.

Против

• Вам нужен полный HTTP-сервер и стек веб-приложений на клиенте
• Брандмауэры и маршрутизаторы с их настройками по умолчанию «вообще не входящие соединения» будут мешать.

---

Не стесняйтесь редактировать, чтобы добавить свои мысли или новый метод!

Answer 2

Я думаю, это зависит от нескольких факторов

• Насколько точной может быть обратная связь (1%, 5%, 50%).
  Точная обратная связь делает возможным использование какого-то индикатора прогресса и кометного толчка. Если вы можете только сказать «Занят ... держись ... почти там ... готово", тогда простой ajax "мы еще там", опрос, конечно, легче кодировать.
• Как своевременно клиент должен видеть сообщение «Готово»
• Сколько времени занимает каждое задание (1 секунда, 10 секунд, 10 минут)
  1 секунда делает это немного спорным. 10 секунд того стоит. 10 минут означают, что вам лучше предложить кофе-брейку: -)
• Сколько будет параллельных запросов
  Если у вас нет «специального» сервера, системы в режиме «живого пуша», как правило, используют соединения, и вы довольно быстро получите максимальную отдачу. Необходимость добавить больше веб-серверов для создания фантастического индикатора выполнения может повредить бюджету.

У меня есть пример кода на 871184 , который показывает раскрученный вручную " forever frame ", который, кажется, работает хорошо. Проект, для которого я разработал этот проект, не очень сложен, хотя операции занимают несколько секунд, и мы можем дать довольно точный процент. Код использует asp.net и jquery, но общие методы будут работать с любым сервером и инфраструктурой javascript.

edit Как указывает John , создание отчетов о состоянии, вероятно, не является задачей службы RESTful. Но ничто не говорит о том, что вы не можете открыть iframe на клиенте, который подключается к странице на сервере, который опрашивает службу. Теория говорит, что сервер и сервис будут, по крайней мере, ближе друг к другу: -)

Answer 3

Посмотрите на Комету . Вы делаете один запрос к серверу, и сервер блокирует и держит соединение открытым, пока не произойдет обновление статуса. Как только это произойдет, ответ будет отправлен и передан. Браузер получает этот ответ, обрабатывает его и немедленно повторно запрашивает тот же URL. В результате события помещаются в браузер. Есть плюсы и минусы, и это может не подходить для всех случаев использования, но обеспечит наиболее своевременное обновление статуса.

Answer 4

REST зависит от HTTP, который является протоколом запроса / ответа. Я не думаю, что вы получите чистый HTTP-сервер, который будет перезванивать клиенту со статусом.

Кроме того, создание отчетов о состоянии не является задачей службы. Клиент должен решить, когда или если он хочет сообщить о состоянии.

Answer 5

Мое мнение - придерживаться решения для опроса, но вас может заинтересовать эта статья в Википедии о HTTP Push технологиях.

Answer 6

Вы также можете использовать самообновляющийся iframe, но вызов AJAX намного лучше. Я не думаю, что есть другой способ.

PS: Если вы откроете сокет от клиента, это не сильно изменится - браузер PHP покажет страницу как «загружающуюся», что не очень удобно для пользователя. (при условии, что вы нажмете или очистите буфер, чтобы другие вещи отображались раньше)