Разработка чат-демона на C++

Вообще то в Job. И насчёт получаса вы явно погорячились.

Уже запостил здесь..

Кешировать последние сообщения перед обращением к базе. Так можно избежать лишней нагрузки на БД. То есть, учитывать специфику задачи. Судя по всему, это кеширование должно быть интегрировано в основной движок (а разве этого нет?).

http://en.wikipedia.org/wiki/Comet_(programming)

>Так можно избежать лишней нагрузки на БД. То есть, учитывать специфику задачи. Судя по всему, это кеширование должно быть интегрировано в основной движок (а разве этого нет?).

В данный момент это всё на аяксе. В сессию на пхп запоминается id последнего показанного сообщения и для каждого юзера раз в секунду идел запрос на бд, мол, выбрать сообщения, где id > последнего. Т.к. для каждого обращения создается копия веб-сервера, то и памяти жрется много. А тут висел бы себе в процессах и всё..

Use IRC, Luke:-)

Тогда я бы все обращения из пхп скрипта делал только через этот процесс (запись, чтение, проверка и т.п.). То есть, чтобы тот процесс обладал монопольным правом работать с базой данных сообщений. Этот процесс и будет собственно выполнять роль кеша. Его отличие от БД будет в том, что он будет хранить последние 100 или 1000 сообщений долнительно у себя в памяти. Во многих случаях операции с базой сведутся к записи (это будет делать сам кеш/процесс), а читаться данные будут скорее всего из кеша напрямую, минуя базу. В общем, как-то так.

А почему C++? Я бы это оставил на выбор разработчика. Мне кажется, что та же Java справилась бы с этой задачей лучше.

Наверное можно и так сделать=) На C++ почему.. Да не столь важно, на самом деле.. Просто такие вещи часто пишут на нем, да и разработчика найти куда проще, кажется..))

>AJAX'ом раз в секунду проверяется наличие новых сообщений

Это неправильный подход. Вот правильный:

http://www.whatwg.org/specs/web-apps/current-work/multipage/section-server-se...

Сервер имеет по одному постоянно открытому соединению с каждым клиентом, как в IM. В текущей (9.2x) Опере это уже реализовано; к тому моменту, когда допишете ваш чат, будет и в FireFox.

Кстати, а как вы себе вообще это представляете? Кроме IE никто не разрешает AJAX-ить на другой порт, на 80 уже висит апач (или кто там у вас). Нужно либо модуль к апачу писать, либо CGI-аналог текущего PHP-скрипта (возможно с кеширующим посредником между ним и базой).

>Это неправильный подход. Вот правильный:

Не сказал бы, что и это правильный, т.к. есть тонна народа, кто сидит на старых браузерах и не гонится за новинками.. Так что пока что это тоже не вариант.. В идеале бы, действительно написать простенький сервер, который держал бы по соединению с клиентом и нет проблемы..

А зачем вообще апач? Пусть сам демон HTTP-запросы и принимает, в данном случае это вполне оправданно.

Тогда надо относительно большую часть HTTP реализовывать (впрочем здесь могу ошибаться). Имхо оверкилл.

Хотя конечно ошибаюсь, достаточно GET-а и отдавать главную страницу чата или ответ на запрос.

>А зачем вообще апач? Пусть сам демон HTTP-запросы и принимает, в данном случае это вполне оправданно

Я про это и говорю. Просто держит с браузером постоянное соединение, страница остается недозагруженной до конца, а при появлении в бд новых сообщений, демон просто пишет в сокет эти сообщения

К тому же, насколько мне известно, недостатка в HTTP-серверах, реализованных в виде маленьких либ, вроде нету.

такое ощущение, что автор ни разу не писал специализированных высоконагруженных HTTP сервисов. в противном случае, он бы не стал так опрометчиво оценивать работу "в полчасика". выводы можно в принципе не делать :)

// wbr

Этим самым, я хотел сказать, что мне не нужны все эти навороты с кешированием и т.д.. Простая проверка с базы и XML-выдача в сокет. Всё.

> Этим самым, я хотел сказать, что мне не нужны все эти навороты с кешированием и т.д.. Простая проверка с базы и XML-выдача в сокет. Всё.

сколько запросов в секунду должна держать вся эта хреновина? в смысле запросов от пользователя.

// wbr

В данном случае автор, видимо, выступает работодателем. Мы же можем помочь ему лучше понять и сформулировать его задачу :) Причем, подозреваю, что от первоначального ТЗ останется только цель - сделать сервис масштабируемым. Ни предложенный метод, ни оценка сложности, конечно, не выдерживают никакой критики.

>сколько запросов в секунду должна держать вся эта хреновина? в смысле запросов от пользователя.

Каких запросов? Открыто постоянное соединение с браузером, как только что-то появляется в базе, то сервер сам кидает инфу в браузер

>В данном случае автор, видимо, выступает работодателем. Мы же можем помочь ему лучше понять и сформулировать его задачу :) Причем, подозреваю, что от первоначального ТЗ останется только цель - сделать сервис масштабируемым. Ни предложенный метод, ни оценка сложности, конечно, не выдерживают никакой критики.

Да, есть только цель, как это лучше сделать, я не знаю. Я предложил вариант, если знаете, как сделать лучше, пожалуйста.. Насчет оценки сложности.. Не знаю, просмотрев несколько примеров, накатал такое на пхп быстренько, но нагрузка всё равно слишком велика, это не то..

> Открыто постоянное соединение с браузером

А раве это хорошо, держать соединение долго? Их кол-во ограничено.

> Каких запросов? Открыто постоянное соединение с браузером, как только что-то появляется в базе, то сервер сам кидает инфу в браузер

что-то я слабо себе представляю, как это реализуется в контексте протокола HTTP.

> Да, есть только цель, как это лучше сделать, я не знаю. Я предложил вариант, если знаете, как сделать лучше, пожалуйста.. Насчет оценки сложности.. Не знаю, просмотрев несколько примеров, накатал такое на пхп быстренько, но нагрузка всё равно слишком велика, это не то..

слишком много - это сколько? сто клиентов? тысяча? сто тысяч? сколько сообщений они тем или иным боком генерят в секунду? тысяча? десять тысяч?

// wbr

>что-то я слабо себе представляю, как это реализуется в контексте протокола HTTP.

Есть iframe, у него в src стоит адрес:порт, где слушает наш сервер. При загрузке, идет GET-запрос, сервер создает сокет, добавляет его в массив открытых сокетов и так для всех, т.е. есть какая-то база со всеми открытыми сокетами, кидает заголовки, страница не остается загруженной до конца. Через какой-то интервал происходит запрос к БД, выбирающий новые сообщения. Если таковые имеются, сервер пробегает по массиву и бросает всем на сокет сообщение, страница "догружается" - появляется сообщение.

Есть такой вариант. Может, можно сделать как-то по-иному..

>слишком много - это сколько? сто клиентов? тысяча? сто тысяч? сколько сообщений они тем или иным боком генерят в секунду? тысяча? десять тысяч?

В данный момент затрудняюсь ответить ибо ничего ещё нет. Но если даже сейчас всё это дело кое-как работает на аяксе, думаю, что тысячи вполне достаточно. Гораздо важнее скорость, с которой всё это дело будет работать.

s/IRC/XMPP/

Java тут лучше пойдет, и быстрее. Apache Mina поможет в реализации сервера

раз пошла такая пьянка, то мое видение решения такое:
1. разбиваем на две части (фронт-енд, бек-енд)
а) фронт - тот что общается с пользователями (не важно пока, по какому протоколу и как часто они его трахают
б) бек - сия часть смотрит непосредственно в базу

2. а и б - разные потоки. есть "С" - некий кэш, в который "б" пишет, "а" читает и маркирует статусом "прочитал".

3. а и б можно реализовать на скриптовых языках (тут надо оценивать объемы генерируемой нагрузки от клиентов, данных мало предоставлено, чтобы выдать окончательное решение).
4. "С" - в качестве оного можно заюзать memcached

еще есть вопросы?

имхо автор действительно не видел больших нагрузок.

1) почему не Jabber/XMPP? 2) если не 1, то почему не IRC?

По всей видимости человек не хочет полностью перепахивать то, что создавалось не один день. Возникла необходимость "апгрейднуть" наработки на предмет высокой нагрузки. Вот засим и пришел топикстартер сюда :)

Зыж, андор, ты ща в питере или где? :) носит тебя по белу-свету :)

>Сервер имеет по одному постоянно открытому соединению с каждым клиентом, как в IM.

Гы. 1000 человек - 1000 коннектов. Ага. Тогда уже на Эрланге придётся писать чат-сервер...

WEB-клиентам постоянные коннекты противопоказаны по своей природе. хотя я ничего против не имею, если речь идет о сотне-другой коннектов, дальше полный бред получится. Акромя академического интереса сие боле не заслуживает. В продакшн такое на пушечный выстрел нельзя подпускать :)