Извините, ничего не найдено.

Не расстраивайся! Лучше выпей чайку!
Регистрация
Справка
Календарь

Вернуться   forum.boolean.name > Программирование в широком смысле слова > Алгоритмика

Алгоритмика Об алгоритмах вообще; методы, обсуждения способов решения

Ответ
 
Опции темы
Старый 29.10.2013, 11:25   #1
pax
Unity/C# кодер
 
Аватар для pax
 
Регистрация: 03.10.2005
Адрес: Россия, Рязань
Сообщений: 7,568
Написано 3,006 полезных сообщений
(для 5,323 пользователей)
Архитектура MMO сервера

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

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

Как-то так:


Основной вопрос состоит в правильной структуре каждого из серверов. Тут пока опыта почти нет. Хотелось бы услышать мнение об этом у участников сообщества.
__________________
Blitz3d to Unity Wiki
(Offline)
 
Ответить с цитированием
Сообщение было полезно следующим пользователям:
impersonalis (29.10.2013)
Старый 29.10.2013, 11:35   #2
impersonalis
Зануда с интернетом
 
Аватар для impersonalis
 
Регистрация: 04.09.2005
Сообщений: 14,014
Написано 6,798 полезных сообщений
(для 20,935 пользователей)
Ответ: Архитектура MMO сервера

Чтобы сделать скриншот из ворда без меток спеллчекера, надо перейти в режим "предварительный просмотр".
К сожалению, по теме сказать нечего - но тоже любопытно
__________________
http://nabatchikov.com
Мир нужно делать лучше и чище. Иначе, зачем мы живем? tormoz
А я растила сына на преданьях
о принцах, троллях, потайных свиданьях,
погонях, похищениях невест.
Да кто же знал, что сказка душу съест?
(Offline)
 
Ответить с цитированием
Сообщение было полезно следующим пользователям:
pax (29.10.2013)
Старый 29.10.2013, 13:54   #3
jimon
 
Сообщений: n/a
Ответ: Архитектура 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 у них по серверу на звёздную систему, если в какой системе будет происходить бой то они вытягивают сервер помощнее из пула и запускают на нем эту систему

думаю можно это отдельно обсудить если скажешь какой жанр игр нужно =)
 
Ответить с цитированием
Эти 9 пользователя(ей) сказали Спасибо за это полезное сообщение:
Andvrok (29.10.2013), DStalk (29.10.2013), HolyDel (04.11.2013), Lestar (29.10.2013), moka (29.10.2013), pax (29.10.2013), Reizel (01.11.2013), St_AnGer (29.10.2013), Taugeshtu (05.11.2013)
Старый 29.10.2013, 14:07   #4
ant2on
Модератор
 
Аватар для ant2on
 
Регистрация: 05.11.2005
Сообщений: 161
Написано 63 полезных сообщений
(для 182 пользователей)
Ответ: Архитектура MMO сервера

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

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

В Pomelo не вникал, показалось сложно.
__________________
Anarki's Revenge
(Offline)
 
Ответить с цитированием
Старый 29.10.2013, 14:32   #5
Lestar
Бывалый
 
Аватар для Lestar
 
Регистрация: 24.05.2011
Адрес: Украина,Харьков
Сообщений: 890
Написано 359 полезных сообщений
(для 880 пользователей)
Ответ: Архитектура MMO сервера

Данных, которые нужно сохранять периодически в БД на самом деле не так и много- покупка чего то там, левел ап, шмот. Все остальные данные в реалтайме можно держать в комнате на аватаре игрока, и писать в бд при дисконнекте. http://habrahabr.ru/company/mailru/blog/182088/ тут интересно написано. socket.io юзает веб сокеты, как то не тру. Pomelo удобоваримо только для сессионных игр.
__________________
Нам суждено построить мосты и храмы,которых никогда не существовало и не могло существовать в природе.
(Offline)
 
Ответить с цитированием
Эти 2 пользователя(ей) сказали Спасибо Lestar за это полезное сообщение:
DStalk (29.10.2013), pax (29.10.2013)
Старый 29.10.2013, 16:24   #6
moka
.
 
Регистрация: 05.08.2006
Сообщений: 10,429
Написано 3,454 полезных сообщений
(для 6,863 пользователей)
Ответ: Архитектура 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).
(Offline)
 
Ответить с цитированием
Эти 3 пользователя(ей) сказали Спасибо moka за это полезное сообщение:
KCEPOKC (14.11.2013), Lestar (29.10.2013), pax (29.10.2013)
Старый 29.10.2013, 17:00   #7
pax
Unity/C# кодер
 
Аватар для pax
 
Регистрация: 03.10.2005
Адрес: Россия, Рязань
Сообщений: 7,568
Написано 3,006 полезных сообщений
(для 5,323 пользователей)
Ответ: Архитектура MMO сервера

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

1. Допустим 5к игроков одновременно максимум.
2. Игровой мир это комнаты с загрузкой, не единый мир.
3. Сессии не длинные, по трафику допустим это шутер с числом игроков в комнате не превышающим 50-100 (в большинстве случаев будет меньше).
4. Основной геймплей - бои длительностью до 20-30 минут (к примеру WoT).
__________________
Blitz3d to Unity Wiki
(Offline)
 
Ответить с цитированием
Старый 29.10.2013, 21:16   #8
jimon
 
Сообщений: n/a
Ответ: Архитектура MMO сервера

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

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

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

всякие сетевые танки и самолетики куда проще делать ибо там игрок не меняет положение в пространстве очень резко
 
Ответить с цитированием
Старый 29.10.2013, 21:49   #9
Lestar
Бывалый
 
Аватар для Lestar
 
Регистрация: 24.05.2011
Адрес: Украина,Харьков
Сообщений: 890
Написано 359 полезных сообщений
(для 880 пользователей)
Ответ: Архитектура MMO сервера

Сообщение от jimon Посмотреть сообщение
сервак с возможностью отката времени
Для каких целей?
__________________
Нам суждено построить мосты и храмы,которых никогда не существовало и не могло существовать в природе.
(Offline)
 
Ответить с цитированием
Старый 29.10.2013, 22:41   #10
pax
Unity/C# кодер
 
Аватар для pax
 
Регистрация: 03.10.2005
Адрес: Россия, Рязань
Сообщений: 7,568
Написано 3,006 полезных сообщений
(для 5,323 пользователей)
Ответ: Архитектура MMO сервера

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

Сообщение от Lestar Посмотреть сообщение
Для каких целей?
Я думаю для точного расчета попаданий. В статье про сеть в Source это описано.
__________________
Blitz3d to Unity Wiki
(Offline)
 
Ответить с цитированием
Сообщение было полезно следующим пользователям:
Lestar (30.10.2013)
Старый 30.10.2013, 00:25   #11
jimon
 
Сообщений: n/a
Ответ: Архитектура MMO сервера

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

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

так делают в большинстве MMO где не требуется моментальная реакция на перемещение игрока
 
Ответить с цитированием
Эти 2 пользователя(ей) сказали Спасибо за это полезное сообщение:
Lestar (30.10.2013), pax (30.10.2013)
Старый 30.10.2013, 02:15   #12
moka
.
 
Регистрация: 05.08.2006
Сообщений: 10,429
Написано 3,454 полезных сообщений
(для 6,863 пользователей)
Ответ: Архитектура MMO сервера

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

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

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

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

Либо сделать комнаты, в которые тупо можно присоединяться, заместо матчей где требуется набор игроков до начала игры.
Но это зависит от гейм-дизайна, контра например такое позволяет, а вот LoL или Dota 2 или стратежки - уже нет.
(Offline)
 
Ответить с цитированием
Эти 3 пользователя(ей) сказали Спасибо moka за это полезное сообщение:
KCEPOKC (14.11.2013), Lestar (30.10.2013), pax (30.10.2013)
Старый 04.11.2013, 10:34   #13
pax
Unity/C# кодер
 
Аватар для pax
 
Регистрация: 03.10.2005
Адрес: Россия, Рязань
Сообщений: 7,568
Написано 3,006 полезных сообщений
(для 5,323 пользователей)
Ответ: Архитектура MMO сервера

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

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

2. Есть ли где статьи по реализации reliable udp? Есть желание попробовать написать такой протокол самому.
__________________
Blitz3d to Unity Wiki
(Offline)
 
Ответить с цитированием
Старый 04.11.2013, 17:32   #14
jimon
 
Сообщений: n/a
Ответ: Архитектура MMO сервера

pax

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

2) есть разные готовые реализации, посмотри на гитхаб к примеру https://github.com/search?q=reliabil...al&ref=cmdform
 
Ответить с цитированием
Эти 4 пользователя(ей) сказали Спасибо за это полезное сообщение:
ant2on (05.11.2013), impersonalis (04.11.2013), pax (04.11.2013), SBJoker (04.11.2013)
Старый 04.11.2013, 17:51   #15
SBJoker
Злобный Админ
 
Аватар для SBJoker
 
Регистрация: 04.09.2005
Сообщений: 5,926
Написано 3,415 полезных сообщений
(для 9,330 пользователей)
Ответ: Архитектура MMO сервера

Есть ещё вариант с плохой сетью в которой пропадают пакеты, тогда пинг будет расти, из-за повторной отправки пропавших пакетов.
__________________
(Offline)
 
Ответить с цитированием
Эти 3 пользователя(ей) сказали Спасибо SBJoker за это полезное сообщение:
ant2on (05.11.2013), impersonalis (04.11.2013), pax (04.11.2013)
Ответ


Опции темы

Ваши права в разделе
Вы не можете создавать темы
Вы не можете отвечать на сообщения
Вы не можете прикреплять файлы
Вы не можете редактировать сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.


Часовой пояс GMT +4, время: 03:22.


vBulletin® Version 3.6.5.
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Перевод: zCarot
Style crйe par Allan - vBulletin-Ressources.com