Серверное приложение (с++ or Java)

Требуется замена заболевшего программиста с++ bkb java. Суть заключается в разработке серверного приложения для онлайн-игры (нац.игра африканских стран, вроде шашок), настройка сервера. Клиент игры ( пишется нашим флэшером ) должен взаимодействовать с серверным приложением. Техническое задание в наличии.

КРАТКОЕ ОПИСАНИЕ:

1. План разработки сервера игры

Протокол:

Возможны 2 варианта работы клиента с сервером

1.синхронная, односторонняя (аналог ― HTTP или SOAP)

2.асинхронная (аналог - Jabber)

В первом случае только клиент посылает сообщение серверу а сервер

только отвечает на него. Этот вариант позволяет создавать более

простых клиентов, упрощает синхронизацию, но клиент должен

периодически опрашивать сервер не появилось ли новых сообщений что

увеличивает трафик и создает дополнительные задержки. Во втором ― как

клиент так и сервер могут посылать запросы или сообщения асинхронно.

Клиент более сложен, т.к. он должен уметь обрабатывать входящий

запросы и различать ответы на разные запросы. Но задержки сводятся к

минимуму. Поэтому далее я буду рассматривать второй вариант.

Клиент-серверное взаимодействие сводится к обмену сообщения в xml

формате поверх, зашифрованного с помощью SSL, tcp/ip соединения. Все

сообщения делятся на классы по типу решаемых задач и уровням доступа.

Например

0 уровень (клиент не авторизован) ― возможны только сообщения о ходе в

систему либо регистрации

1 уровень (демо доступ) ― любые сообщения связанные с Solo игрой

2 уровень (полный доступ)

Любое сообщение содержит имя команды, уникальный номер и блок данных.

Сообщения записываются в стек и обрабатываются последовательно.

Сообщения могут быть 3х видов:

1.требующие запрос к БД

2.требующие запрос к Игровому боту

3.требующие доставить их другому игроку(ам)

Так же сообщения 3-го типа могут создаваться СУБД для уведомления о

некоторых событиях в системе. Сообщения 3-го типа при обработке просто

перемещаются в исходящую очередь нужного клиента(ов). Сообщения 3-го

типа от СУБД извлекаются из специальной временной таблицы блоком

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

Уведомление о появлении таких сообщений осуществляется с помощью

команды NOTIFY (PostgreSQL) и обработка происходит сразу после

создания сообщения.

Структура БД

В БД создаются необходимые таблицы и представления. И для каждой

клиентской команды, требующей запроса к БД, создается хранимая

процедура, которая ее обрабатывает. Таким образом вся логика

находится только внутри базы данных. Исключение ― бот для Solo игры.

Он будет запускаться в сервере и общаться напрямую с клиентом, а ходы

будут записываться в БД.

Структура сервера

Сервер будет состоять из 4х блоков

1.Главный блок. Этот блок запускает дочерние потоки и осуществляет

ожидание клиентов

2.Блок работы с базой данных. Содержит пул соединений с БД. Получает

Запросы от рабочих модулей, передает их в базу и отдает ответ.

3.Рабочий блок. Поток, который обеспечивает работу одного клиента.

Принимает запросы и передает их нужным блокам.

4.Бот. Поток, который запускается для Solo игры. (возможно будет

работать внутри потока запущенного 3-м блоком)

Блоки взаимодействую друг с другом с помощью очередей сообщений и

общей памяти. Для доступа к разделяемым ресурсам используются

блокировки разных типов.

Главный блок после запуска считывает конфигурацию, подключается к БД и

проверяет ее готовность. Далее открывает клиентский порт и ожидает

подключений. При подключении создает новый рабочий поток и передает

ему пользователя.

Пользователь после подключения получает статус 0 и ему доступны только

2 команды: авторизироваться или зарегистрироваться. В случае успешного

прохождения авторизации ему присваивается статус 1 или 2 в зависимости

от вида его учетной записи. Далее в зависимости от статуса

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

клиента или обрыве связи выполняется де-авторизация пользователя.

В общей памяти сервера находятся списки он-лайн пользователей, связи

id из БД и группы для рассылок сообщений в зависимости от текущих игр.

Этапы 1, части 1-2 выполнены:

Этап 1.

1. Альфа-версия документации API (выполнено)

2. Альфа-версия схемы базы (выполнено)

3. Альфа версия сервера с основным игровым функционалом

+ тесты + административный веб-интерфейс с минимальными возможностями

Этап 2.

4. Бета версия сервера с полным набором возможностей

5. Бета-тестирование

Этап 3.

6. Окончательная доработка проекта

7. Тестирования продукта

Оплата как почасовая, так и проектно, в зависимости от вашего выбора.

Если вы из Беларуси - возможна личная встрача.