Boost logo

Boost :

Subject: [boost] Interest in Remote Procedure Call Library?
From: Daniel Larimer (dlarimer_at_[hidden])
Date: 2010-02-06 21:52:26


I have been playing with some code and recently developed a very efficient, extensible, and easy to use API for performing remote procedure calls (with multiple protocols). I am writing to gauge interest and get feedback on the user API. The native "protocol" is a custom combined tcp/udp protocol using multi-cast for discovery, but it would be very easy to add a shared memory solution, a dbus, XML/RPC, CORBA, etc back end to the user api.

Example:

class SomeClass
{
        public:
                int add( int a, int b ) { return a + b );
                void sub( int a, int b, int* result )
                {
                        if(result)
                                *result = a -b;
                };
                void inout( int& a ) { a += 5; }
};

META_INTERFACE( SomeClass,
        METHOD(add)
        METHOD(sub)
        METHOD(inout)
)

// server

SomeClass myclass;
Server myserver( &myclass, "my.named.service" );

// client

RemoteInterface<SomeClass> ri( "my.named.service" );
int result = ri.add(1,4); assert( result == 5 )
ri.sub( 5, 1, &result ); assert( result == 4 );
ri.inout(result); assert( result == 9 );

API can support any type that is serializable. It also supports the signal/slot paradigm. SomeClass could have any number of base-classes both virtual and non-virtual.

With respect to performance, it can perform 15,000+ synchronous (invoke, wait for return) operations per-second on localhost/linux. Asynchronous operations are capable of 500,000+ invokes/sec.

The library doubles as a built-in reflection system allowing run time inspection member functions, parameter types, inheritance, etc.

I am working to convince my employer (small company of 25) that contributing this library would bring more benefits than "costs" to the company. The reasons I think it is a good idea
include:

1) Expose the company to more people (marketing)
2) We can give our customers an "open" API for communicating with our products
2) Offload some of the development / maintenance / support to the open source community
3) I like open source and have personal reasons for wanting it free and open.

So I need to get some more support to convince my employer that this will be a good move. Active interest would be a good sign. Other ideas on the positive aspects of contributing vs keeping it internal would also help me make my case.

Thanks,
Dan


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk