Comments 30
Что случится, если мастер будет недоступен? Как определяется, к какому мастеру коннектится клиент?
На какой кластер подключиться — должен решать сам клиент. Клиенту доступен IP Мастера (то есть есть связка Кластер-IP Мастера). Если какой-то мастер станет недоступен — кластер вырубается и все клиенты кластера теряют соединение. Примерно так же как в World of tanks.
На какой кластер подключиться — должен решать сам клиент.
На основании чего?
Если какой-то мастер станет недоступен — кластер вырубается и все клиенты кластера теряют соединение.
Единая точка отказа? А зачем тогда такая хрупкая архитектура?
Ну например как происходит авторизация в WoT — доступен список кластеров, его например можно задать через Web-сервер. Тот же принцип. Такая архитектура самая простая. Для игр нет необходимости высокой надежности.
Такая архитектура самая простая.
Отнюдь. Самая простая — один сервер.
Для игр нет необходимости высокой надежности.
Правда? То есть потери (денежные и репутационные) из-за того, что у вас несколько десятков-сотен тысяч игроков во время напряженного игрового момента были выкинуты из системы, вас не волнуют?
В WoT такое постоянно происходит (падения, потом железа больше сделали — перестали падать). Над этим можно сделать еще кучу надстроек для повышения надежности. Главное есть такая возможность.
На счет простой. Такая архитектура из одного сервера не потянет большого числа клиентов. У Вас есть идея как это сделать? Я выслушаю Ваши идеи.
На счет простой. Такая архитектура из одного сервера не потянет большого числа клиентов. У Вас есть идея как это сделать? Я выслушаю Ваши идеи.
В WoT такое постоянно происходит (падения, потом железа больше сделали — перестали падать).
И что? Для вас WoT — это ориентир, если у них плохо, то и вам можно?
Такая архитектура из одного сервера не потянет большого числа клиентов. У Вас есть идея как это сделать?
Увеличиваем количество серверов и ставим балансировщик нагрузки.
«Увеличиваем количество серверов и ставим балансировщик нагрузки.» — я так и сделал, Мастер выполняет функции балансировщика нагрузки. Например, он направляет нового клиента на самый ненагруженный Slave.
Для такой задачи (онлайн игры) надежность не нужна. Это не банковский сервер.
В перспективе — можно задумать над этой задачей.
Для такой задачи (онлайн игры) надежность не нужна. Это не банковский сервер.
В перспективе — можно задумать над этой задачей.
Мастер выполняет функции балансировщика нагрузки. Например, он направляет нового клиента на самый ненагруженный Slave.
При отказе (правильно размещенного) балансировщика нагрузки клиенты этого не замечают вообще. А у вас при отказе мастера все клиенты теряют связь с сервером.
Для такой задачи (онлайн игры) надежность не нужна.
Понятно. Скажите название проекта, чтобы я заранее в черный список записал.
Какие варианты отказа мастера Вы имеете ввиду? Сгорел комп, упала сеть или что? Может мы друг друга не поняли? Опишите все варианты — получите на них варианты решения. В общем случае так задачу решать нельзя.
Аппаратный отказ сервера, отказ инфраструктурного ПО, отказ вашего собственного ПО, пропадение сетевой связности между сервером и интернетом.
Я, правда, перестал понимать, что же вы изначально имели в виду, когда писали:
Я, правда, перестал понимать, что же вы изначально имели в виду, когда писали:
Если какой-то мастер станет недоступен — кластер вырубается и все клиенты кластера теряют соединение.
Как вариант можно сделать так: есть дублирующий и рабочий Мастер. Рабочий Мастер раз в секунду (можно менять тайм аут) сбрасывает информацию о соединениях на дублирующий. И в случае падения рабочего дублирующий берет на себя роль рабочего.
НО из этого идет удорожание проекта. Пока мой вариант дешевле. Для дублирующего мастера нужно дополнительное железо.
НО из этого идет удорожание проекта. Пока мой вариант дешевле. Для дублирующего мастера нужно дополнительное железо.
Как можно сделать — я и сам знаю, спасибо. А вот в вашей архитектуре этого заложено не было. Рекомендую задуматься о том, что эта проблема у вас более чем в одном месте.
НО из этого идет удорожание проекта. Пока мой вариант дешевле. Для дублирующего мастера нужно дополнительное железо.
Вариант с одним сервером — еще дешевле.
Вы ошибаетесь на счет надежности — все слишком сильно зависит от типа игры. В WoT потеря одного боя никак на игру не влияет и потому не важна. Но в тоже время если в MMORPG игроков выкинет во время сложного рейдового боя(где например ограничено время или количество попыток) или в MOBA во время рейтингового/турнирного боя это не просто огорчит пользователя, но и нанесет вред его «прогрессу». Или вариант когда для доступа к сражению нужно вообще заплатить(игровыми или реальными деньгами не важно) — надежность очень важна.
Почему же сразу единая точка отказа? Клиент подключается к какой-то известной ему точке, получает от нее список других доступных точек и стучится к ним по очереди, пока кто-нибудь не примет. А как еще иначе вы хотели? Получение адреса первой точки — вводится руками или из конфига.
И вообще, что вы так на человека набросились (ниже по ветке)? Это же первая версия, со временем все исправится. Человек сюда и пришел за помощью, чтобы его проектом заинтересовались и помогли его развивать. А тон ваших комментариев напрочь отбивает это желание. Прямо-таки чувствуются брызги слюны. Поспокойнее, помягче :) Знаете, если вот так месяцами только думать, а как же лучше сделать, руки до написания кода никогда не дойдут.
Я сам давно мечтал найти/сделать что-то подобное — открытый расширяемый кластерный сервер, а тут на тебе! Практически один в один мои мысли. Однако же и я позанудствую. Почему такое скупое описание? Можно было написать хотя бы основные идеи, которые лежат в основе реализации. Пусть без обоснования, но хоть было бы о чем говорить в комментах!
Gauss1985, да, и поправьте, пожалуйста, кодировку всех файлов в репозитории на UTF-8 — смотреть его онлайн невозможно.
И вообще, что вы так на человека набросились (ниже по ветке)? Это же первая версия, со временем все исправится. Человек сюда и пришел за помощью, чтобы его проектом заинтересовались и помогли его развивать. А тон ваших комментариев напрочь отбивает это желание. Прямо-таки чувствуются брызги слюны. Поспокойнее, помягче :) Знаете, если вот так месяцами только думать, а как же лучше сделать, руки до написания кода никогда не дойдут.
Я сам давно мечтал найти/сделать что-то подобное — открытый расширяемый кластерный сервер, а тут на тебе! Практически один в один мои мысли. Однако же и я позанудствую. Почему такое скупое описание? Можно было написать хотя бы основные идеи, которые лежат в основе реализации. Пусть без обоснования, но хоть было бы о чем говорить в комментах!
Gauss1985, да, и поправьте, пожалуйста, кодировку всех файлов в репозитории на UTF-8 — смотреть его онлайн невозможно.
Почему же сразу единая точка отказа?
Потому что автор поста написал «Если какой-то мастер станет недоступен — кластер вырубается и все клиенты кластера теряют соединение.» Это несколько отличается от того, что описали вы.
Это же первая версия
Ах если бы.
И вообще, что вы так на человека набросились (ниже по ветке)?
За позицию «Для игр нет необходимости высокой надежности.»
В основе лежит идея сценариев. Существует сценарий (чистая логика) и контекст сценария.
Сценарий — это последовательность действий (отправка пакетов и реакция на получение), которые совершаются над контекстом.
С сессией (сетевое соединение) связан набор контекстов, каждый из которых предназначен для своего сценария (например, обмен данными и авторизация).
Но когда идет отработка одного их них — остальные должны блокироваться. То есть работа по сессии ведется всегда только по одному сценарию.
Например, у Мастера много сессий с нижестоящими Slave. По каждой сессии отрабатывает свой сценарий.
Сценарию просто подсовывают пакет и он ищет контекст, который с ним связан (либо по ID_Session, либо по ключу, который передан внутри пакета).
Далее совершаются какие-то свои действия по сценарию.
Сценарий — это последовательность действий (отправка пакетов и реакция на получение), которые совершаются над контекстом.
С сессией (сетевое соединение) связан набор контекстов, каждый из которых предназначен для своего сценария (например, обмен данными и авторизация).
Но когда идет отработка одного их них — остальные должны блокироваться. То есть работа по сессии ведется всегда только по одному сценарию.
Например, у Мастера много сессий с нижестоящими Slave. По каждой сессии отрабатывает свой сценарий.
Сценарию просто подсовывают пакет и он ищет контекст, который с ним связан (либо по ID_Session, либо по ключу, который передан внутри пакета).
Далее совершаются какие-то свои действия по сценарию.
Во-первых, это плюсы C++ – скорость, возможность отладки.Всё это можно и с помощью других языков, будет соизмеримо по быстродействию.
Во-вторых, изучать новый язык ради одного компонента?Всего лишь? Серверная часть — одна из самых главных составляющих MMO…
В результате, по моим подсчетам, сервер вполне может держать до миллиона клиентов
Видео-демонстрация:А в видео всего парочка клиентов. Хотелось бы увидеть в видео тест с, ладно, не миллионом, но хотя бы со 100к клиентов.
p.s. как мне сие творение на Ubuntu проверить?
upd: раз требуется DirectX, то, видимо, никак =/
Можно проверить и под 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();// опрос на события
    …
  }
}
У базового класса есть метод 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();// опрос на события
    …
  }
}
В принципе, если не важна общее состояние игры (т.е. все пользователи могут видеть общее состояние), то сойдет, а когда еще между серверами надо синхронизировать — дополнительные нагрузки, причем «дедушка контролирует несколько пап, которые контролируют несколько сыновей» выглядит очень нагруженно для дедушки.
В моем прошлом была реализация высоконагруженного сервера, когда контроллером системы являлись сами «мастера», а супермастер контролировал slave: супермастер следил за нагрузкой и распределял пользователей самостоятельно на этапе авторизации (при этом сам занимаясь авторизацией), что позволяло одновременно распределять на общие сервера. Slave, как по вашему, скидывал в «очередь» сообщений специальные данные, которые порожденные в определенном количестве (для избежании высокой нагрузки) мастера (8 на сервер) обрабатывали по возможности элементы забирая их из очереди и помещали в очередь ответов, которая рассылалась с помощью Slave. С помощью такой очереди каждый мастер мог отвечать за свою «область» или синхронизироваться с помощью «запросов» и «ответов» других мастеров.
Надеюсь наглядно объяснил. =)
В моем прошлом была реализация высоконагруженного сервера, когда контроллером системы являлись сами «мастера», а супермастер контролировал slave: супермастер следил за нагрузкой и распределял пользователей самостоятельно на этапе авторизации (при этом сам занимаясь авторизацией), что позволяло одновременно распределять на общие сервера. Slave, как по вашему, скидывал в «очередь» сообщений специальные данные, которые порожденные в определенном количестве (для избежании высокой нагрузки) мастера (8 на сервер) обрабатывали по возможности элементы забирая их из очереди и помещали в очередь ответов, которая рассылалась с помощью Slave. С помощью такой очереди каждый мастер мог отвечать за свою «область» или синхронизироваться с помощью «запросов» и «ответов» других мастеров.
Надеюсь наглядно объяснил. =)
Если нужно готовое работающее решение по адекватным ценикам — есть Photon Cloud (cloud.exitgames.com).
Sign up to leave a comment.
Описание ММО компонента в составе игрового движка «Tornado»