You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@qpid.apache.org by gm...@apache.org on 2016/06/14 18:12:38 UTC
[3/8] qpid-site git commit: NO-JIRA - Adding Qpid Dispatch Router
0.6.0 release docs
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/ac1c1663/input/releases/qpid-dispatch-0.6.0/book/basic_usage.html.in
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-0.6.0/book/basic_usage.html.in b/input/releases/qpid-dispatch-0.6.0/book/basic_usage.html.in
new file mode 100644
index 0000000..323fdbf
--- /dev/null
+++ b/input/releases/qpid-dispatch-0.6.0/book/basic_usage.html.in
@@ -0,0 +1,166 @@
+
+
+ <div class="section" id="basic-usage-and-examples">
+<h1>2.3. Basic Usage and Examples<a class="headerlink" href="#basic-usage-and-examples" title="Permalink to this headline">.</a></h1>
+<div class="section" id="standalone-and-interior-modes">
+<h2>2.3.1. Standalone and Interior Modes<a class="headerlink" href="#standalone-and-interior-modes" title="Permalink to this headline">.</a></h2>
+<p>The router can operate stand-alone or as a node in a network of routers.
+The mode is configured in the <em>router</em> section of the configuration
+file. In stand-alone mode, the router does not attempt to collaborate
+with any other routers and only routes messages among directly connected
+endpoints.</p>
+<p>If your router is running in stand-alone mode, <em>qdstat -a</em> will look
+like the following:</p>
+<div class="highlight-python"><div class="highlight"><pre><span></span>$ qdstat -a
+Router Addresses
+ class addr phs distrib in-proc local remote cntnr in out thru to-proc from-proc
+ ===============================================================================================================
+ local $_management_internal closest 1 0 0 0 0 0 0 0 0
+ local $displayname closest 1 0 0 0 0 0 0 0 0
+ mobile $management 0 closest 1 0 0 0 1 0 0 1 0
+ local $management closest 1 0 0 0 0 0 0 0 0
+ local temp.1GThUllfR7N+BDP closest 0 1 0 0 0 0 0 0 0
+</pre></div>
+</div>
+<p>Note that there are a number of known addresses. <em>$management</em> is the address of
+the router’s embedded management agent. <em>temp.1GThUllfR7N+BDP</em> is the temporary
+reply-to address of the <em>qdstat</em> client making requests to the agent.</p>
+<p>If you change the mode to interior and restart the processs, the same
+command will yield additional addresses which are used for
+inter-router communication:</p>
+<div class="highlight-python"><div class="highlight"><pre><span></span>$ qdstat -a
+Router Addresses
+ class addr phs distrib in-proc local remote cntnr in out thru to-proc from-proc
+ =================================================================================================================
+ local $_management_internal closest 1 0 0 0 0 0 0 0 0
+ local $displayname closest 1 0 0 0 0 0 0 0 0
+ mobile $management 0 closest 1 0 0 0 1 0 0 1 0
+ local $management closest 1 0 0 0 0 0 0 0 0
+ local qdhello flood 1 0 0 0 0 0 0 0 10
+ local qdrouter flood 1 0 0 0 0 0 0 0 0
+ topo qdrouter flood 1 0 0 0 0 0 0 0 1
+ local qdrouter.ma multicast 1 0 0 0 0 0 0 0 0
+ topo qdrouter.ma multicast 1 0 0 0 0 0 0 0 0
+ local temp.wfx54+zf+YWQF3T closest 0 1 0 0 0 0 0 0 0
+</pre></div>
+</div>
+</div>
+<div class="section" id="mobile-subscribers">
+<h2>2.3.2. Mobile Subscribers<a class="headerlink" href="#mobile-subscribers" title="Permalink to this headline">.</a></h2>
+<p>The term “mobile subscriber” simply refers to the fact that a client may
+connect to the router and subscribe to an address to receive messages
+sent to that address. No matter where in the network the subscriber
+attaches, the messages will be routed to the appropriate destination.</p>
+<p>To illustrate a subscription on a stand-alone router, you can use the
+examples that are provided with Qpid Proton. Using the <em>simple_recv.py</em> example
+receiver:</p>
+<div class="highlight-python"><div class="highlight"><pre><span></span>$ python ./simple_recv.py -a 127.0.0.1/my-address
+</pre></div>
+</div>
+<p>This command creates a receiving link subscribed to the specified
+address. To verify the subscription:</p>
+<div class="highlight-python"><div class="highlight"><pre><span></span>$ qdstat -a
+Router Addresses
+ class addr phs distrib in-proc local remote cntnr in out thru to-proc from-proc
+ ===============================================================================================================
+ local $_management_internal closest 1 0 0 0 0 0 0 0 0
+ local $displayname closest 1 0 0 0 0 0 0 0 0
+ mobile $management 0 closest 1 0 0 0 2 0 0 2 0
+ local $management closest 1 0 0 0 0 0 0 0 0
+ mobile my-address 0 closest 0 1 0 0 0 0 0 0 0
+ local temp.75_d2X23x_KOT51 closest 0 1 0 0 0 0 0 0 0
+</pre></div>
+</div>
+<p>You can then, in a separate command window, run a sender to produce
+messages to that address:</p>
+<div class="highlight-python"><div class="highlight"><pre><span></span>$ python ./simple_send.py -a 127.0.0.1/my-address
+</pre></div>
+</div>
+</div>
+<div class="section" id="dynamic-reply-to">
+<h2>2.3.3. Dynamic Reply-To<a class="headerlink" href="#dynamic-reply-to" title="Permalink to this headline">.</a></h2>
+<p>Dynamic reply-to can be used to obtain a reply-to address that routes
+back to a client’s receiving link regardless of how many hops it has to
+take to get there. To illustrate this feature, see below a simple
+program (written in C++ against the qpid::messaging API) that queries
+the management agent of the attached router for a list of other known
+routers’ management addresses.</p>
+<div class="highlight-python"><div class="highlight"><pre><span></span>#include <qpid/messaging/Address.h>
+#include <qpid/messaging/Connection.h>
+#include <qpid/messaging/Message.h>
+#include <qpid/messaging/Receiver.h>
+#include <qpid/messaging/Sender.h>
+#include <qpid/messaging/Session.h>
+
+using namespace qpid::messaging;
+using namespace qpid::types;
+
+using std::stringstream;
+using std::string;
+
+int main() {
+ const char* url = "amqp:tcp:127.0.0.1:5672";
+ std::string connectionOptions = "{protocol:amqp1.0}";
+
+ Connection connection(url, connectionOptions);
+ connection.open();
+ Session session = connection.createSession();
+ Sender sender = session.createSender("mgmt");
+
+ // create reply receiver and get the reply-to address
+ Receiver receiver = session.createReceiver("#");
+ Address responseAddress = receiver.getAddress();
+
+ Message request;
+ request.setReplyTo(responseAddress);
+ request.setProperty("x-amqp-to", "amqp:/_local/$management");
+ request.setProperty("operation", "DISCOVER-MGMT-NODES");
+ request.setProperty("type", "org.amqp.management");
+ request.setProperty("name, "self");
+
+ sender.send(request);
+ Message response = receiver.fetch();
+ Variant content(response.getContentObject());
+ std::cout << "Response: " << content << std::endl << std::endl;
+
+ connection.close();
+}
+</pre></div>
+</div>
+<p>The equivalent program written in Python against the Proton Messenger
+API:</p>
+<div class="highlight-python"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">proton</span> <span class="kn">import</span> <span class="n">Messenger</span><span class="p">,</span> <span class="n">Message</span>
+
+<span class="k">def</span> <span class="nf">main</span><span class="p">():</span>
+ <span class="n">host</span> <span class="o">=</span> <span class="s2">"0.0.0.0:5672"</span>
+
+ <span class="n">messenger</span> <span class="o">=</span> <span class="n">Messenger</span><span class="p">()</span>
+ <span class="n">messenger</span><span class="o">.</span><span class="n">start</span><span class="p">()</span>
+ <span class="n">messenger</span><span class="o">.</span><span class="n">route</span><span class="p">(</span><span class="s2">"amqp:/*"</span><span class="p">,</span> <span class="s2">"amqp://</span><span class="si">%s</span><span class="s2">/$1"</span> <span class="o">%</span> <span class="n">host</span><span class="p">)</span>
+ <span class="n">reply_subscription</span> <span class="o">=</span> <span class="n">messenger</span><span class="o">.</span><span class="n">subscribe</span><span class="p">(</span><span class="s2">"amqp:/#"</span><span class="p">)</span>
+ <span class="n">reply_address</span> <span class="o">=</span> <span class="n">reply_subscription</span><span class="o">.</span><span class="n">address</span>
+
+ <span class="n">request</span> <span class="o">=</span> <span class="n">Message</span><span class="p">()</span>
+ <span class="n">response</span> <span class="o">=</span> <span class="n">Message</span><span class="p">()</span>
+
+ <span class="n">request</span><span class="o">.</span><span class="n">address</span> <span class="o">=</span> <span class="s2">"amqp:/_local/$management"</span>
+ <span class="n">request</span><span class="o">.</span><span class="n">reply_to</span> <span class="o">=</span> <span class="n">reply_address</span>
+ <span class="n">request</span><span class="o">.</span><span class="n">properties</span> <span class="o">=</span> <span class="p">{</span><span class="s1">u'operation'</span> <span class="p">:</span> <span class="s1">u'DISCOVER-MGMT-NODES'</span><span class="p">,</span>
+ <span class="s1">u'type'</span> <span class="p">:</span> <span class="s1">u'org.amqp.management'</span><span class="p">,</span>
+ <span class="s1">u'name'</span> <span class="p">:</span> <span class="s1">u'self'</span><span class="p">}</span>
+
+ <span class="n">messenger</span><span class="o">.</span><span class="n">put</span><span class="p">(</span><span class="n">request</span><span class="p">)</span>
+ <span class="n">messenger</span><span class="o">.</span><span class="n">send</span><span class="p">()</span>
+ <span class="n">messenger</span><span class="o">.</span><span class="n">recv</span><span class="p">()</span>
+ <span class="n">messenger</span><span class="o">.</span><span class="n">get</span><span class="p">(</span><span class="n">response</span><span class="p">)</span>
+
+ <span class="k">print</span> <span class="s2">"Response: </span><span class="si">%r</span><span class="s2">"</span> <span class="o">%</span> <span class="n">response</span><span class="o">.</span><span class="n">body</span>
+
+ <span class="n">messenger</span><span class="o">.</span><span class="n">stop</span><span class="p">()</span>
+
+<span class="n">main</span><span class="p">()</span>
+</pre></div>
+</div>
+</div>
+</div>
+
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/ac1c1663/input/releases/qpid-dispatch-0.6.0/book/book.html.in
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-0.6.0/book/book.html.in b/input/releases/qpid-dispatch-0.6.0/book/book.html.in
new file mode 100644
index 0000000..1f1fe66
--- /dev/null
+++ b/input/releases/qpid-dispatch-0.6.0/book/book.html.in
@@ -0,0 +1,82 @@
+
+
+ <div class="section" id="qpid-dispatch-router-book">
+<h1>Qpid Dispatch Router Book<a class="headerlink" href="#qpid-dispatch-router-book" title="Permalink to this headline">.</a></h1>
+<div class="toctree-wrapper compound">
+<ul>
+<li class="toctree-l1"><a class="reference internal" href="introduction.html">1. Introduction</a><ul>
+<li class="toctree-l2"><a class="reference internal" href="introduction.html#overview">1.1. Overview</a></li>
+<li class="toctree-l2"><a class="reference internal" href="introduction.html#benefits">1.2. Benefits</a></li>
+<li class="toctree-l2"><a class="reference internal" href="introduction.html#features">1.3. Features</a></li>
+</ul>
+</li>
+<li class="toctree-l1"><a class="reference internal" href="using.html">2. Using Qpid Dispatch</a><ul>
+<li class="toctree-l2"><a class="reference internal" href="default_config.html">2.1. Configuration</a></li>
+<li class="toctree-l2"><a class="reference internal" href="tools.html">2.2. Tools</a><ul>
+<li class="toctree-l3"><a class="reference internal" href="tools.html#qdstat">2.2.1. qdstat</a></li>
+<li class="toctree-l3"><a class="reference internal" href="tools.html#qdmanage">2.2.2. qdmanage</a></li>
+</ul>
+</li>
+<li class="toctree-l2"><a class="reference internal" href="basic_usage.html">2.3. Basic Usage and Examples</a><ul>
+<li class="toctree-l3"><a class="reference internal" href="basic_usage.html#standalone-and-interior-modes">2.3.1. Standalone and Interior Modes</a></li>
+<li class="toctree-l3"><a class="reference internal" href="basic_usage.html#mobile-subscribers">2.3.2. Mobile Subscribers</a></li>
+<li class="toctree-l3"><a class="reference internal" href="basic_usage.html#dynamic-reply-to">2.3.3. Dynamic Reply-To</a></li>
+</ul>
+</li>
+<li class="toctree-l2"><a class="reference internal" href="link_routing.html">2.4. Link Routing</a><ul>
+<li class="toctree-l3"><a class="reference internal" href="link_routing.html#configuration">2.4.1. Configuration</a></li>
+</ul>
+</li>
+<li class="toctree-l2"><a class="reference internal" href="auto_links.html">2.5. Indirect Waypoints and Auto-Links</a><ul>
+<li class="toctree-l3"><a class="reference internal" href="auto_links.html#queue-waypoint-example">2.5.1. Queue Waypoint Example</a></li>
+<li class="toctree-l3"><a class="reference internal" href="auto_links.html#sharded-queue-example">2.5.2. Sharded Queue Example</a></li>
+<li class="toctree-l3"><a class="reference internal" href="auto_links.html#dynamically-adding-shards">2.5.3. Dynamically Adding Shards</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li class="toctree-l1"><a class="reference internal" href="technical_details.html">3. Technical Details and Specifications</a><ul>
+<li class="toctree-l2"><a class="reference internal" href="client_compatibility.html">3.1. Client Compatibility</a></li>
+<li class="toctree-l2"><a class="reference internal" href="addressing.html">3.2. Addressing</a><ul>
+<li class="toctree-l3"><a class="reference internal" href="addressing.html#routing-patterns">3.2.1. Routing patterns</a></li>
+<li class="toctree-l3"><a class="reference internal" href="addressing.html#routing-mechanisms">3.2.2. Routing mechanisms</a></li>
+</ul>
+</li>
+<li class="toctree-l2"><a class="reference internal" href="amqp-mapping.html">3.3. AMQP Mapping</a><ul>
+<li class="toctree-l3"><a class="reference internal" href="amqp-mapping.html#message-annotations">3.3.1. Message Annotations</a></li>
+<li class="toctree-l3"><a class="reference internal" href="amqp-mapping.html#source-target-capabilities">3.3.2. Source/Target Capabilities</a></li>
+<li class="toctree-l3"><a class="reference internal" href="amqp-mapping.html#dynamic-node-properties">3.3.3. Dynamic-Node-Properties</a></li>
+<li class="toctree-l3"><a class="reference internal" href="amqp-mapping.html#addresses-and-address-formats">3.3.4. Addresses and Address Formats</a></li>
+<li class="toctree-l3"><a class="reference internal" href="amqp-mapping.html#implementation-of-the-amqp-management-specification">3.3.5. Implementation of the AMQP Management Specification</a></li>
+</ul>
+</li>
+<li class="toctree-l2"><a class="reference internal" href="schema.html">3.4. Management Schema</a><ul>
+<li class="toctree-l3"><a class="reference internal" href="schema.html#configuration-entities">3.4.1. Configuration Entities</a></li>
+<li class="toctree-l3"><a class="reference internal" href="schema.html#operational-entities">3.4.2. Operational Entities</a></li>
+<li class="toctree-l3"><a class="reference internal" href="schema.html#management-operations">3.4.3. Management Operations</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li class="toctree-l1"><a class="reference internal" href="console.html">4. Console</a><ul>
+<li class="toctree-l2"><a class="reference internal" href="console_overview.html">4.1. Console overview</a></li>
+<li class="toctree-l2"><a class="reference internal" href="console_installation.html">4.2. Console installation</a><ul>
+<li class="toctree-l3"><a class="reference internal" href="console_installation.html#prerequisites">4.2.1. Prerequisites</a></li>
+<li class="toctree-l3"><a class="reference internal" href="console_installation.html#the-console-files">4.2.2. The console files</a></li>
+</ul>
+</li>
+<li class="toctree-l2"><a class="reference internal" href="console_operation.html">4.3. Console operation</a><ul>
+<li class="toctree-l3"><a class="reference internal" href="console_operation.html#logging-in-to-a-router-network">4.3.1. Logging in to a router network</a></li>
+<li class="toctree-l3"><a class="reference internal" href="console_operation.html#overview-page">4.3.2. Overview page</a></li>
+<li class="toctree-l3"><a class="reference internal" href="console_operation.html#topology-page">4.3.3. Topology page</a></li>
+<li class="toctree-l3"><a class="reference internal" href="console_operation.html#list-page">4.3.4. List page</a></li>
+<li class="toctree-l3"><a class="reference internal" href="console_operation.html#charts-page">4.3.5. Charts page</a></li>
+<li class="toctree-l3"><a class="reference internal" href="console_operation.html#schema-page">4.3.6. Schema page</a></li>
+</ul>
+</li>
+</ul>
+</li>
+</ul>
+</div>
+</div>
+
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/ac1c1663/input/releases/qpid-dispatch-0.6.0/book/client_compatibility.html.in
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-0.6.0/book/client_compatibility.html.in b/input/releases/qpid-dispatch-0.6.0/book/client_compatibility.html.in
new file mode 100644
index 0000000..95ba509
--- /dev/null
+++ b/input/releases/qpid-dispatch-0.6.0/book/client_compatibility.html.in
@@ -0,0 +1,33 @@
+
+
+ <div class="section" id="client-compatibility">
+<h1>3.1. Client Compatibility<a class="headerlink" href="#client-compatibility" title="Permalink to this headline">.</a></h1>
+<p>Dispatch Router should, in theory, work with any client that is
+compatible with AMQP 1.0. The following clients have been tested:</p>
+<table border="1" class="docutils">
+<colgroup>
+<col width="20%" />
+<col width="80%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head"><em>Client</em></th>
+<th class="head"><em>Notes</em></th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>qpid::messaging</td>
+<td>The Qpid messaging clients work with Dispatch Router as long as
+they are configured to use the 1.0 version of the protocol. To
+enable AMQP 1.0 in the C++ client, use the {protocol:amqp1.0}
+connection option.</td>
+</tr>
+<tr class="row-odd"><td>Proton Reactor</td>
+<td>The Proton Reactor API is compatible with Dispatch Router.</td>
+</tr>
+<tr class="row-even"><td>Proton Messenger</td>
+<td>Messenger works with Dispatch Router.</td>
+</tr>
+</tbody>
+</table>
+</div>
+
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/ac1c1663/input/releases/qpid-dispatch-0.6.0/book/console.html.in
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-0.6.0/book/console.html.in b/input/releases/qpid-dispatch-0.6.0/book/console.html.in
new file mode 100644
index 0000000..58d31d9
--- /dev/null
+++ b/input/releases/qpid-dispatch-0.6.0/book/console.html.in
@@ -0,0 +1,25 @@
+
+
+ <div class="section" id="console">
+<h1>4. Console<a class="headerlink" href="#console" title="Permalink to this headline">.</a></h1>
+<div class="toctree-wrapper compound">
+<ul>
+<li class="toctree-l1"><a class="reference internal" href="console_overview.html">4.1. Console overview</a></li>
+<li class="toctree-l1"><a class="reference internal" href="console_installation.html">4.2. Console installation</a><ul>
+<li class="toctree-l2"><a class="reference internal" href="console_installation.html#prerequisites">4.2.1. Prerequisites</a></li>
+<li class="toctree-l2"><a class="reference internal" href="console_installation.html#the-console-files">4.2.2. The console files</a></li>
+</ul>
+</li>
+<li class="toctree-l1"><a class="reference internal" href="console_operation.html">4.3. Console operation</a><ul>
+<li class="toctree-l2"><a class="reference internal" href="console_operation.html#logging-in-to-a-router-network">4.3.1. Logging in to a router network</a></li>
+<li class="toctree-l2"><a class="reference internal" href="console_operation.html#overview-page">4.3.2. Overview page</a></li>
+<li class="toctree-l2"><a class="reference internal" href="console_operation.html#topology-page">4.3.3. Topology page</a></li>
+<li class="toctree-l2"><a class="reference internal" href="console_operation.html#list-page">4.3.4. List page</a></li>
+<li class="toctree-l2"><a class="reference internal" href="console_operation.html#charts-page">4.3.5. Charts page</a></li>
+<li class="toctree-l2"><a class="reference internal" href="console_operation.html#schema-page">4.3.6. Schema page</a></li>
+</ul>
+</li>
+</ul>
+</div>
+</div>
+
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/ac1c1663/input/releases/qpid-dispatch-0.6.0/book/console_installation.html.in
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-0.6.0/book/console_installation.html.in b/input/releases/qpid-dispatch-0.6.0/book/console_installation.html.in
new file mode 100644
index 0000000..001b9a3
--- /dev/null
+++ b/input/releases/qpid-dispatch-0.6.0/book/console_installation.html.in
@@ -0,0 +1,40 @@
+
+
+ <div class="section" id="console-installation">
+<h1>4.2. Console installation<a class="headerlink" href="#console-installation" title="Permalink to this headline">.</a></h1>
+<div class="section" id="prerequisites">
+<h2>4.2.1. Prerequisites<a class="headerlink" href="#prerequisites" title="Permalink to this headline">.</a></h2>
+<p>The following need to be installed before running a console:</p>
+<ul class="simple">
+<li>One or more dispatch routers. See the documentation for the dispatch router for help in starting a router network.</li>
+<li>A websockets to tcp proxy.</li>
+<li>A web server. This can be any server capable of serving static html/js/css/image files.</li>
+</ul>
+<p>To install a websockets to tcp proxy:</p>
+<div class="highlight-python"><div class="highlight"><pre><span></span>sudo dnf install python-websockify
+websockify localhost:5673 localhost:5672
+</pre></div>
+</div>
+<p>This will start the proxy listening to ws traffic on port 5673 and translating it to tcp on port 5672.
+One of the routers in the network needs to have a listener configured on port 5672. That listener’s role should be ‘normal’. For example:</p>
+<div class="highlight-python"><div class="highlight"><pre><span></span>listener {
+ host: 0.0.0.0
+ role: normal
+ port: amqp
+ saslMechanisms: ANONYMOUS
+}
+</pre></div>
+</div>
+</div>
+<div class="section" id="the-console-files">
+<h2>4.2.2. The console files<a class="headerlink" href="#the-console-files" title="Permalink to this headline">.</a></h2>
+<dl class="docutils">
+<dt>The files for the console are located under the console/stand-alone directory in the source tree.::</dt>
+<dd>index.html
+plugin/</dd>
+<dt>Copy these files to a directory under the the html or webapps directory of your web server. For example, for apache tomcat the files should be under webapps/dispatch. Then the console is available as::</dt>
+<dd><a class="reference external" href="http://localhost:8080/dispatch">http://localhost:8080/dispatch</a></dd>
+</dl>
+</div>
+</div>
+
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/ac1c1663/input/releases/qpid-dispatch-0.6.0/book/console_operation.html.in
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-0.6.0/book/console_operation.html.in b/input/releases/qpid-dispatch-0.6.0/book/console_operation.html.in
new file mode 100644
index 0000000..2058f78
--- /dev/null
+++ b/input/releases/qpid-dispatch-0.6.0/book/console_operation.html.in
@@ -0,0 +1,37 @@
+
+
+ <div class="section" id="console-operation">
+<h1>4.3. Console operation<a class="headerlink" href="#console-operation" title="Permalink to this headline">.</a></h1>
+<div class="section" id="logging-in-to-a-router-network">
+<h2>4.3.1. Logging in to a router network<a class="headerlink" href="#logging-in-to-a-router-network" title="Permalink to this headline">.</a></h2>
+<img alt="../_images/console_login.png" src="../_images/console_login.png" />
+<p>Enter the address of the websockets to tcp proxy that is connected to a router in the network.</p>
+<p>The Autostart checkbox, when checked, will automatically log in with the previous host:port the next time you start the console.</p>
+</div>
+<div class="section" id="overview-page">
+<h2>4.3.2. Overview page<a class="headerlink" href="#overview-page" title="Permalink to this headline">.</a></h2>
+<img alt="../_images/console_overview.png" src="../_images/console_overview.png" />
+<p>On the overview page, aggregate information about routers, addresses, and connections is displayed.</p>
+</div>
+<div class="section" id="topology-page">
+<h2>4.3.3. Topology page<a class="headerlink" href="#topology-page" title="Permalink to this headline">.</a></h2>
+<img alt="../_images/console_topology.png" src="../_images/console_topology.png" />
+<p>This page displays the router network in a graphical form showing how the routers are connected and information about the individual routers and links.</p>
+</div>
+<div class="section" id="list-page">
+<h2>4.3.4. List page<a class="headerlink" href="#list-page" title="Permalink to this headline">.</a></h2>
+<img alt="../_images/console_entity.png" src="../_images/console_entity.png" />
+<p>Displays detailed information about entities such as routers, links, addresses, memory.</p>
+</div>
+<div class="section" id="charts-page">
+<h2>4.3.5. Charts page<a class="headerlink" href="#charts-page" title="Permalink to this headline">.</a></h2>
+<img alt="../_images/console_charts.png" src="../_images/console_charts.png" />
+<p>This page displays graphs of numeric values that are on the list page.</p>
+</div>
+<div class="section" id="schema-page">
+<h2>4.3.6. Schema page<a class="headerlink" href="#schema-page" title="Permalink to this headline">.</a></h2>
+<img alt="../_images/console_schema.png" src="../_images/console_schema.png" />
+<p>This page displays the json schema that is used to manage the router network.</p>
+</div>
+</div>
+
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/ac1c1663/input/releases/qpid-dispatch-0.6.0/book/console_overview.html.in
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-0.6.0/book/console_overview.html.in b/input/releases/qpid-dispatch-0.6.0/book/console_overview.html.in
new file mode 100644
index 0000000..e7b95f0
--- /dev/null
+++ b/input/releases/qpid-dispatch-0.6.0/book/console_overview.html.in
@@ -0,0 +1,9 @@
+
+
+ <div class="section" id="console-overview">
+<h1>4.1. Console overview<a class="headerlink" href="#console-overview" title="Permalink to this headline">.</a></h1>
+<p>The console is an HTML based web site that displays information about a qpid dispatch router network.</p>
+<p>The console requires an HTML web server that can serve static html, javascript, style sheets, and images.</p>
+<p>The console only provides limited information about the clients that are attached to the router network and is therfore more appropriate for administrators needing to know the layout and health of the router network.</p>
+</div>
+
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/ac1c1663/input/releases/qpid-dispatch-0.6.0/book/default_config.html.in
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-0.6.0/book/default_config.html.in b/input/releases/qpid-dispatch-0.6.0/book/default_config.html.in
new file mode 100644
index 0000000..edbf413
--- /dev/null
+++ b/input/releases/qpid-dispatch-0.6.0/book/default_config.html.in
@@ -0,0 +1,16 @@
+
+
+ <div class="section" id="configuration">
+<h1>2.1. Configuration<a class="headerlink" href="#configuration" title="Permalink to this headline">.</a></h1>
+<p>The default configuration file is installed in
+<cite>install-prefix</cite>/etc/qpid/qdrouterd.conf. This configuration file will
+cause the router to run in standalone mode, listening on the standard
+AMQP port (5672). Dispatch Router looks for the configuration file in
+the installed location by default. If you wish to use a different path,
+the “-c” command line option will instruct Dispatch Router as to which
+configuration to load.</p>
+<p>To run the router, invoke the executable: qdrouterd [-c my-config-file]</p>
+<p>For more details of the configuration file see the <cite>qdrouterd.conf(5)</cite>
+man page.</p>
+</div>
+
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/ac1c1663/input/releases/qpid-dispatch-0.6.0/book/introduction.html.in
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-0.6.0/book/introduction.html.in b/input/releases/qpid-dispatch-0.6.0/book/introduction.html.in
new file mode 100644
index 0000000..45dbc25
--- /dev/null
+++ b/input/releases/qpid-dispatch-0.6.0/book/introduction.html.in
@@ -0,0 +1,98 @@
+
+
+ <div class="section" id="introduction">
+<h1>1. Introduction<a class="headerlink" href="#introduction" title="Permalink to this headline">.</a></h1>
+<div class="section" id="overview">
+<h2>1.1. Overview<a class="headerlink" href="#overview" title="Permalink to this headline">.</a></h2>
+<p>The Dispatch router is an AMQP message message router that provides
+advanced interconnect capabilities. It allows flexible routing of
+messages between any AMQP-enabled endpoints, whether they be clients,
+servers, brokers or any other entity that can send or receive standard
+AMQP messages.</p>
+<p>A messaging client can make a single AMQP connection into a messaging
+bus built of Dispatch routers and, over that connection, exchange
+messages with one or more message brokers, and at the same time exchange
+messages directly with other endpoints without involving a broker at
+all.</p>
+<p>The router is an intermediary for messages but it is <em>not</em> a broker. It
+does not <em>take responsibility for</em> messages. It will, however, propagate
+settlement and disposition across a network such that delivery
+guarantees are met. In other words: the router network will deliver the
+message, possibly via several intermediate routers, <em>and</em> it will route
+the acknowledgement of that message by the ultimate receiver back across
+the same path. This means that <em>responsibility</em> for the message is
+transfered from the original sender to the ultimate receiver <em>as if they
+were directly connected</em>. However this is done via a flexible network
+that allows highly configurable routing of the message transparent to
+both sender and receiver.</p>
+<p>There are some patterns where this enables “brokerless messaging”
+approaches that are preferable to brokered approaches. In other cases a
+broker is essential (in particular where you need the separation of
+responsibility and/or the buffering provided by store-and-forward) but a
+dispatch network can still be useful to tie brokers and clients together
+into patterns that are difficult with a single broker.</p>
+<p>For a “brokerless” example, consider the common brokered implementation
+of the request-response pattern, a client puts a request on a queue and
+then waits for a reply on another queue. In this case the broker can be
+a hindrance - the client may want to know immediatly if there is nobody
+to serve the request, but typically it can only wait for a timeout to
+discover this. With a dispatch network, the client can be informed
+immediately if its message cannot be delivered because nobody is
+listening. When the client receives acknowledgement of the request it
+knows not just that it is sitting on a queue, but that it has actually
+been received by the server.</p>
+<p>For an exampe of using dispatch to enhance the use of brokers, consider
+using an array of brokers to implement a scalable distributed work
+queue. A dispatch network can make this appear as a single queue, with
+senders publishing to a single address and receivers subscribing to a
+single address. The dispatch network can distribute work to any broker
+in the array and collect work from any broker for any receiver. Brokers
+can be shut down or added without affecting clients. This elegantly
+solves the common difficulty of “stuck messages” when implementing this
+pattern with brokers alone. If a receiver is connected to a broker that
+has no messages, but there are messages on another broker, you have to
+somehow transfer them or leave them “stuck”. With a dispatch network,
+<em>all</em> the receivers are connected to <em>all</em> the brokers. If there is a
+message anywhere it can be delivered to any receiver.</p>
+<p>The router is meant to be deployed in topologies of multiple routers,
+preferably with redundant paths. It uses link-state routing protocols
+and algorithms (similar to OSPF or IS-IS from the networking world) to
+calculate the best path from every point to every other point and to
+recover quickly from failures. It does not need to use clustering for
+high availability; rather, it relies on redundant paths to provide
+continued connectivity in the face of system or network failure. Because
+it never takes responsibility for messages it is effectively stateless.
+Messages not delivered to their final destination will not be
+acknowledged to the sender and therefore the sender can re-send such
+messages if it is disconnected from the network.</p>
+</div>
+<div class="section" id="benefits">
+<h2>1.2. Benefits<a class="headerlink" href="#benefits" title="Permalink to this headline">.</a></h2>
+<p>Simplifies connectivity</p>
+<ul class="simple">
+<li>An endpoint can do all of its messaging through a single transport connection</li>
+<li>Avoid opening holes in firewalls for incoming connections</li>
+</ul>
+<p>Provides messaging connectivity where there is no TCP/IP connectivity</p>
+<ul class="simple">
+<li>A server or broker can be in a private IP network (behind a NAT firewall) and be accessible by messaging endpoints in other networks (learn more).</li>
+</ul>
+<p>Simplifies reliability</p>
+<ul class="simple">
+<li>Reliability and availability are provided using redundant topology, not server clustering</li>
+<li>Reliable end-to-end messaging without persistent stores</li>
+<li>Use a message broker only when you need store-and-forward semantics</li>
+</ul>
+</div>
+<div class="section" id="features">
+<h2>1.3. Features<a class="headerlink" href="#features" title="Permalink to this headline">.</a></h2>
+<ul class="simple">
+<li>Can be deployed stand-alone or in a network of routers
+- Supports arbitrary network topology - no restrictions on redundancy
+- Automatic route computation - adjusts quickly to changes in topology</li>
+<li>Provides remote access to brokers or other AMQP servers</li>
+<li>Security</li>
+</ul>
+</div>
+</div>
+
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/ac1c1663/input/releases/qpid-dispatch-0.6.0/book/link_routing.html.in
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-0.6.0/book/link_routing.html.in b/input/releases/qpid-dispatch-0.6.0/book/link_routing.html.in
new file mode 100644
index 0000000..a770baa
--- /dev/null
+++ b/input/releases/qpid-dispatch-0.6.0/book/link_routing.html.in
@@ -0,0 +1,131 @@
+
+
+ <div class="section" id="link-routing">
+<h1>2.4. Link Routing<a class="headerlink" href="#link-routing" title="Permalink to this headline">.</a></h1>
+<p>This feature was introduced in Qpid Dispatch 0.4.
+This feature was significantly updated in Qpid Dispatch 0.6.</p>
+<p>Link-routing is an alternative strategy for routing messages across a
+network of routers. With the existing message-routing strategy, each
+router makes a routing decision on a per-message basis when the
+message is delivered. Link-routing is different because it makes
+routing decisions when link-attach frames arrive. A link is
+effectively chained across the network of routers from the
+establishing node to the destination node. Once the link is
+established, the transfer of message deliveries, flow frames, and
+dispositions is performed across the routed link.</p>
+<p>The main benefit to link-routing is that endpoints can use the full link
+protocol to interact with other endpoints in far-flung parts of the
+network. For example, a client can establish a receiver across the
+network to a queue on a remote broker and use link credit to control
+the flow of messages from the broker. Similarly, a receiver can
+establish a link to a topic on a remote broker using a server-side
+filter.</p>
+<p>Why would one want to do this? One reason is to provide client
+isolation. A network like the following can be deployed:</p>
+<div class="highlight-python"><div class="highlight"><pre><span></span> Public Network
+ +-----------------+
+ | +-----+ |
+ | B1 | Rp | |
+ | +/--\-+ |
+ | / \ |
+ | / \ |
+ +----/--------\---+
+ / \
+ / \
+ / \
+ Private Net A / \ Private Net B
++--------------/--+ +---\-------------+
+| +---/-+ | | +--\--+ |
+| B2 | Ra | | | | Rb | C1 |
+| +-----+ | | +-----+ |
+| | | |
+| | | |
++-----------------+ +-----------------+
+</pre></div>
+</div>
+<p>The clients in Private Net B can be constrained (by firewall policy)
+to only connect to the Router in their own network. Using
+link-routing, these clients can access queues, topics, and other AMQP
+services that are in the Public Network or even in Private Net A.</p>
+<p>For example, The router Ra can be configured to expose queues in
+broker B2 to the network. Client C1 can then establish a connection
+to Rb, the local router, open a subscribing link to “b2.event-queue”,
+and receive messages stored on that queue in broker B2.</p>
+<p>C1 is unable to create a TCP/IP connection to B1 because of its
+isolation (and because B2 is itself in a private network). However,
+with link routing, C1 can interact with B2 using the AMQP link
+protocol.</p>
+<p>Note that in this case, neither C1 nor B2 have been modified in any
+way and neither need be aware of the fact that there is a
+message-router network between them.</p>
+<div class="section" id="configuration">
+<h2>2.4.1. Configuration<a class="headerlink" href="#configuration" title="Permalink to this headline">.</a></h2>
+<p>Starting with the configured topology shown above, how is link-routing
+configured to support the example described above?</p>
+<p>First, router Ra needs to be told how to make a connection to the
+broker B2:</p>
+<div class="highlight-python"><div class="highlight"><pre><span></span>connector {
+ name: broker
+ role: route-container
+ host: <B2-url>
+ port: <B2-port>
+ sasl-mechanisms: ANONYMOUS
+}
+</pre></div>
+</div>
+<p>This <em>route-container</em> connector tells the router how to connect to an
+external AMQP container when it is needed. The name “broker” will be
+used later to refer to this connection.</p>
+<p>Now, the router must be configured to route certain addresses to B2:</p>
+<div class="highlight-python"><div class="highlight"><pre><span></span>linkRoute {
+ prefix: b2
+ dir: in
+ connection: broker
+}
+
+linkRoute {
+ prefix: b2
+ dir: out
+ connection: broker
+}
+</pre></div>
+</div>
+<p>The linkRoute tells router Ra that any sender or receiver that
+is attached with a target or source (respectively) whos address begins
+with “b2”, should be routed to the broker B2 (via the route-container
+connector).</p>
+<p>Note that receiving and sending links are configured and routed
+separately. This allows configuration of link routes for listeners
+only or senders only. A direction of “in” matches client senders
+(i.e. links that carry messages inbound to the router network).
+Direction “out” matches client receivers.</p>
+<dl class="docutils">
+<dt>Examples of addresses that “begin with ‘b2’” include:</dt>
+<dd><ul class="first last simple">
+<li>b2</li>
+<li>b2.queues</li>
+<li>b2.queues.app1</li>
+</ul>
+</dd>
+</dl>
+<p>When the route-container connector is configured, router Ra establishes a
+connection to the broker. Once the connection is open, Ra tells the
+other routers (Rp and Rb) that it is a valid destination for
+link-routes to the “b2” prefix. This means that sender or receiver
+links attached to Rb or Rp will be routed via the shortest path to Ra
+where they are then routed outbound to the broker B2.</p>
+<p>On Rp and Rb, it is advisable to add the identical configuration. It
+is permissible for a linkRoute configuration to reference a connection
+that does not exist.</p>
+<p>This configuration tells the routers that link-routing is intended to
+be available for targets and sources starting with “b2”. This is
+important because it is possible that B2 might be unavailable or shut
+off. If B2 is unreachable, Ra will not advertize itself as a
+destination for “b2” and the other routers might never know that
+“b2” was intended for link-routing.</p>
+<p>The above configuration allows Rb and Rp to reject attaches that
+should be routed to B2 with an error message that indicates that there
+is no route available to the destination.</p>
+</div>
+</div>
+
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org