Re: [boost] Re: RPC library

From: Scott Woods (scottw_at_[hidden])
Date: 2005-03-07 18:11:56

----- Original Message -----
From: "Jarl Lindrud" <jlindrud_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, March 07, 2005 11:59 AM
Subject: [boost] Re: RPC library

> Iain Hanson <Iain.Hanson <at> videonetworks.com> writes:
> >
[snip]
> >
> > Personally I tend to prefer not letting programmers shoot themselves in
> > the foot, if I can avoid it. Unfortunately, they ( and I sometimes ) are
> > incredibly  inventive at finding new ways to do so .
> >
>
[snip]
>
>
> I guess you don't find much need for networking at all in Boost? At least
not
> beyond lowlevel socket API wrappers and assorted utilites that might be
useful
> for something like realtime socket apps. Anything beyond that can, and
should,
> be done with CORBA, regardless of scale and scope.
>
> /Jarl.
>

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?

The library looks good and it is underpinned by a well-known model, i.e. a
procedure call. This is part of its basic strength and also IMO its failing.

Before I attempt to back this up, I would first like to state that RPC-type
mechanisms deliver a very useful facillity and your library is a clean
example
of such a facillity. In Boost-form it would be even more appealing.

My difficulty with RPC is that its goal is to deliver the appearance of a
callable local (i.e. in the same address space) object. In one sense this
is desirable but in another sense I believe this to be "sub-optimal"
thinking.

Implementation of an RPC will involve multiple network "sends". At a
minimum there will be a "request" (client to server) and a "response"
(server to
client). This can be represented as below;

    CLIENT -> [REQUEST] -> SERVER
    CLIENT <- [RESPONSE] <- SERVER

An immediate difficulty for me is that the calling client is blocked for
the period spanning the two transmissions. More importantly there may
be interesting activity in the server during that period that the client
would
like to know about. The RPC model doesnt lend itself to this type
of interaction;

    CLIENT -> [REQUEST] -> SERVER
    CLIENT <- [PROGRESS] <- SERVER
    CLIENT <- [PROGRESS] <- SERVER
    CLIENT <- [..] <- SERVER
    CLIENT <- [RESPONSE] <- SERVER

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.

The long version of this story would cover things like sockets,
marshalling, serialization, I/O multiplexing, threading, state machines and
application protocols. Its interesting that several of these topics have
their
own concurrent threads.

Somewhat sadly I think that the stiffest resistance to a messaging library
is cultural; akin to the resistance to OO. Moving to a pure messaging world
is non-trivial. Its almost a necessity to "go state-driven" at the same
time.
Its been sobering to observe the reception that Andreas' FSM library
has received.

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