qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Richardson <chris.richardso...@gmail.com>
Subject Re: Server-client message relaying with dynamic routes
Date Fri, 28 Mar 2014 11:22:34 GMT
Static routes might be ok for a prototype, but a production system would
have many hundreds or even thousands of clients frequently being added and
removed. My assumption is that a static configuration would incur a much
higher management overhead?

2014-03-28 10:51 GMT+00:00 Gordon Sim <gsim@redhat.com>:

> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message