У нас тут небольшой спор вышел: разделять ли физически процесс обсчитывающий игровой мир с модулем отвечающим за внешние взаимодействия (сокеты)?
Т.е. можно:
— всё оставить в рамках одного процесса.
— использовать два приложения, которые через pipe обмениваются юзерскими пакетами.
— вообще разделить по разным серверам, один сервер обсчитывает мир, шлёт юзерские данные через сокеты на другой сервер, а тот уже рассылает всё по миру.
P.S.
Игровой мир довольно сложный и сервер напрягает по максимуму. Типичные размеры пакета для одного игрока — 500б в его сторону и 8 байт обратно, 15-20 кадров в секунду. Предположительно один сервер должен поддерживать сотни игроков.
Здравствуйте, Nikе, Вы писали:
N>У нас тут небольшой спор вышел: разделять ли физически процесс обсчитывающий игровой мир с модулем отвечающим за внешние взаимодействия (сокеты)? N>Т.е. можно: N>- всё оставить в рамках одного процесса. N>- использовать два приложения, которые через pipe обмениваются юзерскими пакетами. N>- вообще разделить по разным серверам, один сервер обсчитывает мир, шлёт юзерские данные через сокеты на другой сервер, а тот уже рассылает всё по миру.
N>P.S. N>Игровой мир довольно сложный и сервер напрягает по максимуму. Типичные размеры пакета для одного игрока — 500б в его сторону и 8 байт обратно, 15-20 кадров в секунду. Предположительно один сервер должен поддерживать сотни игроков.
Если вы разделите, то сервер все равно будет общаться с внешним миром и содержать для этого модуль, т.е. ни чего не разделится, просто добавится еще один слой. Смысл в этом только если для безопасности или какой-то дополнительной не тривиальной обработки пакетов.
N>У нас тут небольшой спор вышел: разделять ли физически процесс обсчитывающий игровой мир с модулем отвечающим за внешние взаимодействия (сокеты)? N>Т.е. можно: N>- всё оставить в рамках одного процесса. N>- использовать два приложения, которые через pipe обмениваются юзерскими пакетами. N>- вообще разделить по разным серверам, один сервер обсчитывает мир, шлёт юзерские данные через сокеты на другой сервер, а тот уже рассылает всё по миру.
у меня сотен не было, но это не повод молчать
один тред считает мир (по дефолту каждые 100ms)
N тупых тредов слушают клиентов, подбрасывают главному треду события, забирают у него диффы состояния и шлют клиентам
всё в одном процессе, само собой
клиенты интерполируют между этими самыми 100ms
зачем как-то иначе?
Здравствуйте, Qulac, Вы писали:
Q>Если вы разделите, то сервер все равно будет общаться с внешним миром и содержать для этого модуль, т.е. ни чего не разделится, просто добавится еще один слой. Смысл в этом только если для безопасности или какой-то дополнительной не тривиальной обработки пакетов.
Ну вот весь вопрос в этом, есть ли какой-то смысл заморачиваться? Подводные камни и т.п.
Допустим для обработки большого количества внешних ненадёжных соединений сколько ресурсов требуется? Админы говорят, что ничтожное, но я пока хз как это отпрофилировать.
Здравствуйте, koenig, Вы писали:
K>один тред считает мир (по дефолту каждые 100ms)
Ну там 8 тредов, на довольно мощном железе.
K>N тупых тредов слушают клиентов, подбрасывают главному треду события, забирают у него диффы состояния и шлют клиентам K>всё в одном процессе, само собой
Это да.
K>клиенты интерполируют между этими самыми 100ms K>зачем как-то иначе?
Фишка именно в том, что мир огромный и интерактивный. Игра пока только в бету выходит, но в будущем хотелось бы обсчёт мира на нескольких серверах запустить.
Здравствуйте, Nikе, Вы писали:
N>Здравствуйте, Qulac, Вы писали:
Q>>Если вы разделите, то сервер все равно будет общаться с внешним миром и содержать для этого модуль, т.е. ни чего не разделится, просто добавится еще один слой. Смысл в этом только если для безопасности или какой-то дополнительной не тривиальной обработки пакетов.
N>Ну вот весь вопрос в этом, есть ли какой-то смысл заморачиваться? Подводные камни и т.п. N>Допустим для обработки большого количества внешних ненадёжных соединений сколько ресурсов требуется? Админы говорят, что ничтожное, но я пока хз как это отпрофилировать.
Админы, для обычного сценария использования, правы, а вот подводные камни это хитрый игрок, который своими действиями пытается вывести из строя сервер, например посылает большие объёмы данных, что бы они лежали в буфере сервера и тем самым занимали его память. Так что если делить, то для обеспечения безопасности, что бы защитить основной сервер от нежелательных действий игроков.
N>Фишка именно в том, что мир огромный и интерактивный. Игра пока только в бету выходит, но в будущем хотелось бы обсчёт мира на нескольких серверах запустить.
суровый выбор. мне кажется, требования к производительности/bandwidth легко уменьшить умерив аппетиты в сложности мира, а вот latency уменьшить сложно в любом случае. и перекидывания данных — это очередная капля в чашу latency как раз. я бы боялся такое делать.
p.s. не обязательно сложность уменьшать, можно грубее обсчитывать если что
Здравствуйте, koenig, Вы писали:
K>суровый выбор. мне кажется, требования к производительности/bandwidth легко уменьшить умерив аппетиты в сложности мира
Ну тут сложность мира это ключевая фишка игрушки.
K>а вот latency уменьшить сложно в любом случае. и перекидывания данных — это очередная капля в чашу latency как раз. я бы боялся такое делать.
Я думал как-то договориться с провайдерами, чтобы сервера были физически близки или даже особым образом сконфигурированы для уменьшения внутренней латентности.
K>>суровый выбор. мне кажется, требования к производительности/bandwidth легко уменьшить умерив аппетиты в сложности мира N>Ну тут сложность мира это ключевая фишка игрушки.
K>>а вот latency уменьшить сложно в любом случае. и перекидывания данных — это очередная капля в чашу latency как раз. я бы боялся такое делать. N>Я думал как-то договориться с провайдерами, чтобы сервера были физически близки или даже особым образом сконфигурированы для уменьшения внутренней латентности.
тогда бы я взял самый жирный сервак и обсчет раскидывал бы на разные треды, но отдельные процессы и уж тем более распределенные сервера избегал бы как мог
но тут я теоретизирую, такого опыта у меня нет
Здравствуйте, Nikе, Вы писали:
N>Я думал как-то договориться с провайдерами, чтобы сервера были физически близки или даже особым образом сконфигурированы для уменьшения внутренней латентности.
Говорят, Eve Online работает на кластере, соединённом Infiniband. Правда, такой подход противоречит обычному workflow "денег у нас нет, поэтому давайте запустимся на говне, а как деньги появятся — говна докупим, и писать будем сразу на MongoDB, она на говне хорошо масштабируется".
N>>Я думал как-то договориться с провайдерами, чтобы сервера были физически близки или даже особым образом сконфигурированы для уменьшения внутренней латентности.
С>Говорят, Eve Online работает на кластере, соединённом Infiniband. Правда, такой подход противоречит обычному workflow "денег у нас нет, поэтому давайте запустимся на говне, а как деньги появятся — говна докупим, и писать будем сразу на MongoDB, она на говне хорошо масштабируется".
почему противоречит? запустили на дешевом кластере, помучались
купили дорогой
про монго забудем, конечно, он тут вообще непричем
Здравствуйте, Слава, Вы писали:
С>Говорят, Eve Online работает на кластере, соединённом Infiniband. Правда, такой подход противоречит обычному workflow "денег у нас нет, поэтому давайте запустимся на говне, а как деньги появятся — говна докупим, и писать будем сразу на MongoDB, она на говне хорошо масштабируется".
Ну по первоначальным планам там должен был быть вообще универсальный всемогутер с графикой уровня ААА игр. Потом, конечно, порезали до тетриса с претензиями.
Здравствуйте, Nikе, Вы писали:
N>У нас тут небольшой спор вышел: разделять ли физически процесс обсчитывающий игровой мир с модулем отвечающим за внешние взаимодействия (сокеты)? N>Т.е. можно: N>- всё оставить в рамках одного процесса. N>- использовать два приложения, которые через pipe обмениваются юзерскими пакетами. N>- вообще разделить по разным серверам, один сервер обсчитывает мир, шлёт юзерские данные через сокеты на другой сервер, а тот уже рассылает всё по миру.
N>P.S. N>Игровой мир довольно сложный и сервер напрягает по максимуму. Типичные размеры пакета для одного игрока — 500б в его сторону и 8 байт обратно, 15-20 кадров в секунду. Предположительно один сервер должен поддерживать сотни игроков.
зайду с конца. 15-20 кадров — это 900-1200 событий в минуту.
топовые корейцы в Starcraft2 выдают APM до 600 в тяжёлых замесах. при этом полезных действий и того меньше(много дублирующих кликов). в среднем в минуту 300-400 действий.
оно вам столько надо в ММО? анимацию можно сгладить на клиенте.
по поводу серверов могу сказать, что помимо задержки возможно появятся проблемы:
— нужен будет пул сокетов между серверами
чтобы разбивать рассчёт мира на куски и слать его через несколько потоков. один сокет всегда будет узким местом. особенно в случае блокирующих запросов(например, использование чего-либо с ответом)
это помимо управляющего треда, через который вы, вероятно, будете рулить удалёнными процессами;
— появится проблема развала сети
она появляется всегда. просто всегда, даже если железки находятся в одной подсети. в конце концов, это могут быть и виртуалки.
если вы будете обсчитывать мир на нескольких железках, то готовьтесь, что раз в год(а то и чаще), кусок мира из рассчётов у вас выпадет. и это надо будет перекидывать на запасное железо. появляется балансер с монитором;
— единая точка отказа для коннектов
ситуация довольно редкая, но иногда клиентская нода может умереть. клиент переподключится, но только если сможет.
выходом мне тут видится наличие dns с round-robin, за которым спрятано несколько адресов. или просто несколько публичных адресов, которые будет знать клиент;
— где-то ещё должен быть спрятан сервер для мета-гейма.
если это отдельный сервис, то ок. а если они все вместе, то появляется риск потерять в случае проблем ещё и его.
в некоторых играх просто мета идёт в условном оффлайне от основного геймплея.
почему бы не сделать классические инстансы под группу юзеров?
так часто делают, когда даже на одной локации видно только часть игроков. остальных в параллельных измерениях. при необходимости их можно телепортировать.
переход между локациями делается через дополнительный коннект к очередному инсту.
и чего не понимаю, так это откуда там 500 байт в кадр, если мир сложный?
допустим, мир живёт своей жизнью, даже если юзер его не видит. как в косморейнджерах.
так эти рассчёты можно упростить, переделать на формулы и скриптованное поведение по таймеру. честный мир игроку не нужен, он нужен геймдизу.
Здравствуйте, neFormal, Вы писали:
F>оно вам столько надо в ММО? анимацию можно сгладить на клиенте.
Это не ММО, это условно леталка.
F>по поводу серверов могу сказать, что помимо задержки возможно появятся проблемы: F>- нужен будет пул сокетов между серверами F>чтобы разбивать рассчёт мира на куски и слать его через несколько потоков. один сокет всегда будет узким местом. особенно в случае блокирующих запросов(например, использование чего-либо с ответом)
Можно очень хорошо разбить, оставить относительно узкие проходы между локациями, где события легко перекидывать — собственно граница может считаться на разных серверах и мёржиться.
F>это помимо управляющего треда, через который вы, вероятно, будете рулить удалёнными процессами; F>- появится проблема развала сети
Это всё потом, сейчас вопрос — общаться с клиентами непосредственно из аппликухи, которая мир крутит или как-то по другому, в силу неизвестных мне причин?
F>- единая точка отказа для коннектов F>ситуация довольно редкая, но иногда клиентская нода может умереть. клиент переподключится, но только если сможет. F>выходом мне тут видится наличие dns с round-robin, за которым спрятано несколько адресов. или просто несколько публичных адресов, которые будет знать клиент;
Придётся так делать, перед выходом в продакшен.
F>- где-то ещё должен быть спрятан сервер для мета-гейма.
Это что?
F>и чего не понимаю, так это откуда там 500 байт в кадр, если мир сложный?
Я тебе конкретно потом покажу, когда разверну до приемлемого состояния
Здравствуйте, Nikе, Вы писали:
F>>- нужен будет пул сокетов между серверами F>>чтобы разбивать рассчёт мира на куски и слать его через несколько потоков. один сокет всегда будет узким местом. особенно в случае блокирующих запросов(например, использование чего-либо с ответом) N>Можно очень хорошо разбить, оставить относительно узкие проходы между локациями, где события легко перекидывать — собственно граница может считаться на разных серверах и мёржиться.
не, я про рассчёт одного куска мира.
ну, мало ли у вас локация настолько сложная.
F>>это помимо управляющего треда, через который вы, вероятно, будете рулить удалёнными процессами; F>>- появится проблема развала сети N>Это всё потом, сейчас вопрос — общаться с клиентами непосредственно из аппликухи, которая мир крутит или как-то по другому, в силу неизвестных мне причин?
я писал о том, что точка соединения между фронтом и бэком тоже может быть узким местом со специфичными проблемами типа блокировки.
я, честно говоря, пайпы знаю плохо, а сокеты в такой схеме встречались.
видел подобную схему для чятика, где бэков было много, а гейт к ним один. подключения шли к гейту, бэки разбирали, кому отправлять сообщеньки и выкидывали их через гейт обратно.
получилось довольно шустро для питона-то. с хорошим запасом по масштабированию. если канала хватало.
хз только, где будет мерж происходит в вашем случае. вполне может быть, что на клиенте, хотя это тоже будет весело.
сделайте, потом расскажете получится эдакий pg_bouncer
Здравствуйте, Nikе, Вы писали:
N>У нас тут небольшой спор вышел: разделять ли физически процесс обсчитывающий игровой мир с модулем отвечающим за внешние взаимодействия (сокеты)?
N>- всё оставить в рамках одного процесса.
Разделить всегда успеете, если возникнет необходимость. А она возникнуть не должна: несколько сотен клиентов — это несерьезно для асинхронного IO. К тому же, очень важно сначала сделать что-то работающее, а уже потом оптимизировать.
N>>- всё оставить в рамках одного процесса.
scf>Разделить всегда успеете, если возникнет необходимость.
если у них планы раскидать всё на кластер — это адова сложность, учитывая ограничения по времени, кмк.
нащупать работающую архитектуру, скорее всего, будет самой сложной частью проекта — я бы такое не откладывал.
хотя я бы вообще такое не делал, если уж на то пошло
