Комментарии 25
Спасибо, автор
самым интересным мне показался вариант подключения к nginx «псевдо-fcgi» т.е. демон, работающий по этому протоколу, но в один поток…
Т.е. клиенты подключаются к nginx (который в свою очередь обращается к fcgi) и висят там с постоянным соединением ну а этот «fcgi» отправляет полученные сообщения клиенту.
Т.е. клиенты подключаются к nginx (который в свою очередь обращается к fcgi) и висят там с постоянным соединением ну а этот «fcgi» отправляет полученные сообщения клиенту.
Явно не хватает примеров реализации. В общем спасибо.
А я бы поставил irc и к нему веб-морду на nginx+php-fpm
могут быть сложности со сквозной авторизацией и поддержкой игровых ников, пытались уже сделать, хотя может это были сложности конкретных реализаций. Гораздо более заманчивой выглядит интеграция XMPP/Jabber в проект, тем более есть хорошие реализации и на Flash и на чистом JS и даже PHP
А как при интеграции джаббера решаются проблемы сквозной авторизации и другие, которые я в комментарии ниже описал?
да, в XMPP все єто вполне отлично решается. можно проксировать запросы либо через PHPшлюз, который будет обрабатыфвать служебные игровые команды, или же расширить сервер. по моему лучшим способом — это выбрать OpenFire сервер, он отлично масштабируется и на хабре біли статьи как писать плагины для него
При выборе ядра чата играет роль как минимум три критерия:
1. Масштабируемость
2. Производительность
3. Удобство расширения/допиливания
IRC выигрывает перед самописным ядром по п.1, но как у него с п.2 и п.3? Я в итоге под свой проект писал самописное ядро чата, упирая именно на 2+3. А п.1 можно лечить шардингом игрового мира/реалмами.
1. Масштабируемость
2. Производительность
3. Удобство расширения/допиливания
IRC выигрывает перед самописным ядром по п.1, но как у него с п.2 и п.3? Я в итоге под свой проект писал самописное ядро чата, упирая именно на 2+3. А п.1 можно лечить шардингом игрового мира/реалмами.
Производительности сервера не хватит гораздо раньше на саму игру в моем случае, чем на чат.
Там совершенно несерьезная нагрузка от ядра чата по сравнению с нагрузкой от скриптов игры.
Там совершенно несерьезная нагрузка от ядра чата по сравнению с нагрузкой от скриптов игры.
У меня проще. Всё, кроме 2х точек входа в приложение и чата, изначально модульное, запускается в любом количестве экземпляров и разносится по серверам в случае необходимости. А вот производительность чата критична и просто так не увеличивается.
У меня к сожалению по историческим причинам основная часть проекта практически не масштабируется, потому что более одного сервера у меня никогда и не было по финансовым причинам =)
Однако переработка движка для возможности распределять нагрузку на несколько серверов — в планах конечно.
Однако переработка движка для возможности распределять нагрузку на несколько серверов — в планах конечно.
Ооо, переписывать однопоточный, не закладывавший на параллелизм код — это много мучительных часов впереди :)
Почему же однопоточный.
Оба используемых демона — многопоточны.
Но вид взаимодействия (разделяемая память + UNIX сокеты) накладывает ограничения на расширяемость. С другой стороны, для одной машины — это самый быстродействующий вариант.
Оба используемых демона — многопоточны.
Но вид взаимодействия (разделяемая память + UNIX сокеты) накладывает ограничения на расширяемость. С другой стороны, для одной машины — это самый быстродействующий вариант.
Если без shared memory, а только на сокетах — можно было бы разносить. Разницы между unix/tcp/pipe по способу работу нет. Я вообще не люблю разделяемую память — если один процесс падает, то нельзя быть увереным, что её состояние консистентно = перезапуск всего. А с сокетами достаточно закрыть старый, и принять новый.
Абсолютно с вами согласен.
Подводные камни при работе с разделяемой памятью есть.
И расширяемости нет.
Сделал так только потому, что на данный момент все работает на одной машине и использовать для взаимодействия сокеты — все таки медленнее.
Например этот самый чат — самый характерный пример.
Здесь по сути при появлении нового сообщения в общем чате соединяется один клиент через сокет и передает сообщение демону.
После чего клиенты просто обнаруживают сообщение в разделяемой памяти и форматируют для вывода в браузер.
Отсутствует необходимость в куче подключений от всех клиентов через сокеты.
Подводные камни при работе с разделяемой памятью есть.
И расширяемости нет.
Сделал так только потому, что на данный момент все работает на одной машине и использовать для взаимодействия сокеты — все таки медленнее.
Например этот самый чат — самый характерный пример.
Здесь по сути при появлении нового сообщения в общем чате соединяется один клиент через сокет и передает сообщение демону.
После чего клиенты просто обнаруживают сообщение в разделяемой памяти и форматируют для вывода в браузер.
Отсутствует необходимость в куче подключений от всех клиентов через сокеты.
Но это не относится к потокам. Разделяемая память в потоках при аккуратной работе — очень даже приятно.
На IRC не сделаешь полной интеграции с игрой.
Если дойду до топика по этой теме — расскажу подробнее.
Вкратце — Чат у нас используется для многого в игре, есть несколько каналов, часть из них системная; есть различные фильтры сообщений, включая например сообщения для клана, сообщения для участников боя, сообщения для группы…
Через чат могут приходить и команды на обновление списка онлайн например, на основании приходящих из чата сообщений могут происходить некоторые действия.
Если дойду до топика по этой теме — расскажу подробнее.
Вкратце — Чат у нас используется для многого в игре, есть несколько каналов, часть из них системная; есть различные фильтры сообщений, включая например сообщения для клана, сообщения для участников боя, сообщения для группы…
Через чат могут приходить и команды на обновление списка онлайн например, на основании приходящих из чата сообщений могут происходить некоторые действия.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Реализация демона и его взаимодействия с PHP-приложением