qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Server-client message relaying with dynamic routes
Date Fri, 28 Mar 2014 10:51:15 GMT
On 03/27/2014 03:33 PM, Chris Richardson wrote:
> Hi mailinglist,
> I'm trying to set up a broker federation topology with a server and (for
> prototyping) two clients and I need to send messages from one client to the
> other, routed via the server broker since the clients will be
> firewalled/NATed and can not communicate directly. My understanding is that
> the way to do this is with dynamic routing and I've followed the discussion
> on the following thread with some success:
> http://qpid.2158936.n2.nabble.com/Dynamic-routing-between-disconnected-exchanges-td7598100.html.
> That article describes three nodes A, B and C, and relaying from node A to
> C via B.
> So far so good - I can use "drain" on node C's test-topic/C
> exchange/routing key and "spout" to write to node A's test-topic/C
> exchange/routing key and the message is transferred via the "server" (node
> B).
> The problem I have is that this setup relies on TCP links being established
> in both directions between each node. In my client-server scenario this is
> clearly not possible and with the network restriction in place the dynamic
> routing fails. As the documentation states,  "A dynamic exchange route is
> always a pull route. It can never be a push route.". Does this mean that
> the underlying broker link must be established in the same direction as the
> route, or is there some way to override this or get the route from the
> server to utilize the existing link from the client? Solutions involving
> VPNs and tunnels are "not allowed".

What are the message flows here, i.e. what 'topics' or 'queues' will be 
involved? Do you really need dynamic federation or could a static 
configuration work?

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

View raw message