qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tor Rune Skoglund <...@swi.no>
Subject Re: Server-client message relaying with dynamic routes
Date Fri, 04 Apr 2014 10:01:09 GMT
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.

Best regards,
Tor Rune Skoglund, trs@swi.no

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 <gsim@redhat.com>:
>> 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: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org

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

View raw message