Судя по вашему описанию, клиент ведёт себя неадекватно. При реконнекте не должно идти много соединений. Вы должны инициировать соединение с сервером, у него есть таймаут, скажем 30 секунд. Если в течение этого времени ничего не пришло, клиент делает XMLHttpRequest.abort и только потом инициирует новое соединение. Никаких 30 одновременно никак не получится.
26 апреля 2014 г., 22:17 пользователь Ivan Petrov <[email protected]>написал: > значит причины почему лонгпулинг: потому что вебсокеты пока 5/6 > браузерами не поддерживается (у нас в ua по логам столько таковых) > > для доставки сообщений запилили сервер лонгпулинга (на тарантуле). > > соответственно кому надо - кладет евенты с ключами > клиенты подписываются на перечень ключей и получают евенты посредством > запросов к лонгпулинг-сервису > > из за того что клиенты > > a. на GPRS > b. переконнекчиваются > > то время "жизни" сообщения на сервере довольно большое - >= 10 минут. > > далее, есть Event'ы на которые скажем кнопочка в интерфейсе > перекрашивается. с теми все понятно. > > но есть Event'ы по которым делается AJAX запрос. > > все в целом работает оч красиво, юзер практически немедленную реакцию > видит на удаленные события. > > однако есть одна траблема: > > если у юзера пропадает канал на скажем 5 минут, то после его появления > он получает все евенты которые ему пришли за пять минут разом. > > то есть при выходе его "из тени" может выйти так, что его браузер > начинает делать 20-30 AJAX запросов подряд. > > понятно что можно в *каждом отдельном* случае как-то либо "схлопывать > сообщения" внутри большой пачки, либо делать релоад всей страницы итп, > но хочется придумать какое-то относительно универсальное решение. > > вопрос: никто не думал над проблемой лонгпулинга и нестабильного > коннекта с AJAX в ответ на события? > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org >
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
