Работа с добавочным ответом сервера в AJAX (в JavaScript)

Question

У меня есть приложение AJAX, которое обновляет страницу в зависимости от ответа сервера. Команда, на которой основан ответ сервера AJAX, занимает много времени для генерации полного ответа, но она отправляет частичную информацию, как только она рассчитывается. Этот частичный ответ / частичная информация отправляется в «пакете», а время и размер каждого пакета непредсказуемы. Сценарий CGI (на Perl), который передает выходные данные команды в веб-браузер (по запросу AJAX), имеет автоматическую очистку.

Ответ сервера основан на выводе внешней команды. В то время как time cmd> / dev / null дает в среднем около 10,0 секунд, time cmd | head> / dev / null дает менее 0,1 секунды (например, данные). Все данные являются результатом одного вызова этой внешней команды .

Ситуация выглядит следующим образом (диаграмма ASCII-art следует) :

 client |     | server
---------     ---------

request -\
          \
           \
            \
             \->

             /- response
            /      .
           /       .
          /  /-    .
       <-/  /      . 
           /       .
          /  /-  [end]
       <-/  /
           /
          /
       <-/

У меня есть несколько вопросов по этой проблеме.

Примечание: на стороне сервера выполняется как CGI-скрипт в Perl, и я предпочел бы видеть (также) решение без использования библиотеки / фреймворка JavaScript, таких как jQuery.

• Вывод команды, используемой на стороне сервера приложения AJAX, основан на строке. Каждая группа строк, начинающаяся с одного определенного типа линий и заканчивающаяся другим типом линий, состоит из независимых и неизменяемых данных. Должен ли я просто передавать ответ от команды как «text / plain» и выполнять обработку в JavaScript на стороне клиента, или я должен предварительно обработать данные на сервере и отправить целые куски данных в виде JSON, используя mimetype «application / json»?

• Может случиться так, что за большой порцией данных, отправленной сервером сразу, последует другая порция данных. Как справиться с ситуацией, когда обработчик onreadystatechange вызывается, когда предыдущий вызов не завершил работу? Должен ли я использовать глобальную переменную в качестве семафора или передать переменную состояния в качестве параметра обработчика (ну, используйте xhr.onreadystatechange = function() { handleRequest(xhr, state) })?

• Должен ли я использовать для этого «text / plain» или «application / json», или, возможно, «multipart / x0mixed-replace»? Примечание: это приложение должно работать (почти) в любом браузере.

• Как работать с веб-браузером (движки JavaScript), который вызывает onReadyStateChange только после получения полного ответа (поэтому я не вижу xhr.readyState == 3, т.е. частичный ответ более одного раза)? Ну, кроме использования некоторого фреймворка JavaScript.

• Как бороться с неполными ответами (которые в этой ситуации означают неполные строки).

• Должен ли я отправить маркер конца ответа или использовать счетчик, чтобы проверить, все ли данные получены, или я могу просто положиться на обнаружение xhr.readyState == 4?

Даже частичный ответ будет полезен.

Answer 1

Я думаю Комета является частью того, что вам нужно для вашего решения. Кроме того, вы можете (если я правильно понял) проверить Bayeux Protocol , который был реализован Dojo Foundation. Все это все еще очень ново (хотя некоторые из них могут быть возможны с первыми реализациями HTML5).

Кроме того, вам, вероятно, придется реализовать подход опроса. Другой вопрос, сколько данных может обработать интерпретатор JavaScript на стороне клиента. Есть ли у вас возможность как-то «пролистать» свои данные, чтобы у вас не было проблемы с обработкой запросов, которые еще обрабатываются, пока поступает другой ответ?

Answer 2

Я думаю, что клиентская сторона может быть спроектирована для обработки данных порциями, посылая повторные запросы AJAX, пока не будут предоставлены все данные. Это предполагает, что каждый блок может быть отправлен своевременно (без проблем с тайм-аутом на стороне клиента), даже если весь ответ был большим; и этот дизайн, вероятно, проще, чем разработка проверок для определенных состояний частичного ответа, которые могут варьироваться от браузера к браузеру.

В зависимости от того, выполняете ли вы обработку на стороне сервера или на стороне клиента, это будет зависеть, например, от сколько одновременных клиентов вам нужно будет обслуживать, и можете ли вы использовать кэширование для любого из ответов; в некоторых сценариях, где много клиентов, лучше распределить часть нагрузки по ним (конечно, если они могут справиться с этим).