интересно. сам сделал нечто подобное, но на другой технологической основе, хотя сервером стоит также nginx. Кстати, посмотрите в сторону специализированного сервера для такого рода проектов — APE Push Engine
Первую проблему решить я пока не придумал как — если вызвать на клиенте в ответ на каждое сообщение какой-то каллбек, который берет идентификатор сообщения и говорит серверу, что все ОК, сообщение получил, то мы получим те же недостатки поллинга — множество запросов к серверу. Хотя можно просто накапливать в буфер это и раз в Х времени посылать массив, что все ОК или если есть недоставка тогда принудительно сбрасывать.
Также у меня принудительно каждые 3 секунды шлется специальный пинг пакет, сообщающий, что сервер работает и клиент может ставить таймер — если в течении N*3 (для верности) не было ни сообщений ни пинга, принудительно перезапустить соединение.
вторая проблема решается на стороне сервера очередью сообщений и упорядочниванием их перед отсылкой.
в IE не работает по причине, что используется дефолтный транспорт XMLHTTPRequest. На javascript.ru было несколько статей про различные методы стрима и кроссбраузерность. также можно посмотреть на исходники клиентской части того же APE
Если вы про второй недостаток (Отсутствие синхронизации исходящих запросов), то я про отсутствие синхронизации исходящих запросов на стороне клиента, проблема решается просто — небольшим воркэраундом над функцией посылки запроса.
Думаю, в jquery функция $.ajax учитывает особенности IE. Причем из IE все сообщения на сервер уходят, только ответа не видно. Такое ощущение, что просто не срабатывает колбэк success
Я бы решил вторую проблему простой нумерацией исходящих сообшений с ID клиента и сесии. Этот же способ поможет решить первую проблему. Для економии траффика цифры можно сжимать.
Гарантированная доставка возможно в случае отправки клиентом подтверждения о доставке нумеровннаых сообщений.
Race condition может быть только в исходящих от клиента запросов. Сообщения с сервера забираются одним запросом, и следующий запрос не будет создан пока не будет получен ответ на предыдущий.
1) да, складывать их в очередь ровно также как на сервере
2) да, сразу. после этого сразу посылается следующий запрос, только после окончания предыдущего. то есть в любой момент времени может быть не больше одного читающего с сервера данные запроса. А со стороны клиента в текущей реализации два подряд быстро отправленных сообщения уйдут на сервер в параллельных запросах, и не факт что первое придет раньше :)
Если я правильно понял проблему, то с подобным сталкивался. Если дело не в этом, заранее извиняюсь за коммент не в тему.
Нужно сделать вот так:
jQuery.ajax({
// тут параметры
success: function(rawxml)
{
var xml;
if(jQuery.browser.msie)
{
xml = new ActiveXObject(«Microsoft.XMLDOM»);
xml.async = false;
xml.loadXML(rawxml);
}
else xml = rawxml;
// дальше работаем с XML
Великая китайская нация прошла через 5000 лет цивилизации, конечно. В древней земле Китая, трудолюбивый, мужественный и мудрый народ все сотрудничестве национальности развитие огромных просторах земли и построить единую многоэтнической страны, и общее развитие великолепной китайской культуры. Тяжелой китайской истории, то есть рождение китайских этнических групп, развития, смешения и соучредителя единую нацию. С самого раннего древности, наших предков из различных этнических групп на труд, проценты, размножаются на земле Китая. Мы являемся единой многоэтнической страны, составляет 5000 лет, особенно после Цинь и Хань более чем 2000 лет, интеграции долгосрочный обмен термина в различных этнических группах постепенно формируется и развивается. Цинь и Хань, не только заложила основные центром в Центральной равнины в Хан династии, размеры территории, но и открыл для китайской цивилизации, земля рыболовства и охотничьих угодий, кочевой цивилизации и цивилизованных районов и сельскохозяйственных районов «путать» большой прецедент объединения. Цинь и Хань подряд в этом Гуанси, Юньнань, Гуйчжоу
Сложилось несколько негативное впечатление после посещения данного чата… Тролли флудят длинными сообщениями, из-за которых плывет верстка; гости выпрашивают инвайты…
Интересно, на скольки пользователях в чате он загнется? =)
Ну да… Тут я согласен с vkramskikh. Хотя канал загнуть — задача не очень выполнимая даже для 1000 флудящих юзеров, а сейчас там и 10 флудеров не наберется…
Она работала, но пришлось повысить лимит до 4 запросов в секунду, ибо при плотном потоке сообщений даже long-polling запросы посылаются чаще — этого не предусмотрел… Защиту от флуда надо делать внутри серверной части, nginx тут не спасет.
убрал nodelay и вернул ограничение на 1 запрос в секунду — полегче стало, только сообщения теперь приходят пачками с заметной задержкой. Но это лучше чем стена флуда :)
нашел более менее сносное решение проблемы флуда, напишу после того как все флудеры уйдут, ибо при знании конфига nginx оно легко обходится :) сообщения теперь можно слать не чаще 1 раза в 6 секунд, а на long-polling соединения это не влияет
Да, стало намного лучше! Только все равно флудить получается. Можно еще сделать блокирование повторных сообщений (достаточно длинных, чтобы «да/нет/угу» не блокировать) :)
А я вот хочу прочитать, что же там экраном выше написано, но после каждого нового сообщения в чате — кидает обратно вниз. В данном конкретном чате — не критично, но если пользовать по серьёзному — будет мешать.
Думаю это из-за того, что для добавления сообщений в чат используется сразу несколько обращений к DOM-дереву. В реальном чате так, конечно, делать не надо, здесь это сделано для того чтобы не преобразовывать спецсимволы на серверной стороне
Можно, в принципе, на чем угодно. Это вообще как бы пруф-оф-концепт и на полноценный чат не претендует :) Профит использования эрланга по сравнению с перлом вижу разве что в возможности использования многоядерных процессоров (так как текущая реализация на перле выполняется в один поток)
Можно :) Просто что вы будете делать когда у вас будут тысячи подключений? Профит не только в использовании SMP. Профит в скорости обработки, количестве одновременных подключений и в возможности подключать дополнительные ноды без каких либо проблем
Что буду делать когда будут тысячи подключений? Включу kqueue бэкендом (сейчас там простой select). Серверная часть является FSM, как nginx, и может спокойно выдерживать тысячи подключений. Возможность масштабирования из коробки, вещь, конечно хорошая, но тут особо не нужная. Этот чат висит на дохлой вдске с 256 метрами памяти и 480 мгц проца, плюс на той же вдске хостится сайт с80к хитов в сутки — и ничего, успешно работает :)
я не спорю что nginx примет тысячи подключений. Проблема в другом, сможет ли ваш перловый сервер быстро обработать эти все подключения? или вы столкнетесь с очередью, которая будет отдаваться nginx постепенно. Если так будет, то у вас будут большие таймоуты.
Вы, видимо, меня не поняли :) Мой перловый сервер имеет ровно ту же архитектуру, что и nginx — конечный автомат на асинхронных сокетах, и так же как и nginx, может обрабатывать тысячи подключений (от nginx'а). Причины, по которым я вставил посередине nginx, я описал в статье. В принципе, можно его легко убрать и просто заменить AnyEvent::FCGI на AnyEvent::HTTPD и работать напрямую с клиентом — ничего не изменится. Для вас, наверное, впечатление о перле сложилось в те времена, когда на нем ничего кроме CGI-приложений под веб не делали. Рекомендую почитать мою предыдущую статью, ссылка в этом посте :)
Я вообще стараюсь Perl под веб не юзать :) Скрипты, сбор статистики, генерация репортов — то чем перл выигрывает у всех — а именно работа с текстом.
Просто считаю что для каждой задачи есть свой язык :)
Оооо… Зопа это феерическая вещь, оправдывающая свое название на 300%!
Я тоже с ней работал, это незабываемо. После этого появляются афоризмы навроде: «Геморрой — это боль в зопе».
Я ее с большой радостью забросил, а питон оставил. Как язык он шикарный, это, можно сказать, «лучик света в большой темной зопе».
На питоне писать очень легко и приятно, он, честно, не виноват, что его использовали для написания такого монстра :)
хотел написать про велосипед то что вы хотели написать свою реализацию :)
Хотя это полезно, после этого лучше понимаешь все все это устроено и работает
а приватные сообщения там есть?
я осматривал данные технологии, но сходу не придумал как раздавать клиентам идентификаторы или как пихать с сервера сообщения в пул, чтобы некоторые данные слалисль всем юзерам, а некототрые данные слались только определнным юзерам (т.е. весь список мессаг всем, а приватные тоьлко нужным) причем нельзя посылать приватные в общем стеке а потом формировать приватные, иначе умники просто прочитают джсон
просто у меня задача намного сложнее была… и тогда не придумал как сделать. думал про несколько идентификаторов на одном пользователе
но не суть, вроде пришла в голову светлая мысль =)
На заметку: причина, по которой ваш чат не работает в IE — неправильная (по мнению IE) кодировка, указанная в заголовке. У вас сейчас возвращается «utf8», а IE поймёт только «utf-8». Немного подробностей: Системная ошибка: -1072896658.
Пишем Comet-чат