Sorry to have left the discussion so early... I'll try to participate a bit more but life has been (and still is) a hell. There are good platforms out there (corba and dcom) that already performs this kind of work. My first goal was more modest than full RPC support, but as I see it you've made a lot of work. I took a look at the code you had two weeks ago, but don't know how it evolved since then. What I'm curious about is this: suppose that you have a class A with a function member M1 (say which takes a ref to an int and change it for, like, system msec since Epoch). If you have a function that coincidentally takes a pointer (or reference) to A and call its member, where is that member called? Both DCOM and CORBA will work with interfaces that are well-defined on both side to circumvent this case and make it work, but what would your code do in that case? I suppose that actually it wouldnt get back to callee but be called on the same computer, which would not be desired behavior. Another case is exception throwing and memory allocation. What if, while un-marshalling parameters on target, you're OutOfMemory? Or worst, on marshalling it back to origin? That latter case may be a lot of problems since some side effects on target may have been done, and should be undone... or not? Will you restrict the case awfully to the point where the user don't have much choice (no exception, const pointer/reference (watch out for those mutable), one out, no in/out, no class passing / member call back, etc)? Yours, Hans On 1-May-07, at 9:25 PM, Stjepan Rajko wrote:
On 5/1/07, Sohail Somani <s.somani@fincad.com> wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Stjepan Rajko
Yes, each object passed / returned must be serializable via Boost.Serialization. No polymorphic interface is required from the objects.
A call to rpc(f,a1,a2), does it generate some_child<R(T1,T2)> : public some_base which is then serialized and subsequently deserialized and called by some_base *?
Sorry, I sent you the wrong link... oops. The actual link is:
dancinghacker.com/code/marshal/
Apologies.
A call rpc(f,a1,a2), to use that notation, is itself modeled roughly as call<R(T1,T2)> this_particular_call(f,a1,a2) which inherits call_base (which does provide a polymorphic interface). f (function identifier), a1 and a2 are all serialized within the call class, and after a a call rpc_client(this_particular_call) and sent over the network. The syntax can be made to look like it's just a local function call, but the guts of it look like what I described.
On the other side, a registry_server receives the packet, unserializes the function id, and calls a marshaled<R(T1,T2)> wrapper of the actual function. The marshaled class takes care of unserializing the parameters and calling the actual function, then the results get marshaled back etc.
Stjepan _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost