mephisto Nov 21 2009 at 01:45

Реализация демона и его взаимодействия с PHP-приложением

3 min

1.3K

Lumber room

Comments 25

jcdenton_dx Nov 21 2009 at 01:55

Спасибо, автор

-1

mephisto Nov 21 2009 at 02:02

Спасибо за спасибо =)
По существу бы чего-нибудь =)

Nascosto Nov 21 2009 at 02:27

самым интересным мне показался вариант подключения к nginx «псевдо-fcgi» т.е. демон, работающий по этому протоколу, но в один поток…
Т.е. клиенты подключаются к nginx (который в свою очередь обращается к fcgi) и висят там с постоянным соединением ну а этот «fcgi» отправляет полученные сообщения клиенту.

mephisto Nov 21 2009 at 02:36

мм, а можно подробнее?
Если демон работает в один поток, то как он обслуживает сразу несколько соединений?
Или один поток в цикле их обрабатывает?

Nascosto Nov 21 2009 at 02:59

Именно. В цикле!
А что вас смущает?

djkobraz Nov 21 2009 at 02:36

Явно не хватает примеров реализации. В общем спасибо.

mephisto Nov 21 2009 at 02:37

Не хотелось писать слишком длинный топик. Я написал общее описание, если интересно — напишу топик с примерами кода =)

MisterX Nov 21 2009 at 03:22

Буду признателен, будет более понятно, так как подобная реализация в VOC чате. Но там без очередей, и использутся семафоры.

djkobraz Nov 21 2009 at 23:51

Жду с нетерпением =)

Andrey_Rogovsky Nov 21 2009 at 09:22

А я бы поставил irc и к нему веб-морду на nginx+php-fpm

aleks_raiden Nov 21 2009 at 09:57

могут быть сложности со сквозной авторизацией и поддержкой игровых ников, пытались уже сделать, хотя может это были сложности конкретных реализаций. Гораздо более заманчивой выглядит интеграция XMPP/Jabber в проект, тем более есть хорошие реализации и на Flash и на чистом JS и даже PHP

mephisto Nov 21 2009 at 11:06

А как при интеграции джаббера решаются проблемы сквозной авторизации и другие, которые я в комментарии ниже описал?

aleks_raiden Nov 21 2009 at 11:09

да, в XMPP все єто вполне отлично решается. можно проксировать запросы либо через PHPшлюз, который будет обрабатыфвать служебные игровые команды, или же расширить сервер. по моему лучшим способом — это выбрать OpenFire сервер, он отлично масштабируется и на хабре біли статьи как писать плагины для него

DurRandir Nov 21 2009 at 11:03

При выборе ядра чата играет роль как минимум три критерия:
1. Масштабируемость
2. Производительность
3. Удобство расширения/допиливания

IRC выигрывает перед самописным ядром по п.1, но как у него с п.2 и п.3? Я в итоге под свой проект писал самописное ядро чата, упирая именно на 2+3. А п.1 можно лечить шардингом игрового мира/реалмами.

mephisto Nov 21 2009 at 11:05

Производительности сервера не хватит гораздо раньше на саму игру в моем случае, чем на чат.
Там совершенно несерьезная нагрузка от ядра чата по сравнению с нагрузкой от скриптов игры.

DurRandir Nov 21 2009 at 11:49

У меня проще. Всё, кроме 2х точек входа в приложение и чата, изначально модульное, запускается в любом количестве экземпляров и разносится по серверам в случае необходимости. А вот производительность чата критична и просто так не увеличивается.

mephisto Nov 21 2009 at 12:01

У меня к сожалению по историческим причинам основная часть проекта практически не масштабируется, потому что более одного сервера у меня никогда и не было по финансовым причинам =)
Однако переработка движка для возможности распределять нагрузку на несколько серверов — в планах конечно.

DurRandir Nov 21 2009 at 12:03

Ооо, переписывать однопоточный, не закладывавший на параллелизм код — это много мучительных часов впереди :)

mephisto Nov 21 2009 at 12:06

Почему же однопоточный.
Оба используемых демона — многопоточны.
Но вид взаимодействия (разделяемая память + UNIX сокеты) накладывает ограничения на расширяемость. С другой стороны, для одной машины — это самый быстродействующий вариант.

DurRandir Nov 21 2009 at 12:22

Если без shared memory, а только на сокетах — можно было бы разносить. Разницы между unix/tcp/pipe по способу работу нет. Я вообще не люблю разделяемую память — если один процесс падает, то нельзя быть увереным, что её состояние консистентно = перезапуск всего. А с сокетами достаточно закрыть старый, и принять новый.

mephisto Nov 21 2009 at 12:34

Абсолютно с вами согласен.
Подводные камни при работе с разделяемой памятью есть.
И расширяемости нет.
Сделал так только потому, что на данный момент все работает на одной машине и использовать для взаимодействия сокеты — все таки медленнее.
Например этот самый чат — самый характерный пример.
Здесь по сути при появлении нового сообщения в общем чате соединяется один клиент через сокет и передает сообщение демону.
После чего клиенты просто обнаруживают сообщение в разделяемой памяти и форматируют для вывода в браузер.
Отсутствует необходимость в куче подключений от всех клиентов через сокеты.

DurRandir Nov 21 2009 at 13:04

У меня другая схема просто. Все клиенты висят постоянно подключеными, один отправил сообщение — демон чата определил, кому его надо отразить, и сразу же разослал по сокетам. Нет необходимости опрашивать/проверять изменения.

mephisto Nov 21 2009 at 13:25

В принципе да, тоже неплохая реализация.
Спасибо за идею, пригодится, когда буду расширяться =)

DurRandir Nov 21 2009 at 12:23

Но это не относится к потокам. Разделяемая память в потоках при аккуратной работе — очень даже приятно.

mephisto Nov 21 2009 at 11:04

На IRC не сделаешь полной интеграции с игрой.
Если дойду до топика по этой теме — расскажу подробнее.
Вкратце — Чат у нас используется для многого в игре, есть несколько каналов, часть из них системная; есть различные фильтры сообщений, включая например сообщения для клана, сообщения для участников боя, сообщения для группы…
Через чат могут приходить и команды на обновление списка онлайн например, на основании приходящих из чата сообщений могут происходить некоторые действия.

Show the best of all time