[boost] Re: RPC library

From: Johan Nilsson (johan.nilsson_at_[hidden])
Date: 2005-03-09 02:47:18

"Jarl Lindrud" <jlindrud_at_[hidden]> wrote in message 
news:loom.20050308T150947-455_at_post.gmane.org...
> Scott Woods <scottw <at> qbik.com> writes:
>>
>>
>> Hi Jarl,
>>
>> I have browsed your CodeProject materials and followed this thread with
>> interest. The project was familiar but with the pertinent magazine no 
>> longer
>> in my
>> possession, I cannot give you the proper acknowledgements. Was that your
>> work in CUJ?
>
> No, but I think I remember the article you're referring to, in fact here 
> it is:
>
> http://www.cuj.com/documents/s=8206/cujweb0304batov/
>
> I haven't really looked at it, but in some ways it's quite similar.
>
>>
>> To cut a long story short, I believe what is really needed is a 
>> "signaling"
>> or
>> "messaging" library. Construction of an RPC facillity over the top of 
>> such
>> a library would be perfectly valid. The "sub-optimal" thinking I 
>> mentioned
>> earlier is my term for a development environment where RPC is considered
>> the basic building block for distributed computing.
>
> <snip>
>
>>
>> If this message is useful to you maybe its to help decompose the design
>> and implementation of RPC. If the internals of your RPC were totally
>> message-based and state-driven then perhaps everyone would be
>> happy. Well, I would be
>>
>> Cheers,
>> Scott
>>
>
> Thanks for the comments Scott,
>
> You have some good points.
>
> I agree with you that its poor style to have a client block while waiting 
> for a
> reply. In fact, blocking functions are almost always poor style, whether 
> you're
> dealing with network communications or anything else.
>
> Someone mentioned previously in this thread as well, that it would be 
> unwise to
> place remote function calls behind local function call semantics. If the 
> remote
> call is blocking, then I agree, but the problem is that the call blocks, 
> not
> that it's a remote call looking like a local one.
>
> I'm pretty sure I can make my library function well both in non-blocking 
> and
> blocking modes, but it needs to be designed from the bottom up, with that 
> in
> mind, as you're saying. I'm going to be redesigning it anyway, so 
> hopefully
> there will be some opportunity to get it right.

Wouldn't it be "better" to build the foundation on non-blocking (or 
preferrably, asynchronous) I/O? Implementing a blocking/synchronous 
communications layer on top of that should be a lot easier than the other 
way around.

I realize that this would decrease the performance soemwhat for the blocking 
mode, but if you're after performance you're very likely to go for async I/O 
anyway.

As for messaging vs RPC, I think the same thing applies; it is easier to 
build an RPC layer on top of messaging than the other way around. OTOH, 
carefully designing interfaces for remoting from the start makes it possible 
to achieve good performance with RPC as well (and they are likely to reflect 
the fact that the are intended to be remoted).

Just another 0.02EUR.

// Johan