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 <[email protected]>: > 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: [email protected] > For additional commands, e-mail: [email protected] > >
