Home/ Questions/Q 9132833
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-17T08:22:54+00:00

We are building a new client along with a caching proxy component for an

  • 0

We are building a new client along with a caching proxy component for an existing online game. The current setup looks like:

  Server
  |     \
 TCP    TCP
  |       \
Client1  Client2

The new setup will be:

 Server
 |   |
TCP TCP
  \   \
   Proxy          <-- (New!)
   |    \
  0MQ   0MQ
   |      \
Client1  Client2  <-- (New!)

The proxy component will sit close to the existing game server and speak the old line based TCP protocol to it, while speaking a new Google Protocol Buffers-based protocol over 0MQ to the new client. In addition to forwarding and translating messages between the server and its clients, the proxy will also cache (protobuf) messages destined for clients.

The server responds to client requests, but may also send unsolicited messages to specific clients, or to all clients. Since the proxy will maintain a cache of messages destined for a certain client, it needs to keep some state associated with each client.

I’ve been reading quite a bit in the ZeroMQ Guide, but I’m still not sure which of its “patterns” or socket combinations would suit this setup best. I’m hoping there’s some ZeroMQ wizard out there who can give some advice on what the best way to go here is.

The question is not language specific, but the proxy component will be written in Java and the client in C#.

Many thanks in advance!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I think the Asynchronous Client Server pattern will get you close. Each of your clients creates a DEALER socket which connects to the ROUTER socket in your proxy. Review the example Java source. You could base your proxy on the ServerTask class, using the frontend/ROUTER socket and omitting the backend/dealer socket.

    Your server will be able to respond to client requests and send unsolicited messages back to any client. You will need to cache the socket id of each client after the client has sent at least one message.

    Your TCP connection to the game server is conceptually similar to the backend DEALER sockets between the server and workers – however since your connection is classic TCP and and not ZeroMQ you cannot use ZeroMQ sockets and will need to do something custom. And your custom solution requires that you not violate ZeroMQ’s concurrency rules, when you integrate with classic TCP sockets.

    Here is one way – use a set of PAIR sockets (lets call them A and B) and a BlockingQueue to act as a bridge between ZeroMQ and your TCP sockets. And create 3 threads – TCPRead, TCPWrite and ZeroMQ.

    TCPRead reads from the TCP connection to the game server. It converts them to protobuf messages and forwards them through the A socket.

    TCPWrite polls the BlockingQueue for messages. When it receives a message it converts it and sends it to the game server via TCP connection.

    Finally, most of the work is in the ZeroMQ thread. It uses ZeroMQ polling and is constantly polling it’s router socket (for all messages from all clients) and the B socket (for messages from the game server). Sending messages to a client is straightforward and is handled by sending the message to the router socket, prefixing the message with the socket id of the client. Sending messages to the server is done by adding a message to the BlockingQueue. It will be picked up by TCPWrite and forwarded to the game server.

    Once you get this basic design working, you can go nuts and add workers etc as described in the various patterns.

    Hope this helps.

    • 0