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.