[Moscow.pm] а вот кто с лонгпулингом работает?

[Ivan Petrov]

> Судя по вашему описанию, клиент ведёт себя неадекватно. При реконнекте не
> должно идти много соединений. Вы должны инициировать соединение с сервером, у
> него есть таймаут, скажем 30 секунд. Если в течение этого времени ничего не
> пришло, клиент делает XMLHttpRequest.abort и только потом инициирует новое
> соединение. Никаких 30 одновременно никак не получится.

Вы видимо вообще с лонгпулингом не работали?

да примерно так и работает, здесь речь идет уже о том что происходит
ПОСЛЕ XMLHttpRequest.abort.

а после происходят повторные попытки.

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

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


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

 - если событие приводит скажем к изменению цвета кнопки - тут все
   просто
 - если событие рождает AJAX запрос, то вот тут начинаются проблемы.

ибо в некоторых случаях может получаться пакет AJAX запросов.

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

я вопрос тут описал как раз на тему может кто-то продумывал сие на
общеконцептуальном, архитектурном уровне