Требуется замена заболевшего программиста с++ 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. Тестирования продукта


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