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-11 12:13:40

Rutger,
        I apologize for being unable to show you the code at the moment, but the interface that I would like to see would be something along the lines of:

int x 		= stub.add(1,2); // synchronous
future<int> x = stub.add(1,2)  // asynchronous
stub.add(1,2); 			     // one way (no return value)

The way I envision that working is for stub to return an generic "call<int>" object, that when cast to an integer causes a synchronous call to be made, when cast to a future causes the an asynchronous call, and when destructed before being cast causes a one-way call to be made.

The down side to the syntax above is that it causes the creation of a temporary object and several additional function calls (constructor, cast, constructor, destructor) to be made before your request can be made.

The current syntax is:

int x	= stub.add(1,2); // synchronous
future<int> x = stub.add(1,2, CALL_FLAGS); 

Then in my "asyc-throughput tests" I do this:

vector<future<int> > return_values[10000];
for( int i(0);  i < return_values.size(); ++i )
        return_values[i] = stub.add(i,i+1, ASYNC);

// block until I have all 10,000 values
return_values.back().wait(timeout);

// call my callback when complete
return_values.back().finished.connect( some_callback );

I get through put on the order of 500,000 calls per second in the asynchronous mode, but latency does go up some.  

Doing synchronous calls your theoretical max call rate (local host, linux (10us ping))  is about 100,000 calls/second.   In practice I am seeing 15,000 calls per second.  Over ethernet 300us ping, your max call rate is about 3300/second.     

There is a place for both synchronous and asynchronous calling conventions because in practice the end user will often create "chains" of asynchronous calls that are really synchronous in nature.  Thus it is more work for them.  On embedded, asynchronous is the only method possible because you are single threaded.

Dan 

On Feb 11, 2010, at 3:38 AM, Rutger ter Borg wrote:

> OvermindDL1 wrote:
> 
>>> asio::io_service ios;
>>> client m_client( ios, "rpc://server/" );
>>> 
>>> remote_function< void( int ) > m_func = m_client( "some.resource" );
>> 
>> Yep, that is how mine worked, just based on a Boost.Function interface.
>> 
>> 
>> If you come up with some benchmarks I would like to compare it to what
>> I made a couple of years ago (where I was admittedly not as
>> experienced with such things as I am now), so if you could post the
>> complete compilable example with included libraries, I am interested.
> 
> 
> If your application is designed to be synchronous, you can never be faster 
> than a full roundtrip. How would a asynchronous version look like? This 
> would be the part I'm most interested in, the true asynchronous case. On 
> invocation, you would do the send only, i.e., the function returns 
> immediately (perhaps even before doing the send). You would issue a 
> completion handler with your request. 
> 
> perhaps
> 
> remote_function< void( int ) > m_func;
> 
> could be called
> 
> // synchronous case, throwing, blocking send/receive
> m_func( 2 );
> 
> // asynchronous case, nonthrowing, fully async, completion handler
> // result_type must be void
> m_func( 2, some_handler )
> 
> or, something along the line of future semantics?
> 
> future<...> = m_func(2);
> 
> Cheers,
> 
> Rutger
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost