Длинные опросы (long poll)
Другое название способа - "Очередь ожидающих запросов". Краткая схема такова:
- Отправляется запрос на сервер
- Соединение не закрывается сервером
- Событие отправляется в ответ на запрос
- Клиент тут же отправляет новый ожидающий запрос
Каждый пакет данных, таким образом, означает новое (не учитывая Keep-Alive) соединение,
которое будет открыто столько, сколько нужно, пока сервер не решит прислать информацию.
На практике, соединение обычно переустанавливается раз в 20-30 секунд, чтобы избежать возможных проблем, например с HTTP-прокси.
В отличие от простого поллинга, здесь уведомление о событии приходит гораздо быстрее.
Задержка = установление соединения + передача данных
Такие задержки вполне терпимы в случае, если событий немного, и совершенно незаметны, если обновления с сервера приходят раз в минуту и реже. При активном чате и больших сетевых задержках ("большой ping"), они уже более ощутимы.
- Задержки между событием и уведомлением
- ...но не такие как в поллинге
- Входящий трафик на сервер
Этот метод достаточно удобен в реализации, лишь немного сложнее простого поллинга.
В качестве транспорта можно использовать что угодно - от XMLHTTPRequest до тегов script. Все просто, поэтому пример не рассматриваем.
|
Как я понимаю это способ избавиться от недостатков в реализации XMLHTTPRequest - сброс/очистка устаревшего содержимого в response?
Можно в принципи вообще не разрывать связь, а складывать все в response и при поступлении данных их обрабатывать... ну допустим если у нас "своя сеть", а для сброса переподключаться к серверу.
Поддерживаю вопрос: уверен что возможно обрабатывать данные по мере поступления, раз браузер может принимать такие страницы.
Например в php файле в начале мы ставим:
Таким образом скрипт может выполняться например час. И в течении часа браузер будет выводить поступающие данные.
Так почему мы не можем сделать такой запрос через ajax , и обрабатывать данные по мере поступления? Проблема в том, что тот же jquery позволяет вызывать callback функцию только после полной загрузки документа...
а можно привести пример такого запроса?
желательно на примере чата))
Обычный запрос на сервер. Запрос идет на демон чата, демон чата отвечает на запрос только когда приходит сообщение.
А как же timeout? Если сообщений долго не приходит соответсвенно и демон чата тоже долго не отвечает, выйдет лимит времени и ошибка, прийдется переподклбючаться.
Да, именно так. Так что раз в 30 секунд по-любому новый запрос делается на сервер.
ИМХО оптимальнее отслеживать разрыв соединения и только тогда восстанавливать связь.
30 сек. это очень маленький интервал - да когда есть прокся это оптимально, но если сервер может ждать и дольше
И сколько в среднем длится простой соединения, пока сервер его не закрывает?
и что в течении этого времени предлагается делать? циклически проверять наличие обновлений? какой же сервер это выдержит (при чате с 50-100 посетителями онлайн)?
Простоя нет: соединение закрывается, и тут же открывается новое. Задержка на установление соединения с сервером зависит от канала посетителя. Как правило, это в пределах 5-300мс.
Если идет активный чат с кучей сообщений, то такой способ не очень хорош, а если чат, например, двусторонний (два человека, поэтому не так много сообщений), или просто получение событий с сервера - он работает замечательно.
Я предполагаю, что имелся ввиду простой сервера в ожидании наступления события, т. е. каким образом серверу сделать паузу. Мне самому это очень интересно. Я использую ASP и не знаю, как сделать задержку - ни Sleep, ни setTimeout там нет. Допоможите, пожалуйста.
А можете всё же пример написать, так проще для понимания...
Нужен пример!
Илья Кантор пожалуйста приведите пример!
Пример чего конкретно привести?
Это обычный XMLHTTPRequest.
Лично меня интересует пример обработки long-polling запроса в Java сервере (в частности Jetty). Без написания специальных Continuation-сервлетов здесь не обойтись?
PS: вообще учебник хорош - для начинающего в этом деле - само то!
Но дизайн местами убивает :-) Какое-то время откладывал чтение данного ресурса исключительно из-за визуального отторжения.
можете описать вот этот момент серверного скрипта
Соединение не закрывается сервером
* пока не появится событие
И в чем тогда разница этого метода от частых опросов если каждые 20-30 секунд посылается новый xmlhttprequest?
Разница в том, что событие отсылается на клиент тут же, в виде ответа на "подвисший" XmlHttpRequest.
Кроме того, это одно соединение каждые 20-30-100 секунд, а не одно раз в 5-10.
Илья, спасибо все теперь понятно. Вы тут в комментариях писали (Если идет активный чат с кучей сообщений, то такой способ не очень хорош, а если чат двусторонний, или просто получение событий с сервера - он работает замечательно.)
Что то я тут не понял разницу чата с кучей сообщений и двусторонним чатом. Могли бы вы по подробнее описать этот момент?
Поправил соответствующий комментарий.
Илья, Вы на мастер классах говорили, что timeout может быть сколько угодно по времени, даже несколько часов.
Здесь Вы пишете про 30 секунд.
Я сам пробовал на чате написанном на nodeJS сделать timeout больше 30 секунд - не вышло.
Вот пример чата от разработчика nodeJS http://chat.nodejs.org/
В нем тоже timeout 30 секунд.
Возможно я Вас неправильно понял, Вы наверное имели в виду Socket.io - да
там есть возможность держать соединение по времени столько сколько нужно.
Можно дольше делать. Что у вас не вышло, напишите подробнее.
Заработало).
Я раньше тестировал в Firebug для FireFox 3.6 не работало, а сейчас работает, так здорово)))
Даже не знаю баг это был или я что-то не правильно делал.
Но всё таки я где-то слышал, что браузеры должны timeout держать 30 секунд, потом отключаться.
Возможно дело в том, что я использовать кросс-доменный запросы и в качестве транспорта script.
Может быть на script задержка в 30 секунд действует?
Написано:
2. Соединение не закрывается сервером
пока не появится событие
Непонятно как завершить соединение с сервером при закрытии страницы. У меня продолжает висеть соединение после закрытия страницы. Разрывать соединение обязатетьно по таймауту или есть другие способы?
Здравствуйте,
для меня не совсем понятен вопрос с сервером. в чём разница с простым AJAX запросом? толко в том что мы тянем время за которое будет возможность получить эти данные? По сути когда запрос выполняется, то скрип так-же завершается и при новом запуске всё идёт по новой? а как быть если мы пишем свой демон на C++, то мы должны плодить под каждого пользователя поток в котором будет висеть заблокировнное соединение до момента отправки данных или разрыва?
Данный способ отлично подходит если необходимо наиболее скорейшее получение события с сервера. При обычном AJAX мы долбим сервер каждые 5-10 секунд. В таком случает если событие произошло в 1-ую секунду после запросы то клиент получит событие только через 4-9 секунд, а ведь в некоторых приложениях это большая задержка (чаты). А в случает с лонг поллингом задержка будет только в момент создания нового соединения что в худшем случает составляет 1-2 секунды а обычно на много меньше, а к тому же это только в том случает если событие произошло в момент создания нового соединения а шанс что это произойдет очень мал
Добрый вечер. Хотел было воспользоваться данной технологией. Но на одном из форумов мне сообщили о том, будто Long poll съедает много ресурсов сервера. Так ли это?
Да, long polling съедает ресурсы сервера при большом количестве одновременно использующих "сервис" (чят или что-нибудь другое) клиентов, хотя бы потому что приходится поддерживать большое количество TCP-соединений.
Вообще long polling - это плохая практика. Её не следует использовать, если только вы не уверены, что вам ну уж точно он нужен.
КА
Ну ведь вконтакте использует его.
Вконтакте Api
цупкупуцк
Я раньше тестировал в Firebug для FireFox 3.6 не работало, а сейчас работает.
starjack io
Your feedback helps me a lot, A very meaningful event, I hope everything will go well run 3
да актуально и сегодня в сокетах есть свои недостатки
Roksa prywatne
Roksa faceci
Yes, it is relevant and today sockets have their drawbacks Crawl Space Remediation
The overall performance of this valuable web portal was excellent. I really enjoyed watching it, so I would no doubt try to find all the innovations over and over again. 사설스포츠토토사이트
Thank you for your sharing, I can finally understand it
Type 7: The Enthusiast: Energetic enneagram test and experience-seeking, they often seek excitement and joy in life and avoid instability.
Type 8: The Challenger: Strong and decisive, they often seek control and power to protect themselves and loved ones.
Play word games for free at waffle game. You will have comfortable moments with friends and family. Moments of relief after tiring work
Long polling, also known as 'waiting requests queue', seems like an interesting approach to handling server-client communication. It reminds me of the concept of continuous polling used in platforms like omegle, where the server maintains a connection until an event occurs. This method could be quite useful for real-time applications, especially when dealing with low-frequency updates or active chat environments. However, it's essential to consider the potential impact of network delays and server load when implementing this technique.
Метод длинных опросов представляет собой эффективную технику для быстрой передачи событий от incredibox сервера к клиенту, минимизируя задержки и упрощая реализацию асинхронной коммуникации веб-приложений.
The heart of the Kawasaki KDX 220R lies in its 216cc liquid-cooled single-cylinder engine. Unlike its 200cc sibling, the 220 employed a larger bore and revised porting for enhanced power delivery.
This important web portal worked flawlessly throughout. Since I found it entertaining, I would likely watch it again and again in an effort to spot all the advancements. gorilla tag
Насколько часто сервер разрывает соединение после его установления? geometry dash
https://sprunki.net/
The combination of different music is so magical that I can't stop listening to it
https://polytracks.org/
Crazy racing game polytrack, too difficult
https://perchanceaistory.com/
Perchance AI Story is a website that supports multiple languages and can continue to write stories
Отправить комментарий
Приветствуются комментарии:- Полезные.
- Дополняющие прочитанное.
- Вопросы по прочитанному. Именно по прочитанному, чтобы ответ на него помог другим разобраться в предмете статьи. Другие вопросы могут быть удалены.
P.S. Лучшее "спасибо" - не комментарий, как все здорово, а рекомендация или ссылка на статью.Для остальных вопросов и обсуждений есть форум.