4

I am currently working on a project that has client applications communicating with a server process. The client applications could be local to the same machine as the server process, on the same network, or over the internet. I had written a single-threaded asynchronous RPC module for the server process using Boost ASIO while Google Protobuf was used for RPC message serialization. The architecture was a pretty simple client-server model where a client would pack a request into protobuf message and send it to the server which would send back a response. The server process is written in C++ and the client applications were in varying languages. The main use case for this was to present a GUI to allow users to monitor, and interact with, the server process.

In the future, the server process is going to be separated into functionally separate processes instead of one monolithic process. This presents an issue wherein I now have multiple processes for the client applications to connect to. I don't think this would be a problem in the case of the local or lan client applications but, over the internet, this could become unwieldy if the number of processes grow. Furthermore, I may want to enable IPC between server processes by sending each other RPC messages.

I'm not sure what distributed application architecture would best fit this system going forwards. I don't want to reinvent the wheel if it's not necessary so I've taken cursory glances at D-bus and ZeroMQ, but seeing as I don't really have my architecture settled I thought I'd ask you fellow programmers.

Would it be wise to have a single server process handling communication between client applications and server processes or is there a better architecture style I should be considering? If I want to enable IPC between server processes should I have them directly send messages to each other or should I use the single server process mentioned previously? Should I be looking at something like a publish/subscribe model?

Improve this question
5
  • 1
    RPC can mean anything from something as simple as passing serialized hash maps back and forth to something as complicated as maglev. Please be a little more specific about your use cases and requirements.
    – user7146
    Apr 4, 2013 at 6:01
  • 2
    I will heavily edit this to be far more specific. I'm not sure at all how to ask for a reopen though.
    – Nonce
    Apr 4, 2013 at 14:06
  • I don't think ZeroMQ would be a good fit for me primarily because they use their own socket types. I'd rather use raw TCP/UDP sockets.
    – Nonce
    Apr 8, 2013 at 20:15
  • An update to the previous comment. I really like ZeroMQ so far but I cannot figure out a way to securely transport data yet. Also, D-bus seems to have issues with encryption.
    – Nonce
    Apr 12, 2013 at 20:34
  • For anyone looking to do this, the Majordomo pattern from ZeroMQ is pretty much what I had in mind. rfc.zeromq.org/spec:7
    – Nonce
    Apr 13, 2013 at 22:12

1 Answer 1

Reset to default
1

I think you should have one main process as the gateway. To put less load on it, you can have other processes that do part of work. To scale the main process you can have it listen to an IP and port but advertise the IP as a URL. Then you can use DNS providers which give more than 1 IP on look up (they change the order so both IPs get traffic)

That is what small and big websites do. They serve web pages and you would have your app listening on its own ports (could be 80 if over HTTP or any other that you have opened in your firewall)

The sub processes can have sync or async methods. In Java we have containers and ejbs that do this, will have to do more research for such systems in c++

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.