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

Web/сайты Прочее

Был(а) онлайн: 22.05.18 19:51
Umen 24 года

1.0 Был(а) онлайн: 22.05.18 19:51

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

КОРОТКОЕ ИЗЛОЖЕНИЕ:

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

Протокол:
Допустимы 2 варианта работы заказчика с сервером
1.синхронная, односторонняя (аналог ? HTTP либо SOAP)
2.асинхронная (аналог - Jabber)
В первом случае только заказчик посылает сообщение серверу а сервер
только отвечает на него. Данный вариант дозволяет создавать более
примитивных заказчиков, упрощает синхронизацию, но заказчик должен
периодично опрашивать сервер не возникло ли новых сообщений что
увеличивает трафик и создает добавочные задержки. Во втором ? как
заказчик так и сервер могут посылать запросы либо сообщения асинхронно.
Заказчик больше труден, т.к. он должен уметь обрабатывать входящий
запросы и различать результаты на различные запросы. Но задержки сводятся к
минимуму. Следственно дальше я буду рассматривать 2-й вариант.
Заказчик-серверное взаимодействие сводится к обмену сообщения в 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. Тестирования продукта


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

Чтобы добавить заявку к этому заказу, нужно войти или зарегистрироваться

Мой блок

22.05.18 19:51
Umen 24