On Tue, Jun 16, 2009 at 11:38 PM, Yigong Liu
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!
On the open source (but not free in cost for commercial app) networking library RakNet, I created a templated RPC interface for it. It is very efficient, type-safe on both side, and the external interface is more simple then what you have above. Quite literally you just define you function, class member, whatever, then just register it. There is a helper thing to that it returns that you call instead. The tutorial video is at http://www.jenkinssoftware.com/raknet/manual/RPC3Video.htm and if you download it, it is RPC3. I wrote that and donated it to his project. I mostly ripped it out of an old script registration system (that build up the variable conversion operations and called the native C/C++ function as appropriate). It makes heavy use of Boost.Fusion (this was right when Fusion was added to Boost). It made for a wonderful and easy to use system. The above tutorial mostly focuses on features that his old assembly driven RPC system was not capable of, but mine had more features that he never seems to use. For example, when you register a function you can store it in a boost/tr1::function<> object, then if you call that instead it saves a map lookup for the name, and based on the setup you set for it (only call on client systems, only call on server, only call on owner, etc...) it called everything appropriately, very powerful (I really wish he used that feature, I do not like the fact he shows them how to do it dynamically, hence the hashmap lookup... But yea, look at the tutorial video for the basic feature rundown (I did not make that video, Rak'kar did). Another feature mine has that he does not display, if your function has a parameter of Raknet::RPC3* then it auto-fills that in with the RPC3 registration object, letting you get detailed information about your call like if it is a remote call, local call, etc... It also check for various class hierarchies, such as if a NetworkIDObject is a subclass of any class pointer passed in, it will use the corresponding registered NetworkIDObject on the remote system and so forth. Raknet::Bitstream is a bitstream as you would expect (I really want a bitstream like Raknet::Bitstream in boost, does anyone know if one already exists? the only ones I have found do not have the capabilities), and I had him add the operator
/<< functions so streaming can be overloaded.
Either way, he changed the code slightly, added a few more default overloads, etc... since I gave it to him a long while back (back in Boost 1.35's time period, 1.35 was new), but take a look at the RPC3 code and see how it does it, actually very simple, very powerful, type-safe, overloadability, etc... I would be quite happy if my code ended up in Boost. But, thanks to fusion and such, does not require variadic templated (although tr1::function is the main restriction, if it uses variadic templates then there is no real limit to my system then).