Долго искал открытый и бесплатный ММО движок в интернете. Либо это был откровенный бред, либо платный проект. Вообще, этих движков среди компаний, делающих ММО РПГ, полно, но каждая компания пишет свой движок. Единого стандарта нет. Пришлось самому его писать — и я таки сделал это. Долго продумывал интерфейс библиотеки. Потом также долго воплощал в жизнь. Потом допиливал безопасность (AES и RSA на основе OpenSSL, проблема «Man-in-the-middle» устранена). Движок получился кроссплатформенным (работа с сетью благодаря boost). Обмениваться пакетами можно как с помощью TCP, так и UDP.
В результате, по моим подсчетам, сервер вполне может держать до миллиона клиентов (все зависит от железа, чем больше, тем лучше). Это возможно благодаря кластерной организации сервера.
Итак, для клиентской стороны представлен интерфейс Client. С помощью него можно авторизоваться и потом обмениваться данными с сервером.
С сервером дела обстоят сложнее. Он состоит из трех слоев. Первый слой это – Slave. Именно с ним работает клиент после авторизации. Второй слой – Master. Через него проходит авторизация клиента. Когда клиент авторизуется, то используется IP мастера. Далее мастер направляет для соединения клиента на наименее загруженный в кластере Slave. Мастер является главой кластера и обычно с ним связана какое-то количество Slave. С помощью мастера можно объединять клиенты в группы (например, для проведения боя в одной комнате, чтобы физически это был один компьютер). Тогда мастер перераспределяет клиентов так, что бы они имели сетевое соединение с одним Slave. Происходит переброска клиентов (перекоммутация).
Если количество кластеров больше одного и между ними нужно обмениваться данными, то используется SuperServer (третий слой). Суперсервер связывает кластеры в агломерацию. Суперсервер владеет информацией обо всех клиентах агломерации и контролирует процесс авторизации (например, запрет на авторизацию на двух кластерах по одним и тем же данным авторизации клиента).
Особенности реализации.
В основе лежит идея сценариев. Существует сценарий (чистая логика) и контекст сценария.
Сценарий — это последовательность действий (отправка пакетов и реакция на получение), которые совершаются над контекстом.
С сессией (сетевое соединение) связан набор контекстов, каждый из которых предназначен для своего сценария (например, обмен данными и авторизация).
Но когда идет отработка одного их них — остальные должны блокироваться. То есть работа по сессии ведется всегда только по одному сценарию.
Например, у Мастера много сессий с нижестоящими Slave. По каждой сессии отрабатывает свой сценарий.
Сценарию просто подсовывают пакет и он ищет контекст, который с ним связан (либо по ID_Session, либо по ключу, который передан внутри пакета).
Далее совершаются какие-то свои действия по сценарию.
Исходный код движка: github.com/RamilGauss/MMO-Framework
Видео-демонстрация: www.youtube.com/watch?v=g8IlYRepclE
В результате, по моим подсчетам, сервер вполне может держать до миллиона клиентов (все зависит от железа, чем больше, тем лучше). Это возможно благодаря кластерной организации сервера.
Итак, для клиентской стороны представлен интерфейс Client. С помощью него можно авторизоваться и потом обмениваться данными с сервером.
С сервером дела обстоят сложнее. Он состоит из трех слоев. Первый слой это – Slave. Именно с ним работает клиент после авторизации. Второй слой – Master. Через него проходит авторизация клиента. Когда клиент авторизуется, то используется IP мастера. Далее мастер направляет для соединения клиента на наименее загруженный в кластере Slave. Мастер является главой кластера и обычно с ним связана какое-то количество Slave. С помощью мастера можно объединять клиенты в группы (например, для проведения боя в одной комнате, чтобы физически это был один компьютер). Тогда мастер перераспределяет клиентов так, что бы они имели сетевое соединение с одним Slave. Происходит переброска клиентов (перекоммутация).
Если количество кластеров больше одного и между ними нужно обмениваться данными, то используется SuperServer (третий слой). Суперсервер связывает кластеры в агломерацию. Суперсервер владеет информацией обо всех клиентах агломерации и контролирует процесс авторизации (например, запрет на авторизацию на двух кластерах по одним и тем же данным авторизации клиента).
Особенности реализации.
В основе лежит идея сценариев. Существует сценарий (чистая логика) и контекст сценария.
Сценарий — это последовательность действий (отправка пакетов и реакция на получение), которые совершаются над контекстом.
С сессией (сетевое соединение) связан набор контекстов, каждый из которых предназначен для своего сценария (например, обмен данными и авторизация).
Но когда идет отработка одного их них — остальные должны блокироваться. То есть работа по сессии ведется всегда только по одному сценарию.
Например, у Мастера много сессий с нижестоящими Slave. По каждой сессии отрабатывает свой сценарий.
Сценарию просто подсовывают пакет и он ищет контекст, который с ним связан (либо по ID_Session, либо по ключу, который передан внутри пакета).
Далее совершаются какие-то свои действия по сценарию.
Ссылки
Исходный код движка: github.com/RamilGauss/MMO-Framework
Видео-демонстрация: www.youtube.com/watch?v=g8IlYRepclE