Re: [boost] Interest in Remote Procedure Call Library?

Subject: Re: [boost] Interest in Remote Procedure Call Library?
From: Daniel Larimer (dlarimer_at_[hidden])
Date: 2010-02-10 10:57:15

Rutger,
        The only reason I assumed classes is because in our application there are many functions grouped together and we are leveraging hierarchal interfaces.  I suppose that your interface below could work equally well as an alternative interface within the same library.  I kind of like it for its simplicity!

        An update on where I am.  I have successfully added support for overloaded member functions and re-factored the code based upon some feedback given here and in the process have adopted the boost/stl naming conventions.

        I have been thinking about the nature of the library and what I would call it and have concluded the following.

1) The "core library" should be free of any network code or dependency on boost::asio because networking is only one way to "invoke a method" on an object outside of your memory space (or even inside your memory space).

2) The real "generic" function I am attempting to provide is automatic "stub" generation to create a "proxy object" that controls the dispatch of method calls, signal emits, and parameter queries while providing a developer experience as similar as possible to working with a local object and minimizing the amount of time spent using the IDL (Interface Description Language), which in our case is templates and c-preprocessor.

3) Using "Boost.Stub" I would then provide different Stub delegates for handling different kinds of dispatch mechanisms.  I believe I have identified some useful applications for Boost.fusion in some stubs.   If done right, we should be able to create a stub that would give any class an "active object" interface to synchronize calls across threads.  

4) With my latest rework I believe I will be able to get the object code and memory usage small enough to work on an embedded system running LWIP with 64K of ram and 150K of flash.  This requirement means that the library should function well even in environments where dynamic heap allocation, rtti, and exceptions are forbidden!  Support for the embedded platform should not come at the expense of desktop users.  Achieving this should be very possible if the stub library really sticks to its goal of only defining the template hooks that allow any number of delegates to be written.   

5) With all of that said, I believe that the core library will be header only.  What I was calling the "meta interface" is really just providing the necessary type descriptions/hooks/macros to enable the development of delegate classes that do all of the real work.  Some delegates may be compiled into a library while others (such as the default delegate, a pointer to an object in the same memory space) can be header only as well.   With this approach there is almost no "abstraction layer" overhead between the caller, the delegate, and the actual network code (if it happens to be a network RPC delegate).

I need to run some benchmarks, but I believe that the "cost" of using a stub<MyClass,default_delegate> vs a direct pointer to MyClass is at most one function call and a member function pointer de-reference and at best, completely inlined so as to be "identical" at run time.   

Does anyone have any pointers on how to "compare" the asm generated by a particular line or group of lines of code?  I would like to see how much inlining is actually going on and monitor the cause/effects of different template/code structures on the resulting code. 

Thoughts?
Dan  

On Feb 10, 2010, at 9:38 AM, Rutger ter Borg wrote:

> Daniel Larimer wrote:
> 
>> 
>> // 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 );
>> 
> 
> Hello Dan, 
> 
> I'm interested. Is the assumption of classes and member functions needed? 
> What about mimicking the boost::function interface?
> 
> asio::io_service ios;
> client m_client( ios, "rpc://server/" );
> 
> remote_function< void( int ) > m_func = m_client( "some.resource" );
> 
> Cheers,
> 
> Rutger
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost