High-Load Java Server для мультиплеера

Question

Я делаю многопользовательскую игру. Теперь я пытаюсь выбрать технологию для подключения устройств Android к серверу. Клиенты работают на Android, а игра MMORPG. Я хотел бы написать сервер в Java. Прямо сейчас у меня есть только 3 идеи для него:

1) Создание многопотативной среды с простой Java и розетками. Таким образом, будет проще выполнить полнодуплексное соединение между игровым клиентом и сервером. Но у меня есть следующие проблемы:

1.1) Игра MMORPG с большим количеством объектов, и я не уверен, как такие решения масштабируются, если есть например, 5000 человек играют одновременно. Сколько потоков я смогу работать на машине Java? Как я могу примерно рассчитать это? В случае, если 1 нить чтение для каждой розетки и 1 резьба писает в розетку (так что 2 потока для 1 игрока).

1.2) Когда количество игроков растет, как я смогу масштабировать мою автозапись JAR-Archive для распространения нескольких серверов? Может быть, есть какой-то особый трюк, чтобы сделать это?

1.3) Много программирования наверху - сокеты API довольно низкий уровень.

2) Создание сервлета-интерфейса для обслуживания HTTP-запросов.

2.1) Легко контролировать сеансы (и авторизацию) до тех пор, пока у каждого игрока есть его / ее собственное сеанс.

2.2) Может подключиться к Java EE EJB или что-то еще - множество осложнений с программированием уровня системы забираются. Так что я могу сосредоточиться на написании бизнес-логики.

2.3) Может служить всем типам клиентов с HTTP - мобильными устройствами + браузерами.

2.4) Высокоскоростная - даже 1 контейнер сервлета может служить несколько тысяч запросов в секунду, поэтому он будет действительно быстрым.

2.4) Но этот подход не может обеспечить полнодуплексную связь. Мне придется отправлять запросы каждые 1 секунду, чтобы проверить обновления. 1 Вторая задержка не имеет большого значения для игры, так как она является поворотом, но все же она генерирует много трафика. Это возможно, когда играет много игроков? Я слышал о некоторых технологиях Comet, но кажется, что если сервер должен нажать много сообщений в строке, мне все равно придется отправлять запросы каждый раз, когда эта технология еще не создана.

3) Создание розеток и подключение их через JMS к серверу Java EE.

3.1) Cool, потому что позволяет для полной дуплексной связи между клиентами и сервером + предоставляет все крутые функции Java EE. Позже может быть расширен до браузера через интерфейс сервлета.

3.2) Кажется, какой-то чрезмерный. Это действительно, как люди это сделают? Я имею в виду это даже правильный путь? Будет ли любой здравый разработчик этого?

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

Answer 1

Зачем переписать то, что вы можете сойти с полки?

Почему бы не использовать reddwarf server (ранее Проект Darkstar )?

Reddwarf Server - это решение с промежуточным программным обеспечением с открытым исходным кодом для разработки серверной стороны многопользовательских онлайн-игр. Это официальная вилка сообщества проекта Darkstar, проект с открытым исходным кодом, поддерживаемый и управляемый Sun Microsystems. - from Статья википедии Reddwarf

Домен Reddwarf, кажется сегодня (2013-06-12), но все еще есть еще есть wiki , и они Миграция на github repo .

Reddward представляет свою философию и цели как:

.
• сделать код игры на стороне сервера надежным, масштабируемым, настойчивым и неисправным толерантным способом, который является прозрачным для разработчика игр.
• Представляют простую однопоточную модель программирования, управляемой событием к разработчику. Разработчик никогда не должен иметь свой код из-за взаимодействия между кодом, обрабатывающим разные события. (из Reddwarf Учебник )

Не то, что это не значит, что сервер-код - это однопоточное, но это абстрагировано с точки зрения разработчика игры. Учебное пособие Reddwarf предоставляет намного больше информации о том, что Reddwarf Can Делайте и разъясняют многие из его дизайнерских решений.

Тем не менее,

Одна точка беспокойства для вас, однако, заключалась в том, что способность мульти-узла не была полностью реализована в прошлый раз, когда я проверяю (CA. 2011).

с нуля

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

Но в любом случае, в любом случае, относительно ваших 3 варианта, ваш первый кажется мне лучшего для меня, если вы должны были пойти на домашнюю реализацию. Вариант 2 (с использованием HTTP-серльетсах) кажется только адаптированным для некоторых игр, хотя я думаю, что это может быть относительно достойным альтернативой, чтобы реализовать что-то самостоятельно, когда все еще делегируя на промежуточное программное обеспечение, и вы можете извлечь выгоду из многих дополнений веб-сервера для обработки нагрузки ( Модули кеша и т. Д. ...). Вариант 3 (с использованием JMS + Jee) действительно кажется чрезмерно чрезмерным, но трудно точно знать, не зная, что вы имеете в виду.

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

Answer 2

1.1) you can't think in term of one Thread by user. Depending of machine configuration but you could load thousands of threads but it will not scale and lose a lot of time in Thread context switch. Better think NIO Netty like framework with few incoming and outcoming Thread pool executor that perform incoming messages under milli second execution.

1.2) You can simply scale by putting in front of you game server a loadbalancer component that can forward incoming player to right server according their load

1.3) NIO can handle thousands to to millions connection on a single box. Don't worry with this.

2.1) Manage your player sessions and 2.2) be away of EJB architecture. It will eat all your box power instead of allocating power to your game which is your goal.

2.3) HTTP can serve all clients but if you run realtime game i encourage to use binary socket and keep HTTP only for loadbalancing , login , stats and fallback when can't establish a socket connection.

2.4) Socket based server can handle hundred thousands incoming message per second. This is the property of low latency system

While it's very interesting to dive in building such system. What is your goal? Learn to build such system or succeed your game?

Many java multiplayer game server technology framework already exist. SmartFox Server, ElectroTank...

We have our own java high load Nuggeta multiplayer crossplatform java game server that addresses all points discussed above and much more. If you wanna try it it's free.

If your goal is to write a game server it's awesome venture that can takes long time but very exciting. If your goal is to succeed your game. Pick up among Java game server SDK already existing.