From users-return-10278-apmail-qpid-users-archive=qpid.apache.org@qpid.apache.org Thu Mar 27 15:33:35 2014 Return-Path: X-Original-To: apmail-qpid-users-archive@www.apache.org Delivered-To: apmail-qpid-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id CF6C1102A3 for ; Thu, 27 Mar 2014 15:33:35 +0000 (UTC) Received: (qmail 4695 invoked by uid 500); 27 Mar 2014 15:33:34 -0000 Delivered-To: apmail-qpid-users-archive@qpid.apache.org Received: (qmail 2949 invoked by uid 500); 27 Mar 2014 15:33:32 -0000 Mailing-List: contact users-help@qpid.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@qpid.apache.org Delivered-To: mailing list users@qpid.apache.org Received: (qmail 2670 invoked by uid 99); 27 Mar 2014 15:33:27 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 27 Mar 2014 15:33:27 +0000 X-ASF-Spam-Status: No, hits=3.1 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,NORMAL_HTTP_TO_IP,RCVD_IN_DNSWL_LOW,SPF_PASS,URI_HEX,WEIRD_PORT X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of chris.richardson77@gmail.com designates 209.85.219.42 as permitted sender) Received: from [209.85.219.42] (HELO mail-oa0-f42.google.com) (209.85.219.42) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 27 Mar 2014 15:33:22 +0000 Received: by mail-oa0-f42.google.com with SMTP id i4so4542945oah.1 for ; Thu, 27 Mar 2014 08:33:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=y4RTPuZ2ZGPNoYvqtpzXq20Xvp0r+lQgF3c+R9LnpMA=; b=nBjZVXRgUoNkaO7RX//yaEzaEiQnl58XhtUj/mzXQziRZQtzIYrIZWxz8150q0pJvR AIRpyeKKADumPLhNan3sos71X8i6mfDryyx06mKsDm7gdI3kCUjJfBc1zq/NgjA9dkZR p3X84Bljo9dXk1Pz6AC97bCFkX1gf7ORa4gQIxNpXY5GhD+Of2576ETFfz6Asz5/iVPX Z80dGD0AtT7aQj3/Hq10Wxp2VTuVar4XqJi0Y/TRdoZov/ewe06lSlUywe82vL+Q3bER N8rmDU2ofN07UXY0UAdf6XpKEAiNgBLiakmhUjlL7jXIb2bMJS32IM6YDqRAD0MX4ijE gsmg== MIME-Version: 1.0 X-Received: by 10.182.87.69 with SMTP id v5mr1097896obz.77.1395934381427; Thu, 27 Mar 2014 08:33:01 -0700 (PDT) Received: by 10.76.130.170 with HTTP; Thu, 27 Mar 2014 08:33:01 -0700 (PDT) Date: Thu, 27 Mar 2014 15:33:01 +0000 Message-ID: Subject: Server-client message relaying with dynamic routes From: Chris Richardson To: users@qpid.apache.org Cc: Tor Rune Skoglund Content-Type: multipart/alternative; boundary=089e013cb832ef519a04f5984cd8 X-Virus-Checked: Checked by ClamAV on apache.org --089e013cb832ef519a04f5984cd8 Content-Type: text/plain; charset=ISO-8859-1 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". Just for info, I've included some more info from my prototype showing information firstly from the working setup: Client A - 192.168.0.12 Server - 192.168.0.13 Client B - 192.168.0.14 *Server:* *~$ qpid-route link list* Host Port Transport Durable State Last Error ============================================================================= 192.168.0.12 5672 tcp N Operational 192.168.0.14 5672 tcp N Operational *~$ sudo netstat -np | grep 5672* tcp 0 0 192.168.0.13:43022 192.168.0.12:5672 ESTABLISHED 1477/qpidd tcp 0 0 192.168.0.13:5672 192.168.0.12:38576 ESTABLISHED 1477/qpidd tcp 0 0 192.168.0.13:5672 192.168.0.14:46242 ESTABLISHED 1477/qpidd tcp 0 0 192.168.0.13:34905 192.168.0.14:5672 ESTABLISHED 1477/qpidd *Client A:* *~$ qpid-route link list* Host Port Transport Durable State Last Error ============================================================================= 192.168.0.13 5672 tcp N Operational *~$ sudo netstat -np | grep 5672* tcp 0 0 192.168.0.12:5672 192.168.0.13:43022 ESTABLISHED 1467/qpidd tcp 0 0 192.168.0.12:38576 192.168.0.13:5672 ESTABLISHED 1467/qpidd *Client B:* Equivalent to Client A. Then, with some (not so) cunning use of iptables, I blocked incoming connections from the server to the clients: *~$ sudo iptables -vnL* Chain INPUT (policy ACCEPT 2157 packets, 424K bytes) pkts bytes target prot opt in out source destination 4 240 REJECT tcp -- * * 192.168.0.13 0.0.0.0/0 tcp dpt:5672 reject-with icmp-port-unreachable and the server-side links show failure, as one would expect: *~$ qpid-route link list* Host Port Transport Durable State Last Error ============================================================================= 192.168.0.12 5672 tcp N Waiting Connection refused 192.168.0.14 5672 tcp N Waiting Connection refused Any suggestions on how to solve this problem would be greatly appreciated! Thanks in advance Chris --089e013cb832ef519a04f5984cd8--