forum.boolean.name - Сетевая часть ММО игр

forum.boolean.name (http://forum.boolean.name/index.php)

- Алгоритмика (http://forum.boolean.name/forumdisplay.php?f=21)

- - Сетевая часть ММО игр (http://forum.boolean.name/showthread.php?t=14505)

pax	31.03.2011 18:35

Ответ: Epica online

Цитата:

Сообщение от RokWeb (Сообщение 184385)

(1 поток - прием\отправка пакетов, 2 поток - обработка данных)

Однопоточный сервер плохо масштабируемый. Подумайте о использовании многопоточного или асинхронного сервера.

ffinder

31.03.2011 20:05

Ответ: Epica online

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

moka	31.03.2011 20:08

Ответ: Epica online

Цитата:

Сообщение от ffinder (Сообщение 184397)

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

Чем это обосновано? Если например нужен проверяльщик timeout соединений? Его проще запустить отдельным потоком, не так ведь?
Плюс, ещё различные рутинные функции, лучше сделать потоком, если они нужны периодически, просто отправляется поток в сон, и выполняется рутина время от времени?
Я сам как бы не знаю, может это и имеет плохие стороны, но для меня очевидно удобно. Если есть тут "подводные камни", подскажите.

pax	31.03.2011 21:37

Ответ: Epica online

Цитата:

Сообщение от ffinder (Сообщение 184397)

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

И это говорит сторонник эрланга и гипермногопоточности?

Вот тут читал по реализации серверов: http://msdn.microsoft.com/ru-ru/library/dd335942.aspx
Вот что написано про однопоточную систему:

Цитата:

У этого подхода есть и другие недостатки, связанные с производительностью. После подключения примерно тысячи клиентов быстродействие метода Select значительно снижается. Это объясняется тем, что для определения того, доступны ли сокетам данные, ядро должно опросить каждый сокет.

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

Относится конечно к дотнету, но не думаю что есть большие отличия по работе с сокетами под windows

ffinder

31.03.2011 22:41

Ответ: Epica online

Цитата:

Сообщение от pax (Сообщение 184405)

И это говорит сторонник эрланга и гипермногопоточности?

дело в том что VM эрланга:
1. создает 2 системных потока на ядро: один для ввода/вывода (сеть, диск), второй для логики
2. в эрланге процессы легковесные (легко запустить 100500 процессов, даже 300000 не проблема вовсе), в отличии от дотнета.

ffinder

31.03.2011 22:50

Ответ: Epica online

из статьи "про доднед и сокеты":

Цитата:

Как насчет масштабируемости?
Какую бы серверную модель я ни применял, на своем компьютере я не сумел создать более 4000 одновременных соединений или около того.
В этот момент в ответ на новые клиентские запросы начинали генерироваться довольно бесполезные сообщения об ошибках, извещавшие о нехватке места в буфере или о переполнении очередей.
Ясно, что этот предел неприемлем, если ваш сервер должен работать в какой-либо требовательной среде.
Почему же мы упираемся в этот потолок?
Оказывается, ограничивающим фактором является объем доступных ресурсов памяти, а именно, пул неподкачиваемой памяти (nonpaged pool).
Если процесс исчерпал свой пул этой памяти, создать новое соединение с сокетом не удастся.

как-то жалко смотрятся его потуги на фоне эрланка.
на эрланге поставлен рекорд с 1000000 (прописью: ОДИН МИЛЛИОН) одновременных TCP/IP соединений.

pax	31.03.2011 22:55

Ответ: Epica online

Да и компилятор эрланга заточен под это. Но что делать при использовании не Erlang в качестве ЯП для программирования сетей?
Вообще в статье не сказано про то, какая машина у него, сколько памяти и т.д.

ffinder

31.03.2011 23:00

Ответ: Epica online

просьба модераторам вынести часть обсуждения в отдельную тему, и я с удовольствием продолжу.
тут вообще-то тема обсуждения онлайн-игры Epica Online

Randomize

31.03.2011 23:35

Ответ: Сетевая часть ММО игр

Продолжаем

ffinder

31.03.2011 23:48

Ответ: Сетевая часть ММО игр

Существует так называемая "проблема 10000 соединений"
Подробно описана вот здесь: http://www.kegel.com/c10k.html
Вот хорошее "содержание" (взято отсюда)

Цитата:

Рассуждения на тему проблемы обслуживания соединений от 10000 клиентов на одной машине. Разбираются такие технологии как select(), poll(), /dev/poll, kqueue, thread, nonblocking I/O, Realtime Signals, /dev/epoll, asynchronous I/O, ограничение числа filehandler и тредов, использование Zero-Copy, sendfile() и writev. Многочисленные примеры приложений реализующих вышеописанные механизмы.

Кратко резюмирую:

Подходы, в которых используется мультиплексирование ввода/вывода (select) имеют линейный рост времени обработки от числа подключений (чем больше - тем более медленно).

Подход вида "1 клиент - 1 поток" тоже нежизнеспособны, так как 1 системный поток требует 1 мб оперативной памяти. Легко посчитать сколько RAM необходимо для 100 000 подключений.

Есть только несколько технологий, которые позволяют преодолеть этот барьер.
Это kqueue/epoll (linux/freebsd), io completion port (windows server).
Для их работы хватает одного потока.

pax	31.03.2011 23:55

Ответ: Сетевая часть ММО игр

2ffinder Ты кстати обещал статью по эрлангу написать ;) Я с удовольствием почитаю :)

UPD: ставлю Eclipce и erlide, буду иногда пробовать эрланг по мере возможности

HolyDel

01.04.2011 06:44

Ответ: Сетевая часть ММО игр

я бы тоже почитал что нить про эрланг от булочника

FDsagizi

01.04.2011 10:08

Ответ: Сетевая часть ММО игр

Цитата:

Сообщение от ffinder (Сообщение 184418)

Есть только несколько технологий, которые позволяют преодолеть этот барьер.
Это kqueue/epoll (linux/freebsd), io completion port (windows server).
Для их работы хватает одного потока.

еще есть UDP.

Randomize

01.04.2011 12:05

Ответ: Сетевая часть ММО игр

Цитата:

Сообщение от FDsagizi (Сообщение 184441)

еще есть UDP.

Udp - протокол. А мы говорим про технологии, которые этими самыми протоколами и управляют. Вернее работают через них, но хитро.

ffinder

01.04.2011 13:16

Ответ: Сетевая часть ММО игр

Цитата:

Сообщение от FDsagizi (Сообщение 184441)

еще есть UDP.

Да, UDP классный протокол. Для шутеров - видимо единственный вариант.
Но, неупорядоченная доставка пакетов и нет контроля доставки с последующей перепосылкой.
Но там где нужна гарантированная доставка пакетов: чаты, магазины (внутриигровые) - нужно либо изобретать tcp поверх udp, либо...

IGR	02.04.2011 03:29

Ответ: Сетевая часть ММО игр

+1, да можно и на юдп навернуть свою систему уведомлений и перепосылок !! Но вопрос в другом а стоит ли ??
Если игра не динамичный шутхер то лучше не "чудить" а брать сразу тсп !!

moka	02.04.2011 03:56

Ответ: Сетевая часть ММО игр

На деле, udp с механизмом уведомлений по скорости будет то же самое что и tcp, при этом количество клиентов будет не превышать нормальную архитектуру, ту же IOCP к примеру.

DStalk

13.05.2011 21:03

Ответ: Сетевая часть ММО игр

Добрался до PureBasic`a, начал переносить сервер с блица, все вроде норм, но есть несколько вопросов:

1. Пробую мультитреадинг. Наверно поставлю в отдельных тредах процедуры логина, обработки игроков и обработки монстров (3 треда). Вопрос насчет базы данных, надо ли синхронизировать треды, например чтобы не было одновременного доступа к БД?

2. Нормально ли будет, если я например информацию о нужном в данный момент предмете буду запрашивать из БД, или стоит информацию о предметах подгружать в память (переменные, массивы) при старте сервера?

3. Использую SQLite базу данных. Друзья подсказывают, что в некоторых случаях она быстрее MySQL. То что к ней не будет доступа например с сайта для меня не проблема. Что скажут по этому поводу булочники?:) Какая БД лучше?

moka	13.05.2011 22:19

Ответ: Сетевая часть ММО игр

1/2. Вообще доступ к БД, должен выполнятся редко. И может быть с разных потоков. Логика по сути не должна к БД относиться вообще, т.к. её задача - обработка логики.
Менеджер информации, должен отвечать за то что должно быть загружено в ОЗУ, а что нет. Логика работает с данными из ОЗУ, значит они должны быть загружены. Например вещи выставленные на аукцион - должны быть в ОЗУ. При их покупке и т.п. естественно обновлять БД и т.п. Но не выгружать из ОЗУ.
Тут важно понимать, что должно использовать данные и от куда.
По идее, бд - лишь для хранения данных, но никак не для логики и т.п. Всё должно быть в ОЗУ. Те же мобы, они вообще никакого отношения к БД например не имеют. Либо те же вещи, они почти везде и всегда будут в ОЗУ, таким образом нету никаких ссылок к БД.
Вынеси загрузку из БД в отдельный механизм.
Например шмотьё, есть вещи, с которыми может взаимодействовать только персонаж который их имеет, например баночка. Держать эту инфу не нужно в ОЗУ, если этот персонаж не в игре. Если он в игре, то грузить всё с ним связанное.
При этом есть такой момент, вещь может принадлежать игроку, но быть на том же аукционе, таким образом с ней могут взаимодействовать. Получается она должна быть в ОЗУ всегда, даже если её владелец не онлайн. А это реализуется простым списком вещей для аукциона, который есть в БД и в ОЗУ. Таким образом если вещь купили, то её нужно изъять у игрока который был владельцем, если он оффлайн, это делается через БД, и тут нужно быть уверенным что он сейчас не заходит в игру, чтобы не возникло конфликтов, изъятия его шмотки и загрузка её же. По сути, каждая шмотка также имеет уникальный ID, и т.к. она была куплена другим, то тут тупо при загрузке, нужно проверять, не загружены ли эти вещи уже в ОЗУ, если да, то не грузить и т.п. Там куча условий и сценариев на которых можно наколоться.
Поэтому нужно организовать работу с БД и данными в ОЗУ, очень корректно и как весьма мощный механизм.

3. Раньше склонялся к MySQL, но сейчас использую везде MSSQL, намного шустрее выходит, и удобнее с ней работать. Плюс удобный манаджер (визуальный), и другие плюшки относительно самого Query языка.

HolyDel

14.05.2011 09:30

Ответ: Сетевая часть ММО игр

Цитата:

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

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

Цитата:

Раньше склонялся к MySQL, но сейчас использую везде MSSQL

вот под этим подписываюсь полностью

pax	14.05.2011 10:47

Ответ: Сетевая часть ММО игр

Кстати кто может сказать, для серверной части критичным будет использование LINQ to SQL например? Я вот подумываю попробовать для старта использовать компилируемые LINQ запросы. Если уж производительности не хватит - то перевести серверную часть на обычный ADO.NET.
Просто сейчас критичным является срок разработки...

pax	19.05.2011 20:54

Ответ: Сетевая часть ММО игр

Вложений: 1

Подскажите кто что думает вот о такой архитектуре. Если есть комментарии/замечания, то буду очень рад:

Вложение 13810

Оговорюсь сразу - MMO подразумевается по ходовое.

IGR	20.05.2011 00:35

Ответ: Сетевая часть ММО игр

как по мне - решение имеет право на существование !!
:ok:

pax	20.05.2011 14:15

Ответ: Сетевая часть ММО игр

Ну может есть у кого предложения по улучшению, лучшей организации или какие-то рекомендации? У меня опыта в MMO - 0%) я даже в них практически не играл )

moka	20.05.2011 19:39

Ответ: Сетевая часть ММО игр

Что такое Realm?
В моём понятии это сервер, что имеет свою DB и свою независимую игровую логику.
Это в случае если предусматриваются разные сервера, для разделения игроков, возможно по режимам игры (PvP/PvE или т.п.), также они естественно могут иметь разные настройки, и возраст, который будет определять уже общий коэфицент развития игроков в игровом мире.

Получается нужно иметь отдельный сервер, что будет иметь DB всех учётных записей, также этот сервер будет отображать статус realm'ов, и т.п.

Когда user заходит в Launcher, он логиниться под его учётной записью, затем ему выдаётся список серверов, и их статусы.
Он выбирает realm на который заходить, на этом моменте он устанавливает соединение с выбранным сервером, и далее уже получает список персонажей.
При выборе персонажа, идёт уже загрузка в мир, исходя из локации, и т.п.

По сути, первый сервер, имеет ответственность за авторизацию игровой копии (если такое предусматривается), а также аутентификацию учётной записи.
Также, при соблюдении всех проверок, и выборе реалма, должен создаваться временный ключь сессии, на этом же сервере. Который будет запрошен и сверен с предоставленным от клиента. То есть: при выборе realm'а, на сервере учёток создаётся уникальный ключик (хашь хрени всякой), шлётся пользователю, пользователь с этим ключём посылает запрос на realm, который в свою очередь ищет по этому ключику сессию на учётном сервере, находит, и таким образом, он знает уже какой пользователь (учётка), и т.п. соединяется. Этот ключик сессии, должен быть деактивирован каждый раз при дисконнекте, и он же будет участвовать в проверке попытки зайти два раза тем же персонажем, и для логов.

Учётный сервер, сильно отличается от игрового.

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

Учти, что внезапный обрыв клиента, должен быть ожидаемым в любой момент, и с этим придётся считаться, чтобы "замести" все следы недоделанных работ.

Работа с БД, должна также быть весьма отделённой от игровой логики. Почти вся игровая логика должна быть завязана на данных в ОЗУ, а менеджер загрузки данных, должен грузить и выгружать чётко что нада а что нет.

Тут будет много парки с утечкой памяти.
Также, учитывай, что сервер может вдруг упасть, все данные, будут потеряны (те что в ОЗУ), и с этим нужно тоже считаться..

pax	21.05.2011 02:41

Ответ: Сетевая часть ММО игр

Спасибо за комментарий!

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

Про утечки памяти я не боюсь, C# ведь ) самое главное сделать оптимальным работу сборщика мусора, здесь самое тяжелое - сериализация пакетов. На клиенте я создал постоянный буффер для сериализатора, а вот на сервере для параллельной сериализации наверное придется либо делать некоторое количество буферов... не хочется чтобы на сервере сборщик мусора тоже воевал...

Вот я не думал что для всех серверов стоит разделять базу данных... сейчас что-то задумался...

moka	21.05.2011 04:17

Ответ: Сетевая часть ММО игр

Если это отдельный мир, и игрок имеет возможность зайти тем же персонажем на другой realm, тогда разделять БД не нужно на realm'ы.
Либо если это организовать грамотно, тогда будет выгода, т.к. количество записей в таблицах будут в разы меньше, т.к. делены на realm'ы, но нужен тогда сервис транспортировки туда-сюда.

Вот интересно то что в том же WoW, есть Battleground'ы, это типо становишься в очередь, далее сервер ищет команды 10 либо 15 либо 30 (зависит от бг), и затем когда начинается игра, запускается бг, но прикол в том что игроки на бг, с разных серверов, а не с того же. Таким образом за БГ, отвечает отдельный сервер, который собирает инфу с разных бд серверов.
Но там всё сложно, там целые cloud'ы в дата центрах, там всё реально сложно ;)

Хотелось бы знать больше о ТЗ, относительно учётных записей пользователя, realm'ов, и самих персонажей..

pax	28.05.2011 18:52

Ответ: Сетевая часть ММО игр

Да пока больших ТЗ нет. Просто конструирование обобщенной архитектуры.

moka	28.05.2011 20:15

Ответ: Сетевая часть ММО игр

Также, соединение/отсоединение, не должно иметь важных процессов, т.к. нормальное соединение/отсоединение на основе сообщений "игрок_выходит" и типо того, они не обязательно будут всегда. Я могу тупо сделать Clt+F4, такие образом нужно меньше всего зависеть от наличия игрока подсоединённого. Это говорит также о разделении самого клиента с точки зрения сети, так и клиента, с точки зрения игровой информации.

Мыслей куча, большинство конечно будут весьма очевидными, но если будут конкретнее вопросы, то с радостью поделюсь размышлениями.
ЗЫ, сейчас свой ассинхронный сокетный сервер, переписываю :) Хотел реализовать повторное использование сокета, не удалось, он остаётся заbind'еным, а это не позволяет снова его использовать.. :( Если стретитесь с этим, буду рад услышать про это.

Также сделал в локальной сети стресс тест, запустил сервер, на простеньком компе (4гб рама, старый проц), и далее на трёх разных компах запустил по несколько клиентов. Каждый клиент создавал каждый 2мс подключение к серверу, всего он делал 1000 подключений, и затем, каждые 100мс, он слал с каждого подсоединения по 1 биту.
Сервер же, принимал подключения и ставил сокеты на прослушку, принимал сообщение и продолжал слушать каждый подключенный сокет. Также в течении секунды рассылал всем по 1 биту пакет.
В итоге, я позапускал около 20 клиентов на трёх разных компах.
Сервер выдержал без проблем 20 000 подключений, и слал пакетики. Проц вообще не грузило, когда все были подключены. :)

pax	30.05.2011 17:41

Ответ: Сетевая часть ММО игр

Первый вариант асинхронного клиент-сервера с бинарной сериализацией пакетов заработал успешно )
Будем дальше пробовать сеть программировать. Начнем с сервера получения игровых сессий.

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