How should I implement a distributed Remote Method Invocation system in .NET?

Question

Original Post

How would I implement a distributed Remote Method Invocation system?

I'm trying to create something like the following:

• Master Server to track individual "hosts".
• Hosts can communicate with other hosts on the network using a proxy-object-interface based programming style, example: var result = remoteHost.MyMethod(5);

I've tried using RMI libraries like SuperPool and Scs, however they have a few fundamental issues:

• SCS Supports only Server --> Client or Client --> Server communication, no Client --> Client communication.
• As far as I can tell, SuperPool only supports the same, although this picture would suggest otherwise, I cannot find anything in the documentation on how to do this:

The difference would be that any component on clients can also communicate with components on other clients, as opposed to only client-->server or server-->client communication.

How would you suggest I implement this (perhaps using these existing solutions as a base), or is there some other existing solution that might work?

More Extensive Example

Here is a diagram of what I'm trying to do:

_{IMPORTANT NOTE: Clients do NOT connect to each other.}

Process:

1. Client1 connects to Server
2. Client2 connects to Server
3. Client1 invokes a method on Client2, without knowing if the component of Client2 exists on the Server, another Client, or itself.

The idea is the same as what SuperPool has done, except allowing the Client --> Server --> Client communication path for invoking a method on the second client.

Answer 1

From a cursory look at Superpool it does seem to support all possible types communications. It is an RMI layer over a message queue, and allows synchronous or asynchronous communication to a named target or (possibly multiple) unnamed targets. I confess to not really understanding what your architecture is about.

The problem I see with Superpool is that it locks you in to .Net. All your components must be .Net and all must use Superpool.

The "standard" way to deal with decoupled communications between components (decoupled meaning the sender does not necessarily need to know who the receiver is), is to place all the components on a message bus. @Erno de Weerd propossed ZeroMQ which is one possible way to do this, a higher level option (albeit slower) is to use a full fledged message queue server(s) such as RabbitMQ or even MSMQ.

The downside is you lose the invocation syntax of Superpool (or other RMI solutions) and must think of passing messages back and forth through channels instead of calling methods on components.

Answer 2

Although ZeroMQ is quite low level, it supports bidirectional communication and has .NET support and is available on nuget.org

You can multiplex many bidirectional conversations on a DEALER/ROUTER or DEALER/DEALER socket pair and either side can initiate a conversation.

Be aware though that ZeroMQ does not come with everything ready to do method invocation; you would have to create your own protocol or use an existing one and implement it.

Both Salt and Cloudless, built on top of ZeroMQ, provide remote method invocation.

ZeroMQ facilitates very robust asynchronous sockets (and more) Routing messages is absolutly possible. If you combine the Ventilator and Sink in the ZeroMQ Guide you are very close to what you want to accomplish.

Note that you would still have to implement the actual protocol and method invocation.