Я в своем проекте использую только открытый код. Например, boost, openSSL, OGRE, Bullet Engine, MyGUI, Qt.
Открытый это когда вся библиотека доступна в виде исходников.
В основе лежит идея сценариев. Существует сценарий (чистая логика) и контекст сценария.
Сценарий — это последовательность действий (отправка пакетов и реакция на получение), которые совершаются над контекстом.
С сессией (сетевое соединение) связан набор контекстов, каждый из которых предназначен для своего сценария (например, обмен данными и авторизация).
Но когда идет отработка одного их них — остальные должны блокироваться. То есть работа по сессии ведется всегда только по одному сценарию.
Например, у Мастера много сессий с нижестоящими Slave. По каждой сессии отрабатывает свой сценарий.
Сценарию просто подсовывают пакет и он ищет контекст, который с ним связан (либо по ID_Session, либо по ключу, который передан внутри пакета).
Далее совершаются какие-то свои действия по сценарию.
Один сервер не потянет даже 50к. Даже War Thunder имеет больше клиентов. Физически для расчета физики и проведения других действий нужно много процессорного времени.
Тут нужно искать компромисс: одна крайность — научный идеализм (быстрее, надежнее) и вторая — финансовая составляющая.
Как вариант можно сделать так: есть дублирующий и рабочий Мастер. Рабочий Мастер раз в секунду (можно менять тайм аут) сбрасывает информацию о соединениях на дублирующий. И в случае падения рабочего дублирующий берет на себя роль рабочего.
НО из этого идет удорожание проекта. Пока мой вариант дешевле. Для дублирующего мастера нужно дополнительное железо.
Какие варианты отказа мастера Вы имеете ввиду? Сгорел комп, упала сеть или что? Может мы друг друга не поняли? Опишите все варианты — получите на них варианты решения. В общем случае так задачу решать нельзя.
«Увеличиваем количество серверов и ставим балансировщик нагрузки.» — я так и сделал, Мастер выполняет функции балансировщика нагрузки. Например, он направляет нового клиента на самый ненагруженный Slave.
Для такой задачи (онлайн игры) надежность не нужна. Это не банковский сервер.
В перспективе — можно задумать над этой задачей.
В WoT такое постоянно происходит (падения, потом железа больше сделали — перестали падать). Над этим можно сделать еще кучу надстроек для повышения надежности. Главное есть такая возможность.
На счет простой. Такая архитектура из одного сервера не потянет большого числа клиентов. У Вас есть идея как это сделать? Я выслушаю Ваши идеи.
Можно проверить и под Ubuntu. Просто взять проект Share, NetTransport и MMOEngine и использовать совместно с Qt — что бы видеть результат (все библиотеки полностью кросс платформенные).
У базового класса есть метод Work(). Вызывать его в главном потоке (например таймер Qt) и проверять наличие новых событий. Новые события обрабатывать и делать что-то в Qt — например выводить сообщения. Есть класс TDstEvent и TSrcEvent. MMOEngine — наследуется от TSrcEvent — он источник событий. Нужно наследовать свой класс от TDstEvent и задать в MMOEngine указатель на this внутри объекта и забирать события.
То есть (написал наспех, могут быть ошибки, важен сам принцип):
class THandler: public TDstEvent
{
  nsMMOEngine::TClient client;
public:
  THandler()
  {
    client.SetDstEvent(this);
  }
  void Work()
  {
    client.Work();
    nsMMOEngine::TEvent* pEvent = client.GetEvent();// опрос на события
    …
  }
}
Ну например как происходит авторизация в WoT — доступен список кластеров, его например можно задать через Web-сервер. Тот же принцип. Такая архитектура самая простая. Для игр нет необходимости высокой надежности.
На какой кластер подключиться — должен решать сам клиент. Клиенту доступен IP Мастера (то есть есть связка Кластер-IP Мастера). Если какой-то мастер станет недоступен — кластер вырубается и все клиенты кластера теряют соединение. Примерно так же как в World of tanks.
Открытый это когда вся библиотека доступна в виде исходников.
Сценарий — это последовательность действий (отправка пакетов и реакция на получение), которые совершаются над контекстом.
С сессией (сетевое соединение) связан набор контекстов, каждый из которых предназначен для своего сценария (например, обмен данными и авторизация).
Но когда идет отработка одного их них — остальные должны блокироваться. То есть работа по сессии ведется всегда только по одному сценарию.
Например, у Мастера много сессий с нижестоящими Slave. По каждой сессии отрабатывает свой сценарий.
Сценарию просто подсовывают пакет и он ищет контекст, который с ним связан (либо по ID_Session, либо по ключу, который передан внутри пакета).
Далее совершаются какие-то свои действия по сценарию.
Тут нужно искать компромисс: одна крайность — научный идеализм (быстрее, надежнее) и вторая — финансовая составляющая.
НО из этого идет удорожание проекта. Пока мой вариант дешевле. Для дублирующего мастера нужно дополнительное железо.
Для такой задачи (онлайн игры) надежность не нужна. Это не банковский сервер.
В перспективе — можно задумать над этой задачей.
На счет простой. Такая архитектура из одного сервера не потянет большого числа клиентов. У Вас есть идея как это сделать? Я выслушаю Ваши идеи.
У базового класса есть метод Work(). Вызывать его в главном потоке (например таймер Qt) и проверять наличие новых событий. Новые события обрабатывать и делать что-то в Qt — например выводить сообщения. Есть класс TDstEvent и TSrcEvent. MMOEngine — наследуется от TSrcEvent — он источник событий. Нужно наследовать свой класс от TDstEvent и задать в MMOEngine указатель на this внутри объекта и забирать события.
То есть (написал наспех, могут быть ошибки, важен сам принцип):
class THandler: public TDstEvent
{
  nsMMOEngine::TClient client;
public:
  THandler()
  {
    client.SetDstEvent(this);
  }
  void Work()
  {
    client.Work();
    nsMMOEngine::TEvent* pEvent = client.GetEvent();// опрос на события
    …
  }
}