1

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?

4

1 回答 1

3

您可以使用虚拟机内消息传递。这是一个netty游戏服务器（小心！我写的！）已经使用了这种actor模型。它使用 JetLang 进行事件分派和会话来记住与客户端的每个连接。虽然您的用例可能无法直接得到满足，但如果您查看 jetserver 的源代码并衍生出您自己的逻辑，您肯定会得到一些想法。

如果您注意到，即使是无状态的 UDP 也与会话相关联。

于 2012-06-04T17:56:18.973 回答