----- Original Message ----- From: "Jarl Lindrud" <jlindrud@hotmail.com> To: <boost@lists.boost.org> 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