ACB
ACB

Reputation: 1637

C++ Calling methods of a remote object (RPC alike)

Im searching for a RPC library that would allow me to call a memberfunction of an object in another Process (on Windows).

The problem im currently encountering is that some of the Serverside objects already exist and have more than one instance. The Server should be able to pass a pointer/identifier to the client which implements a proxy that then directs the calls to the remote objects instance. So what i basically want is something like this:

Client:
TestProxy test = RemoteTestManager.GetTestById(123);
test.echo("bla");

where the instance of Test already exists on the Server and the RemoteTestManager is a manager class on the server that the client obtained in another rpc call. Also it should preferably run over named pipes as there can be multiple servers on the same machine ( actually i want more like an easy IPC :D ).

So my question actually is: Is there something like this for C++ out there or do i have to code one myself

Upvotes: 3

Views: 2610

Answers (5)

OMID
OMID

Reputation: 1

There are candidates on top of the list. But it depends on problem space. A quick look, Capnproto, by kenton varda, maybe a fit. CORBA is a bit old but used in many systems and frameworks such as ACE. One of the issues is PassByCopy of capability references which in capnproto PassByReference and PassByConstruction also provided. COM system also got some problems which needs it's own discussion. ZeroMQ is really cool which I caught a cold once. And it does not support RPC which means you have to implement it on level zero messaging. Also Google protobuf, kenton varda, could be a choice if you are not looking for features such as capabilities security, promise pipelining and other nice features provided by capnproto. I think you better give it a try and experiment yourself.

As a reminder, RPC is not only about remote object invocation. Areas of concern such as adequate level of abstraction and composition, pipelining, message passing, lambda calculus, capability security, ... are the important ones which have to be paid close attention. So, the better solution is finding the efficient and elegant one to your problem space.

Hope to be assistfull.

Bests, Omid

Upvotes: 0

kwanti
kwanti

Reputation: 435

You might have already found the solution. Just for the reference of other, I have created a library that match what you asked here. Take a look at CppRemote library. This library has features below that match your descriptions:

  • get pointer to objects at server by name (std::string).
  • bind existing object (non-intrusive) at server and then get a proxy to that object from client.
  • server can bind to more than one instance of existing object.
  • it has named pipe transport.
  • lightweight and easy to use.

server code

Test test1, test2;
remote::server svr;
svr.bind<itest>(&test1, "test1");
svr.bind<itest>(&test2, "test2");
svr.start(remote::make_basic_binding<text_serializer, named_pipe_transport>("pid"));
...

client code

remote::session client;
client.start(remote::make_basic_binding<text_serializer, named_pipe_transport>("pid"));

auto test1 = client.get<itest>("test1");
auto test2 = client.get<itest>("test2");
test1->echo("bla");
test2->echo("bla");

Upvotes: 1

Andrew Tomazos
Andrew Tomazos

Reputation: 68708

In terms of low-level serializing the messages across the network Protocol Buffers is a common choice...

http://code.google.com/p/protobuf/

For a more complete RPC stack take a look at Apache Thrift...

http://thrift.apache.org/

Upvotes: 2

Brandon Paddock
Brandon Paddock

Reputation: 321

How about COM? Seems to fit your requirements perfectly.

Upvotes: 1

gbjbaanb
gbjbaanb

Reputation: 52689

ZeroMQ is possibly the best IPC system out at the moment and allows for quite a varied combination of client/server topologies. And its really fast and efficient too.

How you access the server objects depends how they're implemented, CORBA had this facility, but I wouldn't try to use CORBA nowadays (or then TBH). A lot of RPC systems allow you to create objects as needed, or to connect to a single instance. Connecting to a object that is created for you, and kept for each call during that session (ie an object created for each client and kept alive) is still reasonably common. A pool of objects is also reasonably common too. However, you have to manage the lifetime of these server objects, and I can't really advise as you havn't said how yours are managed.

I doubt you want named pipes, stick to tcp/ip connections - connecting to localhost is a very lightweight operation (COM practically is a zero overhead in this configuration).

Upvotes: 0

Related Questions