@Roman: I took a quick look at Jarl Lindrud RCF library. It is in some ways similar but very different in others. The separate client/server concept differs a lot from the node-concept used in my library. I didn't quite understand how objects are handled and addressed in RCF and if it is possible to have two objects of the same type at one server and addressable by one client. Marshalling of in/out variables is one part that is missing in my library. This would be nice for synchronous calls, but could be very bad for asynchronous calls. Using macros to register the functions may be nice for users, but it should not be necessary (which it is for RCF). It provides a proxy class for making the calls to remote functions, which is nice to have. One thing i don't like about RCF is, that it needs the program-wide initialization of the framework in contrast to instancing nodes in my library. Another thing is the dependence on TCP connections, sometimes you need to connect clients where the IP is not available (e.g. via RS232 over optical coupling). After all RCF looks like a more specialized approach compared to my library, but RCF looks like it's easier to get started with than my library so far - something that needs improvement. Do you have experience with using RCF? @Jens Weller The type of serialization is selected by a typedef: #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> typedef boost::archive::text_iarchive iarchive_t; typedef boost::archive::text_oarchive oarchive_t; The archive types occur in the messages for packing/unpacking and some internal functions for function call forwarding. The archive type can easily be replaced by an archive type with a similar interface. The message header encoding also can be easily changed and merged with the information encoded in the archive. Another encoding would be useful to make calls from/to other programming languages, but my library is not designed to be able to communicate with programs, which are not written in c++ and doesn't contain a portable interface definition. One main problem is, that the communication between nodes in my library is not compatible with anything but itself and so far there is no way of "just calling" to some host outside, that isn't a node. Using proxy-classes and a proxy-node to call from/to other systems would be possible and generating them from IDL should also be possible. The question is, for what reason would you want to use another encoding for the messages between the nodes? @Damien Hocking Microsoft not supporting variadic templates is a problem, if you depend on VS. I was under the impression, that Microsoft was ahead of its time and already had all major things in place for C++0x. Thanks for correcting this view.