I am considering using gRPC for communications between three different processes (two use Python and one is in C++). I've made working prototypes with both a single RPC message -> reply structure and a bidirectional stream structure and am trying to decide which overall topology to ultimately go with. The requirements are that I need to be able to know the status of the other two processes from a given process, and that they can send any message to either partner at any time. All three processes are on the same machine.
Here is what I have considered:
Each process implements its own client and server. This way it can try to connect/send something to the other processes as a client to determine if they are running or not. It would be the most work, but it seems to be the safest so that each client could handle a broken connection in the event that either or both of the other processes crashes. I am leaning towards this one at the moment.
Client only process, server only process, and mixed client/server process. This is probably less overhead. Though in writing this out, I realize that for one of the processes I already make both a client/server mix, and it seems servers don't have the ability to check the status of clients cleanly without some sort of heartbeat RPC from the clients. A lot of important information needs to be passed around, so I need to know if a message makes it to target.
Another method that I have not thought of that would achieve the same goal in a cleaner fashion such as some sort of server-to-server-to-server or client-to-client-to-client communications.
If there are other suggestions or flaws in my logic, I would be happy to hear them, thank you.