[Moscow.pm] а вот кто с лонгпулингом работает?
Ivan Petrov
i.petro.77.00 на gmail.com
Пн Апр 28 01:27:30 PDT 2014
> Судя по вашему описанию, клиент ведёт себя неадекватно. При реконнекте не
> должно идти много соединений. Вы должны инициировать соединение с сервером, у
> него есть таймаут, скажем 30 секунд. Если в течение этого времени ничего не
> пришло, клиент делает XMLHttpRequest.abort и только потом инициирует новое
> соединение. Никаких 30 одновременно никак не получится.
Вы видимо вообще с лонгпулингом не работали?
да примерно так и работает, здесь речь идет уже о том что происходит
ПОСЛЕ XMLHttpRequest.abort.
а после происходят повторные попытки.
если повторная попытка удачная, то клиент в результате этой удачи
получает все сообщения накопившиеся "для него" за время пока шли
попытки переустановить соединение.
ну и вообще смысл работы любого сервера лонгпулинга - хранить
сообщения для клиентов пока те реконнектятся.
если бы не было реконнектов, то получился бы вебсокет.
далее получается что поскольку с лонгпулингом мы таким образом можем
получить сразу большой пакет событий, то уже *в обработке* этих
событий получается:
- если событие приводит скажем к изменению цвета кнопки - тут все
просто
- если событие рождает AJAX запрос, то вот тут начинаются проблемы.
ибо в некоторых случаях может получаться пакет AJAX запросов.
вопрос состоит в том что либо мы *в конкретном приложении* придумываем
некие критерии как эти запросы обрабатывать пакетно,
либо видимо можно сформулировать некоторый общий критерий, обобщенную
реакцию самого клиента lp на такие события, как задержки.
я вопрос тут описал как раз на тему может кто-то продумывал сие на
общеконцептуальном, архитектурном уровне
Подробная информация о списке рассылки Moscow-pm