On 09/26/2013 03:28 PM, Ted Ross wrote:

On 09/26/2013 08:23 AM, Gordon Sim wrote:
On 09/26/2013 01:14 PM, Ted Ross wrote:
I'm putting a feature into Dispatch that allows a client to dynamically
obtain a routable reply-to address.  This will involve changes in
Messenger as well.

I'd be interested in hearing a bit more about that, with a view to
making any necessary changes to the qpid::messaging library also.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org


Here's how it looks from a protocol perspective:

                                              Server or
         Client                           First Intermediary
            |                                     |
            |-- Attach Sender  ------------------>|
            |<- Attach ---------------------------|
            |                                     |
            |-- Attach Receiver (src=_dyn_) ----->|
            |<- Attach (src=<temp>) --------------|
            |                                     |
            |-- Xfr (to=SVC, reply-to=<temp>) --->|
            |                                     |
            |<- Xfr (to=<temp>) ------------------|
            |                                     |

The client creates a pair of links, one to send the request and one to
receive the response.  The source-terminus of the response link is
flagged as dynamic.  The peer then assigns a temporary source address to
the link.  This address is valid for the life of the link.  This
temporary address can then be used as a reply-to in the request message.

Great, that will work already with qpid::messaging. Indeed that is how the unmodified client example works (which I've successfully tested again both Qpid brokers, ActiveMQ and HornetQ).

 From an API perspective, it would be nice to hide as much of this
detail as possible from the user.  It might be sufficient to allow a
message to be tagged as "expecting a reply".  The client library could
then do what is needed to set up the reply link and insert the reply-to
field into the message.

-Ted


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Reply via email to