Как длительный опрос может быть полезным?

Question

Я не понимаю, как длительный опрос может быть вообще полезным, если XMLHttpRequest не дает доступа к частичному контенту ???

Нет разницы, где ждать, на клиенте или на сервере.Ответ может быть показан только после завершения.Итак, и короткий опрос, и длинный опрос выглядят одинаково.

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

Где моя ошибка?

Обновление 1.

Таким образом, единственное чувство понятия "комета" - это сервлетнапример) следует просто ждать как можно больше, прежде чем ответить, пытаясь никогда не сказать «нет данных»?

Тогда для чего существует такой интерфейс, как CometProcessor в Tomcat API?

Answer 1

Всякий раз, когда появляется новая строка чата, сервер выполняет длинный запрос на опрос, а клиент выдает новый. Таким образом, вы моделируете поддержку частичного контента, переиздавая запрос каждый раз, когда поступает часть.

Answer 2

Точка длинного опроса состоит в том, чтобы эмулировать процесс передачи сервером данных клиенту. Что делает его эмуляцией, так это то, что сервер выполняет запрос от клиента, так что сервер решает, когда ответить, т.е. Похоже, что сервер контролирует передачу данных, хотя на самом деле это не совсем так. На самом деле это не отправка данных в правильном смысле, поэтому длительный опрос является лишь эмуляцией передачи на основе push.

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

Answer 3

При длинном опросе сервер возвращает complete response , как только у него есть данные (тогда, как говорят другие ответы, клиент отправляет другой запрос).

Таким образом, этот метод быстрее, чем регулярный короткий опрос, когда клиент потенциально может запросить данные через некоторое время после того, как сервер получит их.

НТН

Answer 4

При длительном опросе сервер выполняет «ожидание», сокращая количество настраиваемых HTTP-соединений. Вы запускаете опрос от клиента, а затем сервер растягивает ответ по мере необходимости, пока он фактически не получит данные для возврата. Таким образом, вы не обременяете клиента необходимостью запускать HTTP-запросы снова и снова.