А что насчет throttling-а событий (на клиенте, либо сервере, если он отделяет AJAX от других), делая искусственную паузу, пока очередь не освободится?
On Apr 28, 2014, at 12:27 PM, Ivan Petrov <[email protected]> wrote: >> Судя по вашему описанию, клиент ведёт себя неадекватно. При реконнекте не >> должно идти много соединений. Вы должны инициировать соединение с сервером, у >> него есть таймаут, скажем 30 секунд. Если в течение этого времени ничего не >> пришло, клиент делает XMLHttpRequest.abort и только потом инициирует новое >> соединение. Никаких 30 одновременно никак не получится. > > Вы видимо вообще с лонгпулингом не работали? > > да примерно так и работает, здесь речь идет уже о том что происходит > ПОСЛЕ XMLHttpRequest.abort. > > а после происходят повторные попытки. > > если повторная попытка удачная, то клиент в результате этой удачи > получает все сообщения накопившиеся "для него" за время пока шли > попытки переустановить соединение. > > ну и вообще смысл работы любого сервера лонгпулинга - хранить > сообщения для клиентов пока те реконнектятся. > если бы не было реконнектов, то получился бы вебсокет. > > > далее получается что поскольку с лонгпулингом мы таким образом можем > получить сразу большой пакет событий, то уже *в обработке* этих > событий получается: > > - если событие приводит скажем к изменению цвета кнопки - тут все > просто > - если событие рождает AJAX запрос, то вот тут начинаются проблемы. > > ибо в некоторых случаях может получаться пакет AJAX запросов. > > вопрос состоит в том что либо мы *в конкретном приложении* придумываем > некие критерии как эти запросы обрабатывать пакетно, > либо видимо можно сформулировать некоторый общий критерий, обобщенную > реакцию самого клиента lp на такие события, как задержки. > > я вопрос тут описал как раз на тему может кто-то продумывал сие на > общеконцептуальном, архитектурном уровне > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
