Re: Server-client message relaying with dynamic routes

2014-04-10 Thread Gordon Sim
On 04/09/2014 07:50 PM, Tor Rune Skoglund wrote: There would have to be queueing in and out on all devices and the server (B). B can accept responsibility as "storage proxy". If there is a message from A to C, B would enqueue it for delivery to C. Then A can dequeue it as soon as B holds it. In

Re: Server-client message relaying with dynamic routes

2014-04-09 Thread Tor Rune Skoglund
Den 09. april 2014 19:41, skrev Gordon Sim: On 04/09/2014 03:28 PM, Chris Richardson wrote: I've set this scenario up on my test system (I had to add "--argument domain=BrokerB" to the "qpid-config add incoming|outgoing ..." commands...) Sorry! and it looks promising, except if I understand

Re: Server-client message relaying with dynamic routes

2014-04-09 Thread Gordon Sim
On 04/09/2014 03:28 PM, Chris Richardson wrote: I've set this scenario up on my test system (I had to add "--argument domain=BrokerB" to the "qpid-config add incoming|outgoing ..." commands...) Sorry! and it looks promising, except if I understand correctly there is no queuing on the relaying

Re: Server-client message relaying with dynamic routes

2014-04-09 Thread Chris Richardson
On 8 April 2014 15:41, Gordon Sim wrote: > > >> 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 t

Re: Server-client message relaying with dynamic routes

2014-04-08 Thread Gordon Sim
On 04/04/2014 11: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 u

Re: Server-client message relaying with dynamic routes

2014-04-04 Thread Ted Ross
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

Re: Server-client message relaying with dynamic routes

2014-04-04 Thread Fraser Adams
Hello Tor Rune Re: " We are particularly interested in your comment "...qpidd (which supports establishing basic AMQP 1.0 links to/from other processes)..." " I'm pretty sure that this relates to some features recently added by Gordon to qpidd for AMQP 1.0 the main place that they have been ref

Re: Server-client message relaying with dynamic routes

2014-04-04 Thread Tor Rune Skoglund
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. W

Re: Server-client message relaying with dynamic routes

2014-04-01 Thread 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 r

Re: Server-client message relaying with dynamic routes

2014-03-28 Thread Gordon Sim
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

Re: Server-client message relaying with dynamic routes

2014-03-28 Thread Chris Richardson
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 addressab

Re: Server-client message relaying with dynamic routes

2014-03-28 Thread Gordon Sim
On 03/28/2014 11:22 AM, Chris Richardson wrote: 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?

Re: Server-client message relaying with dynamic routes

2014-03-28 Thread Gordon Sim
On 03/28/2014 12:53 PM, Gordon Sim wrote: On 03/28/2014 11:22 AM, Chris Richardson wrote: 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 woul

Re: Server-client message relaying with dynamic routes

2014-03-28 Thread Chris Richardson
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 : > On 03

Re: Server-client message relaying with dynamic routes

2014-03-28 Thread Gordon Sim
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

Server-client message relaying with dynamic routes

2014-03-27 Thread Chris Richardson
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