Коллеги, рад приветствовать вас на страницах этого форума!

Начинаю разработку нетривиального (на мой взгляд) web-проекта (ближе всего подходит определение "браузерная online-игра", хотя есть ряд существенных отличий от классической реализации). И в связи с этим очень нужен совет гуру и опытных людей по одному ключевому вопросу архитектуры.

Итак, от слов к делу.

Сервис состоит из трех сущностей:

1. Модель (или ядро) сервиса: по "историческим" и на мой взгляд вполне объективным причинам сложилось так, что модель реализована и развивается на языке C++. По сути — это серверная часть проекта. Далее по тексту — model.

2. CGI для взаимодействия с моделью (далее по тексту Mediator) — как раз то решение, на которое я хочу получить объективную критику от уважаемого all . На данный момент предполагаю реализовать этот интерфейс на php.

3. Клиент. Здесь, думаю, все понятно (браузер, ajax, вообщем полный "web2.0")

Взаимодействие сущностей 2 и 3 не вызывает никаких вопросов: здесь все понятно.

Вся суть вопроса — взаимодействие сущностей 1 и 2.

Как Я себе это представляю на данный момент:

Model и Mediator общаются друг с другом через сокеты. Mediator работает так:

0. Создает сессию для общения с клиентом (стандартный механизм php-session)
1. На каждый запрос клиента создает сокет (bottleneck? А не загнется ли сервер? И если загнется, то на скольких "запросах в секунду"?)
2. Преобразовывает запрос в понятный модели (Model) язык
3. Отправляет по сокету запрос в модель
4. Получает от модели ответ
5. Преобразовывает ответ модели в понятный клиенту язык
6. Отправляет клиенту ответ
7. Закрывает сокет

Вот схема примерно такая.

А теперь "+" и "-", которые я вижу в этом решении. Сначала разберемся со знаком "+":

* Mediator и Model общаются через сетевой интерфейс, а это означает, что возможна не только связь по loopback, но и связь с моделью, находящейся на удаленном сервере. Имеем возможность разнести модель по нескольким серверам, что может быть вполне востребовано.

* Вся "рутинная" работа по обработке пользовательских запросов (POST, GET, sessions) возлагается на плечи php: используем для этих целей готовые, проверенные решения.

А теперь "-":

* Единственный минус, который вижу я, это потенциальный bottleneck в Mediator: на каждый запрос клиента создается сокет, и по этому сокету бегают данные. Думаю, что loopback (Model и Mediator — на одном и том же сервере) будет работать быстро. Но есть сомнения. Действительно ли это так? И есть ли еще какие-то "грабли", про которые я забыл?

Вообще, буду признателен за любую конструктивную критику по этой архитектуре.

Всем спасибо за внимание.

Ф>1. Модель (или ядро) сервиса: по "историческим" и на мой взгляд вполне объективным причинам сложилось так, что модель реализована и развивается на языке C++. По сути — это серверная часть проекта. Далее по тексту — model.

Ф>2. CGI для взаимодействия с моделью (далее по тексту Mediator) — как раз то решение, на которое я хочу получить объективную критику от уважаемого all . На данный момент предполагаю реализовать этот интерфейс на php.

Ф>Вся суть вопроса — взаимодействие сущностей 1 и 2.

А. Пишем cgi на С и не мучаемся
В. Выкидываем движок на С и переписываем его на РНР и не мучаемся. Остального для браузерной игры не дано.

Если игра не браузерная (предполагается некий клиент), то:
— Веб сайт к игре пишем на РНР. Статистику всяко брать из базы данных.
— Клиенты взаимодействуют напрямую с сервером на С по определенному разработчиком протоколу


Насчет сокетов. Сервер открывает ровно один сокет, по которому начинает слушать. Клиенты на этот сокет отсылают запросы. Вся фишка — в грамотном построении протокола взаимодействия.

Здравствуйте, Mamut, Вы писали:

Ф>>1. Модель (или ядро) сервиса: по "историческим" и на мой взгляд вполне объективным причинам сложилось так, что модель реализована и развивается на языке C++. По сути — это серверная часть проекта. Далее по тексту — model.

Ф>>2. CGI для взаимодействия с моделью (далее по тексту Mediator) — как раз то решение, на которое я хочу получить объективную критику от уважаемого all . На данный момент предполагаю реализовать этот интерфейс на php.

Ф>>Вся суть вопроса — взаимодействие сущностей 1 и 2.

M>А. Пишем cgi на С и не мучаемся

Вот как раз про "не мучаемся" спорный вопрос. В php реализованы и проверены временем такие вещи, как работа с запросами (post, get), сессии, работа с базой, обработка форм. И потом, разработка cgi на php — процесс гораздо более быстрый, да и возможностей для отладки больше.

M>В. Выкидываем движок на С и переписываем его на РНР и не мучаемся. Остального для браузерной игры не дано.

Вариант в принципе не приемлем, так как движок реализован на C++ по объективным причинам.

M>Если игра не браузерная (предполагается некий клиент), то:

Клиент — браузерный. Но в перспективе может быть и не браузерный.

M>- Веб сайт к игре пишем на РНР. Статистику всяко брать из базы данных.
M>- Клиенты взаимодействуют напрямую с сервером на С по определенному разработчиком протоколу


M>Насчет сокетов. Сервер открывает ровно один сокет, по которому начинает слушать. Клиенты на этот сокет отсылают запросы. Вся фишка — в грамотном построении протокола взаимодействия.


Вообщем я себя уже убедил в том, что изначальный вариант (Model — C++, Mediator — PHP) — приемлемый вариант. Осталось только решить вопрос с производительностью cgi-php. Как вариант, php для общения с моделью может юзать один и тот же сокет, если php поставить через fastcgi. Тогда сразу же избавляемся от bottleneck "по новому сокету на каждый запрос". Вообще, php общается с mysql через сокеты, так что вариант с сокетами — вполне приемлем.

Название темы немного неподходящие. Погуглите на тему веб-сервисов.

Здравствуйте, Флибустьер, Вы писали:

Ф>Вообще, буду признателен за любую конструктивную критику по этой архитектуре.

Помоему 99% распределенных приложений с клиентским WEB интерфейсом работаю так, как указанно вами.

Выбвают разлиные связки PHP+C++, JSP+JAVA, ASP.NET+.NET, а также разные комбинации комбинации.

Bottleneck при такой реализации маловероятен, так как WEB часть обменивается данными с сервером не постоянно, а через некоторые промежутки (дотаточно большие, если AJAX не используется слишком активно).
Если уж действительно возникают проблемы с быстродействием, то можно организовать кеширование на стороне web-сервера, в том числе кеширование соденинения (хотя не знаю насколько возможно в PHP сохранить соединение между запусками сценария).

Ф>Вообщем я себя уже убедил в том, что изначальный вариант (Model — C++, Mediator — PHP) — приемлемый вариант. Осталось только решить вопрос с производительностью cgi-php. Как вариант, php для общения с моделью может юзать один и тот же сокет, если php поставить через fastcgi. Тогда сразу же избавляемся от bottleneck "по новому сокету на каждый запрос". Вообще, php общается с mysql через сокеты, так что вариант с сокетами — вполне приемлем.

Если честно, я не понял, чем занимается серверная часть на С++ и зачем ей нужен РНР