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: Yigong Liu (yigongliu_at_[hidden])
Date: 2009-06-17 01:38:28

Hello,

> i'm currently writing a library for making remote procedure calls to
> C++ objects.
>

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.

> I'll have a closer look on what can be merged with "channels" from the
> boost vault[1], but from the first look it seems that "channels"
> targets a much more general approach. After the first tries, i
> realized, that my implemention has to be very specific (e.g. templates
> only where necessary). So, the design approaches might be too
> different.
>

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.

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".

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

Regards
Yigong