Re: [boost] Re: RPC library

From: Scott Woods (scottw_at_[hidden])
Date: 2005-03-09 15:41:13

----- Original Message ----- 
From: "Caleb Epstein" <caleb.epstein_at_[hidden]>

[snip]

> On Wed, 9 Mar 2005 16:25:34 -0000, Iain Hanson
> <Iain.Hanson_at_[hidden]> wrote:
> 
> > In most, if not all messaging systems you do have connect to an end
> > point. The remote server provides various QoS and you need to register
> > your subject or channel and whether you are a push or a pull publisher.
> > Oh 8-) I think I'm re-inventing the CORBA Notification service. What a
> > surprise.
> 
> This is not how TIBCO RV works.  You need to connect to the RV daemon
> (which can be auto-started on your local host) but you do not need to
> pre-register anything if you're using the normal "reliable" QoS. 
> There is no direct communication between subscribers and the
> publisher.  If a subscriber (or really its RV daemon) detects a gap in
> sequence, it will request a retransmission automatically and, if the
> message is still in-core on the sender side, the sending RVD will
> resend it.  I'd call this NAK-based processing and it is overall quite
> effective.
> 
> With their Certified Messaging protocol, however, each subscriber
> registers with the publisher and must ACK each message.

I may be responsible for some confusion here. If that is the case
then perhaps this will help.

I believe I introduced the term "messaging" to this discussion. I
chose the word because I hoped it would be less confusing than
terms I am used to, i.e. signaling. CORBA Notification is a fine
thing. Messaging systems (involving store and forward) are also
fine things. But neither are really in the same domain as the
original discussion. Which does not necessarily detract from
yours :-)

Lastly I think that Jarls responses (and others) have followed
my original meaning.

All good,
Scott