Архитектура MMO сервера
 

Есть желание попробовать написать ММО клиент-сервер и хотелось бы начать с правильной архитектуры. Есть ли у кого опыт в таких делах?

Пока выделил следующие составляющие (деление на сервера):
1. Авторизация, лодбалансер, бизнес логика
2. Сервера зон/комнат
3. База данных

Как-то так:


Основной вопрос состоит в правильной структуре каждого из серверов. Тут пока опыта почти нет. Хотелось бы услышать мнение об этом у участников сообщества.

Ответ: Архитектура MMO сервера
 

Ответ: Архитектура MMO сервера
 

pax
у меня есть некий опыт написания серверов которые работают, потому расскажу всякое

сначала по терминам
PCU - Peak Concurrent user, грубо говоря сколько сокетов переварит ваш сервак
RPS - Requests Per Second, если обработка не упирается в цпу то это bandwidth/packet_size, при пакете в 5 кб и канале 100 мбит, RPS будет 2.5k (тысяч ! не миллионов)

1) собсно PCU это грубо говоря сколько сокетов может держать ОС, линукс сразу идет НАХ*Й, ибо говно там в сетевом стеке, берем FreeBSD, на всяких ерлангах одна машина (12 ядер, 128 гб рамы) тянет 2kk PCU

2) внизу сервер БД, замечательная штука да, а теперь представим что сверху у нас 100500 серверов, одновременно пытается играть 5 млн юзеров, везде что-то двигается, такая байда может нагенерить трафика на бд в районе 200-400 гб\s, можно конечно взять один йоба сервак, вставить туда 64 ядра, 512-1024 гб рамы и пидорасить тупо 10 ethernet карт по 40 гб\с, но это не выход =) а каналов по 400 гб\с щас ни у кого толком нету

выход это использовать горизонтально масштабируемую бд, разделить их использование по контексту, например база профилей игроков для статистики, база профилей персонажей и их инвертаря и квестов, для каждого сектора локации отдельная бд

плюс каждая бд должна бекапится, скажем если дядя дима прийдет к стойке с ломом и начнет пидорасить все серваки то хороший кластер должен это пережить, для этого используем взаимозаменяемые на лету серваки бд с полной репликацией

для такой цели я рекомендовал бы большинство серверов ставить NoSQL, например MongoDB, и делать там реплики по 3 сервера и обязательно покупать реалтайм бекап (http://www.mongodb.com/press/10gen-a...backup-service мы этот юзаем, он бекапит журнал и потом можно восстановить любую точку во времени), но некоторые (статистика точно) должны быть SQL ибо к ним идут пидорские запросы наподобие "а дай мне топ 10 юзеров" который NoSQL не переваривает

3) авторизация и лобби, они ОЧЕНЬ топорные на логике, по-сути логики там нету, там даже не нужно постоянное подключение, это просто REST API, а если так то юзаем мощный веб-сервер, например Mongrel2 или NGINX, надо отдать должное этим монстрам и на среднем серваке они займут канал 10 гб\с полностью с всего ~10-25% CPU

думаю тут описывать сильно не надо, код авторизации тупо является посредником между веб сервером и бд, лучше всего его написать на C и вшить прямо в код веб сервера (в то место где он CGI делает)

делать балансер тут вообще нету смысла, разве что у тебя будет ОТДЕЛЬНАЯ СТОЙКА И ОТДЕЛЬНЫЙ СВИТЧ на это, единственный тип балансировки который взлетает на highload - ethernet balancing, то есть у нас N серваков у которых по две сетевые карты, одни карты торчат аплинком в мир, вторые карты торчат тупо в один лоу-латенси свитч, в этот свитч торчат все обработчики запросов, обработчики запросов тоже имеют по две карты (одна в свитч, другая аплинк), и когда на балансер приходит ip пакет с запросом то он у него меняет ethernet адресс ! таким образом наш чудо свитч по матрице комутации перекидывает пакет очень быстро, с помощью round-robin можно так забалансировать очень много трафика

4) сервера комнат, думаю надо банально ставить монстро-серваки по много ядер и много рамы, клиенты будут с ними конектится постоянно, потому тут всё зависит от контекста использования - ведь игровая логика бывает разная, всяким MMORPG надо коллизии считать например

этим серверам нужно кешировать состояния мира чтобы не лазить в бд иначе слишком сильно увеличится латентность обработки запросов

верх эволюции это горизонтальное масштабирование в рамках одной комнаты, но я такого не видел, например в EVE Online у них по серверу на звёздную систему, если в какой системе будет происходить бой то они вытягивают сервер помощнее из пула и запускают на нем эту систему

думаю можно это отдельно обсудить если скажешь какой жанр игр нужно =)

Ответ: Архитектура MMO сервера
 

Я сейчас изучаю эту тему. Сделал простенький сервер на node.js + socket.io
Клиент Unity3D + UnitySocketIO

А вообще для MMO есть готовое решение на node.js Pomelo framework (схемы архитектуры)

В Pomelo не вникал, показалось сложно.

Ответ: Архитектура MMO сервера
 

Данных, которые нужно сохранять периодически в БД на самом деле не так и много- покупка чего то там, левел ап, шмот. Все остальные данные в реалтайме можно держать в комнате на аватаре игрока, и писать в бд при дисконнекте. http://habrahabr.ru/company/mailru/blog/182088/ тут интересно написано. socket.io юзает веб сокеты, как то не тру. Pomelo удобоваримо только для сессионных игр.

Ответ: Архитектура MMO сервера
 

Если использовать node.js для серверной логики, то тут есть плюсы и минусы. Плюсы начнём с того что это лёгкость в модифицируемости и скорость разработки - минусы, конечно C++ с правильными руками будет намного мощнее.
Но критические зоны, например коллизия и математика без проблем может быть вынесена в C++ Addon'ы (модули) для node.js, что также можно делать позже (но не слишком).

Относительно сетевого трафика, тут по любому нужно писать свой сериализатор а не использовать тот же socket.io, т.к. унаследуешь кучу проблем от него, которые например Unity вообще не упали. Плюс если писать свой протокол, то можно нормально стримы заюзать от TCP, а не пакетно обрабатывать всё.
Парсер снова, может быть вынесен на C++, и там уже генерить V8 объекты (JSON), которому node.js будет рад.
Есть вот такой протокол, очень многообещающий: http://kentonv.github.io/capnproto/

Также очень зависит от архитектуры твоего игрового сервера.
"ММО, МООшке рознь". Ты упомянул комнаты/зоны, речь идёт о разбиении мира на зоны (как в давние времена в WoW с предзагрузкой при переходах), или как в EVE, или речь идёт о матчах, как в LoL / Dota 2 / BF3 и т.п. играх?

БД, как jimon сказал нужно качественно кластерить и иметь возможность восстановления реплик.
БД использовать для редко нужных данных и периодическом сохранении данных, необходимых для восстановления игрового состояния.
Большинство данных должно держаться в раме и там же оперироваться игровыми серверами, периодически паралельно сохраняя то что нужно в бд.
Если сервера должны обмениваться данными между собой (сервера в плане процессов), то заводи redis, т.к. он очень эффективен для реалтайм быстрых транспортов. Redis - это реалтайм хранилище, подобно простой бд с разными плюшками.

Если тебе нужно общаться между серверами напрямую - например lobby сервер может поискать игровые сервера, и если lobby имеет приоритет на игровыми, попросить игровой сервер на создание игровой комнаты. В подобной ситуации тебе нужно напрямую общаться между серверами.
Тут я бы посоветовал ZeroMQ, он и прост и сложен. Просто для старта, и сложность заключается не в самой либе, а возможностях для сложных архитектурных решений коммуникации между процессами.

Даже логин сервер - должен скейлиться.
Авторизация - это побочный процесс, как addon в процессе, его задача получить данные логина, авторизировать/отклонить, и закинуть данные сессии в redis чтобы другие сервера/процессы могли получить эти данные, также сообщить запрашивающему процессу о статусе авторизации.

Я бы также совмещал RESTful с Real-Time. Большинство должно быть как раз RESTful до игры, а сама игра Real-Time.


Отличная практика для развития в этой сфере - это анализ существующих игр и их архитектуры.
Вот список рекомендуемых примеров: EVE; FireFall; Dota 2 / LoL; BF3.
Каждый из этих примеров утилизирует REST и RT везде. Что-то на REST'е, что-то на RT (realtime).

Ответ: Архитектура MMO сервера
 

Спасибо отписавшимся, я пока не преследую планы по глобальному завоеванию мира, поэтому мои запросы примерно такие:

1. Допустим 5к игроков одновременно максимум.
2. Игровой мир это комнаты с загрузкой, не единый мир.
3. Сессии не длинные, по трафику допустим это шутер с числом игроков в комнате не превышающим 50-100 (в большинстве случаев будет меньше).
4. Основной геймплей - бои длительностью до 20-30 минут (к примеру WoT).

Ответ: Архитектура MMO сервера
 

шутер ? на 100 человек ? имхо слишком сложно :crazy: ты думаешь не о том, всякая бд, авторизация и прочее для 5к PCU можно тупо на php на VDS поднять за 20$\мес и взлетит, а вот сервер ... я бы сказал что для 100 человек это невозможно даже, 20 человек территориально ограничено - более реально, по крайней мере нужно будет раскидывать серваки по всем частям мира чтобы для локальных юзеров был меньший пинг

сетевые реалтайм шутера это как бы верх сетевых технологий, нужно будет юзать UDP, писать сложный предикшен и сервак с возможностью отката времени и тд, да и еще 100 человек, будет очень сложно обеспечить комфорт в игре, хотя написать чтобы заработало хоть как-то можно за пару недель

всякие сетевые танки и самолетики куда проще делать ибо там игрок не меняет положение в пространстве очень резко

Ответ: Архитектура MMO сервера
 

Для каких целей?

Ответ: Архитектура MMO сервера
 

Шутер я предположил по трафику, шутер я писать не буду. Я уже на проекте с роботами понял что синхронизация topdown шутера очень сложная. Надо делать всякие обманы чтобы выглядело нормально. Допустим это космосим (опять же к примеру) и летать надо не на истребителях, а на более тяжелых кораблях.

Я думаю для точного расчета попаданий. В статье про сеть в Source это описано.

Ответ: Архитектура MMO сервера
 

pax
ну реально, если тебе хватит латентности в 200-500 мс для космосима типа EVE, то вполне можно напедалить простенький сервер на 100 человек на банальном C и сокетах, это ни какой либо rocket science уже, думаю 1 средний дедик потянет всех твоих 5к игроков (50 комнат)

технологии довольно банальные, можешь взять TCP, вся игра происходит на сервере, а клиент просто отправляет на него действия, и потом их воспроизводит, нужно только добавить визуальную видимость того что действие типа началось происходить сразу после того как нажал

так делают в большинстве MMO где не требуется моментальная реакция на перемещение игрока

Ответ: Архитектура MMO сервера
 

Latency критичен только в играх где есть прямое взаимодействие между игроками - шутеры, топ-даун и т.п.
А игры с например целями Lineage, EVE и т.п. Latency не так критичен. Там даже можно иметь интерполяцию заместо экстраполяции, если нету никаких действий между игроками с элементами реакции, где от скорости реакции зависит прогресс игроков.

Если это комнаты, то нужно думать над развёрткой серверов в разных регионах (дата-центрах), и обслуживать эти регионы по отдельности (по стандарту) с возможностью и на глобальных сервах играть.

Если у тебя будет матч-мейкинг, то тут всё проблематично, т.к он с таким числом игроков просто не будет толком работать, нормальных матч-мейкинг с учётом рейтингов игроков и разными режимами игр и регионами требует миллионы игроков онлайн, чтобы не ждать по часу пока наберутся люди.

Следственно изначально, либо без режимов игры и учёта рейтинга, и вообще на одном сервере, а потом если поднимается число пользователей, добавлять регионы и уже по стандарту обслуживать игроков с этих регионов. Так будет ниже Latency и игроки довольны будут.

Либо сделать комнаты, в которые тупо можно присоединяться, заместо матчей где требуется набор игроков до начала игры.
Но это зависит от гейм-дизайна, контра например такое позволяет, а вот LoL или Dota 2 или стратежки - уже нет.

Ответ: Архитектура MMO сервера
 

Еще появилось два вопроса (не совсем связанных с mmo):

1. TCP пакеты доходят медленно. При пинге 32 мс пакеты доходят за ~270мс. Это так и должно быть или в коде вероятно проблемы? На локалхосте пакеты доходят за 5 мс.

2. Есть ли где статьи по реализации reliable udp? Есть желание попробовать написать такой протокол самому.

Ответ: Архитектура MMO сервера
 

pax

1) не должно быть, разве что у тебя 50+% потерь пакетов, может ты просто буфер не флашишь чтобы ОС сразу отправляла пакеты ?

2) есть разные готовые реализации, посмотри на гитхаб к примеру https://github.com/search?q=reliabil...al&ref=cmdform

Ответ: Архитектура MMO сервера
 

Есть ещё вариант с плохой сетью в которой пропадают пакеты, тогда пинг будет расти, из-за повторной отправки пропавших пакетов.

Ответ: Архитектура MMO сервера
 

flush на nodejs вроде автоматический при вызове socket.write, он может только вернуть false если не все данные были отправлены в кернел буфер и сохранены в очереди.

Ответ: Архитектура MMO сервера
 

TCP/IP это несколько другой уровень работающий сам по себе, независимо от твоего кода. Он сам обрабатывает пропавшие пакеты и досылает их, сам считает контрольные суммы пакетом, сам организует порядок пакетов.

Ответ: Архитектура MMO сервера
 

Nagles Algorithm - скорее всего. Нужно в настройках выставить NoDelay.
http://nodejs.org/api/net.html#net_s...odelay_nodelay
То же самое нужно и в Unity сделать.

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

Ответ: Архитектура MMO сервера
 

тормоза на node.js + unity

Ответ: Архитектура MMO сервера
 

jimon, net часть написана на C++, и основная логика как раз там.
Тем более не думаю что ты знаешь конкретно о чём говоришь, т.к. на node.js пишут высоконагруженные трейдеры рекламой для крупнейших ad серверов. Я лично знаком с многими в разных команиях в этой сфере.

Если ты видишь игру написанную на С++ которая лагует, ты же не будешь тыкать пальцем в С++ и говорить "ААааха, С++ - говно!". Это немного по децки не находишь?

Ответ: Архитектура MMO сервера
 

Ответ: Архитектура MMO сервера
 

В справке по ноду написано что
Со стороны Unity посмотрю.

PS: научил сервер клеить сообщения и отправлять все с постоянным sendRate. Так что можно наверное уже пробовать писать Boolean Combat на нем)

Ответ: Архитектура MMO сервера
 

Как думаете, нужно шифровать пакеты в ММО? Есть мнение, что если очень надо все равно расшифровать можно, только лишняя нагрузка на сервер...

Ответ: Архитектура MMO сервера
 

В танчиках вроде шифруют, но там уже один товарищ много расшифровал.
Может надо шифровать по ключу и ключ менять каждую неделю? :)

Ответ: Архитектура MMO сервера
 

Есть и такая мысль. Но лучше тогда менять не ключ, а алгоритм шифрования каждую неделю. Когда алгоритм известен, очень просто новый ключ узнать.

Ответ: Архитектура MMO сервера
 

алгоритм RSA всем известен, но я сильно сомневаюсь что это помогает "легко" узнать ключ.

Ответ: Архитектура MMO сервера
 

Ну вот архив .rar например не расшифровать же без ключа? Там какой то особенный алгоритм или я нуб и ничо в этом не понимаю? :)

Ответ: Архитектура MMO сервера
 

Ключик то в клиенте лежит, сервер отправляет свой открытый ключ, если кто-то захочет сделать фейк-клиент, с алгоритмом RSA тут и париться не надо будет, все просто.

Ответ: Архитектура MMO сервера
 

Согласно iso и госту надежными шифрами считаются только те у которых алгоритм открытый.
Именно публичность и независимая экспертиза может это подтвердить, а не авторы алгоритмов.
ЗЫЖ Сам однажды сделал шифр aes-256 - этот факт никакого преимущества в его взломе мне не дает, хотя точно знаю как он работает.

Открытые ключи должны распространяться через всякие системы сертификации.

Что же касается ммо, то важные данные вообще нежелательно пускать через инет, чтобы их никто не подделал, а все приходящие данные от клиента проверять на соответствие.

Например вместо того чтобы принимать данные о координатах игрока от клиента, лучше только принимать данные о том куда игрок хочет двигаться, а само движение считать на сервере.

Ответ: Архитектура MMO сервера
 

золотое правило: клиент всегда врет.
поэтому, как и сказал Самоделкин, надо все считать на сервере.

Ответ: Архитектура MMO сервера
 

Согласен со всем. Не буду ничего шифровать (кроме авторизации:Р). На сервере и так все проверяется...

Ответ: Архитектура MMO сервера
 

Можешь зашифровать базу данных с аккаунтами если там важная личная инфа клиентов.

Ответ: Архитектура MMO сервера
 

Именно таг!
Принцип Керкгоффса:

Ответ: Архитектура MMO сервера
 

Рар (причём тут рар?) не знает правильный ключ, он знает каким должен быть хеш информации при расшифровке её правильным ключом.

Ответ: Архитектура MMO сервера
 

Архивы созданные по ключу это же тоже шифрование?

Ответ: Архитектура MMO сервера
 

я к тому, что это не техническая особенность rar-компрессии, а в принципе приём. А так - да: тоже шифрование.

Ответ: Архитектура MMO сервера
 

Если данные нужно шифровать между сервером и клиентом, то что это за данные в первую очередь?

Как уже сказали - сервер всегда прав, клиент - лох.
Используй Authoritative политику общения между клиентом и сервером.
Клиент лишь "просит" сервер принимает решения.

В любой нормальной мультиплеер игре, клиент - это рендер, а сервер - это логика. Так и в ММО, следственно и необходимость шифровать данные просто пропадает.

Ответ: Архитектура MMO сервера
 

шифровка данных защищает от программ симулирующих действия игроков, тобишь разных ботов/радаров. Но как правило если сильно нужно то ключ взламывается очень быстро. Хотя даже не взламывается а находится/вычисляется.

Ответ: Архитектура MMO сервера
 

rar я привел как пример ;)

Ответ: Архитектура MMO сервера
 

Если игроки заинтересованы в создании ботов - то стоит поразмыслить на счёт игры как таковой и её геймплая. Но это оффтоп.

Ни одна игра не защищена от ботов, самое простое и лучше всего действующие боты это симуляция ввода.

Ответ: Архитектура MMO сервера
 

Помню когда был мал я играл в lineage 2. Так вот на одном сервере придумали защиту против ботов. Если запускаешь бота, то в инвентаре появляются невидимые предметы которые имеют вес и вызывают перегруз в итоге получается закосяченный герой.