Сетевой движок ММОРПГ (3 стр)

Вий
> Не думаю, что там имеет смысл их считать, упрется в скорость памяти. Если доступ почти последовательный, то скорость будет около 3 гигабайт в секунду в один поток.

Ну, кстати, от архитектуры сервера зависит, да. Но я в первом же (или во втором, не помню) сообщении написал, что на сервере с 8 гигабит памяти будет прям совсем тяжко миллиард клиентов онлайн держать. :) Но если именно про серверы MMORPG говорить, учитывая мой опыт работы с ними (реверсил клиент, добился того, что можно залогиниться и по координатам перемещаться), в процессор все несколько раньше упрется. Но вот тут не готов рвать на себе рубашку и спорить, не обладаю достаточным уровнем компетенций.
Но я в сторону именно процессора склоняюсь по тому, что это у нас разговор ещё до мтютексов не дошел. :)

Вий
> Скорость сети при этом 1 гигабит в секунду, то есть в 24 раза медленнее, и это суммарно на все потоки

Вероятно, надо ещё раз пройтись по вопросу, складывается ощущение, что мы о чем-то разном говорим... :)

Вий
> Меня больше беспокоят syscall-ы и вот тут вероятно поможет liburing. Ему придется отдать ядро целиком, зато остальные 3 будут свободны от сисколлов.

В крестах же аффинити маск отлично работает? Чем этот вариант лучше будет, чем напрямую просто треды под аффинити маск вешать?

NicoAZ
> на сервере с 8 гигабит
8 гигабайт, это по 80 килобайт на клиента если клиентов 100к. Это очень много.

Скорость сети измеряют не в байтах а в битах, в байте 8 бит. Сеть в 1 гигабит это самое быстрое что можно спокойно купить с безлимитным трафиком сейчас в датацентрах. Быстрее уже очень дорого. Вот 1 гигабит/с это 125 мегабайт/с после перевода биты-байты

NicoAZ
> В крестах же аффинити маск отлично работает? Чем этот вариант лучше будет, чем напрямую просто треды под аффинити маск вешать?
Liburing позволяет обмениваться данными с ядром линукса (через которое необходимо протащить данные в сеть) без системных вызовов и без мютексов, пользуясь только атомарными переменными. Но чтобы это работало нужно пожертвовать одно ядро для обработки очереди запросов в ядре, чтобы оно постоянно проверяло эти самые атомарные переменные. С учетом длительности сискола (2 переключения контекста процессора: в ядро и обратно), это может оказаться самой важной оптимизацией.

Вий
> Liburing позволяет обмениваться данными с ядром линукса (через которое необходимо протащить данные в сеть)

Ну, у нас по прежнему несколько разные подходы... :) Вы всё ещё настаиваете, что что-то именно в сеть уткнется. :)
Да, ещё один вопрос. Мы трафик-то через TCP или UDP гоним?

NicoAZ
> Мы трафик-то через TCP или UDP гоним?
Пока давай считать что через TCP

NicoAZ
> Вы всё ещё настаиваете, что что-то именно в сеть уткнется.
Если уткнется не в сеть, значит код написан плохо

Вий
> Если уткнется не в сеть, значит код написан плохо
Подытожим, чисто, что б я был уверен, что правильно все понял. Есть RaspberryPi 5. Мы на ней запускаем сервер, который отправляет и принимает пакеты к/от клиентов и отсчитывает все события происходящие в игровом мире, где могут находиться десятки и сотни тысяч человек. По мере роста количества игроков онлайн на этом сервере, мы уткнемся в то, что нам не хватит пропускной способности сети при том, что к нашей RPi подключена сеть на максимально поддерживаемой встроенным адаптером скорости (реальный гигабитный аплинк). Я правильно все понял?

NicoAZ
Да. Все так. Возможно придется жить с rpi4. Их в последний раз когда я смотрел легко было арендовать в дц. Когда упремся - придется организовать серверы в иерархию, купить дорогое железо с быстрым адаптером и решать прочие проблемы, которые в общем то приятно решать когда у тебя есть 100 000 одновременно играющих игроков.

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

Почему речь о rpi4 - потому что это хоть и слабое но реальное железо, которое передаётся в полное распоряжение. Для игрового сервера это важно - так программа будет вести себя предсказуемо.

Ну и arm можно дешево арендовать и в amazon например. Но важно чтобы там (на Арме) все хорошо работало. Оптимизация под ARM когда код уже написан для Интел может быть очень тяжелой. Легче сразу под него писать.

NicoAZ
> Давайте я Вам прям сегодня ради интереса напишу программку
Так что, напишешь сегодня?

Вий
> Так что, напишешь сегодня?
Сейчас уже точно ничего не напишу, у меня второй час ночи. :) Я когда спросил, писать или нет, утвердительного ответа не последовало, вот я и не писал. Завтра могу накидать, там на вряд ли больше 20-30 минут уйдет.

Вий
> Возможно придется жить с rpi4.
А зачем себя искусственно ограничивать? Почему не взять RPi Zero 2? Можно ещё и зелёную повестку реализовать, запитав это все от очень маленькой солнечной панели.

NicoAZ
> А зачем себя искусственно ограничивать?
У меня в аренде 2 rpi4 сервера с гигабитным каналом в датацентре.

Вий
> Это не от того что я плохо думаю лично о тебе, я просто разочаровался в человечестве вообще. К >сожалению программистов умеющих писать высокопроизводительные а не высокозагруженые >прогрммы приходится годами искать на высоченные зарплаты.
Тоже задавался вопросом о высоконагружености и производительности программ, пришлось отказаться от готовых решений и писать свой 3d движок из говна и палок, также задаюсь вопросом по поводу сетевой части как бы сделать так что бы максимально сильно сжать сетевой трафик.

Вий
:)

Вий
> У меня в аренде 2 rpi4 сервера с гигабитным каналом в датацентре.
Аааааа... Понимаю. Вы просто сразу об этом не сказали, подобным инвестициям пропасть явно нельзя позволить.
Пакеты размером 16к они нормально передают?