Re: [Boost-users] New library for RPC-calls using only boost and C++0x

Subject: Re: [Boost-users] New library for RPC-calls using only boost and C++0x
From: Siegfried Kettlitz (siegfried.kettlitz_at_[hidden])
Date: 2009-06-19 01:58:02

Hi Yigong,

>
> FYI, last year Stjepan spent quite some time on a rpc library, have you had
> a chance to look of it? (
> https://svn.boost.org/trac/boost/browser/sandbox/rpc). I remember he
> implemented asynchronous calls and use futures<> to implement synchronous
> calls. If you search last year's email, you may find good discussions about
> this rpc lib.
>

This is for calls to functions and not member-functions. I shouldn't call my
library doing Remote Procedure Calls, but Remote Member Calls.

The approach using futures is one thing, i'd like to implement, too, since
everything needed for that is already in place.

One thing i don't like about that library is, that you need to provide the
interface explicitly multiple times:
reg.set<int (int)>("inc", inc);
rpc::call<std::string, int (int)> call_inc__1("inc",  1);

This could be improved using variadic templates (or boost::fusion).

> Yes, the Channel lib i am working on has a quite different target. It
> intends to define / provide the basic primitives for message passing
> (various name-spaces and dispatchers), and a template framework to compose
> these primitives and create customized message passing systems for specific
> applications. And the resulted messaging systems should be quite simple.
>
> Channel generated messaging systems are peer-peer systems, not like the
> client-server model of RPC. When 2 remote channels connect, the ids / names
> in these 2 channels are exchanged automatically thru Channel's protocol, so
> threads / objects connected with these channels can do messaging with remote
> peers transparently.

Can more than two channels connect?

If so, consider A connected to B, B connected to C. Does A see C and can
communicate with it?

Another big difference is the use of "names" / "ids". In normal rpc systems
> (or rpc based systems such as Corba), the only purpose of object names/urls
> or name-server is for "boot-strapping" - obtaining the inital reference to
> remote server object, after that, names/urls has no use. In RPC systems, the
> interface of components are the remote methods exposed by server objects
> (defined in IDL).
> In Channel, "names/ids" and name-spaces provide the major design scheme /
> framework for distributed systems. The interface of a component in
> distributed systems are what "ids" it publish and what "ids" it subscrib to,
> its physical location doesn't matter much. A component running inside a
> process "A", attached to a channel and pub/sub some ids, can easily be moved
> to another process "B" in a different machine, as long as "B" has a channel
> which connect to "A"'s channel. The component will function as normal as it
> was in process "A".

This sounds very much like Plan9.

Can the namespace-model be built upon a normal RPC-library without much
effort?

I assume, that something like a dynamic name->id resolver added to the
RPC-library provides just what you want.  Instead of native references, the
objects need to be addressed by the "names". When an object changes its id,
the resolver publishes that information and the calls go to the "new"
target. Although defining abstract interfaces for such an implementation is
still a good idea and in the long run better than having multiple
implementations with incompatible interfaces.

> RPC is a really important in many domains, although i talked mostly about
> Channel above. Please keep up your good work!

Thanks, I will.
Siegfried