Servidor Java de alta carga para multiplayer

Question

Eu estou fazendo um jogo multiplayer. Agora estou tentando escolher a tecnologia para conectar os dispositivos Android ao servidor. Os clientes executam no Android, e o jogo é MMORPG. Eu gostaria de escrever o servidor em Java. Agora eu tenho apenas 3 ideias para isso:

1) criando ambiente multithreading com java e soquetes simples. Desta forma, será mais fácil realizar conexão full-duplex entre o cliente do jogo e o servidor. Mas eu tenho as seguintes preocupações:

1.1) O jogo é MMORPG com um grande número de objetos, e não tenho certeza de como essas soluções são escaladas se há, por exemplo, 5000 pessoas jogando ao mesmo tempo. Quantos tópicos poderei correr na máquina Java? Como posso calcular aproximadamente isso? No caso 1 thread está lendo para cada soquete e 1 thread está escrevendo para o soquete (SO2 threads para 1 player).

1.2) Quando o número de jogadores cresce, como poderei dimensionar meu artigo auto-escrito para distribuir vários servidores? Talvez haja algum truque especial para fazer isso?

1.3) Um monte de sobrecarga de programação - API de soquetes é bastante baixo nível.

2) Criando uma interface de servlet para servir solicitações HTTP.

2.1) Fácil de controlar sessões (e autorização) contanto que cada jogador tenha sua própria sessão.

2.2) Pode se conectar ao Java EE EJB ou qualquer outra coisa - muitas complicações com a programação no nível do sistema são tiradas. Para que eu possa me concentrar em escrever lógica de negócios.

2.3) pode atender todos os tipos de clientes com dispositivos HTTP - Mobile + navegadores.

2.4) Alta velocidade - até 1 contêiner de servlet pode servir algumas mil solicitações por segundo, por isso será muito rápido.

2.4) Mas esta abordagem não pode fornecer uma comunicação full-duplex. Vou ter que enviar solicitações a cada 1 segundo para verificar as atualizações. 1 segundo atraso não faz muita diferença para o jogo, pois é baseado em turnos, mas ainda gera muito tráfego. É viável quando há muitos jogadores jogando? Eu ouvi sobre alguma tecnologia de cometa, mas parece que se o servidor tiver que empurrar muitas mensagens na linha, eu ainda terei que enviar solicitações toda vez + esta tecnologia ainda não está bem estabelecida.

3) criando soquetes e conectá-los através do JMS ao servidor Java EE.

3.1) Cool porque permite a comunicação duplex completa entre clientes e servidor + fornece todos os recursos legais do Java EE. Posterior pode ser estendido para navegador através da interface de servlet.

3.2) Parece que algum tipo de superengenharia. É realmente como as pessoas fariam isso? Quero dizer, é mesmo a maneira correta? Será que qualquer desenvolvedor Sane fez isso?

Eu gostaria que você me ajudasse com a escolha, por favor. Eu não tenho muita experiência em fazer algum trabalho assim. E gostaria de ficar com as melhores práticas.

Answer 1

Por que reescrever o que você pode sair da prateleira?

por que não usar servidor reddwarf (anteriormente Projeto Darkstar )?

.

Reddwarf Server é uma solução de middleware de código aberto para o desenvolvimento do lado do servidor de jogos on-line massivamente multiplayer. É o garfo comunitário oficial do projeto Darkstar, um projeto de código aberto suportado e gerenciado pela Sun Microsystems. - de Artigo de Wikipedia de Reddwarf

O domínio de Reddwarf parece hoje (2013-06-12), mas ainda há um wiki e eles são migrando para um repo github .

Reddward apresenta sua filosofia e metas como:

.

• Faça o código do jogo do lado do servidor confiável, escalável, persistente e tolerante a falhas de uma maneira que seja transparente para o desenvolvedor do jogo.
• apresenta um modelo simples de programação orientado por eventos simples para o desenvolvedor. O desenvolvedor nunca deve ter seu código falhar devido a interações entre o controle de código diferentes eventos. (do reddwarf tutorial )

Não que isso não signifique que o código-servidor é simplesmente roscado, mas que é abstraído da perspectiva do desenvolvedor do jogo. O reddwarf tutorial fornece muito mais informações sobre o que o Reddwarf pode fazer e esclarecer muitas de suas decisões de design.

Um ponto de preocupação por você, porém, foi que a capacidade multi-nó não foi totalmente implementada da última vez que cheque (ca. 2011).

do zero

Isso não deve impedi-lo de tentar fazer a maioria dessas coisas do zero, se você valoriza a experiência de aprendizado. No entanto, este é um esforço importante e será bastante demorado, e como, você observou em sua pergunta, algumas dessas questões são bastante de baixo nível na pilha de tecnologia para lidar e aumentará muito a complexidade do código que você terei que manter.

Mas de qualquer maneira, em relação às suas 3 opções, o seu primeiro parece o melhor para mim, se você fosse para uma implementação doméstica. Opção 2 (Usando Servlets HTTP) parece apenas adaptado para alguns jogos, embora eu acho que pode ser uma alternativa relativamente decente para implementar algo mesmo enquanto ainda delegava para o middleware, e você pode se beneficiar de muitas adições do servidor da Web para lidar com a carga ( módulos de cache, etc ...). Opção 3 (usando JMS + Jee) parece superenginada, mas é difícil saber com certeza sem saber o que você tem em mente.

E se você estiver aqui para tentar aprender, então obviamente opção 1 cobrirá muito terreno. Mas vai ser uma batalha bastante difícil.

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.