On 04/04/2014 06:01 AM, Tor Rune Skoglund wrote:
Hi Gordon,
I'm working with Chris on this, as he is off-line for the time being, I
post some additional questions:
Could you please expand on how the dispatch router could be incorporated
into our topology? Specifically, we don't see how to set up a route
between brokers via a dispatch router.
We are particularly interested in your comment "...qpidd (which supports
establishing basic AMQP 1.0 links to/from other processes)..."; Chris've
tried things like adding a link from a broker to a router with
"qpid-route link add..." but this produces errors relating to SASL on
the router side and version errors on the broker side. We haven't
pursued this further as we're not sure this is how it's supposed to
work. Is there any documentation or examples you could refer us to?
But to sum up, are there at all any "best practise" ways to solve
"dynamic routing" for spontaneously connected clients without public IPs
with today's (or tomorrow's :-) ) tool-set?
Simplified setup:
[Machine A/Broker A] [Machine C/Broker C]
[ Private IP ] [ Private IP ]
[Out and In Queues ] [Out and In Queues ]
/\ /\
|| ||
\/ \/
[ Priv IP GW ] [ Priv IP GW ]
[ NAT ] [ NAT ]
["Random" pub IP ] ["Random" pub IP ]
/\ /\
|| Unstable connections (e.g. 3G) ||
\/ \/
_________________________________________________
[ S e r v e r P u b l i c IP ]
[ Out and In Queues per Machine ]
[ S e r v e r B r o k e r B ]
[_________________________________________________]
The "IP analogy" would be that Broker A would not know the route to C it
just sends the message off to B (the "default route"), and lets B
forward the message to the right outgoing queue for C.
Let me outline some Dispatch Router scenarios based on your setup...
First scenario: There are relatively few clients on Machine A and
Machine C and your messaging patterns don't require store and forward.
In this case you can simply put one Dispatch router on the public
server. The clients on A and C can connect outbound through the NAT
firewalls to the router, subscribe to addresses, and send messages to
each other via addresses.
Second scenario: Many clients on A and C but still no need for store
and forward.
In this case, you can put a router on A, C, and on the public server.
The routers are interconnected such that A and C establish connections
outbound to the public router (if you need help with the details, let me
know). Once these connections are established, the router network
appears flat to all of the clients attached in their various places.
Now traffic between processes on A stays on A and likewise for C and
public. Traffic between A and C flows through the public router.
Note that in the above two scenarios, there are no brokers.
Third scenario: Same as (2) but store-and-forward queuing is needed.
In this case. one or more brokers can be connected to the routers for
message queuing. This is not yet supported in the router, but there is
an experimental implementation soon to be committed that integrates
queuing into routed networks.
Best regards,
Tor Rune Skoglund, [email protected]
Den 01. april 2014 13:27, skrev Chris Richardson:
Thanks very much Gordon. I have had some previous endeavours with the
dispatch router (in fact I started there before switching to the broker)
and will return to that plan of attack.
I think we will still need brokers in this topology in order to queue
messages for offline clients, otherwise the router would be the better
option. I look forward to future releases with the improved broker
integration!
/Chris
2014-03-28 15:52 GMT+00:00 Gordon Sim <[email protected]>:
On 03/28/2014 01:36 PM, Chris Richardson wrote:
Ah, now we are really opening Pandora's box! ;)
The term "client" here is actually quite a simplified term and actually
refers loosely speaking to a system managing a number of products on
that... client. Both the management system and the products should be
individually identifiable and addressable over AMQP; it should also be
possible to address them in groups. Furthermore the client system will
typically be connected over an unreliable network link and the messaging
system is expected to guarantee delivery. Given these constraints I
envisage each client system having at least one local exchange (and queues
to cope with disconnections), and most probably it/they will be topic
exchanges to support the addressing functionality. However I'm very new to
the AMQP routing and addressing concepts so I may be misguided.
Even with dynamic routing, you need to manually set it up per exchange
(what it then does is manage the set of routing keys in use for
inter-broker links, based on the interest expressed by subscriptions).
If you are using topic exchanges you might be able to simply forward all
messages for a given exchange through from A->B->C, which you can do by
simple static routes per exchange (not actually any more management
operations than making setting up dynamic routing for the same exchange).
The static routes *should* work ok with 'push' routes (though I will warn
that those are not as well used), allowing you to choose the direction of
the TCP connection independent of the direction of message flow.
Also, without wanting to confuse the picture too much, I'll just note in
passing that the recent developments around AMQP 1.0 may be of some
interest to your scenario. First off there is the 'Dispatch Router'
component. This is superficially similar to a broker, but it only forwards
messages it never accepts responsibility for them. It could be used as the
'server' broker in your setup, with the 'clients' both connecting in and
sending or receiving to/from that. You could use this in conjunction with
qpidd (which supports establishing basic AMQP 1.0 links to/from other
processes), or depending on your use case there may not be a real need for
brokers at all.
(A future release of the router will be able to establish links out to
other 1.0 capable brokers (or other types of 'thing') itself making it even
more flexible/powerful).
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
