Здравствуйте, 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 через сокеты, так что вариант с сокетами — вполне приемлем.