[boost] Re: RPC library

From: Jarl Lindrud (jlindrud_at_[hidden])
Date: 2005-03-03 06:54:21

Johan Nilsson <johan.nilsson <at> esrange.ssc.se> writes:

> 
> Sorry for not taking the time to read through the implementation, but I have 
> another couple of questions:
> 
> - Is it possible to return an interface as an [out] parameter, receiving a 
> proxy to a remoted object?
> 
> - Is it possible to pass an interface as an [in] parameter, having the 
> receiver receive a proxy to the original object?
> 

Both are possible.

The RcfClient<> class derives from the RCF::ClientStub class, which contains all 
the information needed to connect to a specific object (object id, ip, port, 
etc), so the only thing that needs to be done is to tell the serialization 
engine how to handle RcfClient<>'s. Eg

template<typename Archive>
void serialize(Archive &ar, RcfClient<MyInterface> &c, const unsigned int)
{
  serializeParent<RCF::ClientStub>(ar, *this);
}

In fact, in the next release I'll have that done automatically as part of 
defining the interface.

> - Did you consider implement cross-process reference counted lifetime 
> management (ala DCOM)?
> 

I'm not sure that the reference counting semantics of DCOM are one of its better 
points... Requiring a remote client to correctly call AddRef() and Release() is 
pretty fragile, IMO. For now, what I've done is that each object keeps track of 
how many connections are currently connected to it, and when the count reaches 
zero, a timeout is set, and if the timeout expires with no more connections, 
then the object is removed. The RcfClient<> class automatically terminates 
connections when it's destroyed, so as long as you allocate clients on the stack 
it works pretty well.

> - Did you consider specific support for cross-apartment marshalling (sorry 
> for all DCOM terms, but that's what I've been using in the past)? That is, 
> did you consider different threading models, so
> that single threaded applications only would receive callbacks in the 
> context of the main thread?

I haven't considered it, but I just got the same request from another user, so I 
guess it's time to do so... It might be a little messy, and to me it doesn't 
seem very natural. But I realize sometimes its necessary for application 
specific reasons to have client requests handled by a specific user-prepared 
thread, and not just a generic worker thread.

> 
> >
> > Yeah, I implemented portable binary serialization, along with native 
> > binary and
> > text serialization. I had some performance issues with boost 
> > serialization, it
> > seems as if the boost archives are not well optimized to what I'm doing, 
> > which
> > is creating thousands of archives per second, and then serializing a small
> > amount of data to/from them. I haven't looked closely enough yet to say 
> > where
> > the bottleneck is, though.
> 
> Lastly, are these implementations available in the download and, under what 
> kind of license is the current implementation distributed (I'd like to try 
> it out in a current in-house project)?

The alternative serialization system isn't included in the current download, but 
I'll be posting an update soon, with it included. I haven't given very much 
thought to the license, but you're more than welcome to use it, just keep me 
posted on how it works out! If you need something more formal, there's a licence 
under which all CodeProject articles fall, I couldn't find it now, but basically 
you're free to use it as long as the copyright notices are not removed, IIRC.

HTH,

Jarl.