Как стать автором
Обновить

Комментарии 40

longpoll хорошо работает на phpDaemon\node.js и других event движках, а также эмулируется через limit в nginx( будете получать картинку ну очень медленно )
висящая загрузка и постоянное соединение с сервером — не вариант :(
Не все так плохо. Висящая «загрузка...» наблюдается в любой Опере, ФФ 3.6 и iOS Safari. В опере она очень заметная, поэтому заменена на каскад запросов. В iOS Safari практически незаметна (не броская крутилка), в ФФ совсем незаметна (сообщение есть только в строке состояния).
Если делать пинг сервер на nginx + ping.yourdomain.com, то nginx на висящее соединение потратит мизер памяти и мы не займем 1 из 4-х http соединений с нашим ping.yourdomain.com.
Люди в роуминге будут просто счастливы!
В лучшем случае менее 1кб лишнего трафика (если сервер будет отвечать вечно).
Скорее всего далеко не 1кб. Дело в том, что может вы и отправите 1кб полезных данных суммарно, но вполне может оказаться, что оператор тарифицирует трафик по размеру реальных IP пакетов. А это может увеличить реальный расход до ~30кб.
Вы что то тут не то говорите, какие 'реальные пакеты' будут идти во время 'ожидания' ответа сервером?

Да, есть округление трафика сессии (кстати похоже опсосы специально долгие соединение gprs/edge без трафика постоянно обрывают, даже со стационарным клиентом, чем фактически превращают по(мега)килобайтовый тариф в почасовую оплату), может именно это имеется в виду?
А не беда, что на каждое такое соединение нужно будет держать по php-воркеру, кушающих от 5 мегабайт памяти?
а еще вспомним необходимость отдельного доменного имени на такой запрос иначе один из загружающих потоков IE будет постоянно занят.
*один из двух
поспешишь, людей насмешишь :(
Есть решение ping-сервера на nginx с минимум затрат.
Покажите.
Не силен в perl'e nginx'a но это возможно с помощью прямых рук и HttpEmptyGifModule
Я бы еще все-таки повесился на online и offline события, т.к. они отправляются, когда у компьютера отключаются все сетевые соединения, а это верный показатель и никакие картинки можно не грузить.
Хехе =) 100 пользователей онлайн и у вас пойдут 500-ые ошибки. Для php этот вариант вообще не пригоден. Используйте лучше node.js с их асинхронными обработчиками.
Я так и не понял, зачем это нужно может быть?
для определения самому клиенту (а часто и серверу) — есть ли такой юзер онлайн или нет. для многих случаев очень даже нужно.
Это и по названию понятно. А конкретный пример?
Сервер прекрасно понимает, что юзер «онлайн» по его сессии и последним запросам.
А тут, фактически JS — зачем клиенту знать, онлайн он или оффлайн? Он, думаю, и так заметит ошибку при переходе на другую страницу…

P.S. в IE пример не работает, по крайней мере я не смог добиться оффлайна никакими способами.
это надо для веб-приложений, где нет никаких переходов страниц.
Следовательно и нет запросов к вебсерверу? :) А смысл?
Я не придираюсь, просто хочу хоть один пример такого приложения.
И? Банальный рефреш/запрос каждые 6 секунд.
почему нет? есть. но часто _после_ совершения какого-либо действия.

Например, пишите вы пост. в чат. очень важный чат. и важность такая, что если вы не знаете точно, что ваш собеседник онлайн, то и не начинаете писать. Но это надо знать до того, как закончите писать сообщение — а запрос на сервер уйдет то именно в момент отправки.
Подождите, а причем тут собеседник онлайн?
Вы-то эти данные от чата как-то получаете, перезагрузкой или потоком, собеседник в свою очередь, если станет в оффлайне, он уже никак не сообщит чату, что он выпал, чат сам узнает об этом по таймауту потока, например.
это в обычных чатах. есть класс ситем с другими требованиями (и другими клиентами). Где это очень критично (в частости — мой пример — финансовые терминалы (не то что форексом называют, а профессиональные)
Мне не извесны примеры проффесиональных финансовых терминалов на ajax.
На Flash есть много, а на ajax не видел.
Ваши задержки до 15 сек. для терминала просто смертельны.

А в ситуации с выдёргиванием шнура, это не браузеры виноваты, а сетевой стек ОС, у которого таймауты большие.
Восновном эти эвенты применимы для мобильных сервисов, которые могут работать как онлайн так и оффлайн. Например пользователь пишет длинную статью, а нажимает отправить в тот момент когда попадает в зону не покрытия сетью. Веб приложение в момент отключания интернета переделывает свою обычную логику и вместо того, чтобы отправить статью на сервер кладет её в localStorage и ждет пока не поднимется интернет, чтобы отправить её по назначению.
Вот. Теперь понятно. Спасибо :)
А как вам такой способ: веб приложение пытается отправить данные, получает 50x или таймаут, и кладет данные в localStorage?
Например, тудушка thn.gs/ может работать как online так и offline. При исчезновении интернета, сервис сигнализирует об этом симпатичным облачком, которое прикольно становится пустым. Если сервис знает что соединение отсутствует, он не будет даже пытаться отослать данные, а сразу сохранит их в localStorage.
Мозила 3.6.3
Пишет, что я оффлайн. Но я точно уверен, что имею связь с внешним миром.
Не думаю, что это проблема из прокси
Я не совсем понимаю, зачем это надо, но даже если надо, то лучше делать через веб-сокеты тем, кто может, а кто не может — тем делать poll.
Для веб-сокетов сложнее серверная часть, image poll 6 строк кода. Также я писал решение для SSE, но оно не кроссдоменно, не считая изврата с SharedWorkers.
Не согласен насчет сложной серверной части — уже есть готовые решения для java (Netty), nodejs (Socket.IO), php (phpDaemon) — и это только то, что знаю я.
В конце концов, websockets — это то, как должено быть, а всякие long poll — это, извините, костыль.
А разве нельзя с той же целью использовать асинхронный XHR? Современные браузеры, вроде уже приучены в этом случае не мучать пользователя индикатором «загрузка».
Можно и XHR и SSE только получим не кроссдоменный вариант. Lpip позволяет делать кроссдоменные запросы и работает без лишних костылей во всех браузерах.
Ну как это без костылей, если вы сами написали, что для Оперы вы их вообще отключили?
поясните, зачем кросс-доменность в данном случае?
1. Мы имеем одно висящее соединение и поэтому остается только 3 соединения, что может сказаться на общей производительности.
2. Веб-портал имеет несколько онлайн-оффлайн сервисов на разных субдоменах, чтобы не поднимать пинг-сервер на каждом он поднимается на одном домене и общается со всеми кроссдоменно.
А что просто картинку не загружать раз в минуту?
Не загрузилась — пробуем сразу же еще раз (контрольный).

Или если мы будем ошибаться в режиме в течение минуты — это критично?

К тому же для защиты от третьего пункта
«3. При физическом отключении интернета (выдернул шнур) все браузеры не сбрасывают висящее соединение, поэтому оффлайн не приходит.»

Можно использовать таймаут на запрос.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории