Netty Game Server

1
votes

I am trying to build a generic server for always on connected clients.

The architecture consists of 4 main components

  • Stateful App Servers
  • Stateless Gateway Servers
  • Clients Queueing
  • Systems and brokers

Process flow

  1. Client connects to a gateway
  2. Gateway accepts as sends a session id back to client
  3. Client sends a message to gateway
  4. The Gateway writes the request to a Message / Task Queue
  5. A daemon reads the messages on the Queue and forwards them to the App Server(s)'s listening socket
  6. The App Servers runs the message through its business logic
  7. The App Server then at a later point sends a related message to the client into the gateway queue
  8. A thread on the gateway reads the messages in its inbound queue and then sends messages back to clients as identified in the message.
  9. The gateway maintains a map of Client Session Id to the Client Socket object to forward incoming messages to the Client Sockets

I am using Java Netty for gateway. App server is also in Java.

I am tempted to say that the design is like Mongrel2 but I am not completely sure. I would say this is more on the lines of the Helium edge server design of Urban Airship (http://urbanairship.com/blog/2010/08/24/c500k-in-action-at-urban-airship/)

My question is: - Is using a thread for reading messages from the inbound queue and then forwarding them to clients a good idea? Is there a better way to handle this? How do i ensure that the messages go to the respective client socket without using another thread?

1
netty
If you're serious about this project, use Akka (Akka uses Netty) or Erlang. Don't reinvent the wheel. – Ngoc Dao
Is there a specific reason for using Actor based concurrency for this project? I do know Erlang - but in terms of raw speed and long term ability to maintain the codebase, I think Java would be a better bet. WDYT? – kopos

1 Answers

3
votes

You could use in-vm messaging. Here is a netty game server (caution! written by me!) which use this kind of actor model already. It uses JetLang for event dispatch and sessions to remember each connection to client. While your use case may not be directly met, you could definitely get some ideas if you look into jetserver's source code and spin off your own logic.

If you notice, even stateless UDP is tied to the session.