You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@qpid.apache.org by jr...@apache.org on 2017/11/28 19:37:45 UTC
[01/13] qpid-site git commit: QPID-8015: Prepare the dispatch release
scripts for the new user guide
Repository: qpid-site
Updated Branches:
refs/heads/asf-site 325942f6e -> 030c23a69
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/python/generate.py
----------------------------------------------------------------------
diff --git a/python/generate.py b/python/generate.py
index d7f2076..00631eb 100644
--- a/python/generate.py
+++ b/python/generate.py
@@ -53,6 +53,8 @@ def setup_release_script():
assert release_dir != ""
assert checkout_dir is None or checkout_dir != ""
+ call_and_print_on_error("asciidoc --version")
+ call_and_print_on_error("asciidoctor --version")
call_and_print_on_error("cmake --version")
call_and_print_on_error("dot -V")
call_and_print_on_error("doxygen --version")
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/scripts/gen-dispatch-release-docs
----------------------------------------------------------------------
diff --git a/scripts/gen-dispatch-release-docs b/scripts/gen-dispatch-release-docs
index 0f3ec34..14bd6ba 100755
--- a/scripts/gen-dispatch-release-docs
+++ b/scripts/gen-dispatch-release-docs
@@ -7,9 +7,9 @@
# to you under the Apache License, Version 2.0 (the
# "License"); you may not use this file except in compliance
# with the License. You may obtain a copy of the License at
-#
+#
# http://www.apache.org/licenses/LICENSE-2.0
-#
+#
# Unless required by applicable law or agreed to in writing,
# software distributed under the License is distributed on an
# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
@@ -23,34 +23,12 @@ from generate import *
def gen_dispatch_docs(release, source_dir, output_dir):
build_dir = make_temp_dir()
-
+
with working_dir(build_dir):
call("cmake {}", source_dir)
call("make")
call("make doc")
- book_build_dir = join(build_dir, "doc", "book")
-
- for f in list_dir(book_build_dir, "*.html.in"):
- input_file = join(book_build_dir, f)
- output_file = join(output_dir, "book", f)
-
- copy(input_file, output_file)
-
- for f in list_dir(book_build_dir, "*.png"):
- input_file = join(book_build_dir, f)
- output_file = join(output_dir, "book", f)
-
- copy(input_file, output_file)
-
- # book_image_dir = join(build_dir, "doc", "_images")
-
- # for f in list_dir(book_image_dir, "*"):
- # input_file = join(book_image_dir, f)
- # output_file = join(output_dir, "_images", f)
-
- # copy(input_file, output_file)
-
man_build_dir = join(build_dir, "doc", "man")
for f in list_dir(man_build_dir, "*.html.in"):
@@ -59,6 +37,17 @@ def gen_dispatch_docs(release, source_dir, output_dir):
copy(input_file, output_file)
+ book_input_file = join(source_dir, "doc", "new-book", "book.adoc")
+ book_output_dir = join(output_dir, "user-guide")
+ book_output_file = join(book_output_dir, "index.html.in")
+
+ make_dir(book_output_dir)
+
+ call("asciidoctor --no-header-footer -o {} {}", book_output_file, book_input_file)
+
+ # Asciidoctor strips the title - add it back
+ prepend(book_output_file, "<h1>Using Qpid Dispatch</h1>\n")
+
## Now do stuff ##
release, issues_release, source_release, release_dir, checkout_dir = setup_release_script()
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/scripts/gen-dispatch-release-page
----------------------------------------------------------------------
diff --git a/scripts/gen-dispatch-release-page b/scripts/gen-dispatch-release-page
index 6d660ab..8089134 100755
--- a/scripts/gen-dispatch-release-page
+++ b/scripts/gen-dispatch-release-page
@@ -30,8 +30,9 @@ documentation = \
"""
<div class="two-column" markdown="1">
- - [Installing Qpid Dispatch](https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;a=blob_plain;f=README;hb={source_release})
- - [Dispatch Router User Guide](book/book.html)
+ - [Using Qpid Dispatch](user-guide/index.html)
+ - [Installing Qpid Dispatch from
+ source](https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;a=blob_plain;f=README;hb={source_release})
- [qdrouterd](man/qdrouterd.html) - Router daemon
- [qdrouterd.conf](man/qdrouterd.conf.html) - Daemon configuration
- [qdstat](man/qdstat.html) - Get router statistics
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org
[05/13] qpid-site git commit: QPID-8015: Prepare the dispatch release
scripts for the new user guide
Posted by jr...@apache.org.
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/book/book.html.in
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/book/book.html.in b/input/releases/qpid-dispatch-master/book/book.html.in
deleted file mode 100644
index fc42271..0000000
--- a/input/releases/qpid-dispatch-master/book/book.html.in
+++ /dev/null
@@ -1,4876 +0,0 @@
-<div class="sect1">
-<h2 id="introduction">1. Introduction</h2>
-<div class="sectionbody">
-<div class="sect2">
-<h3 id="overview">1.1. Overview</h3>
-<div class="paragraph"><p>The Dispatch router is an AMQP 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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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>
-<div class="sect2">
-<h3 id="benefits">1.2. Benefits</h3>
-<div class="paragraph"><p>Simplifies connectivity</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-An endpoint can do all of its messaging through a single transport
-connection
-</p>
-</li>
-<li>
-<p>
-Avoid opening holes in firewalls for incoming connections
-</p>
-</li>
-</ul></div>
-<div class="paragraph"><p>Provides messaging connectivity where there is no TCP/IP connectivity</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-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).
-</p>
-</li>
-</ul></div>
-<div class="paragraph"><p>Simplifies reliability</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-Reliability and availability are provided using redundant topology,
-not server clustering
-</p>
-</li>
-<li>
-<p>
-Reliable end-to-end messaging without persistent stores
-</p>
-</li>
-<li>
-<p>
-Use a message broker only when you need store-and-forward semantics
-</p>
-</li>
-</ul></div>
-</div>
-<div class="sect2">
-<h3 id="features">1.3. Features</h3>
-<div class="ulist"><ul>
-<li>
-<p>
-Can be deployed stand-alone or in a network of routers
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-Supports arbitrary network topology - no restrictions on redundancy
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-Automatic route computation - adjusts quickly to changes in topology
-</p>
-</li>
-</ul></div>
-</li>
-</ul></div>
-</li>
-<li>
-<p>
-Provides remote access to brokers or other AMQP servers
-</p>
-</li>
-<li>
-<p>
-Security
-</p>
-</li>
-</ul></div>
-</div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_theory_of_operation">2. Theory of Operation</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>This section introduces some key concepts about the router.</p></div>
-<div class="sect2">
-<h3 id="_overview">2.1. Overview</h3>
-<div class="paragraph"><p>The router is an <em>application layer</em> program running as a normal
-user program or as a daemon.</p></div>
-<div class="paragraph"><p>The router accepts AMQP connections from clients and creates AMQP
-connections to brokers or AMQP-based services. The router classifies
-incoming AMQP messages and routes the
-messages between message producers and message consumers.</p></div>
-<div class="paragraph"><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 message source to every message
-destination and to recover quickly from failures. The router relies on
-redundant network paths to provide continued connectivity in the face
-of system or network failure.</p></div>
-<div class="paragraph"><p>A messaging client can make a single AMQP connection into a messaging
-bus built with routers and, over that connection, exchange messages
-with one or more message brokers connected to any router in the
-network. At the same time the client can exchange messages directly
-with other endpoints without involving a broker at all.</p></div>
-</div>
-<div class="sect2">
-<h3 id="_connections">2.2. Connections</h3>
-<div class="paragraph"><p>The router connects clients, servers, AMQP services, and other
-routers through network connections.</p></div>
-<div class="sect3">
-<h4 id="_listener">2.2.1. Listener</h4>
-<div class="paragraph"><p>The router provides <em>listeners</em> that accept client connections.
-A client connecting to a router listener uses the
-same methods that it would use to connect to a broker. From the
-client’s perspective the router connection and link establishment are
-identical to broker connection and link establishment.</p></div>
-<div class="paragraph"><p>Several types of listeners are defined by their role.</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="20%" />
-<col width="80%" />
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">Role</p></td>
-<td align="left" valign="top"><p class="table">Description</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">normal</p></td>
-<td align="left" valign="top"><p class="table">The connection is used for AMQP clients using normal message delivery.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">inter-router</p></td>
-<td align="left" valign="top"><p class="table">The connection is assumed to be to another router in the network. Inter-router discovery and routing protocols can only be used over inter-router connections.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">route-container</p></td>
-<td align="left" valign="top"><p class="table">The connection is a broker or other resource that holds known addresses. The router will use this connection to create links as necessary. The addresses are available for routing only after the remote resource has created a connection.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-<div class="sect3">
-<h4 id="_connector">2.2.2. Connector</h4>
-<div class="paragraph"><p>The router can also be configured to create outbound connections to
-messaging brokers or other AMQP entities using <em>connectors</em>. A
-connector is defined with the network address of the broker and the
-name or names of the resources that are available in that broker. When
-a router connects to a broker through a connector it uses the same
-methods a normal messaging client would use when connecting to the
-broker.</p></div>
-<div class="paragraph"><p>Several types of connectors are defined by their role.</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="20%" />
-<col width="80%" />
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">Role</p></td>
-<td align="left" valign="top"><p class="table">Description</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">normal</p></td>
-<td align="left" valign="top"><p class="table">The connection is used for AMQP clients using normal message delivery. On this connector the router will initiate the connection but it will never create any links. Links are to be created by the peer that accepts the connection.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">inter-router</p></td>
-<td align="left" valign="top"><p class="table">The connection is assumed to be to another router in the network. Inter-router discovery and routing protocols can only be used over inter-router connections.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">route-container</p></td>
-<td align="left" valign="top"><p class="table">The connection is to a broker or other resource that holds known addresses. The router will use this connection to create links as necessary. The addresses are available for routing only after the router has created a connection to the remote resource.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-</div>
-<div class="sect2">
-<h3 id="_addresses">2.3. Addresses</h3>
-<div class="paragraph"><p>AMQP addresses are used to control the flow of messages across a
-network of routers. Addresses are used in a number of different places
-in the AMQP 1.0 protocol. They can be used in a specific message in
-the <em>to</em> and <em>reply-to</em> fields of a message’s properties. They are also
-used during the creation of links in the <em>address</em> field of a <em>source</em> or
-a <em>target</em>.</p></div>
-<div class="admonitionblock">
-<table><tr>
-<td class="icon">
-<div class="title">Note</div>
-</td>
-<td class="content">
-<div class="paragraph"><p>Addresses in this discussion refer to AMQP protocol addresses and not
-to TCP/IP network addresses. TCP/IP network addresses are used by
-messaging clients, brokers, and routers to create AMQP connections.
-AMQP protocol addresses are the names of source and destination
-endpoints for messages within the messaging network.</p></div>
-</td>
-</tr></table>
-</div>
-<div class="paragraph"><p>Addresses designate various kinds of entities in a messaging network:</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-Endpoint processes that consume data or offer a service
-</p>
-</li>
-<li>
-<p>
-Topics that match multiple consumers to multiple producers
-</p>
-</li>
-<li>
-<p>
-Entities within a messaging broker:
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-Queues
-</p>
-</li>
-<li>
-<p>
-Durable Topics
-</p>
-</li>
-<li>
-<p>
-Exchanges
-</p>
-</li>
-</ul></div>
-</li>
-</ul></div>
-<div class="paragraph"><p>The syntax of an AMQP address is opaque as far as the router network
-is concerned. A syntactical structure may be used by the administrator
-who creates addresses but the router treats them as opaque
-strings.</p></div>
-<div class="paragraph"><p>The router maintains several classes of address based on how the address is
-configured or discovered.</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="25%" />
-<col width="75%" />
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">Address Type</p></td>
-<td align="left" valign="top"><p class="table">Description</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">mobile</p></td>
-<td align="left" valign="top"><p class="table">The address is a rendezvous point between senders and receivers. The router aggregates and serializes messages from senders and distributes messages to receivers.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">link route</p></td>
-<td align="left" valign="top"><p class="table">The address defines a private messaging path between a sender and a receiver. The router simply passes messages between the end points.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-<div class="sect3">
-<h4 id="_mobile_addresses">2.3.1. Mobile Addresses</h4>
-<div class="paragraph"><p>Routers consider addresses to be mobile such that any users of an
-address may be directly connected to any router in a network and may
-move around the topology. In cases where messages are broadcast to or
-balanced across multiple consumers, the address users may be connected
-to multiple routers in the network.</p></div>
-<div class="paragraph"><p>Mobile addresses are rendezvous points for senders and receivers.
-Messages arrive at the mobile address and are dispatched to their
-destinations according to the routing defined for the mobile address.
-The details of these routing patterns are discussed later.</p></div>
-<div class="paragraph"><p>Mobile addresses may be discovered during normal router operation or
-configured through management settings.</p></div>
-<div class="sect4">
-<h5 id="_discovered_mobile_addresses">Discovered Mobile Addresses</h5>
-<div class="paragraph"><p>Mobile addresses are created when a client creates a link to a source
-or destination address that is unknown to the router network.</p></div>
-<div class="paragraph"><p>Suppose a service provider wants to offer <em>my-service</em> that clients
-may use. The service provider must open a receiver link with source
-address <em>my-service</em>. The router creates a mobile address
-<em>my-service</em> and propagates the address so that it is known to every
-router in the network.</p></div>
-<div class="paragraph"><p>Later a client wants to use the service and creates a sending link
-with target address <em>my-service</em>. The router matches the service
-provider’s receiver having source address <em>my-service</em> to the client’s
-sender having target address <em>my-service</em> and routes messages between
-the two.</p></div>
-<div class="paragraph"><p>Any number of other clients can create links to the service as
-well. The clients do not have to know where in the router network the
-service provider is physically located nor are the clients required to
-connect to a specific router to use the service. Regardless of how
-many clients are using the service the service provider needs only a
-single connection and link into the router network.</p></div>
-<div class="paragraph"><p>Another view of this same scenario is when a client tries to use the
-service before service provider has connected to the network. In this
-case the router network creates the mobile address <em>my-service</em> as
-before. However, since the mobile address has only client sender links
-and no receiver links the router stalls the clients and prevents them
-from sending any messages. Later, after the service provider connects
-and creates the receiver link, the router will issue credits to the
-clients and the messages will begin to flow between the clients and
-the service.</p></div>
-<div class="paragraph"><p>The service provider can connect, disconnect, and reconnect from a
-different location without having to change any of the clients or
-their connections. Imagine having the service running on a
-laptop. One day the connection is from corporate headquarters and the
-next day the connection is from some remote location. In this case the
-service provider’s computer will typically have different host IP
-addresses for each connection. Using the router network the service
-provider connects to the router network and offers the named service
-and the clients connect to the router network and consume from the
-named service. The router network routes messages between the mobile
-addresses effectively masking host IP addresses of the service
-provider and the client systems.</p></div>
-</div>
-<div class="sect4">
-<h5 id="_configured_mobile_addresses">Configured Mobile Addresses</h5>
-<div class="paragraph"><p>Mobile addresses may be configured using the router <em>autoLink</em>
-object. An address created via an <em>autoLink</em> represents a queue,
-topic, or other service in an external broker. Logically the
-<em>autoLink</em> addresses are treated by the router network as if the
-broker had connected to the router and offered the services itself.</p></div>
-<div class="paragraph"><p>For each configured mobile address the router will create a single
-link to the external resource. Messages flow between sender links and
-receiver links the same regardless if the mobile address was
-discovered or configured.</p></div>
-<div class="paragraph"><p>Multiple <em>autoLink</em> objects may define the same address on multiple
-brokers. In this case the router network creates a sharded resource
-split between the brokers. Any client can seamlessly send and receive
-messages from either broker.</p></div>
-<div class="paragraph"><p>Note that the brokers do not need to be clustered or federated to
-receive this treatment. The brokers may even be from different vendors
-or be different versions of the same broker yet still work together to
-provide a larger service platform.</p></div>
-</div>
-</div>
-<div class="sect3">
-<h4 id="_link_route_addresses">2.3.2. Link Route Addresses</h4>
-<div class="paragraph"><p>Link route addresses may be configured using the router <em>linkRoute</em>
-object. An link route address represents a queue, topic, or other
-service in an external broker similar to addresses configured by
-<em>autoLink</em> objects. For link route addresses the router propagates a
-separate link attachment to the broker resource for each incoming
-client link. The router does not automatically create any links to the
-broker resource.</p></div>
-<div class="paragraph"><p>Using link route addresses the router network does not participate in
-aggregated message distribution. The router simply passes message
-delivery and settlement between the two end points.</p></div>
-</div>
-</div>
-<div class="sect2">
-<h3 id="_message_routing">2.4. Message Routing</h3>
-<div class="paragraph"><p>Addresses have semantics associated with them that are assigned when
-the address is provisioned or discovered. The semantics of an address
-control how routers behave when they see the address being
-used. Address semantics include the following considerations:</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-Routing pattern - balanced, closest, multicast
-</p>
-</li>
-<li>
-<p>
-Routing mechanism - message routed, link routed
-</p>
-</li>
-</ul></div>
-<div class="sect3">
-<h4 id="_routing_patterns">2.4.1. Routing Patterns</h4>
-<div class="paragraph"><p>Routing patterns define the paths that a message with a mobile address can take across a network. These routing patterns can be used for both direct routing, in which the router distributes messages between clients without a broker, and indirect routing, in which the router enables clients to exchange messages through a broker.</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="20%" />
-<col width="80%" />
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">Pattern</p></td>
-<td align="left" valign="top"><p class="table">Description</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">Balanced</p></td>
-<td align="left" valign="top"><p class="table">An anycast method which allows multiple receivers to use the same address. In this case, messages (or links) are routed to exactly one of the receivers and the network attempts to balance the traffic load across the set of receivers using the same address. This routing delivers messages to receivers based on how quickly they settle the deliveries. Faster receivers get more messages.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">Closest</p></td>
-<td align="left" valign="top"><p class="table">An anycast method in which even if there are more receivers for the same address, every message is sent along the shortest path to reach the destination. This means that only one receiver will get the message. Each message is delivered to the closest receivers in terms of topology cost. If there are multiple receivers with the same lowest cost, deliveries will be spread evenly among those receivers.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">Multicast</p></td>
-<td align="left" valign="top"><p class="table">Having multiple consumers on the same address at the same time, messages are routed such that each consumer receives one copy of the message.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-<div class="sect3">
-<h4 id="_routing_mechanisms">2.4.2. Routing Mechanisms</h4>
-<div class="paragraph"><p>The fact that addresses can be used in different ways suggests that
-message routing can be accomplished in different ways. Before going
-into the specifics of the different routing mechanisms, it would be
-good to first define what is meant by the term <em>routing</em>:</p></div>
-<div class="literalblock">
-<div class="content">
-<pre><code>In a network built of multiple, interconnected routers 'routing'
-determines which connection to use to send a message directly
-to its destination or one step closer to its destination.</code></pre>
-</div></div>
-<div class="paragraph"><p>Each router serves as the terminus of a collection of incoming and
-outgoing links. Some of the links are designated for message routing,
-and others are designated for link routing. In both cases, the links
-either connect directly to endpoints that produce and consume
-messages, or they connect to other routers in the network along
-previously established connections.</p></div>
-<div class="sect4">
-<h5 id="_message_routed">Message Routed</h5>
-<div class="paragraph"><p>Message routing occurs upon delivery of a message and is done based on
-the address in the message’s <em>to</em> field.</p></div>
-<div class="paragraph"><p>When a delivery arrives on an incoming message-routing link, the
-router extracts the address from the delivered message’s <em>to</em> field and
-looks the address up in its routing table. The lookup results in zero
-or more outgoing links onto which the message shall be resent.</p></div>
-<div class="paragraph"><p>Message routing can also occur without an address in the
-message’s <em>to</em> field if the incoming link has a target address. In
-fact, if the sender uses a link with a target address, the <em>to</em> field
-shall be ignored even if used.</p></div>
-</div>
-<div class="sect4">
-<h5 id="_link_routed">Link Routed</h5>
-<div class="paragraph"><p>Link routing occurs when a new link is attached to the router across
-one of its AMQP connections. It is done based on the <em>target.address</em>
-field of an inbound link and the <em>source.address</em> field of an outbound
-link.</p></div>
-<div class="paragraph"><p>Link routing uses the same routing table that message routing
-uses. The difference is that the routing occurs during the link-attach
-operation, and link attaches are propagated along the appropriate path
-to the destination. What results is a chain of links, connected
-end-to-end, from source to destination. It is similar to a virtual
-circuit in a telecom system.</p></div>
-<div class="paragraph"><p>Each router in the chain holds pairs of link termini that are tied
-together. The router then simply exchanges all deliveries, delivery
-state changes, and link state changes between the two termini.</p></div>
-<div class="paragraph"><p>The endpoints that use the link chain do not see any difference in
-behavior between a link chain and a single point-to-point link. All of
-the features available in the link protocol (flow control,
-transactional delivery, etc.) are available over a routed link-chain.</p></div>
-</div>
-</div>
-<div class="sect3">
-<h4 id="_message_settlement">2.4.3. Message Settlement</h4>
-<div class="paragraph"><p>Messages may be delivered with varying degrees of reliability.</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-At most once
-</p>
-</li>
-<li>
-<p>
-At least once
-</p>
-</li>
-<li>
-<p>
-Exactly once
-</p>
-</li>
-</ul></div>
-<div class="paragraph"><p>The reliability is negotiated between the client and server during
-link establishment. The router handles all levels of reliability by treating
-messages as either <em>pre-settled</em> or <em>unsettled</em>.</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="20%" />
-<col width="80%" />
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">Delivery</p></td>
-<td align="left" valign="top"><p class="table">Handling</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">pre-settled</p></td>
-<td align="left" valign="top"><p class="table">If the arriving delivery is pre-settled (i.e., fire and forget), the incoming delivery shall be settled by the router, and the outgoing deliveries shall also be pre-settled. In other words, the pre-settled nature of the message delivery is propagated across the network to the message’s destination.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">unsettled</p></td>
-<td align="left" valign="top"><p class="table">Unsettled delivery is also propagated across the network. Because unsettled delivery records cannot be discarded, the router tracks the incoming deliveries and keeps the association of the incoming deliveries to the resulting outgoing deliveries. This kept association allows the router to continue to propagate changes in delivery state (settlement and disposition) back and forth along the path which the message traveled.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-</div>
-<div class="sect2">
-<h3 id="_security">2.5. Security</h3>
-<div class="paragraph"><p>The router uses the SSL protocol and related certificates and SASL
-protocol mechanisms to encrypt and authenticate remote peers. Router
-listeners act as network servers and router connectors act as network
-clients. Both connection types may be configured securely with SSL
-and SASL.</p></div>
-<div class="paragraph"><p>The router Policy module is an optional authorization mechanism
-enforcing user connection restrictions and AMQP resource access
-control.</p></div>
-</div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="using-qpid-dispatch">3. Using Qpid Dispatch</h2>
-<div class="sectionbody">
-<div class="sect2">
-<h3 id="configuration">3.1. Configuration</h3>
-<div class="paragraph"><p>The default configuration file is installed in
-<em>/usr/local/etc/qpid-dispatch/qdrouterd.conf</em>. 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></div>
-<div class="paragraph"><p>To run the router, invoke the executable: <code>qdrouterd [-c my-config-file]</code></p></div>
-<div class="paragraph"><p>For more details of the configuration file see the <em>qdrouterd.conf(5)</em> man
-page.</p></div>
-</div>
-<div class="sect2">
-<h3 id="tools">3.2. Tools</h3>
-<div class="sect3">
-<h4 id="qdstat">3.2.1. qdstat</h4>
-<div class="paragraph"><p><em>qdstat</em> is a command line tool that lets you view the status of a
-Dispatch Router. The following options are useful for seeing what the
-router is doing:</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="17%" />
-<col width="83%" />
-<thead>
-<tr>
-<th align="left" valign="top"><em>Option</em> </th>
-<th align="left" valign="top"><em>Description</em></th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">-l</p></td>
-<td align="left" valign="top"><p class="table">Print a list of AMQP links attached to the router. Links are
-unidirectional. Outgoing links are usually associated with a
-subscription address. The tool distinguishes between <em>endpoint</em> links
-and <em>router</em> links. Endpoint links are attached to clients using the
-router. Router links are attached to other routers in a network of
-routbers.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">-a</p></td>
-<td align="left" valign="top"><p class="table">Print a list of addresses known to the router.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">-n</p></td>
-<td align="left" valign="top"><p class="table">Print a list of known routers in the network.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">-c</p></td>
-<td align="left" valign="top"><p class="table">Print a list of connections to the router.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">--autolinks</p></td>
-<td align="left" valign="top"><p class="table">Print a list of configured auto-links.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">--linkroutes</p></td>
-<td align="left" valign="top"><p class="table">Print a list of configures link-routes.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-<div class="paragraph"><p>For complete details see the <em>qdstat(8)</em> man page and the output of
-<code>qdstat --help</code>.</p></div>
-</div>
-<div class="sect3">
-<h4 id="qdmanage">3.2.2. qdmanage</h4>
-<div class="paragraph"><p><em>qdmanage</em> is a general-purpose AMQP management client that allows you
-to not only view but modify the configuration of a running dispatch
-router.</p></div>
-<div class="paragraph"><p>For example you can query all the connection entities in the router:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdmanage query --type connection</code></pre>
-</div></div>
-<div class="paragraph"><p>To enable logging debug and higher level messages by default:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdmanage update log/DEFAULT enable=debug+</code></pre>
-</div></div>
-<div class="paragraph"><p>In fact, everything that can be configured in the configuration file can
-also be created in a running router via management. For example to
-create a new listener in a running router:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdmanage create type=listener port=5555</code></pre>
-</div></div>
-<div class="paragraph"><p>Now you can connect to port 5555, for exampple:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdmanage query -b localhost:5555 --type listener</code></pre>
-</div></div>
-<div class="paragraph"><p>For complete details see the <em>qdmanage(8)</em> man page and the output of
-<code>qdmanage --help</code>. Also for details of what can be configured see the
-<em>qdrouterd.conf(5)</em> man page.</p></div>
-</div>
-</div>
-<div class="sect2">
-<h3 id="basic-usage-and-examples">3.3. Basic Usage and Examples</h3>
-<div class="sect3">
-<h4 id="standalone-and-interior-modes">3.3.1. Standalone and Interior Modes</h4>
-<div class="paragraph"><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></div>
-<div class="paragraph"><p>If your router is running in stand-alone mode, <em>qdstat -a</em> will look
-like the following:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ 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</code></pre>
-</div></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ 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</code></pre>
-</div></div>
-</div>
-<div class="sect3">
-<h4 id="mobile-subscribers">3.3.2. Mobile Subscribers</h4>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ python ./simple_recv.py -a 127.0.0.1/my-address</code></pre>
-</div></div>
-<div class="paragraph"><p>This command creates a receiving link subscribed to the specified
-address. To verify the subscription:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ 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</code></pre>
-</div></div>
-<div class="paragraph"><p>You can then, in a separate command window, run a sender to produce
-messages to that address:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ python ./simple_send.py -a 127.0.0.1/my-address</code></pre>
-</div></div>
-</div>
-<div class="sect3">
-<h4 id="dynamic-reply-to">3.3.3. Dynamic Reply-To</h4>
-<div class="paragraph"><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>
-<div class="listingblock">
-<div class="content">
-<pre><code>#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();
-}</code></pre>
-</div></div>
-<div class="paragraph"><p>The equivalent program written in Python against the Proton Messenger
-API:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>from proton import Messenger, Message
-
-def main():
- host = "0.0.0.0:5672"
-
- messenger = Messenger()
- messenger.start()
- messenger.route("amqp:/*", "amqp://%s/$1" % host)
- reply_subscription = messenger.subscribe("amqp:/#")
- reply_address = reply_subscription.address
-
- request = Message()
- response = Message()
-
- request.address = "amqp:/_local/$management"
- request.reply_to = reply_address
- request.properties = {u'operation' : u'DISCOVER-MGMT-NODES',
- u'type' : u'org.amqp.management',
- u'name' : u'self'}
-
- messenger.put(request)
- messenger.send()
- messenger.recv()
- messenger.get(response)
-
- print "Response: %r" % response.body
-
- messenger.stop()
-
-main()</code></pre>
-</div></div>
-</div>
-</div>
-<div class="sect2">
-<h3 id="link-routing">3.4. Link Routing</h3>
-<div class="paragraph"><p>This feature was introduced in Qpid Dispatch 0.4. This feature was
-significantly updated in Qpid Dispatch 0.6.</p></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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>
-<div class="listingblock">
-<div class="content">
-<pre><code> Public Network
- +-----------------+
- | +-----+ |
- | B1 | Rp | |
- | +/--\-+ |
- | / \ |
- | / \ |
- +----/--------\---+
- / \
- / \
- / \
- Private Net A / \ Private Net B
- +--------------/--+ +---\-------------+
- | +---/-+ | | +--\--+ |
- | B2 | Ra | | | | Rb | C1 |
- | +-----+ | | +-----+ |
- | | | |
- | | | |
- +-----------------+ +-----------------+</code></pre>
-</div></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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>
-<div class="sect3">
-<h4 id="link-routing-configuration">3.4.1. Configuration</h4>
-<div class="paragraph"><p>Starting with the configured topology shown above, how is link-routing
-configured to support the example described above?</p></div>
-<div class="paragraph"><p>First, router Ra needs to be told how to make a connection to the broker
-B2:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>connector {
- name: broker
- role: route-container
- host: <B2-url>
- port: <B2-port>
- saslMechanisms: ANONYMOUS
-}</code></pre>
-</div></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><p>Now, the router must be configured to route certain addresses to B2:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>linkRoute {
- prefix: b2
- dir: in
- connection: broker
-}
-
-linkRoute {
- prefix: b2
- dir: out
- connection: broker
-}</code></pre>
-</div></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><p>Examples of addresses that "begin with <em>b2</em>" include:</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-b2
-</p>
-</li>
-<li>
-<p>
-b2.queues
-</p>
-</li>
-<li>
-<p>
-b2.queues.app1
-</p>
-</li>
-</ul></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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>
-</div>
-<div class="sect2">
-<h3 id="indirect-waypoints-and-auto-links">3.5. Indirect Waypoints and Auto-Links</h3>
-<div class="paragraph"><p>This feature was introduced in Qpid Dispatch 0.6. It is a significant
-improvement on an earlier somewhat experimental feature called
-Waypoints.</p></div>
-<div class="paragraph"><p>Auto-link is a feature of Qpid Dispatch Router that enables a router to
-actively attach a link to a node on an external AMQP container. The
-obvious application for this feature is to route messages through a
-queue on a broker, but other applications are possible as well.</p></div>
-<div class="paragraph"><p>An auto-link manages the lifecycle of one AMQP link. If messages are to
-be routed to and from a queue on a broker, then two auto-links are
-needed: one for sending messages to the queue and another for receiving
-messages from the queue. The container to which an auto-link attempts to
-attach may be identified in one of two ways:</p></div>
-<div class="quoteblock">
-<div class="content">
-<div class="ulist"><ul>
-<li>
-<p>
-The name of the connector/listener that resulted in the connection of
-the container, or
-</p>
-</li>
-<li>
-<p>
-The AMQP container-id of the remote container.
-</p>
-</li>
-</ul></div>
-</div>
-<div class="attribution">
-</div></div>
-<div class="sect3">
-<h4 id="queue-waypoint-example">3.5.1. Queue Waypoint Example</h4>
-<div class="paragraph"><p>Here is an example configuration for routing messages deliveries through
-a pair of queues on a broker:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>connector {
- name: broker
- role: route-container
- host: <hostname>
- port: <port>
- saslMechanisms: ANONYMOUS
-}
-
-address {
- prefix: queue
- waypoint: yes
-}
-
-autoLink {
- addr: queue.first
- dir: in
- connection: broker
-}
-
-autoLink {
- addr: queue.first
- dir: out
- connection: broker
-}
-
-autoLink {
- addr: queue.second
- dir: in
- connection: broker
-}
-
-autoLink {
- addr: queue.second
- dir: out
- connection: broker
-}</code></pre>
-</div></div>
-<div class="paragraph"><p>The <code>address</code> entity identifies a namespace <em>queue.</em> that will be used
-for routing messages through queues via autolinks. The four <code>autoLink</code> entities
-identify the head and tail of two queues on the broker that will be connected
-via auto-links.</p></div>
-<div class="paragraph"><p>If there is no broker connected, the auto-links shall remain
-<em>inactive</em>. This can be observed by using the <code>qdstat</code> tool:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdstat --autolinks
-AutoLinks
- addr dir phs extAddr link status lastErr
- ========================================================
- queue.first in 1 inactive
- queue.first out 0 inactive
- queue.second in 1 inactive
- queue.second out 0 inactive</code></pre>
-</div></div>
-<div class="paragraph"><p>If a broker comes online with a queue called <em>queue.first</em>, the
-auto-links will attempt to activate:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdstat --autolinks
-AutoLinks
- addr dir phs extAddr link status lastErr
- ===========================================================================
- queue.first in 1 6 active
- queue.first out 0 7 active
- queue.second in 1 failed Node not found: queue.second
- queue.second out 0 failed Node not found: queue.second</code></pre>
-</div></div>
-<div class="paragraph"><p>Note that two of the auto-links are in <em>failed</em> state because the queue
-does not exist on the broker.</p></div>
-<div class="paragraph"><p>If we now use the Qpid Proton example application <code>simple_send.py</code> to send
-three messages to <em>queue.first</em> via the router:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ python simple_send.py -a 127.0.0.1/queue.first -m3
-all messages confirmed</code></pre>
-</div></div>
-<div class="paragraph"><p>and then look at the address statistics on the router:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdstat -a
-Router Addresses
- class addr phs distrib in-proc local remote cntnr in out thru to-proc from-proc
- ========================================================================================================
- mobile queue.first 1 balanced 0 0 0 0 0 0 0 0 0
- mobile queue.first 0 balanced 0 1 0 0 3 3 0 0 0</code></pre>
-</div></div>
-<div class="paragraph"><p>we see that <em>queue.first</em> appears twice in the list of addresses. The
-<code>phs</code>, or phase column shows that there are two phases for the
-address. Phase <em>0</em> is for routing message deliveries from producers to
-the tail of the queue (the <code>out</code> auto-link associated with the queue).
-Phase 1 is for routing deliveries from the head of the queue to
-subscribed consumers.</p></div>
-<div class="paragraph"><p>Note that three deliveries have been counted in the "in" and "out"
-columns for phase <em>0</em>. The "in" column represents the three messages
-that arrived from <code>simple_send.py</code> and the <code>out</code> column represents the three
-deliveries to the queue on the broker.</p></div>
-<div class="paragraph"><p>If we now use <code>simple_recv.py</code> to receive three messages from this address:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ python simple_recv.py -a 127.0.0.1:5672/queue.first -m3
-{u'sequence': int32(1)}
-{u'sequence': int32(2)}
-{u'sequence': int32(3)}</code></pre>
-</div></div>
-<div class="paragraph"><p>We receive the three queued messages. Looking at the addresses again, we
-see that phase 1 was used to deliver those messages from the queue to
-the consumer.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdstat -a
-Router Addresses
- class addr phs distrib in-proc local remote cntnr in out thru to-proc from-proc
- ========================================================================================================
- mobile queue.first 1 balanced 0 0 0 0 3 3 0 0 0
- mobile queue.first 0 balanced 0 1 0 0 3 3 0 0 0</code></pre>
-</div></div>
-<div class="paragraph"><p>Note that even in a multi-router network, and with multiple producers
-and consumers for <em>queue.first</em>, all deliveries will be routed through
-the queue on the connected broker.</p></div>
-</div>
-<div class="sect3">
-<h4 id="sharded-queue-example">3.5.2. Sharded Queue Example</h4>
-<div class="paragraph"><p>Here is an extension of the above example to illustrate how Qpid
-Dispatch Router can be used to create a distributed queue in which
-multiple brokers share the message-queueing load.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>connector {
- name: broker1
- role: route-container
- host: <hostname>
- port: <port>
- saslMechanisms: ANONYMOUS
-}
-
-connector {
- name: broker2
- role: route-container
- host: <hostname>
- port: <port>
- saslMechanisms: ANONYMOUS
-}
-
-address {
- prefix: queue
- waypoint: yes
-}
-
-autoLink {
- addr: queue.first
- dir: in
- connection: broker1
-}
-
-autoLink {
- addr: queue.first
- dir: out
- connection: broker1
-}
-
-autoLink {
- addr: queue.first
- dir: in
- connection: broker2
-}
-
-autoLink {
- addr: queue.first
- dir: out
- connection: broker2
-}</code></pre>
-</div></div>
-<div class="paragraph"><p>In the above configuration, there are two instances of <em>queue.first</em> on
-brokers 1 and 2. Message traffic from producers to address <em>queue.first</em>
-shall be balanced between the two instance and messages from the queues
-shall be balanced across the collection of subscribers to the same
-address.</p></div>
-</div>
-<div class="sect3">
-<h4 id="dynamically-adding-shards">3.5.3. Dynamically Adding Shards</h4>
-<div class="paragraph"><p>Since configurable entities in the router can also be accessed via the
-management protocol, we can remotely add a shard to the above example
-using <code>qdmanage</code>:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>qdmanage create --type org.apache.qpid.dispatch.connector host=<host> port=<port> name=broker3
-qdmanage create --type org.apache.qpid.dispatch.router.config.autoLink addr=queue.first dir=in connection=broker3
-qdmanage create --type org.apache.qpid.dispatch.router.config.autoLink addr=queue.first dir=out connection=broker3</code></pre>
-</div></div>
-</div>
-<div class="sect3">
-<h4 id="address-renaming">3.5.4. Using a Different External Address on an Auto-Link</h4>
-<div class="paragraph"><p>Sometimes, greater flexibility is needed with regard to the addressing
-of a waypoint. For example, the above sharded-queue example requires
-that the two instances of the queue have the same name/address.
-Auto-links can be configured with an independent <code>externalAddr</code> that
-allows the waypoint to have a different address than that which is
-used by the senders and receivers.</p></div>
-<div class="paragraph"><p>Here’s an example:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>connector {
- name: broker
- role: route-container
- host: <hostname>
- port: <port>
- saslMechanisms: ANONYMOUS
-}
-
-address {
- prefix: queue
- waypoint: yes
-}
-
-autoLink {
- addr: queue.first
- externalAddr: broker_queue
- dir: in
- connection: broker
-}
-
-autoLink {
- addr: queue.first
- externalAddr: broker_queue
- dir: out
- connection: broker
-}</code></pre>
-</div></div>
-<div class="paragraph"><p>In the above configuration, the router network provides waypoint
-routing for the address <em>queue.first</em>, where senders and receivers use
-that address to send and receive messages. However, the queue on the
-broker is named "broker_queue". The address is translated through the
-auto-link that is established to the broker.</p></div>
-<div class="paragraph"><p>In this example, the endpoints (senders and receivers) are unaware of
-the <em>broker_queue</em> address and simply interact with <em>queue.first</em>.
-Likewise, the broker is unaware of the <em>queue.first</em> address and
-behaves as though a sender and a receiver is attached each using the
-address <em>broker_queue</em>.</p></div>
-<div class="paragraph"><p>The <code>qdstat</code> tool shows the external address for auto-links.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdstat --autolinks
-AutoLinks
- addr dir phs extAddr link status lastErr
- ===========================================================
- queue.first in 1 broker_queue 6 active
- queue.first out 0 broker_queue 7 active</code></pre>
-</div></div>
-</div>
-</div>
-<div class="sect2">
-<h3 id="policy">3.6. Policy</h3>
-<div class="paragraph"><p>The Policy module is an optional authorization mechanism enforcing
-user connection restrictions and AMQP resource access control.</p></div>
-<div class="paragraph"><p>Policy is assigned when a connection is created. The connection
-properties <strong>AMQP virtual host</strong>, <strong>authenticated user name</strong>, and <strong>connection
-remote host</strong> are passed to the policy engine for a connection
-allow/deny decision. If the connection is allowed then the user is
-assigned to a group that names a set of AMQP resource limits that are
-enforced for the lifetime of the connection.</p></div>
-<div class="admonitionblock">
-<table><tr>
-<td class="icon">
-<div class="title">Note</div>
-</td>
-<td class="content">
-<div class="paragraph"><p>Policy limits are applied only to incoming user network connections.
-Policy limits are not applied to interrouter connections nor are they
-applied to router connections outbound to waypoints.</p></div>
-</td>
-</tr></table>
-</div>
-<div class="sect3">
-<h4 id="_definitions">3.6.1. Definitions</h4>
-<div class="sect4">
-<h5 id="_vhost">vhost</h5>
-<div class="paragraph"><p>A <em>vhost</em> is typically the name of the host to which the client AMQP
-connection is directed. For example, suppose a client application opens
-connection URL:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>amqp://bigbroker.example.com:5672/favorite_subject</code></pre>
-</div></div>
-<div class="paragraph"><p>The client will signal virtual host name <em>bigbroker.example.com</em> to
-the router during AMQP connection startup. Router Policy intercepts
-the virtual host <em>bigbroker.example.com</em> and applies a vhost policy
-with that name to the connection.</p></div>
-</div>
-</div>
-<div class="sect3">
-<h4 id="_policy_features">3.6.2. Policy Features</h4>
-<div class="sect4">
-<h5 id="_total_connection_limit">Total Connection Limit</h5>
-<div class="paragraph"><p>A router may be configured with a total connection limit. This limit
-controls the maximum number of simultaneous incoming user connections
-that are allowed at any time. It protects the router from file
-descriptor resource exhaustion in the face of many incoming client
-connections. This limit is specified and enforced independently of
-any other Policy settings.</p></div>
-</div>
-<div class="sect4">
-<h5 id="_vhost_policy">Vhost Policy</h5>
-<div class="paragraph"><p>Vhost policy defines users and assigns them to user groups. Each
-user group defines the remote hosts from which the members may connect
-to the router network, and what resources in the router network the
-group members are allowed to access.</p></div>
-<div class="paragraph"><p>Vhost policy also defines connection count limits to control the
-number of users that may be simultaneously connected to the vhost.</p></div>
-<div class="admonitionblock">
-<table><tr>
-<td class="icon">
-<div class="title">Note</div>
-</td>
-<td class="content">
-<div class="paragraph"><p>A vhost user may be assigned to one user group only.</p></div>
-</td>
-</tr></table>
-</div>
-</div>
-<div class="sect4">
-<h5 id="_default_vhost">Default Vhost</h5>
-<div class="paragraph"><p>A default vhost may be defined. The default vhost policy is used for
-connections whose vhost is otherwise not defined in the policy database.</p></div>
-<div class="paragraph"><p><a href="#example2">Example 2</a> illustrates how the default vhost feature can
-be used to apply a single vhost policy set of restrictions to any
-number of vhost connections.</p></div>
-</div>
-</div>
-<div class="sect3">
-<h4 id="_policy_schema">3.6.3. Policy Schema</h4>
-<div class="paragraph"><p>Policy configuration is specified in two schema objects.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>policy = {
- <global settings>
-}
-
-vhost = {
- id: vhost-name
- <connection limits>
- groups: {
- group-name: {
- <user group settings>
- }
- }
-}</code></pre>
-</div></div>
-<div class="paragraph"><p>The <em>policy</em> object is a singleton. Multiple <em>vhost</em> objects may be
-created as needed.</p></div>
-<div class="sect4">
-<h5 id="_global_policy">Global Policy</h5>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="35%" />
-<col width="15%" />
-<col width="50%" />
-<thead>
-<tr>
-<th align="left" valign="top"> attribute </th>
-<th align="left" valign="top"> default </th>
-<th align="left" valign="top"> description</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">maxConnections</p></td>
-<td align="left" valign="top"><p class="table">65535</p></td>
-<td align="left" valign="top"><p class="table">Global maximum number of concurrent client connections allowed. This limit is always enforced even if no other policy settings have been defined. This limit is applied to all incoming connections regardless of remote host, authenticated user, or targeted vhost.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">enableVhostPolicy</p></td>
-<td align="left" valign="top"><p class="table">false</p></td>
-<td align="left" valign="top"><p class="table">Enable vhost policy connection denial, and resource limit enforcement.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">policyDir</p></td>
-<td align="left" valign="top"><p class="table">""</p></td>
-<td align="left" valign="top"><p class="table">Absolute path to a directory that holds vhost definition .json files. All vhost definitions in all .json files in this directory are processed.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">defaultVhost</p></td>
-<td align="left" valign="top"><p class="table">"$default"</p></td>
-<td align="left" valign="top"><p class="table">Vhost rule set name to use for connections with a vhost that is otherwise not defined. Default vhost processing may be disabled either by erasing the definition of <em>defaultVhost</em> or by not defining a <em>vhost</em> object named <em>$default</em>.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-<div class="sect4">
-<h5 id="_vhost_policy_2">Vhost Policy</h5>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="35%" />
-<col width="15%" />
-<col width="50%" />
-<thead>
-<tr>
-<th align="left" valign="top"> attribute </th>
-<th align="left" valign="top"> default </th>
-<th align="left" valign="top"> description</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">id</p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-<td align="left" valign="top"><p class="table">Vhost name must be unique.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxConnections</p></td>
-<td align="left" valign="top"><p class="table">65535</p></td>
-<td align="left" valign="top"><p class="table">Maximum number of concurrent client connections allowed.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxConnectionsPerUser</p></td>
-<td align="left" valign="top"><p class="table">65535</p></td>
-<td align="left" valign="top"><p class="table">Maximum number of concurrent client connections allowed for any user.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxConnectionsPerRemoteHost</p></td>
-<td align="left" valign="top"><p class="table">65535</p></td>
-<td align="left" valign="top"><p class="table">Maximum number of concurrent client connections allowed for any remote host.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">allowUnknownUser</p></td>
-<td align="left" valign="top"><p class="table">false</p></td>
-<td align="left" valign="top"><p class="table">Allow unknown users who are not members of a defined user group. Unknown users are assigned to the <em>$default</em> user group and receive <em>$default</em> settings.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">groups</p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-<td align="left" valign="top"><p class="table">A map where each key is a user group name and the value is a Vhost User Group Settings map.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-<div class="sect4">
-<h5 id="_vhost_user_group_settings_map">Vhost User Group Settings Map</h5>
-<div class="paragraph"><p>This object is the data value contained in entries in the policy/groups map.</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="35%" />
-<col width="15%" />
-<col width="50%" />
-<thead>
-<tr>
-<th align="left" valign="top"> Section/Attribute </th>
-<th align="left" valign="top"> default </th>
-<th align="left" valign="top"> description</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table"><strong>Group Membership</strong></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">users</p></td>
-<td align="left" valign="top"><p class="table">""</p></td>
-<td align="left" valign="top"><p class="table">Comma separated list of authenticated users in this group.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><strong>Connection Restrictions</strong></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">remoteHosts</p></td>
-<td align="left" valign="top"><p class="table">""</p></td>
-<td align="left" valign="top"><p class="table">List of remote hosts from which the users may connect. List values may be host names, numeric IP addresses, numeric IP address ranges, or the wildcard <em>*</em>. An empty list denies all access.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><strong>AMQP Connection Open Limits</strong></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxFrameSize</p></td>
-<td align="left" valign="top"><p class="table">2^31-1</p></td>
-<td align="left" valign="top"><p class="table">Largest frame that may be sent on this connection. (AMQP Open, max-frame-size)</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxSessions</p></td>
-<td align="left" valign="top"><p class="table">65535</p></td>
-<td align="left" valign="top"><p class="table">Maximum number of sessions that may be created on this connection. (AMQP Open, channel-max)</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><strong>AMQP Session Begin Limits</strong></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxSessionWindow</p></td>
-<td align="left" valign="top"><p class="table">2^31-1</p></td>
-<td align="left" valign="top"><p class="table">Incoming capacity for new sessions. (AMQP Begin, incoming-window)</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><strong>AMQP Link Attach</strong></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxMessageSize</p></td>
-<td align="left" valign="top"><p class="table">0</p></td>
-<td align="left" valign="top"><p class="table">Largest message size supported by links created on this connection. If this field is zero there is no maximum size imposed by the link endpoint. (AMQP Attach, max-message-size)</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxSenders</p></td>
-<td align="left" valign="top"><p class="table">2^31-1</p></td>
-<td align="left" valign="top"><p class="table">Maximum number of sending links that may be created on this connection.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxReceivers</p></td>
-<td align="left" valign="top"><p class="table">2^31-1</p></td>
-<td align="left" valign="top"><p class="table">Maximum number of receiving links that may be created on this connection.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">allowDynamicSource</p></td>
-<td align="left" valign="top"><p class="table">false</p></td>
-<td align="left" valign="top"><p class="table">This connection is allowed to create receiving links using the Dynamic Link Source feature.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">allowAnonymousSender</p></td>
-<td align="left" valign="top"><p class="table">false</p></td>
-<td align="left" valign="top"><p class="table">This connection is allowed to create sending links using the Anonymous Sender feature.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">allowUserIdProxy</p></td>
-<td align="left" valign="top"><p class="table">false</p></td>
-<td align="left" valign="top"><p class="table">This connection is allowed to send messages with a user_id property that differs from the connection’s authenticated user id.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">sources</p></td>
-<td align="left" valign="top"><p class="table">""</p></td>
-<td align="left" valign="top"><p class="table">List of Source addresses allowed when creating receiving links. This list may be expressed as a CSV string or as a list of strings. An empty list denies all access.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">targets</p></td>
-<td align="left" valign="top"><p class="table">""</p></td>
-<td align="left" valign="top"><p class="table">List of Target addresses allowed when creating sending links. This list may be expressed as a CSV string or as a list of strings. An empty list denies all access.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-</div>
-<div class="sect3">
-<h4 id="_policy_wildcard_and_user_name_substitution">3.6.4. Policy Wildcard and User Name Substitution</h4>
-<div class="paragraph"><p>Policy provides several conventions to make writing rules easier.</p></div>
-<div class="sect4">
-<h5 id="_remote_host_wildcard">Remote Host Wildcard</h5>
-<div class="paragraph"><p>Remote host rules may consist of a single asterisk character to
-specify all hosts.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code> remoteHosts: *</code></pre>
-</div></div>
-<div class="paragraph"><p>The asterisk must stand alone and cannot be appended to a host name
-or to an IP address fragment.</p></div>
-</div>
-<div class="sect4">
-<h5 id="_amqp_source_and_target_wildcard_and_name_substitution">AMQP Source and Target Wildcard and Name Substitution</h5>
-<div class="paragraph"><p>The rule definitions for <code>sources</code> and <code>targets</code> may include the username
-substitution token</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code> {user}</code></pre>
-</div></div>
-<div class="paragraph"><p>or a trailing asterisk.</p></div>
-<div class="paragraph"><p>The username substitution token is replaced with the authenticated user name for
-the connection. Using this token, an administrator may allow access to
-some resources specific to each user without having to name each user
-individually. This token is substituted once for the leftmost
-occurrence in the link name.</p></div>
-<div class="paragraph"><p>The asterisk is recognized only if it is the last character in the
-link name.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code> sources: tmp_{user}, temp*, {user}-home-*</code></pre>
-</div></div>
-</div>
-</div>
-<div class="sect3">
-<h4 id="_composing_policies">3.6.5. Composing Policies</h4>
-<div class="paragraph"><p>This section shows policy examples designed to illustrate some common use cases.</p></div>
-<div class="sect4">
-<h5 id="_example_1_user_policy_disabled">Example 1. User Policy Disabled</h5>
-<div class="paragraph"><p>Policy is disabled when no policy configuation objects are defined.
-Any number of connections are allowed and all users have
-access to all AMQP resources in the network.</p></div>
-</div>
-<div class="sect4">
-<h5 id="example2">Example 2. All Users Have Simple Connection Limits</h5>
-<div class="paragraph"><p>This example shows how to keep users from overwhelming the router with
-connections. Any user can create up to ten connections and the router
-will limit the aggregated user connection count to 100 connections
-total. No other restrictions apply.</p></div>
-<div class="paragraph"><p>This example also shows how to use a default vhost policy effectively.
-Only one vhost policy is defined and all user connections regardless
-of the requested vhost use that policy.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>policy {
- maxConnections: 100 <b><1></b>
-}
-
-vhost {
- name: $default <b><2></b>
- maxConnectionsPerUser: 10 <b><3></b>
- allowUnknownUser: true <b><4></b>
- groups: {
- $default: {
- remoteHosts: * <b><5></b>
- sources: * <b><6></b>
- targets: * <b><6></b>
- }
- }
-}</code></pre>
-</div></div>
-<div class="colist arabic"><ol>
-<li>
-<p>
-The global maxConnections limit of 100 is enforced.
-</p>
-</li>
-<li>
-<p>
-No normal vhost names are defined; user is assigned to default vhost <em>$default</em>.
-</p>
-</li>
-<li>
-<p>
-The vhost maxConnectionsPerUser limit of 10 is enforced.
-</p>
-</li>
-<li>
-<p>
-No groups are defined to have any users but allowUnknownUser is true so all users are assigned to group $default.
-</p>
-</li>
-<li>
-<p>
-The user is allowed to connect from any remote host.
-</p>
-</li>
-<li>
-<p>
-The user is allowed to connect to any source or target in the AMQP network. Router system-wide values are used for the other AMQP settings that are unspecified in the vhost rules.
-</p>
-</li>
-</ol></div>
-</div>
-<div class="sect4">
-<h5 id="_example_3_admins_must_connect_from_localhost">Example 3. Admins Must Connect From Localhost</h5>
-<div class="paragraph"><p>This example shows how an admin group may be created and restricted
-to accessing a vhost only from localhost. The admin users are allowed
-to connect to any AMQP resources while normal users are restricted.</p></div>
-<div class="paragraph"><p>In this example a user connects to vhost <em>example.com</em>.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>vhost {
- name: example.com <b><1></b>
- allowUnknownUser: true <b><3></b>
- groups: {
- admin: {
- users: alice, bob <b><2></b>
- remoteHosts: 127.0.0.1, ::1 <b><4></b>
- sources: * <b><5></b>
- targets: * <b><5></b>
- },
- $default: {
- remoteHosts: * <b><6></b>
- sources: news*, sports*, chat* <b><7></b>
- targets: chat* <b><7></b>
- }
- }
-}</code></pre>
-</div></div>
-<div class="colist arabic"><ol>
-<li>
-<p>
-A connection to vhost <em>example.com</em> locates this vhost rule set.
-</p>
-</li>
-<li>
-<p>
-If one of users <em>alice</em> or <em>bob</em> is connecting then she or he is assigned to the <em>admin</em> user group.
-</p>
-</li>
-<li>
-<p>
-Any other user is not defined by a user group. However, since the <em>allowUnknownUser</em> setting is true then this user is assigned to the <em>$default</em> user group.
-</p>
-</li>
-<li>
-<p>
-Users in the <em>admin</em> user group must connect from localhost. Connections for an <em>admin</em> user from other hosts on the network are denied.
-</p>
-</li>
-<li>
-<p>
-Users in the <em>admin</em> user group are allowed to access any resource offered by the vhost service.
-</p>
-</li>
-<li>
-<p>
-Other users are allowed to connect from any host.
-</p>
-</li>
-<li>
-<p>
-Other users have source and target name lists that restrict the resources they are allowed to access.
-</p>
-</li>
-</ol></div>
-</div>
-<div class="sect4">
-<h5 id="_example_4_limiting_possible_memory_consumption">Example 4. Limiting Possible Memory Consumption</h5>
-<div class="paragraph"><p>Policy provides a mechanism to control how much system buffer memory a
-user connection can potentially consume. The formula for computing
-buffer memory consumption for each session is</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code> potential buffer usage = maxFrameSize * maxSessionWindow</code></pre>
-</div></div>
-<div class="paragraph"><p>By adjusting <em>maxFrameSize</em>, <em>maxSessions</em>, and <em>maxSessionWindow</em> an
-administrator can prevent a user from consuming too much memory by
-buffering messages in flight.</p></div>
-<div class="admonitionblock">
-<table><tr>
-<td class="icon">
-<div class="title">Note</div>
-</td>
-<td class="content">
-<div class="paragraph"><p>The settings passed into the AMQP protocol connection and session
-negotiations. Normal AMQP session flow control limits buffer
-consumption in due course with no processing cycles required by the
-router.</p></div>
-</td>
-</tr></table>
-</div>
-<div class="paragraph"><p>In this example normal users, the traders, are given smaller buffer
-allocations while high-capacity, automated data feeds are given a
-higher buffer allocation. This example skips the details of settings
-unrelated to buffer allocation.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>vhost {
- name: traders.com <b><1></b>
- groups: {
- traders: {
- users: trader-1, trader-2, ... <b><2></b>
- maxFrameSize: 10000 <b><3></b>
- maxSessionWindow: 500 <b><3></b>
- maxSessions: 1 <b><4></b>
- ...
- },
- feeds: {
- users: nyse-feed, nasdaq-feed <b><5></b>
- maxFrameSize: 60000 <b><6></b>
- maxSessionWindow: 20000 <b><6></b>
- maxSessions: 3 <b><7></b>
- ...
- }
- }
-}</code></pre>
-</div></div>
-<div class="colist arabic"><ol>
-<li>
-<p>
-These rules are for vhost traders.com.
-</p>
-</li>
-<li>
-<p>
-The <em>traders</em> group includes trader-1, trader-2, and any other user defined in the list.
-</p>
-</li>
-<li>
-<p>
-<em>maxFrameSize</em> and <em>maxSessionWindow</em> allow for at most 5,000,000 bytes of data to be in flight on each session.
-</p>
-</li>
-<li>
-<p>
-Only one session per connection is allowed.
-</p>
-</li>
-<li>
-<p>
-In the <em>feeds</em> group two users are defined.
-</p>
-</li>
-<li>
-<p>
-<em>maxFrameSize</em> and <em>maxSessionWindow</em> allow for at most 1,200,000,000 bytes of data to be in flight on each session.
-</p>
-</li>
-<li>
-<p>
-Up to three sessions per connection are allowed.
-</p>
-</li>
-</ol></div>
-</div>
-</div>
-</div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="technical-details-and-specifications">4. Technical Details and Specifications</h2>
-<div class="sectionbody">
-<div class="sect2">
-<h3 id="client-compatibility">4.1. Client Compatibility</h3>
-<div class="paragraph"><p>Dispatch Router should, in theory, work with any client that is
-compatible with AMQP 1.0. The following clients have been tested:</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="22%" />
-<col width="78%" />
-<thead>
-<tr>
-<th align="left" valign="top"><em>Client</em> </th>
-<th align="left" valign="top"><em>Notes</em></th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">qpid::messaging</p></td>
-<td align="left" valign="top"><p class="table">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.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">Proton Reactor</p></td>
-<td align="left" valign="top"><p class="table">The Proton Reactor API is compatible with Dispatch
-Router.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">Proton Messenger</p></td>
-<td align="left" valign="top"><p class="table">Messenger works with Dispatch Router.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-<div class="sect2">
-<h3 id="addressing">4.2. Addressing</h3>
-<div class="paragraph"><p>AMQP addresses are used to control the flow of messages across a network
-of routers. Addresses are used in a number of different places in the
-AMQP 1.0 protocol. They can be used in a specific message in the <code>to</code>
-and <code>reply-to</code> fields of a message’s properties. They are also used
-during the creation of links in the <code>address</code> field of a <code>source</code> or
-a <code>target</code>.</p></div>
-<div class="paragraph"><p>Addresses designate various kinds of entities in a messaging network:</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-Endpoint processes that consume data or offer a service
-</p>
-</li>
-<li>
-<p>
-Topics that match multiple consumers to multiple producers
-</p>
-</li>
-<li>
-<p>
-Entities within a messaging broker:
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-Queues
-</p>
-</li>
-<li>
-<p>
-Durable Topics
-</p>
-</li>
-<li>
-<p>
-Exchanges
-</p>
-</li>
-</ul></div>
-</li>
-</ul></div>
-<div class="paragraph"><p>The syntax of an AMQP address is opaque as far as the router network is
-concerned. A syntactical structure may be used by the administrator that
-creates addresses, but the router treats them as opaque strings. Routers
-consider addresses to be mobile such that any address may be directly
-connected to any router in a network and may move around the topology.
-In cases where messages are broadcast to or balanced across multiple
-consumers, an address may be connected to multiple routers in the
-network.</p></div>
-<div class="paragraph"><p>Addresses have sem
<TRUNCATED>
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/book/console1.png
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/book/console1.png b/input/releases/qpid-dispatch-master/book/console1.png
deleted file mode 100644
index f131884..0000000
Binary files a/input/releases/qpid-dispatch-master/book/console1.png and /dev/null differ
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org
[13/13] qpid-site git commit: QPID-8015: Prepare the dispatch release
scripts for the new user guide
Posted by jr...@apache.org.
QPID-8015: Prepare the dispatch release scripts for the new user guide
- Update scripts
- Add asciidoc and asciidoctor deps
- Add style adjustments for asciidoctor output
- Regenerate the dispatch master snapshot
Project: http://git-wip-us.apache.org/repos/asf/qpid-site/repo
Commit: http://git-wip-us.apache.org/repos/asf/qpid-site/commit/030c23a6
Tree: http://git-wip-us.apache.org/repos/asf/qpid-site/tree/030c23a6
Diff: http://git-wip-us.apache.org/repos/asf/qpid-site/diff/030c23a6
Branch: refs/heads/asf-site
Commit: 030c23a6934841a62c81d7ee969a25fef952b7e7
Parents: 325942f
Author: Justin Ross <jr...@apache.org>
Authored: Tue Nov 28 11:34:21 2017 -0800
Committer: Justin Ross <jr...@apache.org>
Committed: Tue Nov 28 11:34:21 2017 -0800
----------------------------------------------------------------------
README.md | 16 +-
content/deferred.css | 15 +
.../qpid-dispatch-master/_images/console1.png | Bin 40412 -> 0 bytes
.../_images/console_charts.png | Bin 70070 -> 0 bytes
.../_images/console_entity.png | Bin 69319 -> 0 bytes
.../_images/console_login.png | Bin 39915 -> 0 bytes
.../_images/console_overview.png | Bin 87960 -> 0 bytes
.../_images/console_schema.png | Bin 68025 -> 0 bytes
.../_images/console_topology.png | Bin 67338 -> 0 bytes
content/releases/qpid-dispatch-master/book.html | 4259 ----------
content/releases/qpid-dispatch-master/book.pdf | Bin 590974 -> 0 bytes
.../qpid-dispatch-master/book/book.html | 5020 -----------
.../qpid-dispatch-master/book/console1.png | Bin 40412 -> 0 bytes
.../book/console_charts.png | Bin 70070 -> 0 bytes
.../book/console_entity.png | Bin 69319 -> 0 bytes
.../qpid-dispatch-master/book/console_login.png | Bin 39915 -> 0 bytes
.../book/console_overview.png | Bin 87960 -> 0 bytes
.../book/console_schema.png | Bin 68025 -> 0 bytes
.../book/console_topology.png | Bin 67338 -> 0 bytes
.../releases/qpid-dispatch-master/console1.png | Bin 40412 -> 0 bytes
.../qpid-dispatch-master/console_charts.png | Bin 70070 -> 0 bytes
.../qpid-dispatch-master/console_entity.png | Bin 69319 -> 0 bytes
.../qpid-dispatch-master/console_login.png | Bin 39915 -> 0 bytes
.../qpid-dispatch-master/console_overview.png | Bin 87960 -> 0 bytes
.../qpid-dispatch-master/console_schema.png | Bin 68025 -> 0 bytes
.../qpid-dispatch-master/console_topology.png | Bin 67338 -> 0 bytes
.../releases/qpid-dispatch-master/index.html | 7 +-
.../qpid-dispatch-master/man/qdmanage.html | 37 +-
.../man/qdrouterd.conf.html | 306 +-
.../qpid-dispatch-master/man/qdrouterd.html | 4 +-
.../qpid-dispatch-master/man/qdstat.html | 268 +-
.../qpid-dispatch-master/qdmanage.8.html | 389 -
.../qpid-dispatch-master/qdrouterd.8.html | 197 -
.../qpid-dispatch-master/qdrouterd.conf.5.html | 1156 ---
.../releases/qpid-dispatch-master/qdstat.8.html | 870 --
.../qpid-dispatch-master/user-guide/index.html | 7969 ++++++++++++++++++
input/deferred.css | 15 +
.../qpid-dispatch-master/_images/console1.png | Bin 40412 -> 0 bytes
.../_images/console_charts.png | Bin 70070 -> 0 bytes
.../_images/console_entity.png | Bin 69319 -> 0 bytes
.../_images/console_login.png | Bin 39915 -> 0 bytes
.../_images/console_overview.png | Bin 87960 -> 0 bytes
.../_images/console_schema.png | Bin 68025 -> 0 bytes
.../_images/console_topology.png | Bin 67338 -> 0 bytes
.../releases/qpid-dispatch-master/book.html.in | 4115 ---------
input/releases/qpid-dispatch-master/book.pdf | Bin 590974 -> 0 bytes
.../qpid-dispatch-master/book/book.html.in | 4876 -----------
.../qpid-dispatch-master/book/console1.png | Bin 40412 -> 0 bytes
.../book/console_charts.png | Bin 70070 -> 0 bytes
.../book/console_entity.png | Bin 69319 -> 0 bytes
.../qpid-dispatch-master/book/console_login.png | Bin 39915 -> 0 bytes
.../book/console_overview.png | Bin 87960 -> 0 bytes
.../book/console_schema.png | Bin 68025 -> 0 bytes
.../book/console_topology.png | Bin 67338 -> 0 bytes
.../releases/qpid-dispatch-master/console1.png | Bin 40412 -> 0 bytes
.../qpid-dispatch-master/console_charts.png | Bin 70070 -> 0 bytes
.../qpid-dispatch-master/console_entity.png | Bin 69319 -> 0 bytes
.../qpid-dispatch-master/console_login.png | Bin 39915 -> 0 bytes
.../qpid-dispatch-master/console_overview.png | Bin 87960 -> 0 bytes
.../qpid-dispatch-master/console_schema.png | Bin 68025 -> 0 bytes
.../qpid-dispatch-master/console_topology.png | Bin 67338 -> 0 bytes
input/releases/qpid-dispatch-master/index.md | 7 +-
.../qpid-dispatch-master/man/qdmanage.html.in | 37 +-
.../man/qdrouterd.conf.html.in | 306 +-
.../qpid-dispatch-master/man/qdrouterd.html.in | 4 +-
.../qpid-dispatch-master/man/qdstat.html.in | 268 +-
.../qpid-dispatch-master/qdmanage.8.html.in | 245 -
.../qpid-dispatch-master/qdrouterd.8.html.in | 53 -
.../qdrouterd.conf.5.html.in | 1012 ---
.../qpid-dispatch-master/qdstat.8.html.in | 726 --
.../user-guide/index.html.in | 7826 +++++++++++++++++
python/generate.py | 2 +
scripts/gen-dispatch-release-docs | 39 +-
scripts/gen-dispatch-release-page | 5 +-
74 files changed, 16396 insertions(+), 23653 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/README.md
----------------------------------------------------------------------
diff --git a/README.md b/README.md
index 3225dfb..304f479 100644
--- a/README.md
+++ b/README.md
@@ -157,14 +157,14 @@ files:
input/releases/index.md # Add current release, move the previous
The scripts depend on the availability of the following tools in your
-environment: cmake, dot, doxygen, epydoc, fop, gcc, javadoc, make,
-pygments, PyYAML, rdoc, git, pandoc, pdflatex and xsltproc. The
-following yum command works to install all the required dependencies
-on Fedora or RHEL.
-
- $ sudo yum install cmake doxygen epydoc fop gcc graphviz java-devel \
- libxslt make python-pygments PyYAML rubygem-rdoc git \
- pandoc-pdf python-sphinx maven
+environment: asciidoc, asciidoctor, cmake, dot, doxygen, epydoc, fop,
+gcc, javadoc, make, pygments, PyYAML, rdoc, git, pandoc, pdflatex and
+xsltproc. The following yum command works to install all the required
+dependencies on Fedora or RHEL.
+
+ $ sudo yum install asciidoc asciidoctor cmake doxygen epydoc \
+ fop gcc graphviz java-devel libxslt make python-pygments \
+ PyYAML rubygem-rdoc git \ pandoc-pdf python-sphinx maven
## Publishing your work
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/deferred.css
----------------------------------------------------------------------
diff --git a/content/deferred.css b/content/deferred.css
index 2170e7b..586435c 100644
--- a/content/deferred.css
+++ b/content/deferred.css
@@ -379,6 +379,21 @@ a[href]:visited {
font-weight: 400;
}
+/* Adjustments for asciidoctor output */
+
+div.sect1, div.sect2, div.paragraph, div.listingblock, div.ulist, div.tableblock, div.toc {
+ margin-bottom: 1em;
+}
+
+div.ulist > ul > li > p {
+ margin-bottom: 0;
+}
+
+div.tableblock td, div.tableblock th {
+ border: 0;
+ border-bottom: 1px solid #efefef;
+}
+
/* Media */
@media screen and (max-width: 800px) {
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/_images/console1.png
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/_images/console1.png b/content/releases/qpid-dispatch-master/_images/console1.png
deleted file mode 100755
index f131884..0000000
Binary files a/content/releases/qpid-dispatch-master/_images/console1.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/_images/console_charts.png
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/_images/console_charts.png b/content/releases/qpid-dispatch-master/_images/console_charts.png
deleted file mode 100755
index 169c2ca..0000000
Binary files a/content/releases/qpid-dispatch-master/_images/console_charts.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/_images/console_entity.png
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/_images/console_entity.png b/content/releases/qpid-dispatch-master/_images/console_entity.png
deleted file mode 100755
index 130c7e7..0000000
Binary files a/content/releases/qpid-dispatch-master/_images/console_entity.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/_images/console_login.png
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/_images/console_login.png b/content/releases/qpid-dispatch-master/_images/console_login.png
deleted file mode 100755
index 63e22c6..0000000
Binary files a/content/releases/qpid-dispatch-master/_images/console_login.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/_images/console_overview.png
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/_images/console_overview.png b/content/releases/qpid-dispatch-master/_images/console_overview.png
deleted file mode 100755
index af25f36..0000000
Binary files a/content/releases/qpid-dispatch-master/_images/console_overview.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/_images/console_schema.png
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/_images/console_schema.png b/content/releases/qpid-dispatch-master/_images/console_schema.png
deleted file mode 100755
index ba56c7b..0000000
Binary files a/content/releases/qpid-dispatch-master/_images/console_schema.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/_images/console_topology.png
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/_images/console_topology.png b/content/releases/qpid-dispatch-master/_images/console_topology.png
deleted file mode 100755
index ae4b22a..0000000
Binary files a/content/releases/qpid-dispatch-master/_images/console_topology.png and /dev/null differ
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org
[12/13] qpid-site git commit: QPID-8015: Prepare the dispatch release
scripts for the new user guide
Posted by jr...@apache.org.
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/book.html
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/book.html b/content/releases/qpid-dispatch-master/book.html
deleted file mode 100644
index 41b9723..0000000
--- a/content/releases/qpid-dispatch-master/book.html
+++ /dev/null
@@ -1,4259 +0,0 @@
-<!DOCTYPE html>
-<!--
- -
- - Licensed to the Apache Software Foundation (ASF) under one
- - or more contributor license agreements. See the NOTICE file
- - distributed with this work for additional information
- - regarding copyright ownership. The ASF licenses this file
- - to you under the Apache License, Version 2.0 (the
- - "License"); you may not use this file except in compliance
- - with the License. You may obtain a copy of the License at
- -
- - http://www.apache.org/licenses/LICENSE-2.0
- -
- - Unless required by applicable law or agreed to in writing,
- - software distributed under the License is distributed on an
- - "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- - KIND, either express or implied. See the License for the
- - specific language governing permissions and limitations
- - under the License.
- -
--->
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
- <head>
- <title>1. Introduction - Apache Qpid™</title>
- <meta http-equiv="X-UA-Compatible" content="IE=edge"/>
- <meta name="viewport" content="width=device-width, initial-scale=1.0"/>
- <link rel="stylesheet" href="/site.css" type="text/css" async="async"/>
- <link rel="stylesheet" href="/deferred.css" type="text/css" defer="defer"/>
- <script type="text/javascript">var _deferredFunctions = [];</script>
- <script type="text/javascript" src="/deferred.js" defer="defer"></script>
- <!--[if lte IE 8]>
- <link rel="stylesheet" href="/ie.css" type="text/css"/>
- <script type="text/javascript" src="/html5shiv.js"></script>
- <![endif]-->
-
- <!-- Redirects for `go get` and godoc.org -->
- <meta name="go-import"
- content="qpid.apache.org git https://git-wip-us.apache.org/repos/asf/qpid-proton.git"/>
- <meta name="go-source"
- content="qpid.apache.org
-https://github.com/apache/qpid-proton/blob/go1/README.md
-https://github.com/apache/qpid-proton/tree/go1{/dir}
-https://github.com/apache/qpid-proton/blob/go1{/dir}/{file}#L{line}"/>
- </head>
- <body>
- <div id="-content">
- <div id="-top" class="panel">
- <a id="-menu-link"><img width="16" height="16" src="" alt="Menu"/></a>
-
- <a id="-search-link"><img width="22" height="16" src="" alt="Search"/></a>
-
- <ul id="-global-navigation">
- <li><a id="-logotype" href="/index.html">Apache Qpid<sup>™</sup></a></li>
- <li><a href="/documentation.html">Documentation</a></li>
- <li><a href="/download.html">Download</a></li>
- <li><a href="/discussion.html">Discussion</a></li>
- </ul>
- </div>
-
- <div id="-menu" class="panel" style="display: none;">
- <div class="flex">
- <section>
- <h3>Project</h3>
-
- <ul>
- <li><a href="/overview.html">Overview</a></li>
- <li><a href="/components/index.html">Components</a></li>
- <li><a href="/releases/index.html">Releases</a></li>
- </ul>
- </section>
-
- <section>
- <h3>Messaging APIs</h3>
-
- <ul>
- <li><a href="/proton/index.html">Qpid Proton</a></li>
- <li><a href="/components/jms/index.html">Qpid JMS</a></li>
- <li><a href="/components/messaging-api/index.html">Qpid Messaging API</a></li>
- </ul>
- </section>
-
- <section>
- <h3>Servers and tools</h3>
-
- <ul>
- <li><a href="/components/broker-j/index.html">Broker-J</a></li>
- <li><a href="/components/cpp-broker/index.html">C++ broker</a></li>
- <li><a href="/components/dispatch-router/index.html">Dispatch router</a></li>
- </ul>
- </section>
-
- <section>
- <h3>Resources</h3>
-
- <ul>
- <li><a href="/dashboard.html">Dashboard</a></li>
- <li><a href="https://cwiki.apache.org/confluence/display/qpid/Index">Wiki</a></li>
- <li><a href="/resources.html">More resources</a></li>
- </ul>
- </section>
- </div>
- </div>
-
- <div id="-search" class="panel" style="display: none;">
- <form action="http://www.google.com/search" method="get">
- <input type="hidden" name="sitesearch" value="qpid.apache.org"/>
- <input type="text" name="q" maxlength="255" autofocus="autofocus" tabindex="1"/>
- <button type="submit">Search</button>
- <a href="/search.html">More ways to search</a>
- </form>
- </div>
-
- <div id="-middle" class="panel">
- <ul id="-path-navigation"><li><a href="/index.html">Home</a></li><li><a href="/releases/index.html">Releases</a></li><li><a href="/releases/qpid-dispatch-master/index.html">Qpid Dispatch documentation snapshot</a></li><li>1. Introduction</li></ul>
-
- <div id="-middle-content">
- <div class="sect1">
-<h2 id="introduction">1. Introduction</h2>
-<div class="sectionbody">
-<div class="sect2">
-<h3 id="overview">1.1. Overview</h3>
-<div class="paragraph"><p>The Dispatch router is an AMQP 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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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>
-<div class="sect2">
-<h3 id="benefits">1.2. Benefits</h3>
-<div class="paragraph"><p>Simplifies connectivity</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-An endpoint can do all of its messaging through a single transport
-connection
-</p>
-</li>
-<li>
-<p>
-Avoid opening holes in firewalls for incoming connections
-</p>
-</li>
-</ul></div>
-<div class="paragraph"><p>Provides messaging connectivity where there is no TCP/IP connectivity</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-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).
-</p>
-</li>
-</ul></div>
-<div class="paragraph"><p>Simplifies reliability</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-Reliability and availability are provided using redundant topology,
-not server clustering
-</p>
-</li>
-<li>
-<p>
-Reliable end-to-end messaging without persistent stores
-</p>
-</li>
-<li>
-<p>
-Use a message broker only when you need store-and-forward semantics
-</p>
-</li>
-</ul></div>
-</div>
-<div class="sect2">
-<h3 id="features">1.3. Features</h3>
-<div class="ulist"><ul>
-<li>
-<p>
-Can be deployed stand-alone or in a network of routers
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-Supports arbitrary network topology - no restrictions on redundancy
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-Automatic route computation - adjusts quickly to changes in topology
-</p>
-</li>
-</ul></div>
-</li>
-</ul></div>
-</li>
-<li>
-<p>
-Provides remote access to brokers or other AMQP servers
-</p>
-</li>
-<li>
-<p>
-Security
-</p>
-</li>
-</ul></div>
-</div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="using-qpid-dispatch">2. Using Qpid Dispatch</h2>
-<div class="sectionbody">
-<div class="sect2">
-<h3 id="configuration">2.1. Configuration</h3>
-<div class="paragraph"><p>The default configuration file is installed in
-<em>/usr/local/etc/qpid-dispatch/qdrouterd.conf</em>. 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></div>
-<div class="paragraph"><p>To run the router, invoke the executable: <code>qdrouterd [-c my-config-file]</code></p></div>
-<div class="paragraph"><p>For more details of the configuration file see the <em>qdrouterd.conf(5)</em> man
-page.</p></div>
-</div>
-<div class="sect2">
-<h3 id="tools">2.2. Tools</h3>
-<div class="sect3">
-<h4 id="qdstat">2.2.1. qdstat</h4>
-<div class="paragraph"><p><em>qdstat</em> is a command line tool that lets you view the status of a
-Dispatch Router. The following options are useful for seeing what the
-router is doing:</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="17%" />
-<col width="83%" />
-<thead>
-<tr>
-<th align="left" valign="top"><em>Option</em> </th>
-<th align="left" valign="top"><em>Description</em></th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">-l</p></td>
-<td align="left" valign="top"><p class="table">Print a list of AMQP links attached to the router. Links are
-unidirectional. Outgoing links are usually associated with a
-subscription address. The tool distinguishes between <em>endpoint</em> links
-and <em>router</em> links. Endpoint links are attached to clients using the
-router. Router links are attached to other routers in a network of
-routbers.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">-a</p></td>
-<td align="left" valign="top"><p class="table">Print a list of addresses known to the router.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">-n</p></td>
-<td align="left" valign="top"><p class="table">Print a list of known routers in the network.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">-c</p></td>
-<td align="left" valign="top"><p class="table">Print a list of connections to the router.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">--autolinks</p></td>
-<td align="left" valign="top"><p class="table">Print a list of configured auto-links.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">--linkroutes</p></td>
-<td align="left" valign="top"><p class="table">Print a list of configures link-routes.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-<div class="paragraph"><p>For complete details see the <em>qdstat(8)</em> man page and the output of
-<code>qdstat --help</code>.</p></div>
-</div>
-<div class="sect3">
-<h4 id="qdmanage">2.2.2. qdmanage</h4>
-<div class="paragraph"><p><em>qdmanage</em> is a general-purpose AMQP management client that allows you
-to not only view but modify the configuration of a running dispatch
-router.</p></div>
-<div class="paragraph"><p>For example you can query all the connection entities in the router:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdmanage query --type connection</code></pre>
-</div></div>
-<div class="paragraph"><p>To enable logging debug and higher level messages by default:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdmanage update log/DEFAULT enable=debug+</code></pre>
-</div></div>
-<div class="paragraph"><p>In fact, everything that can be configured in the configuration file can
-also be created in a running router via management. For example to
-create a new listener in a running router:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdmanage create type=listener port=5555</code></pre>
-</div></div>
-<div class="paragraph"><p>Now you can connect to port 5555, for exampple:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdmanage query -b localhost:5555 --type listener</code></pre>
-</div></div>
-<div class="paragraph"><p>For complete details see the <em>qdmanage(8)</em> man page and the output of
-<code>qdmanage --help</code>. Also for details of what can be configured see the
-<em>qdrouterd.conf(5)</em> man page.</p></div>
-</div>
-</div>
-<div class="sect2">
-<h3 id="basic-usage-and-examples">2.3. Basic Usage and Examples</h3>
-<div class="sect3">
-<h4 id="standalone-and-interior-modes">2.3.1. Standalone and Interior Modes</h4>
-<div class="paragraph"><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></div>
-<div class="paragraph"><p>If your router is running in stand-alone mode, <em>qdstat -a</em> will look
-like the following:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ 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</code></pre>
-</div></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ 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</code></pre>
-</div></div>
-</div>
-<div class="sect3">
-<h4 id="mobile-subscribers">2.3.2. Mobile Subscribers</h4>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ python ./simple_recv.py -a 127.0.0.1/my-address</code></pre>
-</div></div>
-<div class="paragraph"><p>This command creates a receiving link subscribed to the specified
-address. To verify the subscription:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ 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</code></pre>
-</div></div>
-<div class="paragraph"><p>You can then, in a separate command window, run a sender to produce
-messages to that address:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ python ./simple_send.py -a 127.0.0.1/my-address</code></pre>
-</div></div>
-</div>
-<div class="sect3">
-<h4 id="dynamic-reply-to">2.3.3. Dynamic Reply-To</h4>
-<div class="paragraph"><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>
-<div class="listingblock">
-<div class="content">
-<pre><code>#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();
-}</code></pre>
-</div></div>
-<div class="paragraph"><p>The equivalent program written in Python against the Proton Messenger
-API:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>from proton import Messenger, Message
-
-def main():
- host = "0.0.0.0:5672"
-
- messenger = Messenger()
- messenger.start()
- messenger.route("amqp:/*", "amqp://%s/$1" % host)
- reply_subscription = messenger.subscribe("amqp:/#")
- reply_address = reply_subscription.address
-
- request = Message()
- response = Message()
-
- request.address = "amqp:/_local/$management"
- request.reply_to = reply_address
- request.properties = {u'operation' : u'DISCOVER-MGMT-NODES',
- u'type' : u'org.amqp.management',
- u'name' : u'self'}
-
- messenger.put(request)
- messenger.send()
- messenger.recv()
- messenger.get(response)
-
- print "Response: %r" % response.body
-
- messenger.stop()
-
-main()</code></pre>
-</div></div>
-</div>
-</div>
-<div class="sect2">
-<h3 id="link-routing">2.4. Link Routing</h3>
-<div class="paragraph"><p>This feature was introduced in Qpid Dispatch 0.4. This feature was
-significantly updated in Qpid Dispatch 0.6.</p></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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>
-<div class="listingblock">
-<div class="content">
-<pre><code> Public Network
- +-----------------+
- | +-----+ |
- | B1 | Rp | |
- | +/--\-+ |
- | / \ |
- | / \ |
- +----/--------\---+
- / \
- / \
- / \
- Private Net A / \ Private Net B
- +--------------/--+ +---\-------------+
- | +---/-+ | | +--\--+ |
- | B2 | Ra | | | | Rb | C1 |
- | +-----+ | | +-----+ |
- | | | |
- | | | |
- +-----------------+ +-----------------+</code></pre>
-</div></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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>
-<div class="sect3">
-<h4 id="link-routing-configuration">2.4.1. Configuration</h4>
-<div class="paragraph"><p>Starting with the configured topology shown above, how is link-routing
-configured to support the example described above?</p></div>
-<div class="paragraph"><p>First, router Ra needs to be told how to make a connection to the broker
-B2:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>connector {
- name: broker
- role: route-container
- host: <B2-url>
- port: <B2-port>
- saslMechanisms: ANONYMOUS
-}</code></pre>
-</div></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><p>Now, the router must be configured to route certain addresses to B2:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>linkRoute {
- prefix: b2
- dir: in
- connection: broker
-}
-
-linkRoute {
- prefix: b2
- dir: out
- connection: broker
-}</code></pre>
-</div></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><p>Examples of addresses that "begin with <em>b2</em>" include:</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-b2
-</p>
-</li>
-<li>
-<p>
-b2.queues
-</p>
-</li>
-<li>
-<p>
-b2.queues.app1
-</p>
-</li>
-</ul></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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>
-</div>
-<div class="sect2">
-<h3 id="indirect-waypoints-and-auto-links">2.5. Indirect Waypoints and Auto-Links</h3>
-<div class="paragraph"><p>This feature was introduced in Qpid Dispatch 0.6. It is a significant
-improvement on an earlier somewhat experimental feature called
-Waypoints.</p></div>
-<div class="paragraph"><p>Auto-link is a feature of Qpid Dispatch Router that enables a router to
-actively attach a link to a node on an external AMQP container. The
-obvious application for this feature is to route messages through a
-queue on a broker, but other applications are possible as well.</p></div>
-<div class="paragraph"><p>An auto-link manages the lifecycle of one AMQP link. If messages are to
-be routed to and from a queue on a broker, then two auto-links are
-needed: one for sending messages to the queue and another for receiving
-messages from the queue. The container to which an auto-link attempts to
-attach may be identified in one of two ways:</p></div>
-<div class="quoteblock">
-<div class="content">
-<div class="ulist"><ul>
-<li>
-<p>
-The name of the connector/listener that resulted in the connection of
-the container, or
-</p>
-</li>
-<li>
-<p>
-The AMQP container-id of the remote container.
-</p>
-</li>
-</ul></div>
-</div>
-<div class="attribution">
-</div></div>
-<div class="sect3">
-<h4 id="queue-waypoint-example">2.5.1. Queue Waypoint Example</h4>
-<div class="paragraph"><p>Here is an example configuration for routing messages deliveries through
-a pair of queues on a broker:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>connector {
- name: broker
- role: route-container
- host: <hostname>
- port: <port>
- saslMechanisms: ANONYMOUS
-}
-
-address {
- prefix: queue
- waypoint: yes
-}
-
-autoLink {
- addr: queue.first
- dir: in
- connection: broker
-}
-
-autoLink {
- addr: queue.first
- dir: out
- connection: broker
-}
-
-autoLink {
- addr: queue.second
- dir: in
- connection: broker
-}
-
-autoLink {
- addr: queue.second
- dir: out
- connection: broker
-}</code></pre>
-</div></div>
-<div class="paragraph"><p>The <code>address</code> entity identifies a namespace <em>queue.</em> that will be used
-for routing messages through queues via autolinks. The four <code>autoLink</code> entities
-identify the head and tail of two queues on the broker that will be connected
-via auto-links.</p></div>
-<div class="paragraph"><p>If there is no broker connected, the auto-links shall remain
-<em>inactive</em>. This can be observed by using the <code>qdstat</code> tool:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdstat --autolinks
-AutoLinks
- addr dir phase link status lastErr
- ===================================================
- queue.first in 1 inactive
- queue.first out 0 inactive
- queue.second in 1 inactive
- queue.second out 0 inactive</code></pre>
-</div></div>
-<div class="paragraph"><p>If a broker comes online with a queue called <em>queue.first</em>, the
-auto-links will attempt to activate:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdstat --autolinks
-AutoLinks
- addr dir phase link status lastErr
- ======================================================================
- queue.first in 1 6 active
- queue.first out 0 7 active
- queue.second in 1 failed Node not found: queue.second
- queue.second out 0 failed Node not found: queue.second</code></pre>
-</div></div>
-<div class="paragraph"><p>Note that two of the auto-links are in <em>failed</em> state because the queue
-does not exist on the broker.</p></div>
-<div class="paragraph"><p>If we now use the Qpid Proton example application <code>simple_send.py</code> to send
-three messages to <em>queue.first</em> via the router:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ python simple_send.py -a 127.0.0.1/queue.first -m3
-all messages confirmed</code></pre>
-</div></div>
-<div class="paragraph"><p>and then look at the address statistics on the router:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdstat -a
-Router Addresses
- class addr phs distrib in-proc local remote cntnr in out thru to-proc from-proc
- ========================================================================================================
- mobile queue.first 1 balanced 0 0 0 0 0 0 0 0 0
- mobile queue.first 0 balanced 0 1 0 0 3 3 0 0 0</code></pre>
-</div></div>
-<div class="paragraph"><p>we see that <em>queue.first</em> appears twice in the list of addresses. The
-<code>phs</code>, or phase column shows that there are two phases for the
-address. Phase <em>0</em> is for routing message deliveries from producers to
-the tail of the queue (the <code>out</code> auto-link associated with the queue).
-Phase 1 is for routing deliveries from the head of the queue to
-subscribed consumers.</p></div>
-<div class="paragraph"><p>Note that three deliveries have been counted in the "in" and "out"
-columns for phase <em>0</em>. The "in" column represents the three messages
-that arrived from <code>simple_send.py</code> and the <code>out</code> column represents the three
-deliveries to the queue on the broker.</p></div>
-<div class="paragraph"><p>If we now use <code>simple_recv.py</code> to receive three messages from this address:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ python simple_recv.py -a 127.0.0.1:5672/queue.first -m3
-{u'sequence': int32(1)}
-{u'sequence': int32(2)}
-{u'sequence': int32(3)}</code></pre>
-</div></div>
-<div class="paragraph"><p>We receive the three queued messages. Looking at the addresses again, we
-see that phase 1 was used to deliver those messages from the queue to
-the consumer.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdstat -a
-Router Addresses
- class addr phs distrib in-proc local remote cntnr in out thru to-proc from-proc
- ========================================================================================================
- mobile queue.first 1 balanced 0 0 0 0 3 3 0 0 0
- mobile queue.first 0 balanced 0 1 0 0 3 3 0 0 0</code></pre>
-</div></div>
-<div class="paragraph"><p>Note that even in a multi-router network, and with multiple producers
-and consumers for <em>queue.first</em>, all deliveries will be routed through
-the queue on the connected broker.</p></div>
-</div>
-<div class="sect3">
-<h4 id="sharded-queue-example">2.5.2. Sharded Queue Example</h4>
-<div class="paragraph"><p>Here is an extension of the above example to illustrate how Qpid
-Dispatch Router can be used to create a distributed queue in which
-multiple brokers share the message-queueing load.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>connector {
- name: broker1
- role: route-container
- host: <hostname>
- port: <port>
- saslMechanisms: ANONYMOUS
-}
-
-connector {
- name: broker2
- role: route-container
- host: <hostname>
- port: <port>
- saslMechanisms: ANONYMOUS
-}
-
-address {
- prefix: queue
- waypoint: yes
-}
-
-autoLink {
- addr: queue.first
- dir: in
- connection: broker1
-}
-
-autoLink {
- addr: queue.first
- dir: out
- connection: broker1
-}
-
-autoLink {
- addr: queue.first
- dir: in
- connection: broker2
-}
-
-autoLink {
- addr: queue.first
- dir: out
- connection: broker2
-}</code></pre>
-</div></div>
-<div class="paragraph"><p>In the above configuration, there are two instances of <em>queue.first</em> on
-brokers 1 and 2. Message traffic from producers to address <em>queue.first</em>
-shall be balanced between the two instance and messages from the queues
-shall be balanced across the collection of subscribers to the same
-address.</p></div>
-</div>
-<div class="sect3">
-<h4 id="dynamically-adding-shards">2.5.3. Dynamically Adding Shards</h4>
-<div class="paragraph"><p>Since configurable entities in the router can also be accessed via the
-management protocol, we can remotely add a shard to the above example
-using <code>qdmanage</code>:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>qdmanage create --type org.apache.qpid.dispatch.connector host=<host> port=<port> name=broker3
-qdmanage create --type org.apache.qpid.dispatch.router.config.autoLink addr=queue.first dir=in connection=broker3
-qdmanage create --type org.apache.qpid.dispatch.router.config.autoLink addr=queue.first dir=out connection=broker3</code></pre>
-</div></div>
-</div>
-</div>
-<div class="sect2">
-<h3 id="policy">2.6. Policy</h3>
-<div class="paragraph"><p>The Policy module is an optional authorization mechanism enforcing
-user connection restrictions and AMQP resource access control.</p></div>
-<div class="paragraph"><p>Policy is assigned when a connection is created. The connection
-properties <strong>AMQP virtual host</strong>, <strong>authenticated user name</strong>, and <strong>connection
-remote host</strong> are passed to the policy engine for a connection
-allow/deny decision. If the connection is allowed then the user is
-assigned to a group that names a set of AMQP resource limits that are
-enforced for the lifetime of the connection.</p></div>
-<div class="admonitionblock">
-<table><tr>
-<td class="icon">
-<div class="title">Note</div>
-</td>
-<td class="content">
-<div class="paragraph"><p>Policy limits are applied only to incoming user network connections.
-Policy limits are not applied to interrouter connections nor are they
-applied to router connections outbound to waypoints.</p></div>
-</td>
-</tr></table>
-</div>
-<div class="sect3">
-<h4 id="_definitions">2.6.1. Definitions</h4>
-<div class="sect4">
-<h5 id="_vhost">vhost</h5>
-<div class="paragraph"><p>A <em>vhost</em> is typically the name of the host to which the client AMQP
-connection is directed. For example, suppose a client application opens
-connection URL:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>amqp://bigbroker.example.com:5672/favorite_subject</code></pre>
-</div></div>
-<div class="paragraph"><p>The client will signal virtual host name <em>bigbroker.example.com</em> to
-the router during AMQP connection startup. Router Policy intercepts
-the virtual host <em>bigbroker.example.com</em> and applies a vhost policy
-with that name to the connection.</p></div>
-</div>
-</div>
-<div class="sect3">
-<h4 id="_policy_features">2.6.2. Policy Features</h4>
-<div class="sect4">
-<h5 id="_total_connection_limit">Total Connection Limit</h5>
-<div class="paragraph"><p>A router may be configured with a total connection limit. This limit
-controls the maximum number of simultaneous incoming user connections
-that are allowed at any time. It protects the router from file
-descriptor resource exhaustion in the face of many incoming client
-connections. This limit is specified and enforced independently of
-any other Policy settings.</p></div>
-</div>
-<div class="sect4">
-<h5 id="_vhost_policy">Vhost Policy</h5>
-<div class="paragraph"><p>Vhost policy defines users and assigns them to user groups. Each
-user group defines the remote hosts from which the members may connect
-to the router network, and what resources in the router network the
-group members are allowed to access.</p></div>
-<div class="paragraph"><p>Vhost policy also defines connection count limits to control the
-number of users that may be simultaneously connected to the vhost.</p></div>
-<div class="admonitionblock">
-<table><tr>
-<td class="icon">
-<div class="title">Note</div>
-</td>
-<td class="content">
-<div class="paragraph"><p>A vhost user may be assigned to one user group only.</p></div>
-</td>
-</tr></table>
-</div>
-</div>
-<div class="sect4">
-<h5 id="_default_vhost">Default Vhost</h5>
-<div class="paragraph"><p>A default vhost may be defined. The default vhost policy is used for
-connections whose vhost is otherwise not defined in the policy database.</p></div>
-<div class="paragraph"><p><a href="#example2">Example 2</a> illustrates how the default vhost feature can
-be used to apply a single vhost policy set of restrictions to any
-number of vhost connections.</p></div>
-</div>
-</div>
-<div class="sect3">
-<h4 id="_policy_schema">2.6.3. Policy Schema</h4>
-<div class="paragraph"><p>Policy configuration is specified in two schema objects.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>policy = {
- <global settings>
-}
-
-vhost = {
- id: vhost-name
- <connection limits>
- groups: {
- group-name: {
- <user group settings>
- }
- }
-}</code></pre>
-</div></div>
-<div class="paragraph"><p>The <em>policy</em> object is a singleton. Multiple <em>vhost</em> objects may be
-created as needed.</p></div>
-<div class="sect4">
-<h5 id="_global_policy">Global Policy</h5>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="35%" />
-<col width="15%" />
-<col width="50%" />
-<thead>
-<tr>
-<th align="left" valign="top"> attribute </th>
-<th align="left" valign="top"> default </th>
-<th align="left" valign="top"> description</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">maxConnections</p></td>
-<td align="left" valign="top"><p class="table">65535</p></td>
-<td align="left" valign="top"><p class="table">Global maximum number of concurrent client connections allowed. This limit is always enforced even if no other policy settings have been defined. This limit is applied to all incoming connections regardless of remote host, authenticated user, or targeted vhost.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">enableVhostPolicy</p></td>
-<td align="left" valign="top"><p class="table">false</p></td>
-<td align="left" valign="top"><p class="table">Enable vhost policy connection denial, and resource limit enforcement.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">policyDir</p></td>
-<td align="left" valign="top"><p class="table">""</p></td>
-<td align="left" valign="top"><p class="table">Absolute path to a directory that holds vhost definition .json files. All vhost definitions in all .json files in this directory are processed.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">defaultVhost</p></td>
-<td align="left" valign="top"><p class="table">"$default"</p></td>
-<td align="left" valign="top"><p class="table">Vhost rule set name to use for connections with a vhost that is otherwise not defined. Default vhost processing may be disabled either by erasing the definition of <em>defaultVhost</em> or by not defining a <em>vhost</em> object named <em>$default</em>.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-<div class="sect4">
-<h5 id="_vhost_policy_2">Vhost Policy</h5>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="35%" />
-<col width="15%" />
-<col width="50%" />
-<thead>
-<tr>
-<th align="left" valign="top"> attribute </th>
-<th align="left" valign="top"> default </th>
-<th align="left" valign="top"> description</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">id</p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-<td align="left" valign="top"><p class="table">Vhost name must be unique.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxConnections</p></td>
-<td align="left" valign="top"><p class="table">65535</p></td>
-<td align="left" valign="top"><p class="table">Maximum number of concurrent client connections allowed.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxConnectionsPerUser</p></td>
-<td align="left" valign="top"><p class="table">65535</p></td>
-<td align="left" valign="top"><p class="table">Maximum number of concurrent client connections allowed for any user.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxConnectionsPerRemoteHost</p></td>
-<td align="left" valign="top"><p class="table">65535</p></td>
-<td align="left" valign="top"><p class="table">Maximum number of concurrent client connections allowed for any remote host.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">allowUnknownUser</p></td>
-<td align="left" valign="top"><p class="table">false</p></td>
-<td align="left" valign="top"><p class="table">Allow unknown users who are not members of a defined user group. Unknown users are assigned to the <em>$default</em> user group and receive <em>$default</em> settings.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">groups</p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-<td align="left" valign="top"><p class="table">A map where each key is a user group name and the value is a Vhost User Group Settings map.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-<div class="sect4">
-<h5 id="_vhost_user_group_settings_map">Vhost User Group Settings Map</h5>
-<div class="paragraph"><p>This object is the data value contained in entries in the policy/groups map.</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="35%" />
-<col width="15%" />
-<col width="50%" />
-<thead>
-<tr>
-<th align="left" valign="top"> Section/Attribute </th>
-<th align="left" valign="top"> default </th>
-<th align="left" valign="top"> description</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table"><strong>Group Membership</strong></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">users</p></td>
-<td align="left" valign="top"><p class="table">""</p></td>
-<td align="left" valign="top"><p class="table">List of authenticated users in this group.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><strong>Connection Restrictions</strong></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">remoteHosts</p></td>
-<td align="left" valign="top"><p class="table">""</p></td>
-<td align="left" valign="top"><p class="table">List of remote hosts from which the users may connect. List values may be host names, numeric IP addresses, numeric IP address ranges, or the wildcard <em>*</em>. An empty list denies all access.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><strong>AMQP Connection Open Limits</strong></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxFrameSize</p></td>
-<td align="left" valign="top"><p class="table">2^31-1</p></td>
-<td align="left" valign="top"><p class="table">Largest frame that may be sent on this connection. (AMQP Open, max-frame-size)</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxSessions</p></td>
-<td align="left" valign="top"><p class="table">65535</p></td>
-<td align="left" valign="top"><p class="table">Maximum number of sessions that may be created on this connection. (AMQP Open, channel-max)</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><strong>AMQP Session Begin Limits</strong></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxSessionWindow</p></td>
-<td align="left" valign="top"><p class="table">2^31-1</p></td>
-<td align="left" valign="top"><p class="table">Incoming capacity for new sessions. (AMQP Begin, incoming-window)</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><strong>AMQP Link Attach</strong></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxMessageSize</p></td>
-<td align="left" valign="top"><p class="table">0</p></td>
-<td align="left" valign="top"><p class="table">Largest message size supported by links created on this connection. If this field is zero there is no maximum size imposed by the link endpoint. (AMQP Attach, max-message-size)</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxSenders</p></td>
-<td align="left" valign="top"><p class="table">2^31-1</p></td>
-<td align="left" valign="top"><p class="table">Maximum number of sending links that may be created on this connection.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxReceivers</p></td>
-<td align="left" valign="top"><p class="table">2^31-1</p></td>
-<td align="left" valign="top"><p class="table">Maximum number of receiving links that may be created on this connection.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">allowDynamicSource</p></td>
-<td align="left" valign="top"><p class="table">false</p></td>
-<td align="left" valign="top"><p class="table">This connection is allowed to create receiving links using the Dynamic Link Source feature.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">allowAnonymousSender</p></td>
-<td align="left" valign="top"><p class="table">false</p></td>
-<td align="left" valign="top"><p class="table">This connection is allowed to create sending links using the Anonymous Sender feature.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">sources</p></td>
-<td align="left" valign="top"><p class="table">""</p></td>
-<td align="left" valign="top"><p class="table">List of Source addresses allowed when creating receiving links. This list may be expressed as a CSV string or as a list of strings. An empty list denies all access.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">targets</p></td>
-<td align="left" valign="top"><p class="table">""</p></td>
-<td align="left" valign="top"><p class="table">List of Target addresses allowed when creating sending links. This list may be expressed as a CSV string or as a list of strings. An empty list denies all access.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-</div>
-<div class="sect3">
-<h4 id="_policy_wildcard_and_user_name_substitution">2.6.4. Policy Wildcard and User Name Substitution</h4>
-<div class="paragraph"><p>Policy provides several conventions to make writing rules easier.</p></div>
-<div class="sect4">
-<h5 id="_remote_host_wildcard">Remote Host Wildcard</h5>
-<div class="paragraph"><p>Remote host rules may consist of a single asterisk character to
-specify all hosts.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code> remoteHosts: *</code></pre>
-</div></div>
-<div class="paragraph"><p>The asterisk must stand alone and cannot be appended to a host name
-or to an IP address fragment.</p></div>
-</div>
-<div class="sect4">
-<h5 id="_amqp_source_and_target_wildcard_and_name_substitution">AMQP Source and Target Wildcard and Name Substitution</h5>
-<div class="paragraph"><p>The rule definitions for <code>sources</code> and <code>targets</code> may include the username
-substitution token</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code> {user}</code></pre>
-</div></div>
-<div class="paragraph"><p>or a trailing asterisk.</p></div>
-<div class="paragraph"><p>The username substitution token is replaced with the authenticated user name for
-the connection. Using this token, an administrator may allow access to
-some resources specific to each user without having to name each user
-individually. This token is substituted once for the leftmost
-occurrence in the link name.</p></div>
-<div class="paragraph"><p>The asterisk is recognized only if it is the last character in the
-link name.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code> sources: tmp_{user}, temp*, {user}-home-*</code></pre>
-</div></div>
-</div>
-</div>
-<div class="sect3">
-<h4 id="_composing_policies">2.6.5. Composing Policies</h4>
-<div class="paragraph"><p>This section shows policy examples designed to illustrate some common use cases.</p></div>
-<div class="sect4">
-<h5 id="_example_1_user_policy_disabled">Example 1. User Policy Disabled</h5>
-<div class="paragraph"><p>Policy is disabled when no policy configuation objects are defined.
-Any number of connections are allowed and all users have
-access to all AMQP resources in the network.</p></div>
-</div>
-<div class="sect4">
-<h5 id="example2">Example 2. All Users Have Simple Connection Limits</h5>
-<div class="paragraph"><p>This example shows how to keep users from overwhelming the router with
-connections. Any user can create up to ten connections and the router
-will limit the aggregated user connection count to 100 connections
-total. No other restrictions apply.</p></div>
-<div class="paragraph"><p>This example also shows how to use a default vhost policy effectively.
-Only one vhost policy is defined and all user connections regardless
-of the requested vhost use that policy.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>policy {
- maxConnections: 100 <b><1></b>
-}
-
-vhost {
- name: $default <b><2></b>
- maxConnectionsPerUser: 10 <b><3></b>
- allowUnknownUser: true <b><4></b>
- groups: {
- $default: {
- remoteHosts: * <b><5></b>
- sources: * <b><6></b>
- targets: * <b><6></b>
- }
- }
-}</code></pre>
-</div></div>
-<div class="colist arabic"><ol>
-<li>
-<p>
-The global maxConnections limit of 100 is enforced.
-</p>
-</li>
-<li>
-<p>
-No normal vhost names are defined; user is assigned to default vhost <em>$default</em>.
-</p>
-</li>
-<li>
-<p>
-The vhost maxConnectionsPerUser limit of 10 is enforced.
-</p>
-</li>
-<li>
-<p>
-No groups are defined to have any users but allowUnknownUser is true so all users are assigned to group $default.
-</p>
-</li>
-<li>
-<p>
-The user is allowed to connect from any remote host.
-</p>
-</li>
-<li>
-<p>
-The user is allowed to connect to any source or target in the AMQP network. Router system-wide values are used for the other AMQP settings that are unspecified in the vhost rules.
-</p>
-</li>
-</ol></div>
-</div>
-<div class="sect4">
-<h5 id="_example_3_admins_must_connect_from_localhost">Example 3. Admins Must Connect From Localhost</h5>
-<div class="paragraph"><p>This example shows how an admin group may be created and restricted
-to accessing a vhost only from localhost. The admin users are allowed
-to connect to any AMQP resources while normal users are restricted.</p></div>
-<div class="paragraph"><p>In this example a user connects to vhost <em>example.com</em>.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>vhost {
- name: example.com <b><1></b>
- allowUnknownUser: true <b><3></b>
- groups: {
- admin: {
- users: alice, bob <b><2></b>
- remoteHosts: 127.0.0.1, ::1 <b><4></b>
- sources: * <b><5></b>
- targets: * <b><5></b>
- },
- $default: {
- remoteHosts: * <b><6></b>
- sources: news*, sports*, chat* <b><7></b>
- targets: chat* <b><7></b>
- }
- }
-}</code></pre>
-</div></div>
-<div class="colist arabic"><ol>
-<li>
-<p>
-A connection to vhost <em>example.com</em> locates this vhost rule set.
-</p>
-</li>
-<li>
-<p>
-If one of users <em>alice</em> or <em>bob</em> is connecting then she or he is assigned to the <em>admin</em> user group.
-</p>
-</li>
-<li>
-<p>
-Any other user is not defined by a user group. However, since the <em>allowUnknownUser</em> setting is true then this user is assigned to the <em>$default</em> user group.
-</p>
-</li>
-<li>
-<p>
-Users in the <em>admin</em> user group must connect from localhost. Connections for an <em>admin</em> user from other hosts on the network are denied.
-</p>
-</li>
-<li>
-<p>
-Users in the <em>admin</em> user group are allowed to access any resource offered by the vhost service.
-</p>
-</li>
-<li>
-<p>
-Other users are allowed to connect from any host.
-</p>
-</li>
-<li>
-<p>
-Other users have source and target name lists that restrict the resources they are allowed to access.
-</p>
-</li>
-</ol></div>
-</div>
-<div class="sect4">
-<h5 id="_example_4_limiting_possible_memory_consumption">Example 4. Limiting Possible Memory Consumption</h5>
-<div class="paragraph"><p>Policy provides a mechanism to control how much system buffer memory a
-user connection can potentially consume. The formula for computing
-buffer memory consumption for each session is</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code> potential buffer usage = maxFrameSize * maxSessionWindow</code></pre>
-</div></div>
-<div class="paragraph"><p>By adjusting <em>maxFrameSize</em>, <em>maxSessions</em>, and <em>maxSessionWindow</em> an
-administrator can prevent a user from consuming too much memory by
-buffering messages in flight.</p></div>
-<div class="admonitionblock">
-<table><tr>
-<td class="icon">
-<div class="title">Note</div>
-</td>
-<td class="content">
-<div class="paragraph"><p>The settings passed into the AMQP protocol connection and session
-negotiations. Normal AMQP session flow control limits buffer
-consumption in due course with no processing cycles required by the
-router.</p></div>
-</td>
-</tr></table>
-</div>
-<div class="paragraph"><p>In this example normal users, the traders, are given smaller buffer
-allocations while high-capacity, automated data feeds are given a
-higher buffer allocation. This example skips the details of settings
-unrelated to buffer allocation.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>vhost {
- name: traders.com <b><1></b>
- groups: {
- traders: {
- users: trader-1, trader-2, ... <b><2></b>
- maxFrameSize: 10000 <b><3></b>
- maxSessionWindow: 500 <b><3></b>
- maxSessions: 1 <b><4></b>
- ...
- },
- feeds: {
- users: nyse-feed, nasdaq-feed <b><5></b>
- maxFrameSize: 60000 <b><6></b>
- maxSessionWindow: 20000 <b><6></b>
- maxSessions: 3 <b><7></b>
- ...
- }
- }
-}</code></pre>
-</div></div>
-<div class="colist arabic"><ol>
-<li>
-<p>
-These rules are for vhost traders.com.
-</p>
-</li>
-<li>
-<p>
-The <em>traders</em> group includes trader-1, trader-2, and any other user defined in the list.
-</p>
-</li>
-<li>
-<p>
-<em>maxFrameSize</em> and <em>maxSessionWindow</em> allow for at most 5,000,000 bytes of data to be in flight on each session.
-</p>
-</li>
-<li>
-<p>
-Only one session per connection is allowed.
-</p>
-</li>
-<li>
-<p>
-In the <em>feeds</em> group two users are defined.
-</p>
-</li>
-<li>
-<p>
-<em>maxFrameSize</em> and <em>maxSessionWindow</em> allow for at most 1,200,000,000 bytes of data to be in flight on each session.
-</p>
-</li>
-<li>
-<p>
-Up to three sessions per connection are allowed.
-</p>
-</li>
-</ol></div>
-</div>
-</div>
-</div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="technical-details-and-specifications">3. Technical Details and Specifications</h2>
-<div class="sectionbody">
-<div class="sect2">
-<h3 id="client-compatibility">3.1. Client Compatibility</h3>
-<div class="paragraph"><p>Dispatch Router should, in theory, work with any client that is
-compatible with AMQP 1.0. The following clients have been tested:</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="22%" />
-<col width="78%" />
-<thead>
-<tr>
-<th align="left" valign="top"><em>Client</em> </th>
-<th align="left" valign="top"><em>Notes</em></th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">qpid::messaging</p></td>
-<td align="left" valign="top"><p class="table">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.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">Proton Reactor</p></td>
-<td align="left" valign="top"><p class="table">The Proton Reactor API is compatible with Dispatch
-Router.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">Proton Messenger</p></td>
-<td align="left" valign="top"><p class="table">Messenger works with Dispatch Router.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-<div class="sect2">
-<h3 id="addressing">3.2. Addressing</h3>
-<div class="paragraph"><p>AMQP addresses are used to control the flow of messages across a network
-of routers. Addresses are used in a number of different places in the
-AMQP 1.0 protocol. They can be used in a specific message in the <code>to</code>
-and <code>reply-to</code> fields of a message’s properties. They are also used
-during the creation of links in the <code>address</code> field of a <code>source</code> or
-a <code>target</code>.</p></div>
-<div class="paragraph"><p>Addresses designate various kinds of entities in a messaging network:</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-Endpoint processes that consume data or offer a service
-</p>
-</li>
-<li>
-<p>
-Topics that match multiple consumers to multiple producers
-</p>
-</li>
-<li>
-<p>
-Entities within a messaging broker:
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-Queues
-</p>
-</li>
-<li>
-<p>
-Durable Topics
-</p>
-</li>
-<li>
-<p>
-Exchanges
-</p>
-</li>
-</ul></div>
-</li>
-</ul></div>
-<div class="paragraph"><p>The syntax of an AMQP address is opaque as far as the router network is
-concerned. A syntactical structure may be used by the administrator that
-creates addresses, but the router treats them as opaque strings. Routers
-consider addresses to be mobile such that any address may be directly
-connected to any router in a network and may move around the topology.
-In cases where messages are broadcast to or balanced across multiple
-consumers, an address may be connected to multiple routers in the
-network.</p></div>
-<div class="paragraph"><p>Addresses have semantics associated with them. When an address is
-created in the network, it is assigned a set of semantics (and access
-rules) during a process called provisioning. The semantics of an address
-control how routers behave when they see the address being used.</p></div>
-<div class="paragraph"><p>Address semantics include the following considerations:</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-<em>Routing pattern</em> - direct, multicast, balanced
-</p>
-</li>
-<li>
-<p>
-<em>Undeliverable action</em> - drop, hold and retry, redirect
-</p>
-</li>
-<li>
-<p>
-<em>Reliability</em> - N destinations, etc.
-</p>
-</li>
-</ul></div>
-<div class="sect3">
-<h4 id="routing-patterns">3.2.1. Routing patterns</h4>
-<div class="paragraph"><p>Routing patterns constrain the paths that a message can take across a
-network.</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="18%" />
-<col width="82%" />
-<thead>
-<tr>
-<th align="left" valign="top"><em>Pattern</em> </th>
-<th align="left" valign="top"><em>Description</em></th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table"><em>Direct</em></p></td>
-<td align="left" valign="top"><p class="table">Direct routing allows for only one consumer to use an address
-at a time. Messages (or links) follow the lowest cost path across the
-network from the sender to the one receiver.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><em>Multicast</em></p></td>
-<td align="left" valign="top"><p class="table">Multicast routing allows multiple consumers to use the
-same address at the same time. Messages are routed such that each
-consumer receives a copy of the message.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><em>Balanced</em></p></td>
-<td align="left" valign="top"><p class="table">Balanced routing also allows multiple consumers to use the
-same address. In this case, messages are routed to exactly one of the
-consumers, and the network attempts to balance the traffic load across
-the set of consumers using the same address.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-<div class="sect3">
-<h4 id="routing-mechanisms">3.2.2. Routing mechanisms</h4>
-<div class="paragraph"><p>The fact that addresses can be used in different ways suggests that
-message routing can be accomplished in different ways. Before going into
-the specifics of the different routing mechanisms, it would be good to
-first define what is meant by the term <em>routing</em>:</p></div>
-<div class="quoteblock">
-<div class="content">
-<div class="paragraph"><p>In a network built of multiple routers connected by connections (i.e.,
-nodes and edges in a graph), <em>routing</em> determines which connection to
-use to send a message directly to its destination or one step closer to
-its destination.</p></div>
-</div>
-<div class="attribution">
-</div></div>
-<div class="paragraph"><p>Each router serves as the terminus of a collection of incoming and
-outgoing links. The links either connect directly to endpoints that
-produce and consume messages, or they connect to other routers in the
-network along previously established connections.</p></div>
-<div class="sect4">
-<h5 id="message-routing">Message routing</h5>
-<div class="paragraph"><p>Message routing occurs upon delivery of a message and is done based on
-the address in the message’s <code>to</code> field.</p></div>
-<div class="paragraph"><p>When a delivery arrives on an incoming link, the router extracts the
-address from the delivered message’s <code>to</code> field and looks the address up
-in its routing table. The lookup results in zero or more outgoing links
-onto which the message shall be resent.</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="20%" />
-<col width="80%" />
-<thead>
-<tr>
-<th align="left" valign="top"><em>Delivery</em> </th>
-<th align="left" valign="top"><em>Handling</em></th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table"><em>pre-settled</em></p></td>
-<td align="left" valign="top"><p class="table">If the arriving delivery is pre-settled (i.e., fire and
-forget), the incoming delivery shall be settled by the router, and the
-outgoing deliveries shall also be pre-settled. In other words, the
-pre-settled nature of the message delivery is propagated across the
-network to the message’s destination.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><em>unsettled</em></p></td>
-<td align="left" valign="top"><p class="table">Unsettled delivery is also propagated across the network.
-Because unsettled delivery records cannot be discarded, the router
-tracks the incoming deliveries and keeps the association of the incoming
-deliveries to the resulting outgoing deliveries. This kept association
-allows the router to continue to propagate changes in delivery state
-(settlement and disposition) back and forth along the path which the
-message traveled.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-</div>
-</div>
-<div class="sect2">
-<h3 id="amqp-mapping">3.3. AMQP Mapping</h3>
-<div class="paragraph"><p>Dispatch Router is an AMQP router and as such, it provides extensions,
-code-points, and semantics for routing over AMQP. This page documents the
-details of Dispatch Router’s use of AMQP.</p></div>
-<div class="sect3">
-<h4 id="message-annotations">3.3.1. Message Annotations</h4>
-<div class="paragraph"><p>The following Message Annotation fields are defined by Dispatch Router:</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="23%" />
-<col width="19%" />
-<col width="58%" />
-<thead>
-<tr>
-<th align="left" valign="top"><em>Field</em> </th>
-<th align="left" valign="top"><em>Type</em> </th>
-<th align="left" valign="top"><em>Description</em></th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">x-opt-qd.ingress</p></td>
-<td align="left" valign="top"><p class="table">string</p></td>
-<td align="left" valign="top"><p class="table">The identity of the ingress router for a
-message-routed message. The ingress router is the first router
-encountered by a transiting message. The router will, if this field is
-present, leave it unaltered. If the field is not present, the router
-shall insert the field with its own identity.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">x-opt-qd.trace</p></td>
-<td align="left" valign="top"><p class="table">list of string</p></td>
-<td align="left" valign="top"><p class="table">The list of routers through which this
-message-routed message has transited. If this field is not present, the
-router shall do nothing. If the field is present, the router shall
-append its own identity to the end of the list.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">x-opt-qd.to</p></td>
-<td align="left" valign="top"><p class="table">string</p></td>
-<td align="left" valign="top"><p class="table">To-Override for message-routed messages. If this
-field is present, the address in this field shall be used for routing in
-lieu of the <em>to</em> field in the message properties. A router may append,
-remove, or modify this annotation field depending on the policy in place
-for routing the message.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">x-opt-qd.phase</p></td>
-<td align="left" valign="top"><p class="table">integer</p></td>
-<td align="left" valign="top"><p class="table">The address-phase, if not zero, for messages
-flowing between routers.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-<div class="sect3">
-<h4 id="sourcetarget-capabilities">3.3.2. Source/Target Capabilities</h4>
-<div class="paragraph"><p>The following Capability values are used in Sources and Targets.</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="19%" />
-<col width="81%" />
-<thead>
-<tr>
-<th align="left" valign="top"><em>Capability</em> </th>
-<th align="left" valign="top"><em>Description</em></th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">qd.router</p></td>
-<td align="left" valign="top"><p class="table">This capability is added to sources and targets that are
-used for inter-router message exchange. This capability denotes a link
-used for router-control messages flowing between routers.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">qd.router-data</p></td>
-<td align="left" valign="top"><p class="table">This capability is added to sources and targets that
-are used for inter-router message exchange. This capability denotes a
-link used for user messages being message-routed across an inter-router
-connection.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-<div class="sect3">
-<h4 id="dynamic-node-properties">3.3.3. Dynamic-Node-Properties</h4>
-<div class="paragraph"><p>The following dynamic-node-properties are used by Dispatch in Sources.</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="23%" />
-<col width="77%" />
-<thead>
-<tr>
-<th align="left" valign="top"><em>Property</em> </th>
-<th align="left" valign="top"><em>Description</em></th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">x-opt-qd.address</p></td>
-<td align="left" valign="top"><p class="table">The node address describing the destination desired
-for a dynamic source. If this is absent, the router will terminate any
-dynamic receivers. If this address is present, the router will use the
-address to route the dynamic link attach to the proper destination
-container.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-<div class="sect3">
-<h4 id="addresses-and-address-formats">3.3.4. Addresses and Address Formats</h4>
-<div class="paragraph"><p>The following AMQP addresses and address patterns are used within
-Dispatch Router.</p></div>
-<div class="sect4">
-<h5 id="address-patterns">Address Patterns</h5>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="38%" />
-<col width="62%" />
-<thead>
-<tr>
-<th align="left" valign="top"><em>Pattern</em> </th>
-<th align="left" valign="top"><em>Description</em></th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table"><code>_local/<addr></code></p></td>
-<td align="left" valign="top"><p class="table">An address that references a locally attached endpoint.
-Messages using this address pattern shall not be routed over more than
-one link.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><code>_topo/0/<router>/<addr></code></p></td>
-<td align="left" valign="top"><p class="table">An address that references an endpoint attached to a specific router
-node in the network topology. Messages with addresses that follow this
-pattern shall be routed along the shortest path to the specified router.
-Note that addresses of this form are a-priori routable in that the
-address itself contains enough information to route the message to its
-destination.</p>
-<p class="table">The <em>0</em> component immediately preceding the router-id is a placeholder
-for an <em>area</em> which may be used in the future if area routing is
-implemented.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><code><addr></code></p></td>
-<td align="left" valign="top"><p class="table">A mobile address. An address of this format represents an
-endpoint or a set of distinct endpoints that are attached to the network
-in arbitrary locations. It is the responsibility of the router network
-to determine which router nodes are valid destinations for mobile
-addresses.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-<div class="sect4">
-<h5 id="supported-addresses">Supported Addresses</h5>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="36%" />
-<col width="64%" />
-<thead>
-<tr>
-<th align="left" valign="top"><em>Address</em> </th>
-<th align="left" valign="top"><em>Description</em></th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table"><code>$management</code></p></td>
-<td align="left" valign="top"><p class="table">The management agent on the attached router/container.
-This address would be used by an endpoint that is a management
-client/console/tool wishing to access management data from the attached
-container.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><code>_topo/0/Router.E/$management</code></p></td>
-<td align="left" valign="top"><p class="table">The management agent at Router.E in area
-0. This address would be used by a management client wishing to access
-management data from a specific container that is reachable within the
-network.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><code>_local/qdhello</code></p></td>
-<td align="left" valign="top"><p class="table">The router entity in each of the connected routers.
-This address is used to communicate with neighbor routers and is
-exclusively for the HELLO discovery protocol.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><code>_local/qdrouter</code></p></td>
-<td align="left" valign="top"><p class="table">The router entity in each of the connected routers.
-This address is used by a router to communicate with other routers in
-the network.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><code>_topo/0/Router.E/qdrouter</code></p></td>
-<td align="left" valign="top"><p class="table">The router entity at the specifically
-indicated router. This address form is used by a router to communicate
-with a specific router that may or may not be a neighbor.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-</div>
-<div class="sect3">
-<h4 id="implementation-of-the-amqp-management-specification">3.3.5. Implementation of the AMQP Management Specification</h4>
-<div class="paragraph"><p>Qpid Dispatch is manageable remotely via AMQP. It is compliant with the
-emerging AMQP Management specification (draft 9).</p></div>
-<div class="paragraph"><p>Differences from the specification:</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-The <code>name</code> attribute is not required when an entity is created. If
- not supplied it will be set to the same value as the system-generated
- "identity" attribute. Otherwise it is treated as per the standard.
-</p>
-</li>
-<li>
-<p>
-The <code>REGISTER</code> and <code>DEREGISTER</code> operations are not implemented. The router
- automatically discovers peer routers via the router network and makes
- their management addresses available via the standard <code>GET-MGMT-NODES</code>
- operation.
-= Management Schema
-</p>
-</li>
-</ul></div>
-<div class="paragraph"><p>This chapter documents the set of <strong>management entity types</strong> that define
-configuration and management of a Dispatch Router. A management entity type has
-a set of <strong>attributes</strong> that can be read, some attributes can also be
-updated. Some entity types also support <strong>operations</strong> that can be called.</p></div>
-<div class="paragraph"><p>All management entity types have the following standard attributes:</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-type
-</dt>
-<dd>
-<p>
- The fully qualified type of the entity,
- e.g. <code>org.apache.qpid.dispatch.router</code>. This document uses the short name
- without the <code>org.apache.qpid.dispatch</code> prefix e.g. <code>router</code>. The dispatch
- tools will accept the short or long name.
-</p>
-</dd>
-<dt class="hdlist1">
-name
-</dt>
-<dd>
-<p>
- A user-generated identity for the entity. This can be used in other entities
- that need to refer to the named entity.
-</p>
-</dd>
-<dt class="hdlist1">
-identity
-</dt>
-<dd>
-<p>
- A system-generated identity of the entity. It includes
- the short type name and some identifying information. E.g. <code>log/AGENT</code> or
- <code>listener/localhost:amqp</code>
-</p>
-</dd>
-</dl></div>
-<div class="paragraph"><p>There are two main categories of management entity type.</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-Configuration Entities
-</dt>
-<dd>
-<p>
- Parameters that can be set in the configuration file
- (see <code>qdrouterd.conf(5)</code> man page) or set at run-time with the <code>qdmanage(8)</code>
- tool.
-</p>
-</dd>
-<dt class="hdlist1">
-Operational Entities
-</dt>
-<dd>
-<p>
- Run-time status values that can be queried using <code>qdstat(8)</code> or <code>qdmanage(8)</code> tools.
-</p>
-</dd>
-</dl></div>
-</div>
-</div>
-<div class="sect2">
-<h3 id="_configuration_entities">3.4. Configuration Entities</h3>
-<div class="paragraph"><p>Configuration entities define the attributes allowed in the configuration file
-(see <code>qdrouterd.conf(5)</code>) but you can also create entities once the router is
-running using the <code>qdrouterd(8)</code> tool’s <code>create</code> operation. Some entities can also
-be modified using the <code>update</code> operation, see the entity descriptions below.</p></div>
-<div class="sect3">
-<h4 id="_router">3.4.1. router</h4>
-<div class="paragraph"><p>Tracks peer routers and computes routes to destinations.</p></div>
-<div class="paragraph"><p>Operations allowed: <code>READ</code></p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>id</em> (string, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- Router’s unique identity. One of id or routerId is required. The router will fail to start without id or routerId
-</p>
-</dd>
-<dt class="hdlist1">
-<em>mode</em> (One of [<em>standalone</em>, <em>interior</em>], default=<em>standalone</em>, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- In standalone mode, the router operates as a single component. It does not participate in the routing protocol and therefore will not cooperate with other routers. In interior mode, the router operates in cooperation with other interior routers in an interconnected network.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>area</em> (string)
-</dt>
-<dd>
-<p>
- Unused placeholder.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>helloInterval</em> (integer, default=1, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- Interval in seconds between HELLO messages sent to neighbor routers.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>helloMaxAge</em> (integer, default=3, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- Time in seconds after which a neighbor is declared lost if no HELLO is received.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>raInterval</em> (integer, default=30, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- Interval in seconds between Router-Advertisements sent to all routers in a stable network.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>raIntervalFlux</em> (integer, default=4, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- Interval in seconds between Router-Advertisements sent to all routers during topology fluctuations.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>remoteLsMaxAge</em> (integer, default=60, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- Time in seconds after which link state is declared stale if no RA is received.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>addrCount</em> (integer)
-</dt>
-<dd>
-<p>
- Number of addresses known to the router.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>linkCount</em> (integer)
-</dt>
-<dd>
-<p>
- Number of links attached to the router node.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>nodeCount</em> (integer)
-</dt>
-<dd>
-<p>
- Number of known peer router nodes.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>workerThreads</em> (integer, default=4, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- The number of threads that will be created to process message traffic and other application work (timers, non-amqp file descriptors, etc.) .
-</p>
-</dd>
-<dt class="hdlist1">
-<em>debugDump</em> (path, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- A file to dump debugging information that can’t be logged normally.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>saslC
<TRUNCATED>
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/book.pdf
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/book.pdf b/content/releases/qpid-dispatch-master/book.pdf
deleted file mode 100755
index 90fc389..0000000
Binary files a/content/releases/qpid-dispatch-master/book.pdf and /dev/null differ
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org
[08/13] qpid-site git commit: QPID-8015: Prepare the dispatch release
scripts for the new user guide
Posted by jr...@apache.org.
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/user-guide/index.html
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/user-guide/index.html b/content/releases/qpid-dispatch-master/user-guide/index.html
new file mode 100644
index 0000000..5c0ef36
--- /dev/null
+++ b/content/releases/qpid-dispatch-master/user-guide/index.html
@@ -0,0 +1,7969 @@
+<!DOCTYPE html>
+<!--
+ -
+ - Licensed to the Apache Software Foundation (ASF) under one
+ - or more contributor license agreements. See the NOTICE file
+ - distributed with this work for additional information
+ - regarding copyright ownership. The ASF licenses this file
+ - to you under the Apache License, Version 2.0 (the
+ - "License"); you may not use this file except in compliance
+ - with the License. You may obtain a copy of the License at
+ -
+ - http://www.apache.org/licenses/LICENSE-2.0
+ -
+ - Unless required by applicable law or agreed to in writing,
+ - software distributed under the License is distributed on an
+ - "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ - KIND, either express or implied. See the License for the
+ - specific language governing permissions and limitations
+ - under the License.
+ -
+-->
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
+ <head>
+ <title>Using Qpid Dispatch - Apache Qpid™</title>
+ <meta http-equiv="X-UA-Compatible" content="IE=edge"/>
+ <meta name="viewport" content="width=device-width, initial-scale=1.0"/>
+ <link rel="stylesheet" href="/site.css" type="text/css" async="async"/>
+ <link rel="stylesheet" href="/deferred.css" type="text/css" defer="defer"/>
+ <script type="text/javascript">var _deferredFunctions = [];</script>
+ <script type="text/javascript" src="/deferred.js" defer="defer"></script>
+ <!--[if lte IE 8]>
+ <link rel="stylesheet" href="/ie.css" type="text/css"/>
+ <script type="text/javascript" src="/html5shiv.js"></script>
+ <![endif]-->
+
+ <!-- Redirects for `go get` and godoc.org -->
+ <meta name="go-import"
+ content="qpid.apache.org git https://git-wip-us.apache.org/repos/asf/qpid-proton.git"/>
+ <meta name="go-source"
+ content="qpid.apache.org
+https://github.com/apache/qpid-proton/blob/go1/README.md
+https://github.com/apache/qpid-proton/tree/go1{/dir}
+https://github.com/apache/qpid-proton/blob/go1{/dir}/{file}#L{line}"/>
+ </head>
+ <body>
+ <div id="-content">
+ <div id="-top" class="panel">
+ <a id="-menu-link"><img width="16" height="16" src="" alt="Menu"/></a>
+
+ <a id="-search-link"><img width="22" height="16" src="" alt="Search"/></a>
+
+ <ul id="-global-navigation">
+ <li><a id="-logotype" href="/index.html">Apache Qpid<sup>™</sup></a></li>
+ <li><a href="/documentation.html">Documentation</a></li>
+ <li><a href="/download.html">Download</a></li>
+ <li><a href="/discussion.html">Discussion</a></li>
+ </ul>
+ </div>
+
+ <div id="-menu" class="panel" style="display: none;">
+ <div class="flex">
+ <section>
+ <h3>Project</h3>
+
+ <ul>
+ <li><a href="/overview.html">Overview</a></li>
+ <li><a href="/components/index.html">Components</a></li>
+ <li><a href="/releases/index.html">Releases</a></li>
+ </ul>
+ </section>
+
+ <section>
+ <h3>Messaging APIs</h3>
+
+ <ul>
+ <li><a href="/proton/index.html">Qpid Proton</a></li>
+ <li><a href="/components/jms/index.html">Qpid JMS</a></li>
+ <li><a href="/components/messaging-api/index.html">Qpid Messaging API</a></li>
+ </ul>
+ </section>
+
+ <section>
+ <h3>Servers and tools</h3>
+
+ <ul>
+ <li><a href="/components/broker-j/index.html">Broker-J</a></li>
+ <li><a href="/components/cpp-broker/index.html">C++ broker</a></li>
+ <li><a href="/components/dispatch-router/index.html">Dispatch router</a></li>
+ </ul>
+ </section>
+
+ <section>
+ <h3>Resources</h3>
+
+ <ul>
+ <li><a href="/dashboard.html">Dashboard</a></li>
+ <li><a href="https://cwiki.apache.org/confluence/display/qpid/Index">Wiki</a></li>
+ <li><a href="/resources.html">More resources</a></li>
+ </ul>
+ </section>
+ </div>
+ </div>
+
+ <div id="-search" class="panel" style="display: none;">
+ <form action="http://www.google.com/search" method="get">
+ <input type="hidden" name="sitesearch" value="qpid.apache.org"/>
+ <input type="text" name="q" maxlength="255" autofocus="autofocus" tabindex="1"/>
+ <button type="submit">Search</button>
+ <a href="/search.html">More ways to search</a>
+ </form>
+ </div>
+
+ <div id="-middle" class="panel">
+ <ul id="-path-navigation"><li><a href="/index.html">Home</a></li><li><a href="/releases/index.html">Releases</a></li><li><a href="/releases/qpid-dispatch-master/index.html">Qpid Dispatch documentation snapshot</a></li><li>Using Qpid Dispatch</li></ul>
+
+ <div id="-middle-content">
+ <h1>Using Qpid Dispatch</h1>
+<div id="toc" class="toc">
+<div id="toctitle">Table of Contents</div>
+<ul class="sectlevel1">
+<li><a href="#introduction">1. Introduction</a>
+<ul class="sectlevel2">
+<li><a href="#overview">1.1. Overview</a></li>
+<li><a href="#benefits">1.2. Benefits</a></li>
+<li><a href="#features">1.3. Features</a></li>
+</ul>
+</li>
+<li><a href="#theory_of_operation">2. Theory of Operation</a>
+<ul class="sectlevel2">
+<li><a href="#overview_2">2.1. Overview</a></li>
+<li><a href="#connections">2.2. Connections</a>
+<ul class="sectlevel3">
+<li><a href="#listener">2.2.1. Listener</a></li>
+<li><a href="#connector">2.2.2. Connector</a></li>
+</ul>
+</li>
+<li><a href="#addresses">2.3. Addresses</a>
+<ul class="sectlevel3">
+<li><a href="#mobile_addresses">2.3.1. Mobile Addresses</a></li>
+<li><a href="#link_route_addresses">2.3.2. Link Route Addresses</a></li>
+</ul>
+</li>
+<li><a href="#message_routing">2.4. Message Routing</a>
+<ul class="sectlevel3">
+<li><a href="#routing_patterns">2.4.1. Routing Patterns</a></li>
+<li><a href="#routing_mechanisms">2.4.2. Routing Mechanisms</a></li>
+<li><a href="#message_settlement">2.4.3. Message Settlement</a></li>
+</ul>
+</li>
+<li><a href="#security">2.5. Security</a></li>
+</ul>
+</li>
+<li><a href="#getting_started">3. Getting Started</a>
+<ul class="sectlevel2">
+<li><a href="#starting_the_router">3.1. Starting the Router</a></li>
+<li><a href="#routing_messages_in_a_peer_to_peer_configuration">3.2. Routing Messages in a Peer-to-Peer Configuration</a>
+<ul class="sectlevel3">
+<li><a href="#starting_the_receiver_client">3.2.1. Starting the Receiver Client</a></li>
+<li><a href="#sending_messages">3.2.2. Sending Messages</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a href="#router_configuration">4. Configuration</a>
+<ul class="sectlevel2">
+<li><a href="#accessing_the_router_configuration_file">4.1. Accessing the Router Configuration File</a></li>
+<li><a href="#how_the_router_configuration_file_is_structured">4.2. How the Router Configuration File is Structured</a></li>
+<li><a href="#methods_for_changing_router_configuration">4.3. Changing a Router’s Configuration</a>
+<ul class="sectlevel3">
+<li><a href="#making_permanent_change_to_router_configuration">4.3.1. Making a Permanent Change to the Router’s Configuration</a></li>
+<li><a href="#changing_configuration_for_running_router">4.3.2. Changing the Configuration for a Running Router</a></li>
+</ul>
+</li>
+<li><a href="#default_configuration_settings">4.4. Default Configuration Settings</a></li>
+<li><a href="#setting_essential_configuration_properties">4.5. Setting Essential Configuration Properties</a></li>
+</ul>
+</li>
+<li><a href="#router_network_connections">5. Network Connections</a>
+<ul class="sectlevel2">
+<li><a href="#adding_incoming_connections">5.1. Listening for Incoming Connections</a></li>
+<li><a href="#adding_outgoing_connections">5.2. Adding Outgoing Connections</a></li>
+</ul>
+</li>
+<li><a href="#security_config">6. Security</a>
+<ul class="sectlevel2">
+<li><a href="#setting_up_ssl_for_encryption_and_authentication">6.1. Setting Up SSL/TLS for Encryption and Authentication</a></li>
+<li><a href="#setting_up_sasl_for_authentication_and_payload_encryption">6.2. Setting Up SASL for Authentication and Payload Encryption</a></li>
+<li><a href="#securing_incoming_connections">6.3. Securing Incoming Connections</a>
+<ul class="sectlevel3">
+<li><a href="#adding_ssl_encryption_to_incoming_connection">6.3.1. Adding SSL/TLS Encryption to an Incoming Connection</a></li>
+<li><a href="#adding_sasl_authentication_to_incoming_connection">6.3.2. Adding SASL Authentication to an Incoming Connection</a></li>
+<li><a href="#adding_ssl_client_authentication_to_incoming_connection">6.3.3. Adding SSL/TLS Client Authentication to an Incoming Connection</a></li>
+<li><a href="#adding_sasl_payload_encryption_to_incoming_connection">6.3.4. Adding SASL Payload Encryption to an Incoming Connection</a></li>
+</ul>
+</li>
+<li><a href="#securing_outgoing_connections">6.4. Securing Outgoing Connections</a>
+<ul class="sectlevel3">
+<li><a href="#adding_ssl_authentication_to_outgoing_connection">6.4.1. Adding SSL/TLS Client Authentication to an Outgoing Connection</a></li>
+<li><a href="#adding_sasl_authentication_to_outgoing_connection">6.4.2. Adding SASL Authentication to an Outgoing Connection</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a href="#routing">7. Routing</a>
+<ul class="sectlevel2">
+<li><a href="#comparison_of_message_routing_and_link_routing">7.1. Comparison of Message Routing and Link Routing</a>
+<ul class="sectlevel3">
+<li><a href="#when_to_use_message_routing">7.1.1. When to Use Message Routing</a></li>
+<li><a href="#when_to_use_link_routing">7.1.2. When to Use Link Routing</a></li>
+</ul>
+</li>
+<li><a href="#configuring_message_routing">7.2. Configuring Message Routing</a>
+<ul class="sectlevel3">
+<li><a href="#addresses_2">7.2.1. Addresses</a></li>
+<li><a href="#routing_patterns_overview">7.2.2. Routing Patterns</a></li>
+<li><a href="#message_settlement_2">7.2.3. Message Settlement</a></li>
+<li><a href="#routing_messages_between_clients">7.2.4. Routing Messages Between Clients</a></li>
+<li><a href="#routing_messages_through_broker">7.2.5. Routing Messages Through a Broker Queue</a></li>
+<li><a href="#example_routing_messages_through_broker_queues">7.2.6. Example: Routing Messages Through Broker Queues</a></li>
+</ul>
+</li>
+<li><a href="#configuring_link_routing">7.3. Configuring Link Routing</a>
+<ul class="sectlevel3">
+<li><a href="#link_route_addresses_2">7.3.1. Link Route Addresses</a></li>
+<li><a href="#link_route_routing_patterns">7.3.2. Link Route Routing Patterns</a></li>
+<li><a href="#link_route_flow_control">7.3.3. Link Route Flow Control</a></li>
+<li><a href="#creating_link_route">7.3.4. Creating a Link Route</a></li>
+<li><a href="#example_using_a_link_route_to_provide_client_isolation">7.3.5. Example: Using a Link Route to Provide Client Isolation</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a href="#logging">8. Logging</a>
+<ul class="sectlevel2">
+<li><a href="#logging_modules_you_can_configure">8.1. Logging Modules</a>
+<ul class="sectlevel3">
+<li><a href="#the_code_default_code_logging_module">8.1.1. The <code>DEFAULT</code> Logging Module</a></li>
+<li><a href="#the_code_router_code_logging_module">8.1.2. The <code>ROUTER</code> Logging Module</a></li>
+<li><a href="#the_code_router_core_code_logging_module">8.1.3. The <code>ROUTER_CORE</code> Logging Module</a></li>
+<li><a href="#the_code_router_hello_code_logging_module">8.1.4. The <code>ROUTER_HELLO</code> Logging Module</a></li>
+<li><a href="#the_code_router_ls_code_logging_module">8.1.5. The <code>ROUTER_LS</code> Logging Module</a></li>
+<li><a href="#the_code_router_ma_code_logging_module">8.1.6. The <code>ROUTER_MA</code> Logging Module</a></li>
+<li><a href="#the_code_message_code_logging_module">8.1.7. The <code>MESSAGE</code> Logging Module</a></li>
+<li><a href="#the_code_server_code_logging_module">8.1.8. The <code>SERVER</code> Logging Module</a></li>
+<li><a href="#the_code_agent_code_logging_module">8.1.9. The <code>AGENT</code> Logging Module</a></li>
+<li><a href="#the_code_container_code_logging_module">8.1.10. The <code>CONTAINER</code> Logging Module</a></li>
+<li><a href="#the_code_error_code_logging_module">8.1.11. The <code>ERROR</code> Logging Module</a></li>
+<li><a href="#the_code_policy_code_logging_module">8.1.12. The <code>POLICY</code> Logging Module</a></li>
+</ul>
+</li>
+<li><a href="#configure_default_logging">8.2. Configuring Logging</a></li>
+<li><a href="#viewing_log_entries">8.3. Viewing Log Entries</a>
+<ul class="sectlevel3">
+<li><a href="#viewing_log_entries_on_the_console">8.3.1. Viewing Log Entries on the Console</a></li>
+<li><a href="#viewing_log_entries_on_the_cli">8.3.2. Viewing Log Entries on the CLI</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a href="#policy">9. Policy</a>
+<ul class="sectlevel2">
+<li><a href="#definitions">9.1. Definitions</a>
+<ul class="sectlevel3">
+<li><a href="#vhost">9.1.1. vhost</a></li>
+</ul>
+</li>
+<li><a href="#policy_features">9.2. Policy Features</a>
+<ul class="sectlevel3">
+<li><a href="#total_connection_limit">9.2.1. Total Connection Limit</a></li>
+<li><a href="#vhost_policy">9.2.2. Vhost Policy</a></li>
+<li><a href="#default_vhost">9.2.3. Default Vhost</a></li>
+</ul>
+</li>
+<li><a href="#policy_schema">9.3. Policy Schema</a>
+<ul class="sectlevel3">
+<li><a href="#global_policy">9.3.1. Global Policy</a></li>
+<li><a href="#vhost_policy_2">9.3.2. Vhost Policy</a></li>
+<li><a href="#vhost_user_group_settings_map">9.3.3. Vhost User Group Settings Map</a></li>
+</ul>
+</li>
+<li><a href="#policy_wildcard_and_user_name_substitution">9.4. Policy Wildcard and User Name Substitution</a>
+<ul class="sectlevel3">
+<li><a href="#remote_host_wildcard">9.4.1. Remote Host Wildcard</a></li>
+<li><a href="#amqp_source_and_target_wildcard_and_name_substitution">9.4.2. AMQP Source and Target Wildcard and Name Substitution</a></li>
+</ul>
+</li>
+<li><a href="#composing_policies">9.5. Composing Policies</a>
+<ul class="sectlevel3">
+<li><a href="#example_1_user_policy_disabled">9.5.1. Example 1. User Policy Disabled</a></li>
+<li><a href="#example2">9.5.2. Example 2. All Users Have Simple Connection Limits</a></li>
+<li><a href="#example_3_admins_must_connect_from_localhost">9.5.3. Example 3. Admins Must Connect From Localhost</a></li>
+<li><a href="#example_4_limiting_possible_memory_consumption">9.5.4. Example 4. Limiting Possible Memory Consumption</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a href="#management">10. Management</a>
+<ul class="sectlevel2">
+<li><a href="#using_apache_qpid_dispatch_router_console">10.1. Using Apache Qpid Dispatch Router Console</a>
+<ul class="sectlevel3">
+<li><a href="#console-overview">10.1.1. Console Overview</a></li>
+<li><a href="#console-installation">10.1.2. Console Installation</a></li>
+<li><a href="#console-operation">10.1.3. Console Operation</a></li>
+</ul>
+</li>
+<li><a href="#monitoring_using_qdstat">10.2. Monitoring Dispatch Router Using <code>qdstat</code></a>
+<ul class="sectlevel3">
+<li><a href="#syntax_for_using_code_qdstat_code">10.2.1. Syntax for Using <code>qdstat</code></a></li>
+<li><a href="#viewing_general_statistics_for_a_router">10.2.2. Viewing General Statistics for a Router</a></li>
+<li><a href="#viewing_a_list_of_connections_to_a_router">10.2.3. Viewing a List of Connections to a Router</a></li>
+<li><a href="#viewing_amqp_links_attached_to_a_router">10.2.4. Viewing AMQP Links Attached to a Router</a></li>
+<li><a href="#viewing_known_routers_on_a_network">10.2.5. Viewing Known Routers on a Network</a></li>
+<li><a href="#viewing_addresses_known_to_a_router">10.2.6. Viewing Addresses Known to a Router</a></li>
+<li><a href="#viewing_a_router_s_autolinks">10.2.7. Viewing a Router’s Autolinks</a></li>
+<li><a href="#viewing_the_status_of_a_router_s_link_routes">10.2.8. Viewing the Status of a Router’s Link Routes</a></li>
+<li><a href="#viewing_memory_consumption_information">10.2.9. Viewing Memory Consumption Information</a></li>
+</ul>
+</li>
+<li><a href="#managing_router">10.3. Managing Dispatch Router Using <code>qdmanage</code></a>
+<ul class="sectlevel3">
+<li><a href="#syntax_for_using_code_qdmanage_code">10.3.1. Syntax for Using <code>qdmanage</code></a></li>
+<li><a href="#managing_network_connections">10.3.2. Managing Network Connections</a></li>
+<li><a href="#managing_security">10.3.3. Managing Security</a></li>
+<li><a href="#managing_routing">10.3.4. Managing Routing</a></li>
+<li><a href="#managing_logging">10.3.5. Managing Logging</a></li>
+</ul>
+</li>
+<li><a href="#management_entities">10.4. Management Entities</a></li>
+</ul>
+</li>
+<li><a href="#reliability">11. Reliability</a>
+<ul class="sectlevel2">
+<li><a href="#path_redundancy">11.1. Path Redundancy</a></li>
+<li><a href="#path_redundancy_and_temporal_decoupling">11.2. Path Redundancy and Temporal Decoupling</a></li>
+<li><a href="#sharded_queue">11.3. Sharded Queue</a></li>
+</ul>
+</li>
+<li><a href="#technical_details_specifications">12. Technical Details and Specifications</a>
+<ul class="sectlevel2">
+<li><a href="#client_compatibility">12.1. Client Compatibility</a></li>
+<li><a href="#amqp_mapping">12.2. AMQP Mapping</a>
+<ul class="sectlevel3">
+<li><a href="#message_annotations">12.2.1. Message Annotations</a></li>
+<li><a href="#sourcetarget_capabilities">12.2.2. Source/Target Capabilities</a></li>
+<li><a href="#dynamic_node_properties">12.2.3. Dynamic-Node-Properties</a></li>
+<li><a href="#addresses_and_address_formats">12.2.4. Addresses and Address Formats</a></li>
+<li><a href="#implementation_of_the_amqp_management_specification">12.2.5. Implementation of the AMQP Management Specification</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a href="#cyrus_sasl">Appendix A: Using Cyrus SASL to Provide Authentication</a>
+<ul class="sectlevel2">
+<li><a href="#generating_sasl_database">A.1. Generating a SASL Database</a></li>
+<li><a href="#viewing_users_in_a_sasl_database">A.2. Viewing Users in a SASL Database</a></li>
+<li><a href="#configuring_sasl_database">A.3. Configuring a SASL Database</a></li>
+</ul>
+</li>
+<li><a href="#router_configuration_reference">Appendix B: Configuration Reference</a>
+<ul class="sectlevel2">
+<li><a href="#configuration_file">B.1. Configuration File</a>
+<ul class="sectlevel3">
+<li><a href="#configuration_sections">B.1.1. Configuration Sections</a></li>
+</ul>
+</li>
+</ul>
+</li>
+</ul>
+</div>
+<div class="sect1">
+<h2 id="introduction">1. Introduction</h2>
+<div class="sectionbody">
+<div class="sect2">
+<h3 id="overview">1.1. Overview</h3>
+<div class="paragraph">
+<p>The Dispatch Router is an AMQP 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>
+</div>
+<div class="paragraph">
+<p>A messaging client can make a single AMQP connection into a messaging
+bus built of Dispatch Router 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>
+</div>
+<div class="paragraph">
+<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>
+</div>
+<div class="paragraph">
+<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>
+</div>
+<div class="paragraph">
+<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 immediately if there is nobody
+to serve the request, but typically it can only wait for a timeout to
+discover this. With a Dispatch Router 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>
+</div>
+<div class="paragraph">
+<p>For an exampe of using Dispatch Router 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 Router 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>
+</div>
+<div class="paragraph">
+<p>Dispatch 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>
+<div class="sect2">
+<h3 id="benefits">1.2. Benefits</h3>
+<div class="paragraph">
+<p>Simplifies connectivity</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>An endpoint can do all of its messaging through a single transport
+connection</p>
+</li>
+<li>
+<p>Avoid opening holes in firewalls for incoming connections</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Provides messaging connectivity where there is no TCP/IP connectivity</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>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).</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Simplifies reliability</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Reliability and availability are provided using redundant topology,
+not server clustering</p>
+</li>
+<li>
+<p>Reliable end-to-end messaging without persistent stores</p>
+</li>
+<li>
+<p>Use a message broker only when you need store-and-forward semantics</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="features">1.3. Features</h3>
+<div class="ulist">
+<ul>
+<li>
+<p>Can be deployed stand-alone or in a network of routers</p>
+<div class="ulist">
+<ul>
+<li>
+<p>Supports arbitrary network topology - no restrictions on redundancy</p>
+<div class="ulist">
+<ul>
+<li>
+<p>Automatic route computation - adjusts quickly to changes in topology</p>
+</li>
+</ul>
+</div>
+</li>
+</ul>
+</div>
+</li>
+<li>
+<p>Provides remote access to brokers or other AMQP servers</p>
+</li>
+<li>
+<p>Security</p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="theory_of_operation">2. Theory of Operation</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>This section introduces some key concepts about the router.</p>
+</div>
+<div class="sect2">
+<h3 id="overview_2">2.1. Overview</h3>
+<div class="paragraph">
+<p>The Dispatch Router is an <em>application layer</em> program running as a normal
+user program or as a daemon.</p>
+</div>
+<div class="paragraph">
+<p>Dispatch Router accepts AMQP connections from clients and creates AMQP
+connections to brokers or AMQP-based services. Dispatch Router classifies
+incoming AMQP messages and routes the
+messages between message producers and message consumers.</p>
+</div>
+<div class="paragraph">
+<p>Dispatch 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 message source to every message
+destination and to recover quickly from failures. Dispatch Router relies on
+redundant network paths to provide continued connectivity in the face
+of system or network failure.</p>
+</div>
+<div class="paragraph">
+<p>A messaging client can make a single AMQP connection into a messaging
+bus built with routers and, over that connection, exchange messages
+with one or more message brokers connected to any router in the
+network. At the same time the client can exchange messages directly
+with other endpoints without involving a broker at all.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="connections">2.2. Connections</h3>
+<div class="paragraph">
+<p>Dispatch Router connects clients, servers, AMQP services, and other
+routers through network connections.</p>
+</div>
+<div class="sect3">
+<h4 id="listener">2.2.1. Listener</h4>
+<div class="paragraph">
+<p>Dispatch Router provides <em>listeners</em> that accept client connections.
+A client connecting to a router listener uses the
+same methods that it would use to connect to a broker. From the
+client’s perspective the router connection and link establishment are
+identical to broker connection and link establishment.</p>
+</div>
+<div class="paragraph">
+<p>Several types of listeners are defined by their role.</p>
+</div>
+<table class="tableblock frame-all grid-all spread">
+<colgroup>
+<col style="width: 20%;">
+<col style="width: 80%;">
+</colgroup>
+<tbody>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Role</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Description</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">normal</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">The connection is used for AMQP clients using normal message delivery.</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">inter-router</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">The connection is assumed to be to another router in the network. Inter-router discovery and routing protocols can only be used over inter-router connections.</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">route-container</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">The connection is a broker or other resource that holds known addresses. The router will use this connection to create links as necessary. The addresses are available for routing only after the remote resource has created a connection.</p></td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="sect3">
+<h4 id="connector">2.2.2. Connector</h4>
+<div class="paragraph">
+<p>Dispatch Router can also be configured to create outbound connections to
+messaging brokers or other AMQP entities using <em>connectors</em>. A
+connector is defined with the network address of the broker and the
+name or names of the resources that are available in that broker. When
+a router connects to a broker through a connector it uses the same
+methods a normal messaging client would use when connecting to the
+broker.</p>
+</div>
+<div class="paragraph">
+<p>Several types of connectors are defined by their role.</p>
+</div>
+<table class="tableblock frame-all grid-all spread">
+<colgroup>
+<col style="width: 20%;">
+<col style="width: 80%;">
+</colgroup>
+<tbody>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Role</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Description</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">normal</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">The connection is used for AMQP clients using normal message delivery. On this connector the router will initiate the connection but it will never create any links. Links are to be created by the peer that accepts the connection.</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">inter-router</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">The connection is assumed to be to another router in the network. Inter-router discovery and routing protocols can only be used over inter-router connections.</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">route-container</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">The connection is to a broker or other resource that holds known addresses. The router will use this connection to create links as necessary. The addresses are available for routing only after the router has created a connection to the remote resource.</p></td>
+</tr>
+</tbody>
+</table>
+</div>
+</div>
+<div class="sect2">
+<h3 id="addresses">2.3. Addresses</h3>
+<div class="paragraph">
+<p>AMQP addresses are used to control the flow of messages across a
+network of routers. Addresses are used in a number of different places
+in the AMQP 1.0 protocol. They can be used in a specific message in
+the <em>to</em> and <em>reply-to</em> fields of a message’s properties. They are also
+used during the creation of links in the <em>address</em> field of a <em>source</em> or
+a <em>target</em>.</p>
+</div>
+<div class="admonitionblock note">
+<table>
+<tr>
+<td class="icon">
+<div class="title">Note</div>
+</td>
+<td class="content">
+<div class="paragraph">
+<p>Addresses in this discussion refer to AMQP protocol addresses and not
+to TCP/IP network addresses. TCP/IP network addresses are used by
+messaging clients, brokers, and routers to create AMQP connections.
+AMQP protocol addresses are the names of source and destination
+endpoints for messages within the messaging network.</p>
+</div>
+</td>
+</tr>
+</table>
+</div>
+<div class="paragraph">
+<p>Addresses designate various kinds of entities in a messaging network:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Endpoint processes that consume data or offer a service</p>
+</li>
+<li>
+<p>Topics that match multiple consumers to multiple producers</p>
+</li>
+<li>
+<p>Entities within a messaging broker:</p>
+<div class="ulist">
+<ul>
+<li>
+<p>Queues</p>
+</li>
+<li>
+<p>Durable Topics</p>
+</li>
+<li>
+<p>Exchanges</p>
+</li>
+</ul>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>The syntax of an AMQP address is opaque as far as the router network
+is concerned. A syntactical structure may be used by the administrator
+who creates addresses but the router treats them as opaque
+strings.</p>
+</div>
+<div class="paragraph">
+<p>Dispatch Router maintains several classes of address based on how the address is
+configured or discovered.</p>
+</div>
+<table class="tableblock frame-all grid-all spread">
+<colgroup>
+<col style="width: 25%;">
+<col style="width: 75%;">
+</colgroup>
+<tbody>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Address Type</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Description</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">mobile</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">The address is a rendezvous point between senders and receivers. The router aggregates and serializes messages from senders and distributes messages to receivers.</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">link route</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">The address defines a private messaging path between a sender and a receiver. The router simply passes messages between the end points.</p></td>
+</tr>
+</tbody>
+</table>
+<div class="sect3">
+<h4 id="mobile_addresses">2.3.1. Mobile Addresses</h4>
+<div class="paragraph">
+<p>Routers consider addresses to be mobile such that any users of an
+address may be directly connected to any router in a network and may
+move around the topology. In cases where messages are broadcast to or
+balanced across multiple consumers, the address users may be connected
+to multiple routers in the network.</p>
+</div>
+<div class="paragraph">
+<p>Mobile addresses are rendezvous points for senders and receivers.
+Messages arrive at the mobile address and are dispatched to their
+destinations according to the routing defined for the mobile address.
+The details of these routing patterns are discussed later.</p>
+</div>
+<div class="paragraph">
+<p>Mobile addresses may be discovered during normal router operation or
+configured through management settings.</p>
+</div>
+<div class="sect4">
+<h5 id="discovered_mobile_addresses">Discovered Mobile Addresses</h5>
+<div class="paragraph">
+<p>Mobile addresses are created when a client creates a link to a source
+or destination address that is unknown to the router network.</p>
+</div>
+<div class="paragraph">
+<p>Suppose a service provider wants to offer <em>my-service</em> that clients
+may use. The service provider must open a receiver link with source
+address <em>my-service</em>. The router creates a mobile address
+<em>my-service</em> and propagates the address so that it is known to every
+router in the network.</p>
+</div>
+<div class="paragraph">
+<p>Later a client wants to use the service and creates a sending link
+with target address <em>my-service</em>. The router matches the service
+provider’s receiver having source address <em>my-service</em> to the client’s
+sender having target address <em>my-service</em> and routes messages between
+the two.</p>
+</div>
+<div class="paragraph">
+<p>Any number of other clients can create links to the service as
+well. The clients do not have to know where in the router network the
+service provider is physically located nor are the clients required to
+connect to a specific router to use the service. Regardless of how
+many clients are using the service the service provider needs only a
+single connection and link into the router network.</p>
+</div>
+<div class="paragraph">
+<p>Another view of this same scenario is when a client tries to use the
+service before service provider has connected to the network. In this
+case the router network creates the mobile address <em>my-service</em> as
+before. However, since the mobile address has only client sender links
+and no receiver links the router stalls the clients and prevents them
+from sending any messages. Later, after the service provider connects
+and creates the receiver link, the router will issue credits to the
+clients and the messages will begin to flow between the clients and
+the service.</p>
+</div>
+<div class="paragraph">
+<p>The service provider can connect, disconnect, and reconnect from a
+different location without having to change any of the clients or
+their connections. Imagine having the service running on a
+laptop. One day the connection is from corporate headquarters and the
+next day the connection is from some remote location. In this case the
+service provider’s computer will typically have different host IP
+addresses for each connection. Using the router network the service
+provider connects to the router network and offers the named service
+and the clients connect to the router network and consume from the
+named service. The router network routes messages between the mobile
+addresses effectively masking host IP addresses of the service
+provider and the client systems.</p>
+</div>
+</div>
+<div class="sect4">
+<h5 id="configured_mobile_addresses">Configured Mobile Addresses</h5>
+<div class="paragraph">
+<p>Mobile addresses may be configured using the router <em>autoLink</em>
+object. An address created via an <em>autoLink</em> represents a queue,
+topic, or other service in an external broker. Logically the
+<em>autoLink</em> addresses are treated by the router network as if the
+broker had connected to the router and offered the services itself.</p>
+</div>
+<div class="paragraph">
+<p>For each configured mobile address the router will create a single
+link to the external resource. Messages flow between sender links and
+receiver links the same regardless if the mobile address was
+discovered or configured.</p>
+</div>
+<div class="paragraph">
+<p>Multiple <em>autoLink</em> objects may define the same address on multiple
+brokers. In this case the router network creates a sharded resource
+split between the brokers. Any client can seamlessly send and receive
+messages from either broker.</p>
+</div>
+<div class="paragraph">
+<p>Note that the brokers do not need to be clustered or federated to
+receive this treatment. The brokers may even be from different vendors
+or be different versions of the same broker yet still work together to
+provide a larger service platform.</p>
+</div>
+</div>
+</div>
+<div class="sect3">
+<h4 id="link_route_addresses">2.3.2. Link Route Addresses</h4>
+<div class="paragraph">
+<p>Link route addresses may be configured using the router <em>linkRoute</em>
+object. An link route address represents a queue, topic, or other
+service in an external broker similar to addresses configured by
+<em>autoLink</em> objects. For link route addresses the router propagates a
+separate link attachment to the broker resource for each incoming
+client link. The router does not automatically create any links to the
+broker resource.</p>
+</div>
+<div class="paragraph">
+<p>Using link route addresses the router network does not participate in
+aggregated message distribution. The router simply passes message
+delivery and settlement between the two end points.</p>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="message_routing">2.4. Message Routing</h3>
+<div class="paragraph">
+<p>Addresses have semantics associated with them that are assigned when
+the address is provisioned or discovered. The semantics of an address
+control how routers behave when they see the address being
+used. Address semantics include the following considerations:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Routing pattern - balanced, closest, multicast</p>
+</li>
+<li>
+<p>Routing mechanism - message routed, link routed</p>
+</li>
+</ul>
+</div>
+<div class="sect3">
+<h4 id="routing_patterns">2.4.1. Routing Patterns</h4>
+<div class="paragraph">
+<p>Routing patterns define the paths that a message with a mobile address can take across a network. These routing patterns can be used for both direct routing, in which the router distributes messages between clients without a broker, and indirect routing, in which the router enables clients to exchange messages through a broker.</p>
+</div>
+<table class="tableblock frame-all grid-all spread">
+<colgroup>
+<col style="width: 20%;">
+<col style="width: 80%;">
+</colgroup>
+<tbody>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Pattern</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Description</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Balanced</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">An anycast method which allows multiple receivers to use the same address. In this case, messages (or links) are routed to exactly one of the receivers and the network attempts to balance the traffic load across the set of receivers using the same address. This routing delivers messages to receivers based on how quickly they settle the deliveries. Faster receivers get more messages.</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Closest</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">An anycast method in which even if there are more receivers for the same address, every message is sent along the shortest path to reach the destination. This means that only one receiver will get the message. Each message is delivered to the closest receivers in terms of topology cost. If there are multiple receivers with the same lowest cost, deliveries will be spread evenly among those receivers.</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Multicast</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Having multiple consumers on the same address at the same time, messages are routed such that each consumer receives one copy of the message.</p></td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="sect3">
+<h4 id="routing_mechanisms">2.4.2. Routing Mechanisms</h4>
+<div class="paragraph">
+<p>The fact that addresses can be used in different ways suggests that
+message routing can be accomplished in different ways. Before going
+into the specifics of the different routing mechanisms, it would be
+good to first define what is meant by the term <em>routing</em>:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>In a network built of multiple, interconnected routers 'routing'
+determines which connection to use to send a message directly
+to its destination or one step closer to its destination.</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Each router serves as the terminus of a collection of incoming and
+outgoing links. Some of the links are designated for message routing,
+and others are designated for link routing. In both cases, the links
+either connect directly to endpoints that produce and consume
+messages, or they connect to other routers in the network along
+previously established connections.</p>
+</div>
+<div class="sect4">
+<h5 id="message_routed">Message Routed</h5>
+<div class="paragraph">
+<p>Message routing occurs upon delivery of a message and is done based on
+the address in the message’s <em>to</em> field.</p>
+</div>
+<div class="paragraph">
+<p>When a delivery arrives on an incoming message-routing link, the
+router extracts the address from the delivered message’s <em>to</em> field and
+looks the address up in its routing table. The lookup results in zero
+or more outgoing links onto which the message shall be resent.</p>
+</div>
+<div class="paragraph">
+<p>Message routing can also occur without an address in the
+message’s <em>to</em> field if the incoming link has a target address. In
+fact, if the sender uses a link with a target address, the <em>to</em> field
+shall be ignored even if used.</p>
+</div>
+</div>
+<div class="sect4">
+<h5 id="link_routed">Link Routed</h5>
+<div class="paragraph">
+<p>Link routing occurs when a new link is attached to the router across
+one of its AMQP connections. It is done based on the <em>target.address</em>
+field of an inbound link and the <em>source.address</em> field of an outbound
+link.</p>
+</div>
+<div class="paragraph">
+<p>Link routing uses the same routing table that message routing
+uses. The difference is that the routing occurs during the link-attach
+operation, and link attaches are propagated along the appropriate path
+to the destination. What results is a chain of links, connected
+end-to-end, from source to destination. It is similar to a virtual
+circuit in a telecom system.</p>
+</div>
+<div class="paragraph">
+<p>Each router in the chain holds pairs of link termini that are tied
+together. The router then simply exchanges all deliveries, delivery
+state changes, and link state changes between the two termini.</p>
+</div>
+<div class="paragraph">
+<p>The endpoints that use the link chain do not see any difference in
+behavior between a link chain and a single point-to-point link. All of
+the features available in the link protocol (flow control,
+transactional delivery, etc.) are available over a routed link-chain.</p>
+</div>
+</div>
+</div>
+<div class="sect3">
+<h4 id="message_settlement">2.4.3. Message Settlement</h4>
+<div class="paragraph">
+<p>Messages may be delivered with varying degrees of reliability.</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>At most once</p>
+</li>
+<li>
+<p>At least once</p>
+</li>
+<li>
+<p>Exactly once</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>The reliability is negotiated between the client and server during
+link establishment. The router handles all levels of reliability by treating
+messages as either <em>pre-settled</em> or <em>unsettled</em>.</p>
+</div>
+<table class="tableblock frame-all grid-all spread">
+<colgroup>
+<col style="width: 20%;">
+<col style="width: 80%;">
+</colgroup>
+<tbody>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Delivery</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Handling</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">pre-settled</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">If the arriving delivery is pre-settled (i.e., fire and forget), the incoming delivery shall be settled by the router, and the outgoing deliveries shall also be pre-settled. In other words, the pre-settled nature of the message delivery is propagated across the network to the message’s destination.</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">unsettled</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Unsettled delivery is also propagated across the network. Because unsettled delivery records cannot be discarded, the router tracks the incoming deliveries and keeps the association of the incoming deliveries to the resulting outgoing deliveries. This kept association allows the router to continue to propagate changes in delivery state (settlement and disposition) back and forth along the path which the message traveled.</p></td>
+</tr>
+</tbody>
+</table>
+</div>
+</div>
+<div class="sect2">
+<h3 id="security">2.5. Security</h3>
+<div class="paragraph">
+<p>Dispatch Router uses the SSL protocol and related certificates and SASL
+protocol mechanisms to encrypt and authenticate remote peers. Router
+listeners act as network servers and router connectors act as network
+clients. Both connection types may be configured securely with SSL
+and SASL.</p>
+</div>
+<div class="paragraph">
+<p>The router <code>policy</code> module is an optional authorization mechanism
+enforcing user connection restrictions and AMQP resource access
+control.</p>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="getting_started">3. Getting Started</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Before configuring Dispatch Router, you should understand how to start the router, how it is configured by default, and how to use it in a simple peer-to-peer configuration.</p>
+</div>
+<div class="sect2">
+<h3 id="starting_the_router">3.1. Starting the Router</h3>
+<div class="olist arabic">
+<div class="title">Procedure</div>
+<ol class="arabic">
+<li>
+<p>To start the router, use the <strong><code>qdrouterd</code></strong> command.</p>
+<div class="openblock">
+<div class="content">
+<div class="paragraph">
+<p>This example uses the default configuration to start the router as a daemon:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">$ qdrouterd -d</pre>
+</div>
+</div>
+</div>
+</div>
+<div class="admonitionblock note">
+<table>
+<tr>
+<td class="icon">
+<div class="title">Note</div>
+</td>
+<td class="content">
+<div class="paragraph">
+<p>You can specify a different configuration file with which to start the router. For more information, see <a href="#methods_for_changing_router_configuration"><em>Changing a Router’s Configuration</em></a>.</p>
+</div>
+</td>
+</tr>
+</table>
+</div>
+<div class="paragraph">
+<p>The router starts, using the default configuration file stored at <code>/etc/qpid-dispatch/qdrouterd.conf</code>.</p>
+</div>
+</li>
+<li>
+<p>View the log to verify the router status:</p>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">$ qdstat --log</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>This example shows that the router was correctly installed, is running, and is ready to route traffic between clients:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">$ qdstat --log
+Fri May 20 09:38:03 2017 SERVER (info) Container Name: Router.A <b class="conum">(1)</b>
+Fri May 20 09:38:03 2017 ROUTER (info) Router started in Standalone mode <b class="conum">(2)</b>
+Fri May 20 09:38:03 2017 ROUTER_CORE (info) Router Core thread running. 0/Router.A
+Fri May 20 09:38:03 2017 ROUTER_CORE (info) In-process subscription M/$management
+Fri May 20 09:38:03 2017 AGENT (info) Activating management agent on $_management_internal <b class="conum">(3)</b>
+Fri May 20 09:38:03 2017 ROUTER_CORE (info) In-process subscription L/$management
+Fri May 20 09:38:03 2017 ROUTER_CORE (info) In-process subscription L/$_management_internal
+Fri May 20 09:38:03 2017 DISPLAYNAME (info) Activating DisplayNameService on $displayname
+Fri May 20 09:38:03 2017 ROUTER_CORE (info) In-process subscription L/$displayname
+Fri May 20 09:38:03 2017 CONN_MGR (info) Configured Listener: 0.0.0.0:amqp proto=any role=normal <b class="conum">(4)</b>
+Fri May 20 09:38:03 2017 POLICY (info) Policy configured maximumConnections: 0, policyFolder: '', access rules enabled: 'false'
+Fri May 20 09:38:03 2017 POLICY (info) Policy fallback defaultApplication is disabled
+Fri May 20 09:38:03 2017 SERVER (info) Operational, 4 Threads Running <b class="conum">(5)</b></pre>
+</div>
+</div>
+<div class="colist arabic">
+<ol>
+<li>
+<p>The name of this router instance.</p>
+</li>
+<li>
+<p>By default, the router starts in <em>standalone</em> mode, which means that it cannot connect to other routers or be used in a router network.</p>
+</li>
+<li>
+<p>The management agent. It provides the <code>$management</code> address, through which management tools such as <code>qdmanage</code> and <code>qdstat</code> can perform create, read, update, and delete (CRUD) operations on the router. As an AMQP endpoint, the management agent supports all operations defined by the <a href="https://www.oasis-open.org/committees/download.php/54441/AMQP%20Management%20v1.0%20WD09">AMQP management specification (Draft 9)</a>.</p>
+</li>
+<li>
+<p>A listener is started on all available network interfaces and listens for connections on the standard AMQP port (5672, which is not encrypted).</p>
+</li>
+<li>
+<p>Threads for handling message traffic and all other internal operations.</p>
+</li>
+</ol>
+</div>
+</li>
+</ol>
+</div>
+</div>
+<div class="sect2">
+<h3 id="routing_messages_in_a_peer_to_peer_configuration">3.2. Routing Messages in a Peer-to-Peer Configuration</h3>
+<div class="paragraph">
+<p>This example demonstrates how the router can connect clients by receiving and sending messages between them. It uses the router’s default configuration file and does not require a broker.</p>
+</div>
+<div class="imageblock" style="text-align: center">
+<div class="content">
+<img src="images/01-peer-to-peer.png" alt="Peer-to-peer Communication">
+</div>
+<div class="title">Figure 1. Peer-to-peer Communication</div>
+</div>
+<div class="paragraph">
+<p>As the diagram indicates, the configuration consists of an Dispatch Router component with two clients connected to it: a sender and a receiver. The receiver wants to receive messages on a specific address, and the sender sends
+messages to that address.</p>
+</div>
+<div class="paragraph">
+<p>A broker is not used in this example, so there is no <em>"store and forward"</em> mechanism in the middle. Instead, the messages flow from sender to receiver only if the receiver is online, and the sender can confirm that the messages have arrived at their destination.</p>
+</div>
+<div class="paragraph">
+<p>This example uses a Apache Qpid Proton Python client to start a receiver client, and then send five messages from the sender client.</p>
+</div>
+<div class="paragraph">
+<div class="title">Prerequisites</div>
+<p>Apache Qpid Proton Python must be installed before you can complete the peer-to-peer routing example. For more information, see <a href="https://qpid.apache.org/proton/" class="bare">https://qpid.apache.org/proton/</a>.</p>
+</div>
+<div class="olist arabic">
+<div class="title">Procedure</div>
+<ol class="arabic">
+<li>
+<p><a href="#starting_the_receiver_client">Start the receiver client</a>.</p>
+</li>
+<li>
+<p><a href="#sending_messages">Send messages</a>.</p>
+</li>
+</ol>
+</div>
+<div class="sect3">
+<h4 id="starting_the_receiver_client">3.2.1. Starting the Receiver Client</h4>
+<div class="paragraph">
+<p>In this example, the receiver client is started first. This means that the messages will be sent as soon as the sender client is started.</p>
+</div>
+<div class="admonitionblock note">
+<table>
+<tr>
+<td class="icon">
+<div class="title">Note</div>
+</td>
+<td class="content">
+<div class="paragraph">
+<p>In practice, the order in which you start senders and receivers does not matter. In both cases, messages will be sent as soon as the receiver comes online.</p>
+</div>
+</td>
+</tr>
+</table>
+</div>
+<div class="ulist">
+<div class="title">Procedure</div>
+<ul>
+<li>
+<p>To start the receiver by using the Python receiver client, navigate to the Python examples directory and run the <code>simple_recv.py</code> example:</p>
+<div class="openblock">
+<div class="content">
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">$ cd <em>INSTALL_DIR</em>/examples/python/
+$ python simple_recv.py -a 127.0.0.1:5672/examples -m 5</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>This command starts the receiver and listens on the default address (<code>127.0.0.1:5672/examples</code>). The receiver is also set to receive a maximum of five messages.</p>
+</div>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect3">
+<h4 id="sending_messages">3.2.2. Sending Messages</h4>
+<div class="paragraph">
+<p>After starting the receiver client, you can send messages from the sender. These messages will travel through the router to the receiver.</p>
+</div>
+<div class="ulist">
+<div class="title">Procedure</div>
+<ul>
+<li>
+<p>In a new terminal window, navigate to the Python examples directory and run the <code>simple_send.py</code> example:</p>
+<div class="openblock">
+<div class="content">
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">$ cd <em>INSTALL_DIR</em>/examples/python/
+$ python simple_send.py -a 127.0.0.1:5672/examples -m 5</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>This command sends five auto-generated messages to the default address (<code>127.0.0.1:5672/examples</code>) and then confirms that they were delivered and acknowledged by the receiver:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">all messages confirmed</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>The receiver client receives the messages and displays their content:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">{u'sequence': 1L}
+{u'sequence': 2L}
+{u'sequence': 3L}
+{u'sequence': 4L}
+{u'sequence': 5L}</pre>
+</div>
+</div>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="router_configuration">4. Configuration</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Before starting Dispatch Router, you should understand where the router’s configuration file is stored, how the file is structured, and the methods you can use to modify it.</p>
+</div>
+<div class="sect2">
+<h3 id="accessing_the_router_configuration_file">4.1. Accessing the Router Configuration File</h3>
+<div class="paragraph">
+<p>The router’s configuration is defined in the router configuration file. You can access this file to view and modify that configuration.</p>
+</div>
+<div class="ulist">
+<div class="title">Procedure</div>
+<ul>
+<li>
+<p>Open the following file: <code>/etc/qpid-dispatch/qdrouterd.conf</code>.</p>
+<div class="openblock">
+<div class="content">
+<div class="paragraph">
+<p>When Dispatch Router is installed, <code>qdrouterd.conf</code> is installed in this directory by default. When the router is started, it runs with the settings defined in this file.</p>
+</div>
+<div class="paragraph">
+<p>For more information about the router configuration file (including available entities and attributes), see the <a href="https://qpid.apache.org/releases/qpid-dispatch-0.8.0/man/qdrouterd.html">qdrouterd man page</a>.</p>
+</div>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="how_the_router_configuration_file_is_structured">4.2. How the Router Configuration File is Structured</h3>
+<div class="paragraph">
+<p>Before you can make changes to a router configuration file, you should understand how the file is structured.</p>
+</div>
+<div class="paragraph">
+<p>The configuration file contains sections. A section is a configurable entity, and it contains a set of attribute name-value pairs that define the settings for that entity. The syntax is as follows:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">sectionName {
+ attributeName: attributeValue
+ attributeName: attributeValue
+ ...
+}</pre>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="methods_for_changing_router_configuration">4.3. Changing a Router’s Configuration</h3>
+<div class="paragraph">
+<p>You can use different methods for changing a router’s configuration based on whether the router is currently running, and whether you want the change to take effect immediately.</p>
+</div>
+<div class="ulist">
+<div class="title">Choices</div>
+<ul>
+<li>
+<p><a href="#making_permanent_change_to_router_configuration">Make a permanent change to the router’s configuration</a>.</p>
+</li>
+<li>
+<p><a href="#changing_configuration_for_running_router">Change the configuration for a running router.</a></p>
+</li>
+</ul>
+</div>
+<div class="sect3">
+<h4 id="making_permanent_change_to_router_configuration">4.3.1. Making a Permanent Change to the Router’s Configuration</h4>
+<div class="paragraph">
+<p>You can make a permanent change to the router’s configuration by editing the router’s configuration file directly. You must restart the router for the changes to take effect, but the changes will be saved even if the router is stopped.</p>
+</div>
+<div class="olist arabic">
+<div class="title">Procedure</div>
+<ol class="arabic">
+<li>
+<p>Do one of the following:</p>
+<div class="ulist">
+<ul>
+<li>
+<p>Edit the default configuration file (<code>/etc/qpid-dispatch/qdrouterd.conf</code>).</p>
+</li>
+<li>
+<p>Create a new configuration file.</p>
+</li>
+</ul>
+</div>
+</li>
+<li>
+<p>Start (or restart) the router.</p>
+<div class="paragraph">
+<p>If you created a new configuration file, you must specify the path using the <code>--conf</code> parameter. For example, the following command starts the router with a non-default configuration file:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap"># qdrouterd -d --conf /etc/qpid-dispatch/new-configuration-file.conf</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</div>
+<div class="sect3">
+<h4 id="changing_configuration_for_running_router">4.3.2. Changing the Configuration for a Running Router</h4>
+<div class="paragraph">
+<p>If the router is running, you can change its configuration on the fly. The changes you make take effect immediately, but are lost if the router is stopped.</p>
+</div>
+<div class="ulist">
+<div class="title">Procedure</div>
+<ul>
+<li>
+<p>Use <code>qdmanage</code> to change the configuration.</p>
+<div class="paragraph">
+<p>For more information about using <code>qdmanage</code>, see <a href="#managing_router">Managing Dispatch Router Using <em>qdmanage</em></a>.</p>
+</div>
+</li>
+</ul>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="default_configuration_settings">4.4. Default Configuration Settings</h3>
+<div class="paragraph">
+<p>The router’s configuration file controls the way in which the router functions. The default configuration file contains the minimum number of settings required for the router to run. As you become more familiar with the router, you can add to or change these settings, or create your own configuration files.</p>
+</div>
+<div class="paragraph">
+<p>When you installed Dispatch Router, the default configuration file was added at the following path: <code>/etc/qpid-dispatch/qdrouterd.conf</code>. It includes some basic configuration settings that define the router’s operating mode, how it listens for incoming connections, and routing patterns for the message routing mechanism.</p>
+</div>
+<div class="listingblock">
+<div class="title">Default Configuration File</div>
+<div class="content">
+<pre class="nowrap">router {
+ mode: standalone <b class="conum">(1)</b>
+ id: Router.A <b class="conum">(2)</b>
+}
+
+listener { <b class="conum">(3)</b>
+ host: 0.0.0.0 <b class="conum">(4)</b>
+ port: amqp <b class="conum">(5)</b>
+ authenticatePeer: no <b class="conum">(6)</b>
+}
+
+address { <b class="conum">(7)</b>
+ prefix: closest
+ distribution: closest
+}
+
+address {
+ prefix: multicast
+ distribution: multicast
+}
+
+address {
+ prefix: unicast
+ distribution: closest
+}
+
+address {
+ prefix: exclusive
+ distribution: closest
+}
+
+address {
+ prefix: broadcast
+ distribution: multicast
+}</pre>
+</div>
+</div>
+<div class="colist arabic">
+<ol>
+<li>
+<p>By default, the router operates in <em>standalone</em> mode. This means that it can only communicate with endpoints that are directly connected to it. It cannot connect to other routers, or participate in a router network.</p>
+</li>
+<li>
+<p>The unique identifier of the router. This ID is used as the <code>container-id</code> (container name) at the AMQP protocol level. It is required, and the router will not start if this attribute is not defined.</p>
+</li>
+<li>
+<p>The <code>listener</code> entity handles incoming connections from client endpoints.</p>
+</li>
+<li>
+<p>The IP address on which the router will listen for incoming connections. By default, the router is configured to listen on all network interfaces.</p>
+</li>
+<li>
+<p>The port on which the router will listen for incoming connections. By default, the default AMQP port (5672) is specified with a symbolic service name.</p>
+</li>
+<li>
+<p>Specifies whether the router should authenticate peers before they can connect to the router. By default, peer authentication is not required.</p>
+</li>
+<li>
+<p>By default, the router is configured to use the message routing mechanism. Each <code>address</code> entity defines how messages that are received with a particular address <code>prefix</code> should be distributed. For example, all messages with addresses that start with <code>closest</code> will be distributed using the <code>closest</code> distribution pattern.</p>
+</li>
+</ol>
+</div>
+<div class="admonitionblock note">
+<table>
+<tr>
+<td class="icon">
+<div class="title">Note</div>
+</td>
+<td class="content">
+<div class="paragraph">
+<p>If a client requests a message with an address that is not defined in the router’s configuration file, the <code>balanced</code> distribution pattern will be used automatically.</p>
+</div>
+</td>
+</tr>
+</table>
+</div>
+</div>
+<div class="sect2">
+<h3 id="setting_essential_configuration_properties">4.5. Setting Essential Configuration Properties</h3>
+<div class="paragraph">
+<p>The router’s default configuration settings enable the router to run with minimal configuration. However, you may need to change some of these settings for the router to run properly in your environment.</p>
+</div>
+<div class="olist arabic">
+<div class="title">Procedure</div>
+<ol class="arabic">
+<li>
+<p>Open the router’s configuration file.</p>
+<div class="paragraph">
+<p>If you are changing the router’s default configuration file, the file is located at <code>/etc/qpid-dispatch/qdrouterd.conf</code>.</p>
+</div>
+</li>
+<li>
+<p>To define essential router information, change the following attributes as needed in the <code>router</code> section:</p>
+<div class="openblock">
+<div class="content">
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">router {
+ mode: <em>STANDALONE/INTERIOR</em>
+ id: <em>ROUTER_ID</em>
+}</pre>
+</div>
+</div>
+<div class="dlist">
+<dl>
+<dt class="hdlist1"><code>mode</code></dt>
+<dd>
+<p>Specify one of the following modes:</p>
+<div class="ulist">
+<ul>
+<li>
+<p><code>standalone</code> - Use this mode if the router does not communicate with other routers and is not part of a router network. When operating in this mode, the router only routes messages between directly connected endpoints.</p>
+</li>
+<li>
+<p><code>interior</code> - Use this mode if the router is part of a router network and needs to collaborate with other routers.</p>
+</li>
+</ul>
+</div>
+</dd>
+<dt class="hdlist1"><code>id</code></dt>
+<dd>
+<p>The unique identifier for the router. This ID will also be the container name at the AMQP protocol level.</p>
+</dd>
+</dl>
+</div>
+<div class="paragraph">
+<p>For information about additional attributes, see <a href="#router_configuration_file_router">Router</a> in the <em>Configuration Reference</em>.</p>
+</div>
+</div>
+</div>
+</li>
+<li>
+<p>If necessary for your environment, secure the router.</p>
+<div class="openblock">
+<div class="content">
+<div class="ulist">
+<ul>
+<li>
+<p><a href="#setting_up_ssl_for_encryption_and_authentication">Set up SSL/TLS for encryption, authentication, or both</a></p>
+</li>
+<li>
+<p><a href="#setting_up_sasl_for_authentication_and_payload_encryption">Set up SASL for authentication and payload encryption</a></p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</li>
+<li>
+<p>Connect the router to other routers, clients, and brokers.</p>
+<div class="openblock">
+<div class="content">
+<div class="ulist">
+<ul>
+<li>
+<p><a href="#adding_incoming_connections">Add incoming connections</a></p>
+</li>
+<li>
+<p><a href="#adding_outgoing_connections">Add outgoing connections</a></p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</li>
+<li>
+<p>Set up routing for your environment:</p>
+<div class="openblock">
+<div class="content">
+<div class="ulist">
+<ul>
+<li>
+<p><a href="#routing_messages_between_clients">Configure the router to route messages between clients directly</a></p>
+</li>
+<li>
+<p><a href="#routing_messages_through_broker">Configure the router to route messages through a broker queue</a></p>
+</li>
+<li>
+<p><a href="#creating_link_route">Create a link route to define a private messaging path between endpoints</a></p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</li>
+<li>
+<p><a href="#logging">Set up logging</a>.</p>
+</li>
+</ol>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="router_network_connections">5. Network Connections</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Connections define how the router communicates with clients, other routers, and brokers. You can configure <em>incoming connections</em> to define how the router listens for data from clients and other routers, and you can configure <em>outgoing connections</em> to define how the router sends data to other routers and brokers.</p>
+</div>
+<div class="sect2">
+<h3 id="adding_incoming_connections">5.1. Listening for Incoming Connections</h3>
+<div class="paragraph">
+<p>Listening for incoming connections involves setting the host and port on which the router should listen for traffic.</p>
+</div>
+<div class="olist arabic">
+<div class="title">Procedure</div>
+<ol class="arabic">
+<li>
+<p>In the router’s configuration file, add a <code>listener</code>:</p>
+<div class="openblock">
+<div class="content">
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">listener {
+ host: <em>HOST_NAME/ADDRESS</em>
+ port: <em>PORT_NUMBER/NAME</em>
+ ...
+}</pre>
+</div>
+</div>
+<div class="dlist">
+<dl>
+<dt class="hdlist1"><code>host</code></dt>
+<dd>
+<p>Either an IP address (IPv4 or IPv6) or hostname on which the router should listen for incoming connections.</p>
+</dd>
+<dt class="hdlist1"><code>port</code></dt>
+<dd>
+<p>The port number or symbolic service name on which the router should listen for incoming connections.</p>
+</dd>
+</dl>
+</div>
+<div class="paragraph">
+<p>For information about additional attributes, see <a href="#router_configuration_file_listener">Listener</a> in the <em>Configuration Reference</em>.</p>
+</div>
+</div>
+</div>
+</li>
+<li>
+<p>If necessary, <a href="#securing_incoming_connections">secure the connection</a>.</p>
+<div class="paragraph">
+<p>If you have set up SSL/TLS or SASL in your environment, you can configure the router to only accept encrypted or authenticated communication on this connection.</p>
+</div>
+</li>
+<li>
+<p>If you want the router to listen for incoming connections on additional hosts or ports, configure an additional <code>listener</code> entity for each host and port.</p>
+</li>
+</ol>
+</div>
+</div>
+<div class="sect2">
+<h3 id="adding_outgoing_connections">5.2. Adding Outgoing Connections</h3>
+<div class="paragraph">
+<p>Configuring outgoing connections involves setting the host and port on which the router connects to other routers and brokers.</p>
+</div>
+<div class="paragraph">
+<p>When a router connects to a broker, the broker might provide backup connection data that the router can use if the primary connection fails. If the primary connection fails, the router attempts to reconnect by using a combination of the primary and — if provided — backup connections in round-robin fashion until the connection is successful. For more information about viewing the backup connection data provided by the broker, see <a href="#managing_connectors">Managing Connectors</a>.</p>
+</div>
+<div class="olist arabic">
+<div class="title">Procedure</div>
+<ol class="arabic">
+<li>
+<p>In the router’s configuration file, add a <code>connector</code>:</p>
+<div class="openblock">
+<div class="content">
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">connector {
+ name: <em>NAME</em>
+ host: <em>HOST_NAME/ADDRESS</em>
+ port: <em>PORT_NUMBER/NAME</em>
+ ...
+}</pre>
+</div>
+</div>
+<div class="dlist">
+<dl>
+<dt class="hdlist1"><code>name</code></dt>
+<dd>
+<p>The name of the <code>connector</code>. You should specify a name that describes the entity to which the connector connects. This name is used by configured addresses (for example, a <code>linkRoute</code> entity) in order to specify which connection should be used for them.</p>
+</dd>
+<dt class="hdlist1"><code>host</code></dt>
+<dd>
+<p>Either an IP address (IPv4 or IPv6) or hostname on which the router should connect.</p>
+</dd>
+<dt class="hdlist1"><code>port</code></dt>
+<dd>
+<p>The port number or symbolic service name on which the router should connect.</p>
+</dd>
+</dl>
+</div>
+<div class="paragraph">
+<p>For information about additional attributes, see <a href="#router_configuration_file_connector">Connector</a> in the <em>Configuration Reference</em>.</p>
+</div>
+</div>
+</div>
+</li>
+<li>
+<p>If necessary, <a href="#securing_outgoing_connections">secure the connection</a>.</p>
+<div class="paragraph">
+<p>If you have set up SSL/TLS or SASL in your environment, you can configure the router to only send encrypted or authenticated communication on this connection.</p>
+</div>
+</li>
+<li>
+<p>For each remaining router or broker to which this router should connect, configure an additional <code>connector</code> entity.</p>
+</li>
+</ol>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="security_config">6. Security</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>You can configure Dispatch Router to communicate with clients, routers, and brokers in a secure way by authenticating and encrypting the router’s connections. Dispatch Router supports the following security protocols:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p><em>SSL/TLS</em> for certificate-based encryption and mutual authentication</p>
+</li>
+<li>
+<p><em>SASL</em> for authentication and payload encryption</p>
+</li>
+</ul>
+</div>
+<div class="sect2">
+<h3 id="setting_up_ssl_for_encryption_and_authentication">6.1. Setting Up SSL/TLS for Encryption and Authentication</h3>
+<div class="paragraph">
+<p>Before you can secure incoming and outgoing connections using SSL/TLS encryption and authentication, you must first set up the SSL/TLS profile in the router’s configuration file.</p>
+</div>
+<div class="paragraph">
+<div class="title">Prerequisites</div>
+<p>You must have the following files in PEM format:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>An X.509 CA certificate (used for signing the router certificate for the SSL/TLS server authentication feature).</p>
+</li>
+<li>
+<p>A private key (with or without password protection) for the router.</p>
+</li>
+<li>
+<p>An X.509 router certificate signed by the X.509 CA certificate.</p>
+</li>
+</ul>
+</div>
+<div class="ulist">
+<div class="title">Procedure</div>
+<ul>
+<li>
+<p>In the router’s configuration file, add an <code>sslProfile</code> section:</p>
+<div class="openblock">
+<div class="content">
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">sslProfile {
+ name: <em>NAME</em>
+ ciphers: <em>CIPHERS</em>
+ certDb: <em>PATH</em>.pem
+ certFile: <em>PATH</em>.pem
+ keyFile: <em>PATH</em>.pem
+ password: <em>PASSWORD/PATH_TO_PASSWORD_FILE</em>
+ ...
+}</pre>
+</div>
+</div>
+<div class="dlist">
+<dl>
+<dt class="hdlist1"><code>name</code></dt>
+<dd>
+<p>A name for the SSL/TLS profile. You can use this name to refer to the profile from the incoming and outgoing connections.</p>
+<div class="paragraph">
+<p>For example:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">name: router-ssl-profile</pre>
+</div>
+</div>
+</dd>
+<dt class="hdlist1"><code>ciphers</code></dt>
+<dd>
+<p>The SSL cipher suites that can be used by this SSL/TLS profile. If certain ciphers are unsuitable for your environment, you can use this attribute to restrict them from being used.</p>
+<div class="paragraph">
+<p>To enable a cipher list, enter one or more cipher strings separated by colons (<code>:</code>). For example:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">ciphers: ALL:!aNULL:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>To see the full list of available ciphers, use the <code>openssl ciphers</code> command. For more information about each cipher, see the <a href="https://www.openssl.org/docs/manmaster/man1/ciphers.html" target="_blank" rel="noopener">ciphers man page</a>.</p>
+</div>
+</dd>
+<dt class="hdlist1"><code>certDb</code></dt>
+<dd>
+<p>The absolute path to the database that contains the public certificates of trusted certificate authorities (CA).</p>
+<div class="paragraph">
+<p>For example:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">certDb: /qdrouterd/ssl_certs/ca-cert.pem</pre>
+</div>
+</div>
+</dd>
+<dt class="hdlist1"><code>certFile</code></dt>
+<dd>
+<p>The absolute path to the file containing the PEM-formatted public certificate to be used on the local end of any connections using this profile.</p>
+<div class="paragraph">
+<p>For example:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">certFile: /qdrouterd/ssl_certs/router-cert-pwd.pem</pre>
+</div>
+</div>
+</dd>
+<dt class="hdlist1"><code>keyFile</code></dt>
+<dd>
+<p>The absolute path to the file containing the PEM-formatted private key for the above certificate.</p>
+<div class="paragraph">
+<p>For example:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">keyFile: /qdrouterd/ssl_certs/router-key-pwd.pem</pre>
+</div>
+</div>
+</dd>
+<dt class="hdlist1"><code>passwordFile</code> or <code>password</code></dt>
+<dd>
+<p>If the private key is password-protected, you must provide the password by either specifying the absolute path to a file containing the password that unlocks the certificate key, or entering the password directly in the configuration file.</p>
+<div class="paragraph">
+<p>For example:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">password: routerKeyPassword</pre>
+</div>
+</div>
+</dd>
+</dl>
+</div>
+<div class="paragraph">
+<p>For information about additional <code>sslProfile</code> attributes, see <a href="#router_configuration_file_sslprofile"><em>sslProfile</em></a> in the <em>Configuration Reference</em>.</p>
+</div>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="setting_up_sasl_for_authentication_and_payload_encryption">6.2. Setting Up SASL for Authentication and Payload Encryption</h3>
+<div class="paragraph">
+<p>If you plan to use SASL to authenticate connections, you must first add the SASL attributes to the <code>router</code> entity in the router’s configuration file. These attributes define a set of SASL parameters that can be used by the router’s incoming and outgoing connections.</p>
+</div>
+<div class="paragraph">
+<div class="title">Prerequisites</div>
+<p>Before you can set up SASL, you must have the following:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p><a href="#generating_sasl_database">The SASL database is generated.</a></p>
+</li>
+<li>
+<p><a href="#configuring_sasl_database">The SASL configuration file is configured.</a></p>
+</li>
+</ul>
+</div>
+<div class="ulist">
+<div class="title">Procedure</div>
+<ul>
+<li>
+<p>In the router’s configuration file, add the following attributes to the <code>router</code> section:</p>
+<div class="openblock">
+<div class="content">
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">router {
+ ...
+ saslConfigPath: <em>PATH</em>
+ saslConfigName: <em>FILE_NAME</em>
+}</pre>
+</div>
+</div>
+<div class="dlist">
+<dl>
+<dt class="hdlist1"><code>saslConfigPath</code></dt>
+<dd>
+<p>The absolute path to the SASL configuration file.</p>
+<div class="paragraph">
+<p>For example:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">saslConfigPath: /qdrouterd/security</pre>
+</div>
+</div>
+</dd>
+<dt class="hdlist1"><code>saslConfigName</code></dt>
+<dd>
+<p>The name of the SASL configuration file. This name should <em>not</em> include the <code>.conf</code> file extension.</p>
+<div class="paragraph">
+<p>For example:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">saslConfigName: qdrouterd_sasl</pre>
+</div>
+</div>
+</dd>
+</dl>
+</div>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="securing_incoming_connections">6.3. Securing Incoming Connections</h3>
+<div class="paragraph">
+<p>You can secure incoming connections by configuring each connection’s <code>listener</code> entity for encryption, authentication, or both.</p>
+</div>
+<div class="paragraph">
+<div class="title">Prerequisites</div>
+<p>Before securing incoming connections, the security protocols you plan to use should be set up.</p>
+</div>
+<div class="ulist">
+<div class="title">Choices</div>
+<ul>
+<li>
+<p><a href="#adding_ssl_encryption_to_incoming_connection">Add SSL/TLS encryption</a></p>
+</li>
+<li>
+<p><a href="#adding_sasl_authentication_to_incoming_connection">Add SASL authentication</a></p>
+</li>
+<li>
+<p><a href="#adding_ssl_client_authentication_to_incoming_connection">Add SSL/TLS client authentication</a></p>
+</li>
+<li>
+<p><a href="#adding_sasl_payload_encryption_to_incoming_connection">Add SASL payload encryption</a></p>
+</li>
+</ul>
+</div>
+<div class="sect3">
+<h4 id="adding_ssl_encryption_to_incoming_connection">6.3.1. Adding SSL/TLS Encryption to an Incoming Connection</h4>
+<div class="paragraph">
+<p>You can configure an incoming connection to accept encrypted connections only. By adding SSL/TLS encryption, to connect to this router, a remote peer must first start an SSL/TLS handshake with the router and be able to validate the server certificate received by the router during the handshake.</p>
+</div>
+<div class="ulist">
+<div class="title">Procedure</div>
+<ul>
+<li>
+<p>In the router’s configuration file, add the following attributes to the connection’s <code>listener</code> entity:</p>
+<div class="openblock">
+<div class="content">
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">listener {
+ ...
+ sslProfile: <em>SSL_PROFILE_NAME</em>
+ requireSsl: yes
+}</pre>
+</div>
+</div>
+<div class="dlist">
+<dl>
+<dt class="hdlist1"><code>sslProfile</code></dt>
+<dd>
+<p>The name of the SSL/TLS profile you set up.</p>
+</dd>
+<dt class="hdlist1"><code>requireSsl</code></dt>
+<dd>
+<p>Enter <code>yes</code> to require all clients connecting to the router on this connection to use encryption.</p>
+</dd>
+</dl>
+</div>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect3">
+<h4 id="adding_sasl_authentication_to_incoming_connection">6.3.2. Adding SASL Authentication to an Incoming Connection</h4>
+<div class="paragraph">
+<p>You can configure an incoming connection to authenticate the client using SASL. You can use SASL authentication with or without SSL/TLS encryption.</p>
+</div>
+<div class="ulist">
+<div class="title">Procedure</div>
+<ul>
+<li>
+<p>In the router’s configuration file, add the following attributes to the connection’s <code>listener</code> section:</p>
+<div class="openblock">
+<div class="content">
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">listener {
+ ...
+ authenticatePeer: yes
+ saslMechanisms: <em>MECHANISMS</em>
+}</pre>
+</div>
+</div>
+<div class="dlist">
+<dl>
+<dt class="hdlist1"><code>authenticatePeer</code></dt>
+<dd>
+<p>Set this attribute to <code>yes</code> to require the router to authenticate the identity of a remote peer before it can use this incoming connection.</p>
+</dd>
+<dt class="hdlist1"><code>saslMechanisms</code></dt>
+<dd>
+<p>The SASL authentication mechanism (or mechanisms) to use for peer authentication. You can choose any of the Cyrus SASL authentication mechanisms <em>except</em> for <code>ANONYMOUS</code>. To specify multiple authentication mechanisms, separate each mechanism with a space.</p>
+<div class="paragraph">
+<p>For a full list of supported Cyrus SASL authentication mechanisms, see <a href="https://www.cyrusimap.org/sasl/sasl/authentication_mechanisms.html" target="_blank" rel="noopener">Authentication Mechanisms</a>.</p>
+</div>
+</dd>
+</dl>
+</div>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect3">
+<h4 id="adding_ssl_client_authentication_to_incoming_connection">6.3.3. Adding SSL/TLS Client Authentication to an Incoming Connection</h4>
+<div class="paragraph">
+<p>You can configure an incoming connection to authenticate the client using SSL/TLS.</p>
+</div>
+<div class="paragraph">
+<p>The base SSL/TLS configuration provides content encryption and server authentication, which means that remote peers can verify the router’s identity, but the router cannot verify a peer’s identity.</p>
+</div>
+<div class="paragraph">
+<p>However, you can require an incoming connection to use SSL/TLS client authentication, which means that remote peers must provide an additional certificate to the router during the SSL/TLS handshake. By using this certificate, the router can verify the client’s identity without using a username and password.</p>
+</div>
+<div class="paragraph">
+<p>You can use SSL/TLS client authentication with or without SASL authentication.</p>
+</div>
+<div class="ulist">
+<div class="title">Procedure</div>
+<ul>
+<li>
+<p>In the router’s configuration, file, add the following attribute to the connection’s <code>listener</code> entity:</p>
+<div class="openblock">
+<div class="content">
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">listener {
+ ...
+ authenticatePeer: yes
+}</pre>
+</div>
+</div>
+<div class="dlist">
+<dl>
+<dt class="hdlist1"><code>authenticatePeer</code></dt>
+<dd>
+<p>Set this attribute to <code>yes</code> to require the router to authenticate the identity of a remote peer before it can use this incoming connection.</p>
+</dd>
+</dl>
+</div>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect3">
+<h4 id="adding_sasl_payload_encryption_to_incoming_connection">6.3.4. Adding SASL Payload Encryption to an Incoming Connection</h4>
+<div class="paragraph">
+<p>If you do not use SSL/TLS, you can still encrypt the incoming connection by using SASL payload encryption.</p>
+</div>
+<div class="ulist">
+<div class="title">Procedure</div>
+<ul>
+<li>
+<p>In the router’s configuration file, add the following attributes to the connection’s <code>listener</code> section:</p>
+<div class="openblock">
+<div class="content">
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">listener {
+ ...
+ requireEncryption: yes
+ saslMechanisms: <em>MECHANISMS</em>
+}</pre>
+</div>
+</div>
+<div class="dlist">
+<dl>
+<dt class="hdlist1"><code>requireEncryption</code></dt>
+<dd>
+<p>Set this attribute to <code>yes</code> to require the router to use SASL payload encryption for the connection.</p>
+</dd>
+<dt class="hdlist1"><code>saslMechanisms</code></dt>
+<dd>
+<p>The SASL mechanism to use. You can choose any of the Cyrus SASL authentication mechanisms. To specify multiple authentication mechanisms, separate each mechanism with a space.</p>
+<div class="paragraph">
+<p>For a full list of supported Cyrus SASL authentication mechanisms, see <a href="https://www.cyrusimap.org/sasl/sasl/authentication_mechanisms.html" target="_blank" rel="noopener">Authentication Mechanisms</a>.</p>
+</div>
+</dd>
+</dl>
+</div>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="securing_outgoing_connections">6.4. Securing Outgoing Connections</h3>
+<div class="paragraph">
+<p>You can secure outgoing connections by configuring each connection’s <code>connector</code> entity for encryption, authentication, or both.</p>
+</div>
+<div class="paragraph">
+<div class="title">Prerequisites</div>
+<p>Before securing outgoing connections, the security protocols you plan to use should be set up.</p>
+</div>
+<div class="ulist">
+<div class="title">Choices</div>
+<ul>
+<li>
+<p><a href="#adding_ssl_authentication_to_outgoing_connection">Add SSL/TLS authentication</a></p>
+</li>
+<li>
+<p><a href="#adding_sasl_authentication_to_outgoing_connection">Add SASL authentication</a></p>
+</li>
+</u
<TRUNCATED>
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org
[02/13] qpid-site git commit: QPID-8015: Prepare the dispatch release
scripts for the new user guide
Posted by jr...@apache.org.
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/user-guide/index.html.in
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/user-guide/index.html.in b/input/releases/qpid-dispatch-master/user-guide/index.html.in
new file mode 100644
index 0000000..1f1e40a
--- /dev/null
+++ b/input/releases/qpid-dispatch-master/user-guide/index.html.in
@@ -0,0 +1,7826 @@
+<h1>Using Qpid Dispatch</h1>
+<div id="toc" class="toc">
+<div id="toctitle">Table of Contents</div>
+<ul class="sectlevel1">
+<li><a href="#introduction">1. Introduction</a>
+<ul class="sectlevel2">
+<li><a href="#overview">1.1. Overview</a></li>
+<li><a href="#benefits">1.2. Benefits</a></li>
+<li><a href="#features">1.3. Features</a></li>
+</ul>
+</li>
+<li><a href="#theory_of_operation">2. Theory of Operation</a>
+<ul class="sectlevel2">
+<li><a href="#overview_2">2.1. Overview</a></li>
+<li><a href="#connections">2.2. Connections</a>
+<ul class="sectlevel3">
+<li><a href="#listener">2.2.1. Listener</a></li>
+<li><a href="#connector">2.2.2. Connector</a></li>
+</ul>
+</li>
+<li><a href="#addresses">2.3. Addresses</a>
+<ul class="sectlevel3">
+<li><a href="#mobile_addresses">2.3.1. Mobile Addresses</a></li>
+<li><a href="#link_route_addresses">2.3.2. Link Route Addresses</a></li>
+</ul>
+</li>
+<li><a href="#message_routing">2.4. Message Routing</a>
+<ul class="sectlevel3">
+<li><a href="#routing_patterns">2.4.1. Routing Patterns</a></li>
+<li><a href="#routing_mechanisms">2.4.2. Routing Mechanisms</a></li>
+<li><a href="#message_settlement">2.4.3. Message Settlement</a></li>
+</ul>
+</li>
+<li><a href="#security">2.5. Security</a></li>
+</ul>
+</li>
+<li><a href="#getting_started">3. Getting Started</a>
+<ul class="sectlevel2">
+<li><a href="#starting_the_router">3.1. Starting the Router</a></li>
+<li><a href="#routing_messages_in_a_peer_to_peer_configuration">3.2. Routing Messages in a Peer-to-Peer Configuration</a>
+<ul class="sectlevel3">
+<li><a href="#starting_the_receiver_client">3.2.1. Starting the Receiver Client</a></li>
+<li><a href="#sending_messages">3.2.2. Sending Messages</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a href="#router_configuration">4. Configuration</a>
+<ul class="sectlevel2">
+<li><a href="#accessing_the_router_configuration_file">4.1. Accessing the Router Configuration File</a></li>
+<li><a href="#how_the_router_configuration_file_is_structured">4.2. How the Router Configuration File is Structured</a></li>
+<li><a href="#methods_for_changing_router_configuration">4.3. Changing a Router’s Configuration</a>
+<ul class="sectlevel3">
+<li><a href="#making_permanent_change_to_router_configuration">4.3.1. Making a Permanent Change to the Router’s Configuration</a></li>
+<li><a href="#changing_configuration_for_running_router">4.3.2. Changing the Configuration for a Running Router</a></li>
+</ul>
+</li>
+<li><a href="#default_configuration_settings">4.4. Default Configuration Settings</a></li>
+<li><a href="#setting_essential_configuration_properties">4.5. Setting Essential Configuration Properties</a></li>
+</ul>
+</li>
+<li><a href="#router_network_connections">5. Network Connections</a>
+<ul class="sectlevel2">
+<li><a href="#adding_incoming_connections">5.1. Listening for Incoming Connections</a></li>
+<li><a href="#adding_outgoing_connections">5.2. Adding Outgoing Connections</a></li>
+</ul>
+</li>
+<li><a href="#security_config">6. Security</a>
+<ul class="sectlevel2">
+<li><a href="#setting_up_ssl_for_encryption_and_authentication">6.1. Setting Up SSL/TLS for Encryption and Authentication</a></li>
+<li><a href="#setting_up_sasl_for_authentication_and_payload_encryption">6.2. Setting Up SASL for Authentication and Payload Encryption</a></li>
+<li><a href="#securing_incoming_connections">6.3. Securing Incoming Connections</a>
+<ul class="sectlevel3">
+<li><a href="#adding_ssl_encryption_to_incoming_connection">6.3.1. Adding SSL/TLS Encryption to an Incoming Connection</a></li>
+<li><a href="#adding_sasl_authentication_to_incoming_connection">6.3.2. Adding SASL Authentication to an Incoming Connection</a></li>
+<li><a href="#adding_ssl_client_authentication_to_incoming_connection">6.3.3. Adding SSL/TLS Client Authentication to an Incoming Connection</a></li>
+<li><a href="#adding_sasl_payload_encryption_to_incoming_connection">6.3.4. Adding SASL Payload Encryption to an Incoming Connection</a></li>
+</ul>
+</li>
+<li><a href="#securing_outgoing_connections">6.4. Securing Outgoing Connections</a>
+<ul class="sectlevel3">
+<li><a href="#adding_ssl_authentication_to_outgoing_connection">6.4.1. Adding SSL/TLS Client Authentication to an Outgoing Connection</a></li>
+<li><a href="#adding_sasl_authentication_to_outgoing_connection">6.4.2. Adding SASL Authentication to an Outgoing Connection</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a href="#routing">7. Routing</a>
+<ul class="sectlevel2">
+<li><a href="#comparison_of_message_routing_and_link_routing">7.1. Comparison of Message Routing and Link Routing</a>
+<ul class="sectlevel3">
+<li><a href="#when_to_use_message_routing">7.1.1. When to Use Message Routing</a></li>
+<li><a href="#when_to_use_link_routing">7.1.2. When to Use Link Routing</a></li>
+</ul>
+</li>
+<li><a href="#configuring_message_routing">7.2. Configuring Message Routing</a>
+<ul class="sectlevel3">
+<li><a href="#addresses_2">7.2.1. Addresses</a></li>
+<li><a href="#routing_patterns_overview">7.2.2. Routing Patterns</a></li>
+<li><a href="#message_settlement_2">7.2.3. Message Settlement</a></li>
+<li><a href="#routing_messages_between_clients">7.2.4. Routing Messages Between Clients</a></li>
+<li><a href="#routing_messages_through_broker">7.2.5. Routing Messages Through a Broker Queue</a></li>
+<li><a href="#example_routing_messages_through_broker_queues">7.2.6. Example: Routing Messages Through Broker Queues</a></li>
+</ul>
+</li>
+<li><a href="#configuring_link_routing">7.3. Configuring Link Routing</a>
+<ul class="sectlevel3">
+<li><a href="#link_route_addresses_2">7.3.1. Link Route Addresses</a></li>
+<li><a href="#link_route_routing_patterns">7.3.2. Link Route Routing Patterns</a></li>
+<li><a href="#link_route_flow_control">7.3.3. Link Route Flow Control</a></li>
+<li><a href="#creating_link_route">7.3.4. Creating a Link Route</a></li>
+<li><a href="#example_using_a_link_route_to_provide_client_isolation">7.3.5. Example: Using a Link Route to Provide Client Isolation</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a href="#logging">8. Logging</a>
+<ul class="sectlevel2">
+<li><a href="#logging_modules_you_can_configure">8.1. Logging Modules</a>
+<ul class="sectlevel3">
+<li><a href="#the_code_default_code_logging_module">8.1.1. The <code>DEFAULT</code> Logging Module</a></li>
+<li><a href="#the_code_router_code_logging_module">8.1.2. The <code>ROUTER</code> Logging Module</a></li>
+<li><a href="#the_code_router_core_code_logging_module">8.1.3. The <code>ROUTER_CORE</code> Logging Module</a></li>
+<li><a href="#the_code_router_hello_code_logging_module">8.1.4. The <code>ROUTER_HELLO</code> Logging Module</a></li>
+<li><a href="#the_code_router_ls_code_logging_module">8.1.5. The <code>ROUTER_LS</code> Logging Module</a></li>
+<li><a href="#the_code_router_ma_code_logging_module">8.1.6. The <code>ROUTER_MA</code> Logging Module</a></li>
+<li><a href="#the_code_message_code_logging_module">8.1.7. The <code>MESSAGE</code> Logging Module</a></li>
+<li><a href="#the_code_server_code_logging_module">8.1.8. The <code>SERVER</code> Logging Module</a></li>
+<li><a href="#the_code_agent_code_logging_module">8.1.9. The <code>AGENT</code> Logging Module</a></li>
+<li><a href="#the_code_container_code_logging_module">8.1.10. The <code>CONTAINER</code> Logging Module</a></li>
+<li><a href="#the_code_error_code_logging_module">8.1.11. The <code>ERROR</code> Logging Module</a></li>
+<li><a href="#the_code_policy_code_logging_module">8.1.12. The <code>POLICY</code> Logging Module</a></li>
+</ul>
+</li>
+<li><a href="#configure_default_logging">8.2. Configuring Logging</a></li>
+<li><a href="#viewing_log_entries">8.3. Viewing Log Entries</a>
+<ul class="sectlevel3">
+<li><a href="#viewing_log_entries_on_the_console">8.3.1. Viewing Log Entries on the Console</a></li>
+<li><a href="#viewing_log_entries_on_the_cli">8.3.2. Viewing Log Entries on the CLI</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a href="#policy">9. Policy</a>
+<ul class="sectlevel2">
+<li><a href="#definitions">9.1. Definitions</a>
+<ul class="sectlevel3">
+<li><a href="#vhost">9.1.1. vhost</a></li>
+</ul>
+</li>
+<li><a href="#policy_features">9.2. Policy Features</a>
+<ul class="sectlevel3">
+<li><a href="#total_connection_limit">9.2.1. Total Connection Limit</a></li>
+<li><a href="#vhost_policy">9.2.2. Vhost Policy</a></li>
+<li><a href="#default_vhost">9.2.3. Default Vhost</a></li>
+</ul>
+</li>
+<li><a href="#policy_schema">9.3. Policy Schema</a>
+<ul class="sectlevel3">
+<li><a href="#global_policy">9.3.1. Global Policy</a></li>
+<li><a href="#vhost_policy_2">9.3.2. Vhost Policy</a></li>
+<li><a href="#vhost_user_group_settings_map">9.3.3. Vhost User Group Settings Map</a></li>
+</ul>
+</li>
+<li><a href="#policy_wildcard_and_user_name_substitution">9.4. Policy Wildcard and User Name Substitution</a>
+<ul class="sectlevel3">
+<li><a href="#remote_host_wildcard">9.4.1. Remote Host Wildcard</a></li>
+<li><a href="#amqp_source_and_target_wildcard_and_name_substitution">9.4.2. AMQP Source and Target Wildcard and Name Substitution</a></li>
+</ul>
+</li>
+<li><a href="#composing_policies">9.5. Composing Policies</a>
+<ul class="sectlevel3">
+<li><a href="#example_1_user_policy_disabled">9.5.1. Example 1. User Policy Disabled</a></li>
+<li><a href="#example2">9.5.2. Example 2. All Users Have Simple Connection Limits</a></li>
+<li><a href="#example_3_admins_must_connect_from_localhost">9.5.3. Example 3. Admins Must Connect From Localhost</a></li>
+<li><a href="#example_4_limiting_possible_memory_consumption">9.5.4. Example 4. Limiting Possible Memory Consumption</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a href="#management">10. Management</a>
+<ul class="sectlevel2">
+<li><a href="#using_apache_qpid_dispatch_router_console">10.1. Using Apache Qpid Dispatch Router Console</a>
+<ul class="sectlevel3">
+<li><a href="#console-overview">10.1.1. Console Overview</a></li>
+<li><a href="#console-installation">10.1.2. Console Installation</a></li>
+<li><a href="#console-operation">10.1.3. Console Operation</a></li>
+</ul>
+</li>
+<li><a href="#monitoring_using_qdstat">10.2. Monitoring Dispatch Router Using <code>qdstat</code></a>
+<ul class="sectlevel3">
+<li><a href="#syntax_for_using_code_qdstat_code">10.2.1. Syntax for Using <code>qdstat</code></a></li>
+<li><a href="#viewing_general_statistics_for_a_router">10.2.2. Viewing General Statistics for a Router</a></li>
+<li><a href="#viewing_a_list_of_connections_to_a_router">10.2.3. Viewing a List of Connections to a Router</a></li>
+<li><a href="#viewing_amqp_links_attached_to_a_router">10.2.4. Viewing AMQP Links Attached to a Router</a></li>
+<li><a href="#viewing_known_routers_on_a_network">10.2.5. Viewing Known Routers on a Network</a></li>
+<li><a href="#viewing_addresses_known_to_a_router">10.2.6. Viewing Addresses Known to a Router</a></li>
+<li><a href="#viewing_a_router_s_autolinks">10.2.7. Viewing a Router’s Autolinks</a></li>
+<li><a href="#viewing_the_status_of_a_router_s_link_routes">10.2.8. Viewing the Status of a Router’s Link Routes</a></li>
+<li><a href="#viewing_memory_consumption_information">10.2.9. Viewing Memory Consumption Information</a></li>
+</ul>
+</li>
+<li><a href="#managing_router">10.3. Managing Dispatch Router Using <code>qdmanage</code></a>
+<ul class="sectlevel3">
+<li><a href="#syntax_for_using_code_qdmanage_code">10.3.1. Syntax for Using <code>qdmanage</code></a></li>
+<li><a href="#managing_network_connections">10.3.2. Managing Network Connections</a></li>
+<li><a href="#managing_security">10.3.3. Managing Security</a></li>
+<li><a href="#managing_routing">10.3.4. Managing Routing</a></li>
+<li><a href="#managing_logging">10.3.5. Managing Logging</a></li>
+</ul>
+</li>
+<li><a href="#management_entities">10.4. Management Entities</a></li>
+</ul>
+</li>
+<li><a href="#reliability">11. Reliability</a>
+<ul class="sectlevel2">
+<li><a href="#path_redundancy">11.1. Path Redundancy</a></li>
+<li><a href="#path_redundancy_and_temporal_decoupling">11.2. Path Redundancy and Temporal Decoupling</a></li>
+<li><a href="#sharded_queue">11.3. Sharded Queue</a></li>
+</ul>
+</li>
+<li><a href="#technical_details_specifications">12. Technical Details and Specifications</a>
+<ul class="sectlevel2">
+<li><a href="#client_compatibility">12.1. Client Compatibility</a></li>
+<li><a href="#amqp_mapping">12.2. AMQP Mapping</a>
+<ul class="sectlevel3">
+<li><a href="#message_annotations">12.2.1. Message Annotations</a></li>
+<li><a href="#sourcetarget_capabilities">12.2.2. Source/Target Capabilities</a></li>
+<li><a href="#dynamic_node_properties">12.2.3. Dynamic-Node-Properties</a></li>
+<li><a href="#addresses_and_address_formats">12.2.4. Addresses and Address Formats</a></li>
+<li><a href="#implementation_of_the_amqp_management_specification">12.2.5. Implementation of the AMQP Management Specification</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a href="#cyrus_sasl">Appendix A: Using Cyrus SASL to Provide Authentication</a>
+<ul class="sectlevel2">
+<li><a href="#generating_sasl_database">A.1. Generating a SASL Database</a></li>
+<li><a href="#viewing_users_in_a_sasl_database">A.2. Viewing Users in a SASL Database</a></li>
+<li><a href="#configuring_sasl_database">A.3. Configuring a SASL Database</a></li>
+</ul>
+</li>
+<li><a href="#router_configuration_reference">Appendix B: Configuration Reference</a>
+<ul class="sectlevel2">
+<li><a href="#configuration_file">B.1. Configuration File</a>
+<ul class="sectlevel3">
+<li><a href="#configuration_sections">B.1.1. Configuration Sections</a></li>
+</ul>
+</li>
+</ul>
+</li>
+</ul>
+</div>
+<div class="sect1">
+<h2 id="introduction">1. Introduction</h2>
+<div class="sectionbody">
+<div class="sect2">
+<h3 id="overview">1.1. Overview</h3>
+<div class="paragraph">
+<p>The Dispatch Router is an AMQP 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>
+</div>
+<div class="paragraph">
+<p>A messaging client can make a single AMQP connection into a messaging
+bus built of Dispatch Router 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>
+</div>
+<div class="paragraph">
+<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>
+</div>
+<div class="paragraph">
+<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>
+</div>
+<div class="paragraph">
+<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 immediately if there is nobody
+to serve the request, but typically it can only wait for a timeout to
+discover this. With a Dispatch Router 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>
+</div>
+<div class="paragraph">
+<p>For an exampe of using Dispatch Router 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 Router 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>
+</div>
+<div class="paragraph">
+<p>Dispatch 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>
+<div class="sect2">
+<h3 id="benefits">1.2. Benefits</h3>
+<div class="paragraph">
+<p>Simplifies connectivity</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>An endpoint can do all of its messaging through a single transport
+connection</p>
+</li>
+<li>
+<p>Avoid opening holes in firewalls for incoming connections</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Provides messaging connectivity where there is no TCP/IP connectivity</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>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).</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Simplifies reliability</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Reliability and availability are provided using redundant topology,
+not server clustering</p>
+</li>
+<li>
+<p>Reliable end-to-end messaging without persistent stores</p>
+</li>
+<li>
+<p>Use a message broker only when you need store-and-forward semantics</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="features">1.3. Features</h3>
+<div class="ulist">
+<ul>
+<li>
+<p>Can be deployed stand-alone or in a network of routers</p>
+<div class="ulist">
+<ul>
+<li>
+<p>Supports arbitrary network topology - no restrictions on redundancy</p>
+<div class="ulist">
+<ul>
+<li>
+<p>Automatic route computation - adjusts quickly to changes in topology</p>
+</li>
+</ul>
+</div>
+</li>
+</ul>
+</div>
+</li>
+<li>
+<p>Provides remote access to brokers or other AMQP servers</p>
+</li>
+<li>
+<p>Security</p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="theory_of_operation">2. Theory of Operation</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>This section introduces some key concepts about the router.</p>
+</div>
+<div class="sect2">
+<h3 id="overview_2">2.1. Overview</h3>
+<div class="paragraph">
+<p>The Dispatch Router is an <em>application layer</em> program running as a normal
+user program or as a daemon.</p>
+</div>
+<div class="paragraph">
+<p>Dispatch Router accepts AMQP connections from clients and creates AMQP
+connections to brokers or AMQP-based services. Dispatch Router classifies
+incoming AMQP messages and routes the
+messages between message producers and message consumers.</p>
+</div>
+<div class="paragraph">
+<p>Dispatch 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 message source to every message
+destination and to recover quickly from failures. Dispatch Router relies on
+redundant network paths to provide continued connectivity in the face
+of system or network failure.</p>
+</div>
+<div class="paragraph">
+<p>A messaging client can make a single AMQP connection into a messaging
+bus built with routers and, over that connection, exchange messages
+with one or more message brokers connected to any router in the
+network. At the same time the client can exchange messages directly
+with other endpoints without involving a broker at all.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="connections">2.2. Connections</h3>
+<div class="paragraph">
+<p>Dispatch Router connects clients, servers, AMQP services, and other
+routers through network connections.</p>
+</div>
+<div class="sect3">
+<h4 id="listener">2.2.1. Listener</h4>
+<div class="paragraph">
+<p>Dispatch Router provides <em>listeners</em> that accept client connections.
+A client connecting to a router listener uses the
+same methods that it would use to connect to a broker. From the
+client’s perspective the router connection and link establishment are
+identical to broker connection and link establishment.</p>
+</div>
+<div class="paragraph">
+<p>Several types of listeners are defined by their role.</p>
+</div>
+<table class="tableblock frame-all grid-all spread">
+<colgroup>
+<col style="width: 20%;">
+<col style="width: 80%;">
+</colgroup>
+<tbody>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Role</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Description</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">normal</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">The connection is used for AMQP clients using normal message delivery.</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">inter-router</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">The connection is assumed to be to another router in the network. Inter-router discovery and routing protocols can only be used over inter-router connections.</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">route-container</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">The connection is a broker or other resource that holds known addresses. The router will use this connection to create links as necessary. The addresses are available for routing only after the remote resource has created a connection.</p></td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="sect3">
+<h4 id="connector">2.2.2. Connector</h4>
+<div class="paragraph">
+<p>Dispatch Router can also be configured to create outbound connections to
+messaging brokers or other AMQP entities using <em>connectors</em>. A
+connector is defined with the network address of the broker and the
+name or names of the resources that are available in that broker. When
+a router connects to a broker through a connector it uses the same
+methods a normal messaging client would use when connecting to the
+broker.</p>
+</div>
+<div class="paragraph">
+<p>Several types of connectors are defined by their role.</p>
+</div>
+<table class="tableblock frame-all grid-all spread">
+<colgroup>
+<col style="width: 20%;">
+<col style="width: 80%;">
+</colgroup>
+<tbody>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Role</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Description</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">normal</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">The connection is used for AMQP clients using normal message delivery. On this connector the router will initiate the connection but it will never create any links. Links are to be created by the peer that accepts the connection.</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">inter-router</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">The connection is assumed to be to another router in the network. Inter-router discovery and routing protocols can only be used over inter-router connections.</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">route-container</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">The connection is to a broker or other resource that holds known addresses. The router will use this connection to create links as necessary. The addresses are available for routing only after the router has created a connection to the remote resource.</p></td>
+</tr>
+</tbody>
+</table>
+</div>
+</div>
+<div class="sect2">
+<h3 id="addresses">2.3. Addresses</h3>
+<div class="paragraph">
+<p>AMQP addresses are used to control the flow of messages across a
+network of routers. Addresses are used in a number of different places
+in the AMQP 1.0 protocol. They can be used in a specific message in
+the <em>to</em> and <em>reply-to</em> fields of a message’s properties. They are also
+used during the creation of links in the <em>address</em> field of a <em>source</em> or
+a <em>target</em>.</p>
+</div>
+<div class="admonitionblock note">
+<table>
+<tr>
+<td class="icon">
+<div class="title">Note</div>
+</td>
+<td class="content">
+<div class="paragraph">
+<p>Addresses in this discussion refer to AMQP protocol addresses and not
+to TCP/IP network addresses. TCP/IP network addresses are used by
+messaging clients, brokers, and routers to create AMQP connections.
+AMQP protocol addresses are the names of source and destination
+endpoints for messages within the messaging network.</p>
+</div>
+</td>
+</tr>
+</table>
+</div>
+<div class="paragraph">
+<p>Addresses designate various kinds of entities in a messaging network:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Endpoint processes that consume data or offer a service</p>
+</li>
+<li>
+<p>Topics that match multiple consumers to multiple producers</p>
+</li>
+<li>
+<p>Entities within a messaging broker:</p>
+<div class="ulist">
+<ul>
+<li>
+<p>Queues</p>
+</li>
+<li>
+<p>Durable Topics</p>
+</li>
+<li>
+<p>Exchanges</p>
+</li>
+</ul>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>The syntax of an AMQP address is opaque as far as the router network
+is concerned. A syntactical structure may be used by the administrator
+who creates addresses but the router treats them as opaque
+strings.</p>
+</div>
+<div class="paragraph">
+<p>Dispatch Router maintains several classes of address based on how the address is
+configured or discovered.</p>
+</div>
+<table class="tableblock frame-all grid-all spread">
+<colgroup>
+<col style="width: 25%;">
+<col style="width: 75%;">
+</colgroup>
+<tbody>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Address Type</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Description</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">mobile</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">The address is a rendezvous point between senders and receivers. The router aggregates and serializes messages from senders and distributes messages to receivers.</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">link route</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">The address defines a private messaging path between a sender and a receiver. The router simply passes messages between the end points.</p></td>
+</tr>
+</tbody>
+</table>
+<div class="sect3">
+<h4 id="mobile_addresses">2.3.1. Mobile Addresses</h4>
+<div class="paragraph">
+<p>Routers consider addresses to be mobile such that any users of an
+address may be directly connected to any router in a network and may
+move around the topology. In cases where messages are broadcast to or
+balanced across multiple consumers, the address users may be connected
+to multiple routers in the network.</p>
+</div>
+<div class="paragraph">
+<p>Mobile addresses are rendezvous points for senders and receivers.
+Messages arrive at the mobile address and are dispatched to their
+destinations according to the routing defined for the mobile address.
+The details of these routing patterns are discussed later.</p>
+</div>
+<div class="paragraph">
+<p>Mobile addresses may be discovered during normal router operation or
+configured through management settings.</p>
+</div>
+<div class="sect4">
+<h5 id="discovered_mobile_addresses">Discovered Mobile Addresses</h5>
+<div class="paragraph">
+<p>Mobile addresses are created when a client creates a link to a source
+or destination address that is unknown to the router network.</p>
+</div>
+<div class="paragraph">
+<p>Suppose a service provider wants to offer <em>my-service</em> that clients
+may use. The service provider must open a receiver link with source
+address <em>my-service</em>. The router creates a mobile address
+<em>my-service</em> and propagates the address so that it is known to every
+router in the network.</p>
+</div>
+<div class="paragraph">
+<p>Later a client wants to use the service and creates a sending link
+with target address <em>my-service</em>. The router matches the service
+provider’s receiver having source address <em>my-service</em> to the client’s
+sender having target address <em>my-service</em> and routes messages between
+the two.</p>
+</div>
+<div class="paragraph">
+<p>Any number of other clients can create links to the service as
+well. The clients do not have to know where in the router network the
+service provider is physically located nor are the clients required to
+connect to a specific router to use the service. Regardless of how
+many clients are using the service the service provider needs only a
+single connection and link into the router network.</p>
+</div>
+<div class="paragraph">
+<p>Another view of this same scenario is when a client tries to use the
+service before service provider has connected to the network. In this
+case the router network creates the mobile address <em>my-service</em> as
+before. However, since the mobile address has only client sender links
+and no receiver links the router stalls the clients and prevents them
+from sending any messages. Later, after the service provider connects
+and creates the receiver link, the router will issue credits to the
+clients and the messages will begin to flow between the clients and
+the service.</p>
+</div>
+<div class="paragraph">
+<p>The service provider can connect, disconnect, and reconnect from a
+different location without having to change any of the clients or
+their connections. Imagine having the service running on a
+laptop. One day the connection is from corporate headquarters and the
+next day the connection is from some remote location. In this case the
+service provider’s computer will typically have different host IP
+addresses for each connection. Using the router network the service
+provider connects to the router network and offers the named service
+and the clients connect to the router network and consume from the
+named service. The router network routes messages between the mobile
+addresses effectively masking host IP addresses of the service
+provider and the client systems.</p>
+</div>
+</div>
+<div class="sect4">
+<h5 id="configured_mobile_addresses">Configured Mobile Addresses</h5>
+<div class="paragraph">
+<p>Mobile addresses may be configured using the router <em>autoLink</em>
+object. An address created via an <em>autoLink</em> represents a queue,
+topic, or other service in an external broker. Logically the
+<em>autoLink</em> addresses are treated by the router network as if the
+broker had connected to the router and offered the services itself.</p>
+</div>
+<div class="paragraph">
+<p>For each configured mobile address the router will create a single
+link to the external resource. Messages flow between sender links and
+receiver links the same regardless if the mobile address was
+discovered or configured.</p>
+</div>
+<div class="paragraph">
+<p>Multiple <em>autoLink</em> objects may define the same address on multiple
+brokers. In this case the router network creates a sharded resource
+split between the brokers. Any client can seamlessly send and receive
+messages from either broker.</p>
+</div>
+<div class="paragraph">
+<p>Note that the brokers do not need to be clustered or federated to
+receive this treatment. The brokers may even be from different vendors
+or be different versions of the same broker yet still work together to
+provide a larger service platform.</p>
+</div>
+</div>
+</div>
+<div class="sect3">
+<h4 id="link_route_addresses">2.3.2. Link Route Addresses</h4>
+<div class="paragraph">
+<p>Link route addresses may be configured using the router <em>linkRoute</em>
+object. An link route address represents a queue, topic, or other
+service in an external broker similar to addresses configured by
+<em>autoLink</em> objects. For link route addresses the router propagates a
+separate link attachment to the broker resource for each incoming
+client link. The router does not automatically create any links to the
+broker resource.</p>
+</div>
+<div class="paragraph">
+<p>Using link route addresses the router network does not participate in
+aggregated message distribution. The router simply passes message
+delivery and settlement between the two end points.</p>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="message_routing">2.4. Message Routing</h3>
+<div class="paragraph">
+<p>Addresses have semantics associated with them that are assigned when
+the address is provisioned or discovered. The semantics of an address
+control how routers behave when they see the address being
+used. Address semantics include the following considerations:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Routing pattern - balanced, closest, multicast</p>
+</li>
+<li>
+<p>Routing mechanism - message routed, link routed</p>
+</li>
+</ul>
+</div>
+<div class="sect3">
+<h4 id="routing_patterns">2.4.1. Routing Patterns</h4>
+<div class="paragraph">
+<p>Routing patterns define the paths that a message with a mobile address can take across a network. These routing patterns can be used for both direct routing, in which the router distributes messages between clients without a broker, and indirect routing, in which the router enables clients to exchange messages through a broker.</p>
+</div>
+<table class="tableblock frame-all grid-all spread">
+<colgroup>
+<col style="width: 20%;">
+<col style="width: 80%;">
+</colgroup>
+<tbody>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Pattern</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Description</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Balanced</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">An anycast method which allows multiple receivers to use the same address. In this case, messages (or links) are routed to exactly one of the receivers and the network attempts to balance the traffic load across the set of receivers using the same address. This routing delivers messages to receivers based on how quickly they settle the deliveries. Faster receivers get more messages.</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Closest</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">An anycast method in which even if there are more receivers for the same address, every message is sent along the shortest path to reach the destination. This means that only one receiver will get the message. Each message is delivered to the closest receivers in terms of topology cost. If there are multiple receivers with the same lowest cost, deliveries will be spread evenly among those receivers.</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Multicast</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Having multiple consumers on the same address at the same time, messages are routed such that each consumer receives one copy of the message.</p></td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="sect3">
+<h4 id="routing_mechanisms">2.4.2. Routing Mechanisms</h4>
+<div class="paragraph">
+<p>The fact that addresses can be used in different ways suggests that
+message routing can be accomplished in different ways. Before going
+into the specifics of the different routing mechanisms, it would be
+good to first define what is meant by the term <em>routing</em>:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>In a network built of multiple, interconnected routers 'routing'
+determines which connection to use to send a message directly
+to its destination or one step closer to its destination.</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Each router serves as the terminus of a collection of incoming and
+outgoing links. Some of the links are designated for message routing,
+and others are designated for link routing. In both cases, the links
+either connect directly to endpoints that produce and consume
+messages, or they connect to other routers in the network along
+previously established connections.</p>
+</div>
+<div class="sect4">
+<h5 id="message_routed">Message Routed</h5>
+<div class="paragraph">
+<p>Message routing occurs upon delivery of a message and is done based on
+the address in the message’s <em>to</em> field.</p>
+</div>
+<div class="paragraph">
+<p>When a delivery arrives on an incoming message-routing link, the
+router extracts the address from the delivered message’s <em>to</em> field and
+looks the address up in its routing table. The lookup results in zero
+or more outgoing links onto which the message shall be resent.</p>
+</div>
+<div class="paragraph">
+<p>Message routing can also occur without an address in the
+message’s <em>to</em> field if the incoming link has a target address. In
+fact, if the sender uses a link with a target address, the <em>to</em> field
+shall be ignored even if used.</p>
+</div>
+</div>
+<div class="sect4">
+<h5 id="link_routed">Link Routed</h5>
+<div class="paragraph">
+<p>Link routing occurs when a new link is attached to the router across
+one of its AMQP connections. It is done based on the <em>target.address</em>
+field of an inbound link and the <em>source.address</em> field of an outbound
+link.</p>
+</div>
+<div class="paragraph">
+<p>Link routing uses the same routing table that message routing
+uses. The difference is that the routing occurs during the link-attach
+operation, and link attaches are propagated along the appropriate path
+to the destination. What results is a chain of links, connected
+end-to-end, from source to destination. It is similar to a virtual
+circuit in a telecom system.</p>
+</div>
+<div class="paragraph">
+<p>Each router in the chain holds pairs of link termini that are tied
+together. The router then simply exchanges all deliveries, delivery
+state changes, and link state changes between the two termini.</p>
+</div>
+<div class="paragraph">
+<p>The endpoints that use the link chain do not see any difference in
+behavior between a link chain and a single point-to-point link. All of
+the features available in the link protocol (flow control,
+transactional delivery, etc.) are available over a routed link-chain.</p>
+</div>
+</div>
+</div>
+<div class="sect3">
+<h4 id="message_settlement">2.4.3. Message Settlement</h4>
+<div class="paragraph">
+<p>Messages may be delivered with varying degrees of reliability.</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>At most once</p>
+</li>
+<li>
+<p>At least once</p>
+</li>
+<li>
+<p>Exactly once</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>The reliability is negotiated between the client and server during
+link establishment. The router handles all levels of reliability by treating
+messages as either <em>pre-settled</em> or <em>unsettled</em>.</p>
+</div>
+<table class="tableblock frame-all grid-all spread">
+<colgroup>
+<col style="width: 20%;">
+<col style="width: 80%;">
+</colgroup>
+<tbody>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Delivery</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Handling</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">pre-settled</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">If the arriving delivery is pre-settled (i.e., fire and forget), the incoming delivery shall be settled by the router, and the outgoing deliveries shall also be pre-settled. In other words, the pre-settled nature of the message delivery is propagated across the network to the message’s destination.</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">unsettled</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Unsettled delivery is also propagated across the network. Because unsettled delivery records cannot be discarded, the router tracks the incoming deliveries and keeps the association of the incoming deliveries to the resulting outgoing deliveries. This kept association allows the router to continue to propagate changes in delivery state (settlement and disposition) back and forth along the path which the message traveled.</p></td>
+</tr>
+</tbody>
+</table>
+</div>
+</div>
+<div class="sect2">
+<h3 id="security">2.5. Security</h3>
+<div class="paragraph">
+<p>Dispatch Router uses the SSL protocol and related certificates and SASL
+protocol mechanisms to encrypt and authenticate remote peers. Router
+listeners act as network servers and router connectors act as network
+clients. Both connection types may be configured securely with SSL
+and SASL.</p>
+</div>
+<div class="paragraph">
+<p>The router <code>policy</code> module is an optional authorization mechanism
+enforcing user connection restrictions and AMQP resource access
+control.</p>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="getting_started">3. Getting Started</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Before configuring Dispatch Router, you should understand how to start the router, how it is configured by default, and how to use it in a simple peer-to-peer configuration.</p>
+</div>
+<div class="sect2">
+<h3 id="starting_the_router">3.1. Starting the Router</h3>
+<div class="olist arabic">
+<div class="title">Procedure</div>
+<ol class="arabic">
+<li>
+<p>To start the router, use the <strong><code>qdrouterd</code></strong> command.</p>
+<div class="openblock">
+<div class="content">
+<div class="paragraph">
+<p>This example uses the default configuration to start the router as a daemon:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">$ qdrouterd -d</pre>
+</div>
+</div>
+</div>
+</div>
+<div class="admonitionblock note">
+<table>
+<tr>
+<td class="icon">
+<div class="title">Note</div>
+</td>
+<td class="content">
+<div class="paragraph">
+<p>You can specify a different configuration file with which to start the router. For more information, see <a href="#methods_for_changing_router_configuration"><em>Changing a Router’s Configuration</em></a>.</p>
+</div>
+</td>
+</tr>
+</table>
+</div>
+<div class="paragraph">
+<p>The router starts, using the default configuration file stored at <code>/etc/qpid-dispatch/qdrouterd.conf</code>.</p>
+</div>
+</li>
+<li>
+<p>View the log to verify the router status:</p>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">$ qdstat --log</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>This example shows that the router was correctly installed, is running, and is ready to route traffic between clients:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">$ qdstat --log
+Fri May 20 09:38:03 2017 SERVER (info) Container Name: Router.A <b class="conum">(1)</b>
+Fri May 20 09:38:03 2017 ROUTER (info) Router started in Standalone mode <b class="conum">(2)</b>
+Fri May 20 09:38:03 2017 ROUTER_CORE (info) Router Core thread running. 0/Router.A
+Fri May 20 09:38:03 2017 ROUTER_CORE (info) In-process subscription M/$management
+Fri May 20 09:38:03 2017 AGENT (info) Activating management agent on $_management_internal <b class="conum">(3)</b>
+Fri May 20 09:38:03 2017 ROUTER_CORE (info) In-process subscription L/$management
+Fri May 20 09:38:03 2017 ROUTER_CORE (info) In-process subscription L/$_management_internal
+Fri May 20 09:38:03 2017 DISPLAYNAME (info) Activating DisplayNameService on $displayname
+Fri May 20 09:38:03 2017 ROUTER_CORE (info) In-process subscription L/$displayname
+Fri May 20 09:38:03 2017 CONN_MGR (info) Configured Listener: 0.0.0.0:amqp proto=any role=normal <b class="conum">(4)</b>
+Fri May 20 09:38:03 2017 POLICY (info) Policy configured maximumConnections: 0, policyFolder: '', access rules enabled: 'false'
+Fri May 20 09:38:03 2017 POLICY (info) Policy fallback defaultApplication is disabled
+Fri May 20 09:38:03 2017 SERVER (info) Operational, 4 Threads Running <b class="conum">(5)</b></pre>
+</div>
+</div>
+<div class="colist arabic">
+<ol>
+<li>
+<p>The name of this router instance.</p>
+</li>
+<li>
+<p>By default, the router starts in <em>standalone</em> mode, which means that it cannot connect to other routers or be used in a router network.</p>
+</li>
+<li>
+<p>The management agent. It provides the <code>$management</code> address, through which management tools such as <code>qdmanage</code> and <code>qdstat</code> can perform create, read, update, and delete (CRUD) operations on the router. As an AMQP endpoint, the management agent supports all operations defined by the <a href="https://www.oasis-open.org/committees/download.php/54441/AMQP%20Management%20v1.0%20WD09">AMQP management specification (Draft 9)</a>.</p>
+</li>
+<li>
+<p>A listener is started on all available network interfaces and listens for connections on the standard AMQP port (5672, which is not encrypted).</p>
+</li>
+<li>
+<p>Threads for handling message traffic and all other internal operations.</p>
+</li>
+</ol>
+</div>
+</li>
+</ol>
+</div>
+</div>
+<div class="sect2">
+<h3 id="routing_messages_in_a_peer_to_peer_configuration">3.2. Routing Messages in a Peer-to-Peer Configuration</h3>
+<div class="paragraph">
+<p>This example demonstrates how the router can connect clients by receiving and sending messages between them. It uses the router’s default configuration file and does not require a broker.</p>
+</div>
+<div class="imageblock" style="text-align: center">
+<div class="content">
+<img src="images/01-peer-to-peer.png" alt="Peer-to-peer Communication">
+</div>
+<div class="title">Figure 1. Peer-to-peer Communication</div>
+</div>
+<div class="paragraph">
+<p>As the diagram indicates, the configuration consists of an Dispatch Router component with two clients connected to it: a sender and a receiver. The receiver wants to receive messages on a specific address, and the sender sends
+messages to that address.</p>
+</div>
+<div class="paragraph">
+<p>A broker is not used in this example, so there is no <em>"store and forward"</em> mechanism in the middle. Instead, the messages flow from sender to receiver only if the receiver is online, and the sender can confirm that the messages have arrived at their destination.</p>
+</div>
+<div class="paragraph">
+<p>This example uses a Apache Qpid Proton Python client to start a receiver client, and then send five messages from the sender client.</p>
+</div>
+<div class="paragraph">
+<div class="title">Prerequisites</div>
+<p>Apache Qpid Proton Python must be installed before you can complete the peer-to-peer routing example. For more information, see <a href="https://qpid.apache.org/proton/" class="bare">https://qpid.apache.org/proton/</a>.</p>
+</div>
+<div class="olist arabic">
+<div class="title">Procedure</div>
+<ol class="arabic">
+<li>
+<p><a href="#starting_the_receiver_client">Start the receiver client</a>.</p>
+</li>
+<li>
+<p><a href="#sending_messages">Send messages</a>.</p>
+</li>
+</ol>
+</div>
+<div class="sect3">
+<h4 id="starting_the_receiver_client">3.2.1. Starting the Receiver Client</h4>
+<div class="paragraph">
+<p>In this example, the receiver client is started first. This means that the messages will be sent as soon as the sender client is started.</p>
+</div>
+<div class="admonitionblock note">
+<table>
+<tr>
+<td class="icon">
+<div class="title">Note</div>
+</td>
+<td class="content">
+<div class="paragraph">
+<p>In practice, the order in which you start senders and receivers does not matter. In both cases, messages will be sent as soon as the receiver comes online.</p>
+</div>
+</td>
+</tr>
+</table>
+</div>
+<div class="ulist">
+<div class="title">Procedure</div>
+<ul>
+<li>
+<p>To start the receiver by using the Python receiver client, navigate to the Python examples directory and run the <code>simple_recv.py</code> example:</p>
+<div class="openblock">
+<div class="content">
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">$ cd <em>INSTALL_DIR</em>/examples/python/
+$ python simple_recv.py -a 127.0.0.1:5672/examples -m 5</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>This command starts the receiver and listens on the default address (<code>127.0.0.1:5672/examples</code>). The receiver is also set to receive a maximum of five messages.</p>
+</div>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect3">
+<h4 id="sending_messages">3.2.2. Sending Messages</h4>
+<div class="paragraph">
+<p>After starting the receiver client, you can send messages from the sender. These messages will travel through the router to the receiver.</p>
+</div>
+<div class="ulist">
+<div class="title">Procedure</div>
+<ul>
+<li>
+<p>In a new terminal window, navigate to the Python examples directory and run the <code>simple_send.py</code> example:</p>
+<div class="openblock">
+<div class="content">
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">$ cd <em>INSTALL_DIR</em>/examples/python/
+$ python simple_send.py -a 127.0.0.1:5672/examples -m 5</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>This command sends five auto-generated messages to the default address (<code>127.0.0.1:5672/examples</code>) and then confirms that they were delivered and acknowledged by the receiver:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">all messages confirmed</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>The receiver client receives the messages and displays their content:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">{u'sequence': 1L}
+{u'sequence': 2L}
+{u'sequence': 3L}
+{u'sequence': 4L}
+{u'sequence': 5L}</pre>
+</div>
+</div>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="router_configuration">4. Configuration</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Before starting Dispatch Router, you should understand where the router’s configuration file is stored, how the file is structured, and the methods you can use to modify it.</p>
+</div>
+<div class="sect2">
+<h3 id="accessing_the_router_configuration_file">4.1. Accessing the Router Configuration File</h3>
+<div class="paragraph">
+<p>The router’s configuration is defined in the router configuration file. You can access this file to view and modify that configuration.</p>
+</div>
+<div class="ulist">
+<div class="title">Procedure</div>
+<ul>
+<li>
+<p>Open the following file: <code>/etc/qpid-dispatch/qdrouterd.conf</code>.</p>
+<div class="openblock">
+<div class="content">
+<div class="paragraph">
+<p>When Dispatch Router is installed, <code>qdrouterd.conf</code> is installed in this directory by default. When the router is started, it runs with the settings defined in this file.</p>
+</div>
+<div class="paragraph">
+<p>For more information about the router configuration file (including available entities and attributes), see the <a href="https://qpid.apache.org/releases/qpid-dispatch-0.8.0/man/qdrouterd.html">qdrouterd man page</a>.</p>
+</div>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="how_the_router_configuration_file_is_structured">4.2. How the Router Configuration File is Structured</h3>
+<div class="paragraph">
+<p>Before you can make changes to a router configuration file, you should understand how the file is structured.</p>
+</div>
+<div class="paragraph">
+<p>The configuration file contains sections. A section is a configurable entity, and it contains a set of attribute name-value pairs that define the settings for that entity. The syntax is as follows:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">sectionName {
+ attributeName: attributeValue
+ attributeName: attributeValue
+ ...
+}</pre>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="methods_for_changing_router_configuration">4.3. Changing a Router’s Configuration</h3>
+<div class="paragraph">
+<p>You can use different methods for changing a router’s configuration based on whether the router is currently running, and whether you want the change to take effect immediately.</p>
+</div>
+<div class="ulist">
+<div class="title">Choices</div>
+<ul>
+<li>
+<p><a href="#making_permanent_change_to_router_configuration">Make a permanent change to the router’s configuration</a>.</p>
+</li>
+<li>
+<p><a href="#changing_configuration_for_running_router">Change the configuration for a running router.</a></p>
+</li>
+</ul>
+</div>
+<div class="sect3">
+<h4 id="making_permanent_change_to_router_configuration">4.3.1. Making a Permanent Change to the Router’s Configuration</h4>
+<div class="paragraph">
+<p>You can make a permanent change to the router’s configuration by editing the router’s configuration file directly. You must restart the router for the changes to take effect, but the changes will be saved even if the router is stopped.</p>
+</div>
+<div class="olist arabic">
+<div class="title">Procedure</div>
+<ol class="arabic">
+<li>
+<p>Do one of the following:</p>
+<div class="ulist">
+<ul>
+<li>
+<p>Edit the default configuration file (<code>/etc/qpid-dispatch/qdrouterd.conf</code>).</p>
+</li>
+<li>
+<p>Create a new configuration file.</p>
+</li>
+</ul>
+</div>
+</li>
+<li>
+<p>Start (or restart) the router.</p>
+<div class="paragraph">
+<p>If you created a new configuration file, you must specify the path using the <code>--conf</code> parameter. For example, the following command starts the router with a non-default configuration file:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap"># qdrouterd -d --conf /etc/qpid-dispatch/new-configuration-file.conf</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</div>
+<div class="sect3">
+<h4 id="changing_configuration_for_running_router">4.3.2. Changing the Configuration for a Running Router</h4>
+<div class="paragraph">
+<p>If the router is running, you can change its configuration on the fly. The changes you make take effect immediately, but are lost if the router is stopped.</p>
+</div>
+<div class="ulist">
+<div class="title">Procedure</div>
+<ul>
+<li>
+<p>Use <code>qdmanage</code> to change the configuration.</p>
+<div class="paragraph">
+<p>For more information about using <code>qdmanage</code>, see <a href="#managing_router">Managing Dispatch Router Using <em>qdmanage</em></a>.</p>
+</div>
+</li>
+</ul>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="default_configuration_settings">4.4. Default Configuration Settings</h3>
+<div class="paragraph">
+<p>The router’s configuration file controls the way in which the router functions. The default configuration file contains the minimum number of settings required for the router to run. As you become more familiar with the router, you can add to or change these settings, or create your own configuration files.</p>
+</div>
+<div class="paragraph">
+<p>When you installed Dispatch Router, the default configuration file was added at the following path: <code>/etc/qpid-dispatch/qdrouterd.conf</code>. It includes some basic configuration settings that define the router’s operating mode, how it listens for incoming connections, and routing patterns for the message routing mechanism.</p>
+</div>
+<div class="listingblock">
+<div class="title">Default Configuration File</div>
+<div class="content">
+<pre class="nowrap">router {
+ mode: standalone <b class="conum">(1)</b>
+ id: Router.A <b class="conum">(2)</b>
+}
+
+listener { <b class="conum">(3)</b>
+ host: 0.0.0.0 <b class="conum">(4)</b>
+ port: amqp <b class="conum">(5)</b>
+ authenticatePeer: no <b class="conum">(6)</b>
+}
+
+address { <b class="conum">(7)</b>
+ prefix: closest
+ distribution: closest
+}
+
+address {
+ prefix: multicast
+ distribution: multicast
+}
+
+address {
+ prefix: unicast
+ distribution: closest
+}
+
+address {
+ prefix: exclusive
+ distribution: closest
+}
+
+address {
+ prefix: broadcast
+ distribution: multicast
+}</pre>
+</div>
+</div>
+<div class="colist arabic">
+<ol>
+<li>
+<p>By default, the router operates in <em>standalone</em> mode. This means that it can only communicate with endpoints that are directly connected to it. It cannot connect to other routers, or participate in a router network.</p>
+</li>
+<li>
+<p>The unique identifier of the router. This ID is used as the <code>container-id</code> (container name) at the AMQP protocol level. It is required, and the router will not start if this attribute is not defined.</p>
+</li>
+<li>
+<p>The <code>listener</code> entity handles incoming connections from client endpoints.</p>
+</li>
+<li>
+<p>The IP address on which the router will listen for incoming connections. By default, the router is configured to listen on all network interfaces.</p>
+</li>
+<li>
+<p>The port on which the router will listen for incoming connections. By default, the default AMQP port (5672) is specified with a symbolic service name.</p>
+</li>
+<li>
+<p>Specifies whether the router should authenticate peers before they can connect to the router. By default, peer authentication is not required.</p>
+</li>
+<li>
+<p>By default, the router is configured to use the message routing mechanism. Each <code>address</code> entity defines how messages that are received with a particular address <code>prefix</code> should be distributed. For example, all messages with addresses that start with <code>closest</code> will be distributed using the <code>closest</code> distribution pattern.</p>
+</li>
+</ol>
+</div>
+<div class="admonitionblock note">
+<table>
+<tr>
+<td class="icon">
+<div class="title">Note</div>
+</td>
+<td class="content">
+<div class="paragraph">
+<p>If a client requests a message with an address that is not defined in the router’s configuration file, the <code>balanced</code> distribution pattern will be used automatically.</p>
+</div>
+</td>
+</tr>
+</table>
+</div>
+</div>
+<div class="sect2">
+<h3 id="setting_essential_configuration_properties">4.5. Setting Essential Configuration Properties</h3>
+<div class="paragraph">
+<p>The router’s default configuration settings enable the router to run with minimal configuration. However, you may need to change some of these settings for the router to run properly in your environment.</p>
+</div>
+<div class="olist arabic">
+<div class="title">Procedure</div>
+<ol class="arabic">
+<li>
+<p>Open the router’s configuration file.</p>
+<div class="paragraph">
+<p>If you are changing the router’s default configuration file, the file is located at <code>/etc/qpid-dispatch/qdrouterd.conf</code>.</p>
+</div>
+</li>
+<li>
+<p>To define essential router information, change the following attributes as needed in the <code>router</code> section:</p>
+<div class="openblock">
+<div class="content">
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">router {
+ mode: <em>STANDALONE/INTERIOR</em>
+ id: <em>ROUTER_ID</em>
+}</pre>
+</div>
+</div>
+<div class="dlist">
+<dl>
+<dt class="hdlist1"><code>mode</code></dt>
+<dd>
+<p>Specify one of the following modes:</p>
+<div class="ulist">
+<ul>
+<li>
+<p><code>standalone</code> - Use this mode if the router does not communicate with other routers and is not part of a router network. When operating in this mode, the router only routes messages between directly connected endpoints.</p>
+</li>
+<li>
+<p><code>interior</code> - Use this mode if the router is part of a router network and needs to collaborate with other routers.</p>
+</li>
+</ul>
+</div>
+</dd>
+<dt class="hdlist1"><code>id</code></dt>
+<dd>
+<p>The unique identifier for the router. This ID will also be the container name at the AMQP protocol level.</p>
+</dd>
+</dl>
+</div>
+<div class="paragraph">
+<p>For information about additional attributes, see <a href="#router_configuration_file_router">Router</a> in the <em>Configuration Reference</em>.</p>
+</div>
+</div>
+</div>
+</li>
+<li>
+<p>If necessary for your environment, secure the router.</p>
+<div class="openblock">
+<div class="content">
+<div class="ulist">
+<ul>
+<li>
+<p><a href="#setting_up_ssl_for_encryption_and_authentication">Set up SSL/TLS for encryption, authentication, or both</a></p>
+</li>
+<li>
+<p><a href="#setting_up_sasl_for_authentication_and_payload_encryption">Set up SASL for authentication and payload encryption</a></p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</li>
+<li>
+<p>Connect the router to other routers, clients, and brokers.</p>
+<div class="openblock">
+<div class="content">
+<div class="ulist">
+<ul>
+<li>
+<p><a href="#adding_incoming_connections">Add incoming connections</a></p>
+</li>
+<li>
+<p><a href="#adding_outgoing_connections">Add outgoing connections</a></p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</li>
+<li>
+<p>Set up routing for your environment:</p>
+<div class="openblock">
+<div class="content">
+<div class="ulist">
+<ul>
+<li>
+<p><a href="#routing_messages_between_clients">Configure the router to route messages between clients directly</a></p>
+</li>
+<li>
+<p><a href="#routing_messages_through_broker">Configure the router to route messages through a broker queue</a></p>
+</li>
+<li>
+<p><a href="#creating_link_route">Create a link route to define a private messaging path between endpoints</a></p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</li>
+<li>
+<p><a href="#logging">Set up logging</a>.</p>
+</li>
+</ol>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="router_network_connections">5. Network Connections</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Connections define how the router communicates with clients, other routers, and brokers. You can configure <em>incoming connections</em> to define how the router listens for data from clients and other routers, and you can configure <em>outgoing connections</em> to define how the router sends data to other routers and brokers.</p>
+</div>
+<div class="sect2">
+<h3 id="adding_incoming_connections">5.1. Listening for Incoming Connections</h3>
+<div class="paragraph">
+<p>Listening for incoming connections involves setting the host and port on which the router should listen for traffic.</p>
+</div>
+<div class="olist arabic">
+<div class="title">Procedure</div>
+<ol class="arabic">
+<li>
+<p>In the router’s configuration file, add a <code>listener</code>:</p>
+<div class="openblock">
+<div class="content">
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">listener {
+ host: <em>HOST_NAME/ADDRESS</em>
+ port: <em>PORT_NUMBER/NAME</em>
+ ...
+}</pre>
+</div>
+</div>
+<div class="dlist">
+<dl>
+<dt class="hdlist1"><code>host</code></dt>
+<dd>
+<p>Either an IP address (IPv4 or IPv6) or hostname on which the router should listen for incoming connections.</p>
+</dd>
+<dt class="hdlist1"><code>port</code></dt>
+<dd>
+<p>The port number or symbolic service name on which the router should listen for incoming connections.</p>
+</dd>
+</dl>
+</div>
+<div class="paragraph">
+<p>For information about additional attributes, see <a href="#router_configuration_file_listener">Listener</a> in the <em>Configuration Reference</em>.</p>
+</div>
+</div>
+</div>
+</li>
+<li>
+<p>If necessary, <a href="#securing_incoming_connections">secure the connection</a>.</p>
+<div class="paragraph">
+<p>If you have set up SSL/TLS or SASL in your environment, you can configure the router to only accept encrypted or authenticated communication on this connection.</p>
+</div>
+</li>
+<li>
+<p>If you want the router to listen for incoming connections on additional hosts or ports, configure an additional <code>listener</code> entity for each host and port.</p>
+</li>
+</ol>
+</div>
+</div>
+<div class="sect2">
+<h3 id="adding_outgoing_connections">5.2. Adding Outgoing Connections</h3>
+<div class="paragraph">
+<p>Configuring outgoing connections involves setting the host and port on which the router connects to other routers and brokers.</p>
+</div>
+<div class="paragraph">
+<p>When a router connects to a broker, the broker might provide backup connection data that the router can use if the primary connection fails. If the primary connection fails, the router attempts to reconnect by using a combination of the primary and — if provided — backup connections in round-robin fashion until the connection is successful. For more information about viewing the backup connection data provided by the broker, see <a href="#managing_connectors">Managing Connectors</a>.</p>
+</div>
+<div class="olist arabic">
+<div class="title">Procedure</div>
+<ol class="arabic">
+<li>
+<p>In the router’s configuration file, add a <code>connector</code>:</p>
+<div class="openblock">
+<div class="content">
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">connector {
+ name: <em>NAME</em>
+ host: <em>HOST_NAME/ADDRESS</em>
+ port: <em>PORT_NUMBER/NAME</em>
+ ...
+}</pre>
+</div>
+</div>
+<div class="dlist">
+<dl>
+<dt class="hdlist1"><code>name</code></dt>
+<dd>
+<p>The name of the <code>connector</code>. You should specify a name that describes the entity to which the connector connects. This name is used by configured addresses (for example, a <code>linkRoute</code> entity) in order to specify which connection should be used for them.</p>
+</dd>
+<dt class="hdlist1"><code>host</code></dt>
+<dd>
+<p>Either an IP address (IPv4 or IPv6) or hostname on which the router should connect.</p>
+</dd>
+<dt class="hdlist1"><code>port</code></dt>
+<dd>
+<p>The port number or symbolic service name on which the router should connect.</p>
+</dd>
+</dl>
+</div>
+<div class="paragraph">
+<p>For information about additional attributes, see <a href="#router_configuration_file_connector">Connector</a> in the <em>Configuration Reference</em>.</p>
+</div>
+</div>
+</div>
+</li>
+<li>
+<p>If necessary, <a href="#securing_outgoing_connections">secure the connection</a>.</p>
+<div class="paragraph">
+<p>If you have set up SSL/TLS or SASL in your environment, you can configure the router to only send encrypted or authenticated communication on this connection.</p>
+</div>
+</li>
+<li>
+<p>For each remaining router or broker to which this router should connect, configure an additional <code>connector</code> entity.</p>
+</li>
+</ol>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="security_config">6. Security</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>You can configure Dispatch Router to communicate with clients, routers, and brokers in a secure way by authenticating and encrypting the router’s connections. Dispatch Router supports the following security protocols:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p><em>SSL/TLS</em> for certificate-based encryption and mutual authentication</p>
+</li>
+<li>
+<p><em>SASL</em> for authentication and payload encryption</p>
+</li>
+</ul>
+</div>
+<div class="sect2">
+<h3 id="setting_up_ssl_for_encryption_and_authentication">6.1. Setting Up SSL/TLS for Encryption and Authentication</h3>
+<div class="paragraph">
+<p>Before you can secure incoming and outgoing connections using SSL/TLS encryption and authentication, you must first set up the SSL/TLS profile in the router’s configuration file.</p>
+</div>
+<div class="paragraph">
+<div class="title">Prerequisites</div>
+<p>You must have the following files in PEM format:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>An X.509 CA certificate (used for signing the router certificate for the SSL/TLS server authentication feature).</p>
+</li>
+<li>
+<p>A private key (with or without password protection) for the router.</p>
+</li>
+<li>
+<p>An X.509 router certificate signed by the X.509 CA certificate.</p>
+</li>
+</ul>
+</div>
+<div class="ulist">
+<div class="title">Procedure</div>
+<ul>
+<li>
+<p>In the router’s configuration file, add an <code>sslProfile</code> section:</p>
+<div class="openblock">
+<div class="content">
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">sslProfile {
+ name: <em>NAME</em>
+ ciphers: <em>CIPHERS</em>
+ certDb: <em>PATH</em>.pem
+ certFile: <em>PATH</em>.pem
+ keyFile: <em>PATH</em>.pem
+ password: <em>PASSWORD/PATH_TO_PASSWORD_FILE</em>
+ ...
+}</pre>
+</div>
+</div>
+<div class="dlist">
+<dl>
+<dt class="hdlist1"><code>name</code></dt>
+<dd>
+<p>A name for the SSL/TLS profile. You can use this name to refer to the profile from the incoming and outgoing connections.</p>
+<div class="paragraph">
+<p>For example:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">name: router-ssl-profile</pre>
+</div>
+</div>
+</dd>
+<dt class="hdlist1"><code>ciphers</code></dt>
+<dd>
+<p>The SSL cipher suites that can be used by this SSL/TLS profile. If certain ciphers are unsuitable for your environment, you can use this attribute to restrict them from being used.</p>
+<div class="paragraph">
+<p>To enable a cipher list, enter one or more cipher strings separated by colons (<code>:</code>). For example:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">ciphers: ALL:!aNULL:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>To see the full list of available ciphers, use the <code>openssl ciphers</code> command. For more information about each cipher, see the <a href="https://www.openssl.org/docs/manmaster/man1/ciphers.html" target="_blank" rel="noopener">ciphers man page</a>.</p>
+</div>
+</dd>
+<dt class="hdlist1"><code>certDb</code></dt>
+<dd>
+<p>The absolute path to the database that contains the public certificates of trusted certificate authorities (CA).</p>
+<div class="paragraph">
+<p>For example:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">certDb: /qdrouterd/ssl_certs/ca-cert.pem</pre>
+</div>
+</div>
+</dd>
+<dt class="hdlist1"><code>certFile</code></dt>
+<dd>
+<p>The absolute path to the file containing the PEM-formatted public certificate to be used on the local end of any connections using this profile.</p>
+<div class="paragraph">
+<p>For example:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">certFile: /qdrouterd/ssl_certs/router-cert-pwd.pem</pre>
+</div>
+</div>
+</dd>
+<dt class="hdlist1"><code>keyFile</code></dt>
+<dd>
+<p>The absolute path to the file containing the PEM-formatted private key for the above certificate.</p>
+<div class="paragraph">
+<p>For example:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">keyFile: /qdrouterd/ssl_certs/router-key-pwd.pem</pre>
+</div>
+</div>
+</dd>
+<dt class="hdlist1"><code>passwordFile</code> or <code>password</code></dt>
+<dd>
+<p>If the private key is password-protected, you must provide the password by either specifying the absolute path to a file containing the password that unlocks the certificate key, or entering the password directly in the configuration file.</p>
+<div class="paragraph">
+<p>For example:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">password: routerKeyPassword</pre>
+</div>
+</div>
+</dd>
+</dl>
+</div>
+<div class="paragraph">
+<p>For information about additional <code>sslProfile</code> attributes, see <a href="#router_configuration_file_sslprofile"><em>sslProfile</em></a> in the <em>Configuration Reference</em>.</p>
+</div>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="setting_up_sasl_for_authentication_and_payload_encryption">6.2. Setting Up SASL for Authentication and Payload Encryption</h3>
+<div class="paragraph">
+<p>If you plan to use SASL to authenticate connections, you must first add the SASL attributes to the <code>router</code> entity in the router’s configuration file. These attributes define a set of SASL parameters that can be used by the router’s incoming and outgoing connections.</p>
+</div>
+<div class="paragraph">
+<div class="title">Prerequisites</div>
+<p>Before you can set up SASL, you must have the following:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p><a href="#generating_sasl_database">The SASL database is generated.</a></p>
+</li>
+<li>
+<p><a href="#configuring_sasl_database">The SASL configuration file is configured.</a></p>
+</li>
+</ul>
+</div>
+<div class="ulist">
+<div class="title">Procedure</div>
+<ul>
+<li>
+<p>In the router’s configuration file, add the following attributes to the <code>router</code> section:</p>
+<div class="openblock">
+<div class="content">
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">router {
+ ...
+ saslConfigPath: <em>PATH</em>
+ saslConfigName: <em>FILE_NAME</em>
+}</pre>
+</div>
+</div>
+<div class="dlist">
+<dl>
+<dt class="hdlist1"><code>saslConfigPath</code></dt>
+<dd>
+<p>The absolute path to the SASL configuration file.</p>
+<div class="paragraph">
+<p>For example:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">saslConfigPath: /qdrouterd/security</pre>
+</div>
+</div>
+</dd>
+<dt class="hdlist1"><code>saslConfigName</code></dt>
+<dd>
+<p>The name of the SASL configuration file. This name should <em>not</em> include the <code>.conf</code> file extension.</p>
+<div class="paragraph">
+<p>For example:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">saslConfigName: qdrouterd_sasl</pre>
+</div>
+</div>
+</dd>
+</dl>
+</div>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="securing_incoming_connections">6.3. Securing Incoming Connections</h3>
+<div class="paragraph">
+<p>You can secure incoming connections by configuring each connection’s <code>listener</code> entity for encryption, authentication, or both.</p>
+</div>
+<div class="paragraph">
+<div class="title">Prerequisites</div>
+<p>Before securing incoming connections, the security protocols you plan to use should be set up.</p>
+</div>
+<div class="ulist">
+<div class="title">Choices</div>
+<ul>
+<li>
+<p><a href="#adding_ssl_encryption_to_incoming_connection">Add SSL/TLS encryption</a></p>
+</li>
+<li>
+<p><a href="#adding_sasl_authentication_to_incoming_connection">Add SASL authentication</a></p>
+</li>
+<li>
+<p><a href="#adding_ssl_client_authentication_to_incoming_connection">Add SSL/TLS client authentication</a></p>
+</li>
+<li>
+<p><a href="#adding_sasl_payload_encryption_to_incoming_connection">Add SASL payload encryption</a></p>
+</li>
+</ul>
+</div>
+<div class="sect3">
+<h4 id="adding_ssl_encryption_to_incoming_connection">6.3.1. Adding SSL/TLS Encryption to an Incoming Connection</h4>
+<div class="paragraph">
+<p>You can configure an incoming connection to accept encrypted connections only. By adding SSL/TLS encryption, to connect to this router, a remote peer must first start an SSL/TLS handshake with the router and be able to validate the server certificate received by the router during the handshake.</p>
+</div>
+<div class="ulist">
+<div class="title">Procedure</div>
+<ul>
+<li>
+<p>In the router’s configuration file, add the following attributes to the connection’s <code>listener</code> entity:</p>
+<div class="openblock">
+<div class="content">
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">listener {
+ ...
+ sslProfile: <em>SSL_PROFILE_NAME</em>
+ requireSsl: yes
+}</pre>
+</div>
+</div>
+<div class="dlist">
+<dl>
+<dt class="hdlist1"><code>sslProfile</code></dt>
+<dd>
+<p>The name of the SSL/TLS profile you set up.</p>
+</dd>
+<dt class="hdlist1"><code>requireSsl</code></dt>
+<dd>
+<p>Enter <code>yes</code> to require all clients connecting to the router on this connection to use encryption.</p>
+</dd>
+</dl>
+</div>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect3">
+<h4 id="adding_sasl_authentication_to_incoming_connection">6.3.2. Adding SASL Authentication to an Incoming Connection</h4>
+<div class="paragraph">
+<p>You can configure an incoming connection to authenticate the client using SASL. You can use SASL authentication with or without SSL/TLS encryption.</p>
+</div>
+<div class="ulist">
+<div class="title">Procedure</div>
+<ul>
+<li>
+<p>In the router’s configuration file, add the following attributes to the connection’s <code>listener</code> section:</p>
+<div class="openblock">
+<div class="content">
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">listener {
+ ...
+ authenticatePeer: yes
+ saslMechanisms: <em>MECHANISMS</em>
+}</pre>
+</div>
+</div>
+<div class="dlist">
+<dl>
+<dt class="hdlist1"><code>authenticatePeer</code></dt>
+<dd>
+<p>Set this attribute to <code>yes</code> to require the router to authenticate the identity of a remote peer before it can use this incoming connection.</p>
+</dd>
+<dt class="hdlist1"><code>saslMechanisms</code></dt>
+<dd>
+<p>The SASL authentication mechanism (or mechanisms) to use for peer authentication. You can choose any of the Cyrus SASL authentication mechanisms <em>except</em> for <code>ANONYMOUS</code>. To specify multiple authentication mechanisms, separate each mechanism with a space.</p>
+<div class="paragraph">
+<p>For a full list of supported Cyrus SASL authentication mechanisms, see <a href="https://www.cyrusimap.org/sasl/sasl/authentication_mechanisms.html" target="_blank" rel="noopener">Authentication Mechanisms</a>.</p>
+</div>
+</dd>
+</dl>
+</div>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect3">
+<h4 id="adding_ssl_client_authentication_to_incoming_connection">6.3.3. Adding SSL/TLS Client Authentication to an Incoming Connection</h4>
+<div class="paragraph">
+<p>You can configure an incoming connection to authenticate the client using SSL/TLS.</p>
+</div>
+<div class="paragraph">
+<p>The base SSL/TLS configuration provides content encryption and server authentication, which means that remote peers can verify the router’s identity, but the router cannot verify a peer’s identity.</p>
+</div>
+<div class="paragraph">
+<p>However, you can require an incoming connection to use SSL/TLS client authentication, which means that remote peers must provide an additional certificate to the router during the SSL/TLS handshake. By using this certificate, the router can verify the client’s identity without using a username and password.</p>
+</div>
+<div class="paragraph">
+<p>You can use SSL/TLS client authentication with or without SASL authentication.</p>
+</div>
+<div class="ulist">
+<div class="title">Procedure</div>
+<ul>
+<li>
+<p>In the router’s configuration, file, add the following attribute to the connection’s <code>listener</code> entity:</p>
+<div class="openblock">
+<div class="content">
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">listener {
+ ...
+ authenticatePeer: yes
+}</pre>
+</div>
+</div>
+<div class="dlist">
+<dl>
+<dt class="hdlist1"><code>authenticatePeer</code></dt>
+<dd>
+<p>Set this attribute to <code>yes</code> to require the router to authenticate the identity of a remote peer before it can use this incoming connection.</p>
+</dd>
+</dl>
+</div>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect3">
+<h4 id="adding_sasl_payload_encryption_to_incoming_connection">6.3.4. Adding SASL Payload Encryption to an Incoming Connection</h4>
+<div class="paragraph">
+<p>If you do not use SSL/TLS, you can still encrypt the incoming connection by using SASL payload encryption.</p>
+</div>
+<div class="ulist">
+<div class="title">Procedure</div>
+<ul>
+<li>
+<p>In the router’s configuration file, add the following attributes to the connection’s <code>listener</code> section:</p>
+<div class="openblock">
+<div class="content">
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">listener {
+ ...
+ requireEncryption: yes
+ saslMechanisms: <em>MECHANISMS</em>
+}</pre>
+</div>
+</div>
+<div class="dlist">
+<dl>
+<dt class="hdlist1"><code>requireEncryption</code></dt>
+<dd>
+<p>Set this attribute to <code>yes</code> to require the router to use SASL payload encryption for the connection.</p>
+</dd>
+<dt class="hdlist1"><code>saslMechanisms</code></dt>
+<dd>
+<p>The SASL mechanism to use. You can choose any of the Cyrus SASL authentication mechanisms. To specify multiple authentication mechanisms, separate each mechanism with a space.</p>
+<div class="paragraph">
+<p>For a full list of supported Cyrus SASL authentication mechanisms, see <a href="https://www.cyrusimap.org/sasl/sasl/authentication_mechanisms.html" target="_blank" rel="noopener">Authentication Mechanisms</a>.</p>
+</div>
+</dd>
+</dl>
+</div>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="securing_outgoing_connections">6.4. Securing Outgoing Connections</h3>
+<div class="paragraph">
+<p>You can secure outgoing connections by configuring each connection’s <code>connector</code> entity for encryption, authentication, or both.</p>
+</div>
+<div class="paragraph">
+<div class="title">Prerequisites</div>
+<p>Before securing outgoing connections, the security protocols you plan to use should be set up.</p>
+</div>
+<div class="ulist">
+<div class="title">Choices</div>
+<ul>
+<li>
+<p><a href="#adding_ssl_authentication_to_outgoing_connection">Add SSL/TLS authentication</a></p>
+</li>
+<li>
+<p><a href="#adding_sasl_authentication_to_outgoing_connection">Add SASL authentication</a></p>
+</li>
+</ul>
+</div>
+<div class="sect3">
+<h4 id="adding_ssl_authentication_to_outgoing_connection">6.4.1. Adding SSL/TLS Client Authentication to an Outgoing Connection</h4>
+<div class="paragraph">
+<p>If an outgoing connection connects to an external client configured with mutual authentication, you should ensure that the outgoing connection is configured to provide the external client with a valid security certificate during the SSL/TLS handshake.</p>
+</div>
+<div class="paragraph">
+<p>You can use SSL/TLS client authentication with or without SASL authentication.</p>
+</div>
+<div class="ulist">
+<div class="title">Procedure</div>
+<ul>
+<li>
+<p>In the router’s configuration file, add the <code>sslProfile</code> attribute to the connection’s <code>connector</code> entity:</p>
+<div class="openblock">
+<div class="content">
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">connector {
+ ...
+ sslProfile: <em>SSL_PROFILE_NAME</em>
+}</pre>
+</div>
+</div>
+<div class="dlist">
+<dl>
+<dt class="hdlist1"><code>sslProfile</code></dt>
+<dd>
+<p>The name of the SSL/TLS profile you set up.</p>
+</dd>
+</dl>
+</div>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect3">
+<h4 id="adding_sasl_authentication_to_outgoing_connection">6.4.2. Adding SASL Authentication to an Outgoing Connection</h4>
+<div class="paragraph">
+<p>You can configure an outgoing connection to provide authentication credentials to the external container. You can use SASL authentication with or without SSL/TLS encryption.</p>
+</div>
+<div class="ulist">
+<div class="title">Procedure</div>
+<ul>
+<li>
+<p>In the router’s configuration file, add the <code>saslMechanisms</code> attribute to the connection’s <code>connector</code> entity:</p>
+<div class="openblock">
+<div class="content">
+<div class="listingblock">
+<div class="content">
+<pre class="nowrap">connector {
+ ...
+ saslMechanisms: <em>MECHANISMS</em>
+ saslUsername: <em>USERNAME</em>
+ saslPassword: <em>PASSWORD</em>
+}</pre>
+</div>
+</div>
+<div class="dlist">
+<dl>
+<dt class="hdlist1"><code>saslMechanisms</code></dt>
+<dd>
+<p>One or more SASL mechanisms to use to authenticate the router to the external container. You can choose any of the Cyrus SASL authentication mechanisms. To specify multiple authentication mechanisms, separate each mechanism with a space.</p>
+<div class="paragraph">
+<p>For a full list of supported Cyrus SASL authentication mechanisms, see <a href="https://www.cyrusimap.org/sasl/sasl/authentication_mechanisms.html" target="_blank" rel="noopener">Authentication Mechanisms</a>.</p>
+</div>
+</dd>
+<dt class="hdlist1"><code>saslUsername</code></dt>
+<dd>
+<p>If any of the SASL mechanisms uses username/password authentication, then provide the username to connect to the external container.</p>
+</dd>
+<dt class="hdlist1"><code>saslPassword</code></dt>
+<dd>
+<p>If any of the SASL mechanisms uses username/password authentication, then provide the password to connect to the external container.</p>
+</dd>
+</dl>
+</div>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="routing">7. Routing</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Routing is the process by which messages are delivered to their destinations. To accomplish this, Dispatch Router provides two routing mechanisms: <em>message routing</em> and <em>link routing</em>.</p>
+</div>
+<div class="dlist">
+<dl>
+<dt class="hdlist1">Message routing</dt>
+<dd>
+<p>Routing is performed on messages as producers send them to a router. When a message arrives on a router, the router routes the message and its <em>settlement</em> based on the message’s <em>address</em> and <em>routing pattern</em>.</p>
+<div class="openblock">
+<div class="content">
+<div class="imageblock" style="text-align: center">
+<div class="content">
+<img src="images/message-routing.png" alt="Message Routing">
+</div>
+<div class="title">Figure 2. Message Routing</div>
+</div>
+<div class="paragraph">
+<p>In this diagram, the message producer attaches a link to the router, and then sends a message over the link. When the router receives the message, it identifies the message’s destination based on the message’s address, and then uses its routing table to determine the best route to deliver the message either to its destination or to the next hop in the route. All dispositions (including settlement) are propagated along the same path that the original message transfer took. Flow control is handled between the sender and the router, and then between the router and the receiver.</p>
+</div>
+</div>
+</div>
+</dd>
+<dt class="hdlist1">Link routing</dt>
+<dd>
+<p>Routing is performed on link-attach frames, which are chained together to form a virtual messaging path that directly connects a sender and receiver. Once a link route
<TRUNCATED>
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org
[09/13] qpid-site git commit: QPID-8015: Prepare the dispatch release
scripts for the new user guide
Posted by jr...@apache.org.
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/qdrouterd.conf.5.html
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/qdrouterd.conf.5.html b/content/releases/qpid-dispatch-master/qdrouterd.conf.5.html
deleted file mode 100644
index 045a248..0000000
--- a/content/releases/qpid-dispatch-master/qdrouterd.conf.5.html
+++ /dev/null
@@ -1,1156 +0,0 @@
-<!DOCTYPE html>
-<!--
- -
- - Licensed to the Apache Software Foundation (ASF) under one
- - or more contributor license agreements. See the NOTICE file
- - distributed with this work for additional information
- - regarding copyright ownership. The ASF licenses this file
- - to you under the Apache License, Version 2.0 (the
- - "License"); you may not use this file except in compliance
- - with the License. You may obtain a copy of the License at
- -
- - http://www.apache.org/licenses/LICENSE-2.0
- -
- - Unless required by applicable law or agreed to in writing,
- - software distributed under the License is distributed on an
- - "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- - KIND, either express or implied. See the License for the
- - specific language governing permissions and limitations
- - under the License.
- -
--->
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
- <head>
- <title>SYNOPSIS - Apache Qpid™</title>
- <meta http-equiv="X-UA-Compatible" content="IE=edge"/>
- <meta name="viewport" content="width=device-width, initial-scale=1.0"/>
- <link rel="stylesheet" href="/site.css" type="text/css" async="async"/>
- <link rel="stylesheet" href="/deferred.css" type="text/css" defer="defer"/>
- <script type="text/javascript">var _deferredFunctions = [];</script>
- <script type="text/javascript" src="/deferred.js" defer="defer"></script>
- <!--[if lte IE 8]>
- <link rel="stylesheet" href="/ie.css" type="text/css"/>
- <script type="text/javascript" src="/html5shiv.js"></script>
- <![endif]-->
-
- <!-- Redirects for `go get` and godoc.org -->
- <meta name="go-import"
- content="qpid.apache.org git https://git-wip-us.apache.org/repos/asf/qpid-proton.git"/>
- <meta name="go-source"
- content="qpid.apache.org
-https://github.com/apache/qpid-proton/blob/go1/README.md
-https://github.com/apache/qpid-proton/tree/go1{/dir}
-https://github.com/apache/qpid-proton/blob/go1{/dir}/{file}#L{line}"/>
- </head>
- <body>
- <div id="-content">
- <div id="-top" class="panel">
- <a id="-menu-link"><img width="16" height="16" src="" alt="Menu"/></a>
-
- <a id="-search-link"><img width="22" height="16" src="" alt="Search"/></a>
-
- <ul id="-global-navigation">
- <li><a id="-logotype" href="/index.html">Apache Qpid<sup>™</sup></a></li>
- <li><a href="/documentation.html">Documentation</a></li>
- <li><a href="/download.html">Download</a></li>
- <li><a href="/discussion.html">Discussion</a></li>
- </ul>
- </div>
-
- <div id="-menu" class="panel" style="display: none;">
- <div class="flex">
- <section>
- <h3>Project</h3>
-
- <ul>
- <li><a href="/overview.html">Overview</a></li>
- <li><a href="/components/index.html">Components</a></li>
- <li><a href="/releases/index.html">Releases</a></li>
- </ul>
- </section>
-
- <section>
- <h3>Messaging APIs</h3>
-
- <ul>
- <li><a href="/proton/index.html">Qpid Proton</a></li>
- <li><a href="/components/jms/index.html">Qpid JMS</a></li>
- <li><a href="/components/messaging-api/index.html">Qpid Messaging API</a></li>
- </ul>
- </section>
-
- <section>
- <h3>Servers and tools</h3>
-
- <ul>
- <li><a href="/components/broker-j/index.html">Broker-J</a></li>
- <li><a href="/components/cpp-broker/index.html">C++ broker</a></li>
- <li><a href="/components/dispatch-router/index.html">Dispatch router</a></li>
- </ul>
- </section>
-
- <section>
- <h3>Resources</h3>
-
- <ul>
- <li><a href="/dashboard.html">Dashboard</a></li>
- <li><a href="https://cwiki.apache.org/confluence/display/qpid/Index">Wiki</a></li>
- <li><a href="/resources.html">More resources</a></li>
- </ul>
- </section>
- </div>
- </div>
-
- <div id="-search" class="panel" style="display: none;">
- <form action="http://www.google.com/search" method="get">
- <input type="hidden" name="sitesearch" value="qpid.apache.org"/>
- <input type="text" name="q" maxlength="255" autofocus="autofocus" tabindex="1"/>
- <button type="submit">Search</button>
- <a href="/search.html">More ways to search</a>
- </form>
- </div>
-
- <div id="-middle" class="panel">
- <ul id="-path-navigation"><li><a href="/index.html">Home</a></li><li><a href="/releases/index.html">Releases</a></li><li><a href="/releases/qpid-dispatch-master/index.html">Qpid Dispatch documentation snapshot</a></li><li>SYNOPSIS</li></ul>
-
- <div id="-middle-content">
- <div class="sect1">
-<h2 id="_synopsis">SYNOPSIS</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>Provides the initial configuration when <em>qdrouterd(8)</em> starts. The configuration
-of a running router can be modified using <em>qdmanage(8)</em>.</p></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_description">DESCRIPTION</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>The configuration file is made up of sections with this syntax:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>sectionName {
- attributeName: attributeValue
- attributeName: attributeValue
- ...
-}</code></pre>
-</div></div>
-<div class="paragraph"><p>For example you can define a router using the <em>router</em> section</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>router {
- mode: standalone
- id: Router.A
- ...
-}</code></pre>
-</div></div>
-<div class="paragraph"><p>or define a listener using the <em>listener</em> section</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>listener {
- host: 0.0.0.0
- port: 20102
- saslMechanisms: ANONYMOUS
- ...
-}</code></pre>
-</div></div>
-<div class="paragraph"><p>or define a connector using the <em>connector</em> section</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>connector {
- role: inter-router
- host: 0.0.0.0
- port: 20003
- saslMechanisms: ANONYMOUS
- ...
-}</code></pre>
-</div></div>
-<div class="paragraph"><p>An <em>sslProfile</em> section with SSL credentials can be included in multiple <em>listener</em> or <em>connector</em> entities. Here’s an example, note
-how the <em>sslProfile</em> attribute of <em>listener</em> sections references the <em>name</em>
-attribute of <em>sslProfile</em> sections.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>sslProfile {
- name: my-ssl
- certDb: ca-certificate-1.pem
- certFile: server-certificate-1.pem
- keyFile: server-private-key.pem
-}
-
-listener {
- sslProfile: my-ssl
- host: 0.0.0.0
- port: 20102
- saslMechanisms: ANONYMOUS
-}</code></pre>
-</div></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_configuration_sections">Configuration Sections</h2>
-<div class="sectionbody">
-<div class="sect2">
-<h3 id="_router">router</h3>
-<div class="paragraph"><p>Tracks peer routers and computes routes to destinations.</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>id</em> (string)
-</dt>
-<dd>
-<p>
- Router’s unique identity. One of id or routerId is required. The router will fail to start without id or routerId
-</p>
-</dd>
-<dt class="hdlist1">
-<em>mode</em> (One of [<em>standalone</em>, <em>interior</em>], default=<em>standalone</em>)
-</dt>
-<dd>
-<p>
- In standalone mode, the router operates as a single component. It does not participate in the routing protocol and therefore will not cooperate with other routers. In interior mode, the router operates in cooperation with other interior routers in an interconnected network.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>helloInterval</em> (integer, default=1)
-</dt>
-<dd>
-<p>
- Interval in seconds between HELLO messages sent to neighbor routers.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>helloMaxAge</em> (integer, default=3)
-</dt>
-<dd>
-<p>
- Time in seconds after which a neighbor is declared lost if no HELLO is received.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>raInterval</em> (integer, default=30)
-</dt>
-<dd>
-<p>
- Interval in seconds between Router-Advertisements sent to all routers in a stable network.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>raIntervalFlux</em> (integer, default=4)
-</dt>
-<dd>
-<p>
- Interval in seconds between Router-Advertisements sent to all routers during topology fluctuations.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>remoteLsMaxAge</em> (integer, default=60)
-</dt>
-<dd>
-<p>
- Time in seconds after which link state is declared stale if no RA is received.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>workerThreads</em> (integer, default=4)
-</dt>
-<dd>
-<p>
- The number of threads that will be created to process message traffic and other application work (timers, non-amqp file descriptors, etc.) .
-</p>
-</dd>
-<dt class="hdlist1">
-<em>debugDump</em> (path)
-</dt>
-<dd>
-<p>
- A file to dump debugging information that can’t be logged normally.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>saslConfigPath</em> (path)
-</dt>
-<dd>
-<p>
- Absolute path to the SASL configuration file.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>saslConfigName</em> (string, default=<em>qdrouterd</em>)
-</dt>
-<dd>
-<p>
- Name of the SASL configuration. This string + <em>.conf</em> is the name of the configuration file.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>routerId</em> (string)
-</dt>
-<dd>
-<p>
- (DEPRECATED) Router’s unique identity. This attribute has been deprecated. Use id instead
-</p>
-</dd>
-<dt class="hdlist1">
-<em>mobileAddrMaxAge</em> (integer, default=60)
-</dt>
-<dd>
-<p>
- (DEPRECATED) This value is no longer used in the router.
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_sslprofile">sslProfile</h3>
-<div class="paragraph"><p>Attributes for setting TLS/SSL configuration for connections.</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>certDb</em> (path)
-</dt>
-<dd>
-<p>
- The absolute path to the database that contains the public certificates of trusted certificate authorities (CA).
-</p>
-</dd>
-<dt class="hdlist1">
-<em>certFile</em> (path)
-</dt>
-<dd>
-<p>
- The absolute path to the file containing the PEM-formatted public certificate to be used on the local end of any connections using this profile.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>keyFile</em> (path)
-</dt>
-<dd>
-<p>
- The absolute path to the file containing the PEM-formatted private key for the above certificate.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>passwordFile</em> (path)
-</dt>
-<dd>
-<p>
- If the above private key is password protected, this is the absolute path to a file containing the password that unlocks the certificate key.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>password</em> (string)
-</dt>
-<dd>
-<p>
- An alternative to storing the password in a file referenced by passwordFile is to supply the password right here in the configuration file. This option can be used by supplying the password in the <em>password</em> option. Don’t use both password and passwordFile in the same profile.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>uidFormat</em> (string)
-</dt>
-<dd>
-<p>
- A list of x509 client certificate fields that will be used to build a string that will uniquely identify the client certificate owner. For e.g. a value of <em>cou</em> indicates that the uid will consist of c - common name concatenated with o - organization-company name concatenated with u - organization unit; or a value of <em>o2</em> indicates that the uid will consist of o (organization name) concatenated with 2 (the sha256 fingerprint of the entire certificate) . Allowed values can be any combination of <em>c</em>( ISO3166 two character country code), <em>s</em>(state or province), <em>l</em>(Locality; generally - city), <em>o</em>(Organization - Company Name), <em>u</em>(Organization Unit - typically certificate type or brand), <em>n</em>(CommonName - typically a user name for client certificates) and <em>1</em>(sha1 certificate fingerprint, as displayed in the fingerprints section when looking at a certificate with say a web browser is the hash of the entire certificate) and
2 (sha256 certificate fingerprint) and 5 (sha512 certificate fingerprint).
-</p>
-</dd>
-<dt class="hdlist1">
-<em>displayNameFile</em> (string)
-</dt>
-<dd>
-<p>
- The absolute path to the file containing the unique id to dispay name mapping
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_listener">listener</h3>
-<div class="paragraph"><p>Listens for incoming connections to the router.</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>host</em> (string, default=<em>127.0.0.1</em>)
-</dt>
-<dd>
-<p>
- IP address: ipv4 or ipv6 literal or a host name
-</p>
-</dd>
-<dt class="hdlist1">
-<em>port</em> (string, default=<em>amqp</em>)
-</dt>
-<dd>
-<p>
- Port number or symbolic service name.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>protocolFamily</em> (One of [<em>IPv4</em>, <em>IPv6</em>])
-</dt>
-<dd>
-<p>
- [<em>IPv4</em>, <em>IPv6</em>] IPv4: Internet Protocol version 4; IPv6: Internet Protocol version 6. If not specified, the protocol family will be automatically determined from the address.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>role</em> (One of [<em>normal</em>, <em>inter-router</em>, <em>route-container</em>, <em>on-demand</em>], default=<em>normal</em>)
-</dt>
-<dd>
-<p>
- The role of an established connection. In the normal role, the connection is assumed to be used for AMQP clients that are doing normal message delivery over the connection. In the inter-router role, the connection is assumed to be to another router in the network. Inter-router discovery and routing protocols can only be used over inter-router connections. route-container role can be used for router-container connections, for example, a router-broker connection. on-demand role has been deprecated.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>cost</em> (integer, default=<em>1</em>)
-</dt>
-<dd>
-<p>
- For the <em>inter-router</em> role only. This value assigns a cost metric to the inter-router connection. The default (and minimum) value is one. Higher values represent higher costs. The cost is used to influence the routing algorithm as it attempts to use the path with the lowest total cost from ingress to egress.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>sslProfile</em> (string)
-</dt>
-<dd>
-<p>
- Name of the sslProfile.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>saslMechanisms</em> (string)
-</dt>
-<dd>
-<p>
- Space separated list of accepted SASL authentication mechanisms.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>authenticatePeer</em> (boolean)
-</dt>
-<dd>
-<p>
- yes: Require the peer’s identity to be authenticated; no: Do not require any authentication.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>requireEncryption</em> (boolean)
-</dt>
-<dd>
-<p>
- yes: Require the connection to the peer to be encrypted; no: Permit non-encrypted communication with the peer
-</p>
-</dd>
-<dt class="hdlist1">
-<em>requireSsl</em> (boolean)
-</dt>
-<dd>
-<p>
- yes: Require the use of SSL or TLS on the connection; no: Allow clients to connect without SSL or TLS.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>trustedCerts</em> (path)
-</dt>
-<dd>
-<p>
- This optional setting can be used to reduce the set of available CAs for client authentication. If used, this setting must provide the absolute path to a PEM file that contains the trusted certificates.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>maxFrameSize</em> (integer, default=16384)
-</dt>
-<dd>
-<p>
- Defaults to 16384. If specified, it is the maximum frame size in octets that will be used in the connection-open negotiation with a connected peer. The frame size is the largest contiguous set of uninterrupted data that can be sent for a message delivery over the connection. Interleaving of messages on different links is done at frame granularity.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>idleTimeoutSeconds</em> (integer, default=16)
-</dt>
-<dd>
-<p>
- The idle timeout, in seconds, for connections through this listener. If no frames are received on the connection for this time interval, the connection shall be closed.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>stripAnnotations</em> (One of [<em>in</em>, <em>out</em>, <em>both</em>, <em>no</em>], default=<em>both</em>)
-</dt>
-<dd>
-<p>
- [<em>in</em>, <em>out</em>, <em>both</em>, <em>no</em>] in: Strip the dispatch router specific annotations only on ingress; out: Strip the dispatch router specific annotations only on egress; both: Strip the dispatch router specific annotations on both ingress and egress; no - do not strip dispatch router specific annotations
-</p>
-</dd>
-<dt class="hdlist1">
-<em>linkCapacity</em> (integer)
-</dt>
-<dd>
-<p>
- The capacity of links within this connection, in terms of message deliveries. The capacity is the number of messages that can be in-flight concurrently for each link.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>addr</em> (string, default=<em>127.0.0.1</em>)
-</dt>
-<dd>
-<p>
- (DEPRECATED)IP address: ipv4 or ipv6 literal or a host name. This attribute has been deprecated. Use host instead
-</p>
-</dd>
-<dt class="hdlist1">
-<em>allowNoSasl</em> (boolean)
-</dt>
-<dd>
-<p>
- (DEPRECATED) This attribute is now controlled by the authenticatePeer attribute.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>requirePeerAuth</em> (boolean)
-</dt>
-<dd>
-<p>
- (DEPRECATED) This attribute is now controlled by the authenticatePeer attribute.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>allowUnsecured</em> (boolean)
-</dt>
-<dd>
-<p>
- (DEPRECATED) This attribute is now controlled by the requireEncryption attribute.
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_connector">connector</h3>
-<div class="paragraph"><p>Establishes an outgoing connection from the router.</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>host</em> (string, default=<em>127.0.0.1</em>)
-</dt>
-<dd>
-<p>
- IP address: ipv4 or ipv6 literal or a host name
-</p>
-</dd>
-<dt class="hdlist1">
-<em>port</em> (string, default=<em>amqp</em>)
-</dt>
-<dd>
-<p>
- Port number or symbolic service name.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>protocolFamily</em> (One of [<em>IPv4</em>, <em>IPv6</em>])
-</dt>
-<dd>
-<p>
- [<em>IPv4</em>, <em>IPv6</em>] IPv4: Internet Protocol version 4; IPv6: Internet Protocol version 6. If not specified, the protocol family will be automatically determined from the address.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>role</em> (One of [<em>normal</em>, <em>inter-router</em>, <em>route-container</em>, <em>on-demand</em>], default=<em>normal</em>)
-</dt>
-<dd>
-<p>
- The role of an established connection. In the normal role, the connection is assumed to be used for AMQP clients that are doing normal message delivery over the connection. In the inter-router role, the connection is assumed to be to another router in the network. Inter-router discovery and routing protocols can only be used over inter-router connections. route-container role can be used for router-container connections, for example, a router-broker connection. on-demand role has been deprecated.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>cost</em> (integer, default=<em>1</em>)
-</dt>
-<dd>
-<p>
- For the <em>inter-router</em> role only. This value assigns a cost metric to the inter-router connection. The default (and minimum) value is one. Higher values represent higher costs. The cost is used to influence the routing algorithm as it attempts to use the path with the lowest total cost from ingress to egress.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>sslProfile</em> (string)
-</dt>
-<dd>
-<p>
- Name of the sslProfile.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>saslMechanisms</em> (string)
-</dt>
-<dd>
-<p>
- Space separated list of accepted SASL authentication mechanisms.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>allowRedirect</em> (boolean, default=True)
-</dt>
-<dd>
-<p>
- Allow the peer to redirect this connection to another address.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>maxFrameSize</em> (integer, default=65536)
-</dt>
-<dd>
-<p>
- Maximum frame size in octets that will be used in the connection-open negotiation with a connected peer. The frame size is the largest contiguous set of uninterrupted data that can be sent for a message delivery over the connection. Interleaving of messages on different links is done at frame granularity.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>idleTimeoutSeconds</em> (integer, default=16)
-</dt>
-<dd>
-<p>
- The idle timeout, in seconds, for connections through this connector. If no frames are received on the connection for this time interval, the connection shall be closed.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>stripAnnotations</em> (One of [<em>in</em>, <em>out</em>, <em>both</em>, <em>no</em>], default=<em>both</em>)
-</dt>
-<dd>
-<p>
- [<em>in</em>, <em>out</em>, <em>both</em>, <em>no</em>] in: Strip the dispatch router specific annotations only on ingress; out: Strip the dispatch router specific annotations only on egress; both: Strip the dispatch router specific annotations on both ingress and egress; no - do not strip dispatch router specific annotations
-</p>
-</dd>
-<dt class="hdlist1">
-<em>linkCapacity</em> (integer)
-</dt>
-<dd>
-<p>
- The capacity of links within this connection, in terms of message deliveries. The capacity is the number of messages that can be in-flight concurrently for each link.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>verifyHostName</em> (boolean, default=True)
-</dt>
-<dd>
-<p>
- yes: Ensures that when initiating a connection (as a client) the host name in the URL to which this connector connects to matches the host name in the digital certificate that the peer sends back as part of the SSL connection; no: Does not perform host name verification
-</p>
-</dd>
-<dt class="hdlist1">
-<em>saslUsername</em> (string)
-</dt>
-<dd>
-<p>
- The user name that the connector is using to connect to a peer.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>saslPassword</em> (string)
-</dt>
-<dd>
-<p>
- The password that the connector is using to connect to a peer.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>addr</em> (string, default=<em>127.0.0.1</em>)
-</dt>
-<dd>
-<p>
- (DEPRECATED)IP address: ipv4 or ipv6 literal or a host name. This attribute has been deprecated. Use host instead
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_log">log</h3>
-<div class="paragraph"><p>Configure logging for a particular module. You can use the <code>UPDATE</code> operation to change log settings while the router is running.</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>module</em> (One of [<em>ROUTER</em>, <em>ROUTER_CORE</em>, <em>ROUTER_HELLO</em>, <em>ROUTER_LS</em>, <em>ROUTER_MA</em>, <em>MESSAGE</em>, <em>SERVER</em>, <em>AGENT</em>, <em>CONTAINER</em>, <em>ERROR</em>, <em>POLICY</em>, <em>DEFAULT</em>], required)
-</dt>
-<dd>
-<p>
- Module to configure. The special module <em>DEFAULT</em> specifies defaults for all modules.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>enable</em> (string)
-</dt>
-<dd>
-<p>
- Levels are: trace, debug, info, notice, warning, error, critical. The enable string is a comma-separated list of levels. A level may have a trailing <em>+</em> to enable that level and above. For example <em>trace,debug,warning+</em> means enable trace, debug, warning, error and critical. The value <em>none</em> means disable logging for the module.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>timestamp</em> (boolean)
-</dt>
-<dd>
-<p>
- Include timestamp in log messages.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>source</em> (boolean)
-</dt>
-<dd>
-<p>
- Include source file and line number in log messages.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>output</em> (string)
-</dt>
-<dd>
-<p>
- Where to send log messages. Can be <em>stderr</em>, <em>stdout</em>, <em>syslog</em> or a file name.
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_address">address</h3>
-<div class="paragraph"><p>Entity type for address configuration. This is used to configure the treatment of message-routed deliveries within a particular address-space. The configuration controls distribution and address phasing.</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>prefix</em> (string, required)
-</dt>
-<dd>
-<p>
- The address prefix for the configured settings
-</p>
-</dd>
-<dt class="hdlist1">
-<em>distribution</em> (One of [<em>multicast</em>, <em>closest</em>, <em>balanced</em>], default=<em>balanced</em>)
-</dt>
-<dd>
-<p>
- Treatment of traffic associated with the address
-</p>
-</dd>
-<dt class="hdlist1">
-<em>waypoint</em> (boolean)
-</dt>
-<dd>
-<p>
- Designates this address space as being used for waypoints. This will cause the proper address-phasing to be used.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>ingressPhase</em> (integer)
-</dt>
-<dd>
-<p>
- Advanced - Override the ingress phase for this address
-</p>
-</dd>
-<dt class="hdlist1">
-<em>egressPhase</em> (integer)
-</dt>
-<dd>
-<p>
- Advanced - Override the egress phase for this address
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_linkroute">linkRoute</h3>
-<div class="paragraph"><p>Entity type for link-route configuration. This is used to identify remote containers that shall be destinations for routed link-attaches. The link-routing configuration applies to an addressing space defined by a prefix.</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>prefix</em> (string, required)
-</dt>
-<dd>
-<p>
- The address prefix for the configured settings
-</p>
-</dd>
-<dt class="hdlist1">
-<em>containerId</em> (string)
-</dt>
-<dd>
-<p>
- ContainerID for the target container
-</p>
-</dd>
-<dt class="hdlist1">
-<em>connection</em> (string)
-</dt>
-<dd>
-<p>
- The name from a connector or listener
-</p>
-</dd>
-<dt class="hdlist1">
-<em>distribution</em> (One of [<em>linkBalanced</em>], default=<em>linkBalanced</em>)
-</dt>
-<dd>
-<p>
- Treatment of traffic associated with the address
-</p>
-</dd>
-<dt class="hdlist1">
-<em>dir</em> (One of [<em>in</em>, <em>out</em>], required)
-</dt>
-<dd>
-<p>
- The permitted direction of links: <em>in</em> means client senders; <em>out</em> means client receivers
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_autolink">autoLink</h3>
-<div class="paragraph"><p>Entity type for configuring auto-links. Auto-links are links whose lifecycle is managed by the router. These are typically used to attach to waypoints on remote containers (brokers, etc.).</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>addr</em> (string, required)
-</dt>
-<dd>
-<p>
- The address of the provisioned object
-</p>
-</dd>
-<dt class="hdlist1">
-<em>dir</em> (One of [<em>in</em>, <em>out</em>], required)
-</dt>
-<dd>
-<p>
- The direction of the link to be created. In means into the router, out means out of the router.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>phase</em> (integer)
-</dt>
-<dd>
-<p>
- The address phase for this link. Defaults to <em>0</em> for <em>out</em> links and <em>1</em> for <em>in</em> links.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>containerId</em> (string)
-</dt>
-<dd>
-<p>
- ContainerID for the target container
-</p>
-</dd>
-<dt class="hdlist1">
-<em>connection</em> (string)
-</dt>
-<dd>
-<p>
- The name from a connector or listener
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_console">console</h3>
-<div class="paragraph"><p>Start a websocket/tcp proxy and http file server to serve the web console</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>listener</em> (string)
-</dt>
-<dd>
-<p>
- The name of the listener to send the proxied tcp traffic to.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>wsport</em> (integer, default=5673)
-</dt>
-<dd>
-<p>
- port on which to listen for websocket traffic
-</p>
-</dd>
-<dt class="hdlist1">
-<em>proxy</em> (string)
-</dt>
-<dd>
-<p>
- The full path to the proxy program to run.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>home</em> (string)
-</dt>
-<dd>
-<p>
- The full path to the html/css/js files for the console.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>args</em> (string)
-</dt>
-<dd>
-<p>
- Optional args to pass the proxy program for logging, authentication, etc.
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_policy">policy</h3>
-<div class="paragraph"><p>Defines global connection limit</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>maxConnections</em> (integer, default=65535)
-</dt>
-<dd>
-<p>
- Global maximum number of concurrent client connections allowed. This limit is always enforced even if no other policy settings have been defined.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>enableVhostPolicy</em> (boolean)
-</dt>
-<dd>
-<p>
- Enable vhost policy user groups, connection denial, and resource limit enforcement
-</p>
-</dd>
-<dt class="hdlist1">
-<em>policyDir</em> (path)
-</dt>
-<dd>
-<p>
- Absolute path to a directory that holds vhost definition .json files. All vhost definitions in all .json files in this directory are processed.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>defaultVhost</em> (string)
-</dt>
-<dd>
-<p>
- Vhost rule set name to use for connections with a vhost that is otherwise not defined. Default vhost processing may be disabled either by erasing the definition of defaultVhost or by not defining a vhost object named <em>$default</em>.
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_vhost">vhost</h3>
-<div class="paragraph"><p>AMQP virtual host policy definition of users, user groups, allowed remote hosts, and AMQP restrictions.</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>maxConnections</em> (integer, default=65535)
-</dt>
-<dd>
-<p>
- Maximum number of concurrent client connections allowed.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>maxConnectionsPerUser</em> (integer, default=65535)
-</dt>
-<dd>
-<p>
- Maximum number of concurrent client connections allowed for any single user.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>maxConnectionsPerHost</em> (integer, default=65535)
-</dt>
-<dd>
-<p>
- Maximum number of concurrent client connections allowed for any remote host.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>allowUnknownUser</em> (boolean)
-</dt>
-<dd>
-<p>
- Unrestricted users, those who are not members of a defined user group, are allowed to connect to this application. Unrestricted users are assigned to the <em>default</em> user group and receive <em>default</em> settings.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>groups</em> (map)
-</dt>
-<dd>
-<p>
- A map where each key is a user group name and the value is a map of the corresponding settings for that group.
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_container">container</h3>
-<div class="paragraph"><p>(DEPRECATED)Attributes related to the AMQP container. This entity has been deprecated. Use the router entity instead.</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>containerName</em> (string)
-</dt>
-<dd>
-<p>
- The name of the AMQP container. If not specified, the container name will be set to a value of the container’s choosing. The automatically assigned container name is not guaranteed to be persistent across restarts of the container.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>workerThreads</em> (integer, default=4)
-</dt>
-<dd>
-<p>
- The number of threads that will be created to process message traffic and other application work (timers, non-amqp file descriptors, etc.) .
-</p>
-</dd>
-<dt class="hdlist1">
-<em>debugDump</em> (path)
-</dt>
-<dd>
-<p>
- A file to dump debugging information that can’t be logged normally.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>saslConfigPath</em> (path)
-</dt>
-<dd>
-<p>
- Absolute path to the SASL configuration file.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>saslConfigName</em> (string)
-</dt>
-<dd>
-<p>
- Name of the SASL configuration. This string + <em>.conf</em> is the name of the configuration file.
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_waypoint">waypoint</h3>
-<div class="paragraph"><p>(DEPRECATED) A remote node that messages for an address pass through. This entity has been deprecated. Use autoLink instead</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>address</em> (string, required)
-</dt>
-<dd>
-<p>
- The AMQP address of the waypoint.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>connector</em> (string, required)
-</dt>
-<dd>
-<p>
- The name of the on-demand connector used to reach the waypoint’s container.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>inPhase</em> (integer, default=-1)
-</dt>
-<dd>
-<p>
- The phase of the address as it is routed <em>to</em> the waypoint.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>outPhase</em> (integer, default=-1)
-</dt>
-<dd>
-<p>
- The phase of the address as it is routed <em>from</em> the waypoint.
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_fixedaddress">fixedAddress</h3>
-<div class="paragraph"><p>(DEPRECATED) Establishes treatment for addresses starting with a prefix. This entity has been deprecated. Use address instead</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>prefix</em> (string, required)
-</dt>
-<dd>
-<p>
- The address prefix (always starting with <em>/</em>).
-</p>
-</dd>
-<dt class="hdlist1">
-<em>phase</em> (integer)
-</dt>
-<dd>
-<p>
- The phase of a multi-hop address passing through one or more waypoints.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>fanout</em> (One of [<em>multiple</em>, <em>single</em>], default=<em>multiple</em>)
-</dt>
-<dd>
-<p>
- One of <em>multiple</em> or <em>single</em>. Multiple fanout is a non-competing pattern. If there are multiple consumers using the same address, each consumer will receive its own copy of every message sent to the address. Single fanout is a competing pattern where each message is sent to only one consumer.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>bias</em> (One of [<em>closest</em>, <em>spread</em>], default=<em>closest</em>)
-</dt>
-<dd>
-<p>
- Only if fanout is single. One of <em>closest</em> or <em>spread</em>. Closest bias means that messages to an address will always be delivered to the closest (lowest cost) subscribed consumer. Spread bias will distribute the messages across subscribers in an approximately even manner.
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_linkroutepattern">linkRoutePattern</h3>
-<div class="paragraph"><p>(DEPRECATED) An address pattern to match against link sources and targets to cause the router to link-route the attach across the network to a remote node. This entity has been deprecated. Use linkRoute instead</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>prefix</em> (string, required)
-</dt>
-<dd>
-<p>
- An address prefix to match against target and source addresses. This pattern must be of the form <em><text>.<text1>.<textN></em> or <em><text></em> or <em><text>.</em> and matches any address that contains that prefix. For example, if the prefix is set to org.apache (or org.apache.), any address that has the prefix <em>org.apache</em> (like org.apache.dev) will match. Note that a prefix must not start with a (.), can end in a (.) and can contain zero or more dots (.). Any characters between the dots are simply treated as part of the address
-</p>
-</dd>
-<dt class="hdlist1">
-<em>dir</em> (One of [<em>in</em>, <em>out</em>, <em>both</em>], default=<em>both</em>)
-</dt>
-<dd>
-<p>
- Link direction for match: <em>in</em> matches only links inbound to the client; <em>out</em> matches only links outbound from the client; <em>both</em> matches any link.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>connector</em> (string)
-</dt>
-<dd>
-<p>
- The name of the on-demand connector used to reach the target node’s container. If this value is not provided, it means that the target container is expected to be connected to a different router in the network. This prevents links to a link-routable address from being misinterpreted as message-routing links when there is no route to a valid destination available.
-</p>
-</dd>
-</dl></div>
-</div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_see_also">SEE ALSO</h2>
-<div class="sectionbody">
-<div class="paragraph"><p><strong>qdrouterd(8)</strong>, <strong>qdmanage(8)</strong></p></div>
-<div class="paragraph"><p><a href="http://qpid.apache.org/components/dispatch-router">http://qpid.apache.org/components/dispatch-router</a></p></div>
-</div>
-</div>
-
-
- <hr/>
-
- <ul id="-apache-navigation">
- <li><a href="http://www.apache.org/">Apache</a></li>
- <li><a href="http://www.apache.org/licenses/">License</a></li>
- <li><a href="http://www.apache.org/foundation/sponsorship.html">Sponsorship</a></li>
- <li><a href="http://www.apache.org/foundation/thanks.html">Thanks!</a></li>
- <li><a href="/security.html">Security</a></li>
- <li><a href="http://www.apache.org/"><img id="-apache-feather" width="48" height="14" src="" alt="Apache"/></a></li>
- </ul>
-
- <p id="-legal">
- Apache Qpid, Messaging built on AMQP; Copyright © 2015
- The Apache Software Foundation; Licensed under
- the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache
- License, Version 2.0</a>; Apache Qpid, Qpid, Qpid Proton,
- Proton, Apache, the Apache feather logo, and the Apache Qpid
- project logo are trademarks of The Apache Software
- Foundation; All other marks mentioned may be trademarks or
- registered trademarks of their respective owners
- </p>
- </div>
- </div>
- </div>
- </body>
-</html>
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/qdstat.8.html
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/qdstat.8.html b/content/releases/qpid-dispatch-master/qdstat.8.html
deleted file mode 100644
index 8ecbb47..0000000
--- a/content/releases/qpid-dispatch-master/qdstat.8.html
+++ /dev/null
@@ -1,870 +0,0 @@
-<!DOCTYPE html>
-<!--
- -
- - Licensed to the Apache Software Foundation (ASF) under one
- - or more contributor license agreements. See the NOTICE file
- - distributed with this work for additional information
- - regarding copyright ownership. The ASF licenses this file
- - to you under the Apache License, Version 2.0 (the
- - "License"); you may not use this file except in compliance
- - with the License. You may obtain a copy of the License at
- -
- - http://www.apache.org/licenses/LICENSE-2.0
- -
- - Unless required by applicable law or agreed to in writing,
- - software distributed under the License is distributed on an
- - "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- - KIND, either express or implied. See the License for the
- - specific language governing permissions and limitations
- - under the License.
- -
--->
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
- <head>
- <title>SYNOPSIS - Apache Qpid™</title>
- <meta http-equiv="X-UA-Compatible" content="IE=edge"/>
- <meta name="viewport" content="width=device-width, initial-scale=1.0"/>
- <link rel="stylesheet" href="/site.css" type="text/css" async="async"/>
- <link rel="stylesheet" href="/deferred.css" type="text/css" defer="defer"/>
- <script type="text/javascript">var _deferredFunctions = [];</script>
- <script type="text/javascript" src="/deferred.js" defer="defer"></script>
- <!--[if lte IE 8]>
- <link rel="stylesheet" href="/ie.css" type="text/css"/>
- <script type="text/javascript" src="/html5shiv.js"></script>
- <![endif]-->
-
- <!-- Redirects for `go get` and godoc.org -->
- <meta name="go-import"
- content="qpid.apache.org git https://git-wip-us.apache.org/repos/asf/qpid-proton.git"/>
- <meta name="go-source"
- content="qpid.apache.org
-https://github.com/apache/qpid-proton/blob/go1/README.md
-https://github.com/apache/qpid-proton/tree/go1{/dir}
-https://github.com/apache/qpid-proton/blob/go1{/dir}/{file}#L{line}"/>
- </head>
- <body>
- <div id="-content">
- <div id="-top" class="panel">
- <a id="-menu-link"><img width="16" height="16" src="" alt="Menu"/></a>
-
- <a id="-search-link"><img width="22" height="16" src="" alt="Search"/></a>
-
- <ul id="-global-navigation">
- <li><a id="-logotype" href="/index.html">Apache Qpid<sup>™</sup></a></li>
- <li><a href="/documentation.html">Documentation</a></li>
- <li><a href="/download.html">Download</a></li>
- <li><a href="/discussion.html">Discussion</a></li>
- </ul>
- </div>
-
- <div id="-menu" class="panel" style="display: none;">
- <div class="flex">
- <section>
- <h3>Project</h3>
-
- <ul>
- <li><a href="/overview.html">Overview</a></li>
- <li><a href="/components/index.html">Components</a></li>
- <li><a href="/releases/index.html">Releases</a></li>
- </ul>
- </section>
-
- <section>
- <h3>Messaging APIs</h3>
-
- <ul>
- <li><a href="/proton/index.html">Qpid Proton</a></li>
- <li><a href="/components/jms/index.html">Qpid JMS</a></li>
- <li><a href="/components/messaging-api/index.html">Qpid Messaging API</a></li>
- </ul>
- </section>
-
- <section>
- <h3>Servers and tools</h3>
-
- <ul>
- <li><a href="/components/broker-j/index.html">Broker-J</a></li>
- <li><a href="/components/cpp-broker/index.html">C++ broker</a></li>
- <li><a href="/components/dispatch-router/index.html">Dispatch router</a></li>
- </ul>
- </section>
-
- <section>
- <h3>Resources</h3>
-
- <ul>
- <li><a href="/dashboard.html">Dashboard</a></li>
- <li><a href="https://cwiki.apache.org/confluence/display/qpid/Index">Wiki</a></li>
- <li><a href="/resources.html">More resources</a></li>
- </ul>
- </section>
- </div>
- </div>
-
- <div id="-search" class="panel" style="display: none;">
- <form action="http://www.google.com/search" method="get">
- <input type="hidden" name="sitesearch" value="qpid.apache.org"/>
- <input type="text" name="q" maxlength="255" autofocus="autofocus" tabindex="1"/>
- <button type="submit">Search</button>
- <a href="/search.html">More ways to search</a>
- </form>
- </div>
-
- <div id="-middle" class="panel">
- <ul id="-path-navigation"><li><a href="/index.html">Home</a></li><li><a href="/releases/index.html">Releases</a></li><li><a href="/releases/qpid-dispatch-master/index.html">Qpid Dispatch documentation snapshot</a></li><li>SYNOPSIS</li></ul>
-
- <div id="-middle-content">
- <div class="sect1">
-<h2 id="_synopsis">SYNOPSIS</h2>
-<div class="sectionbody">
-<div class="paragraph"><p><strong>qdstat</strong> [<em>OPTIONS</em>]</p></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_description">DESCRIPTION</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>Shows status information about networks of Dispatch routers. It can display
-connections, network nodes and links, and router stats such as memory use.</p></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_options">OPTIONS</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>-h, --help
-: show this help message and exit</p></div>
-<div class="paragraph"><p>--version
-: Print version and exit.</p></div>
-<div class="paragraph"><p>-g, --general
-: Show General Router Stats</p></div>
-<div class="paragraph"><p>-c, --connections
-: Show Connections</p></div>
-<div class="paragraph"><p>-l, --links
-: Show Router Links</p></div>
-<div class="paragraph"><p>-n, --nodes
-: Show Router Nodes</p></div>
-<div class="paragraph"><p>-a, --address
-: Show Router Addresses</p></div>
-<div class="paragraph"><p>-m, --memory
-: Show Router Memory Stats</p></div>
-<div class="paragraph"><p>--autolinks
-: Show Auto Links</p></div>
-<div class="paragraph"><p>--linkroutes
-: Show Link Routes</p></div>
-<div class="paragraph"><p>-v, --verbose
-: Show maximum detail</p></div>
-<div class="paragraph"><p>--log
-: Show recent log entries</p></div>
-<div class="paragraph"><p>--limit=LIMIT
-: Limit number of log entries</p></div>
-<div class="sect2">
-<h3 id="_connection_options">Connection Options</h3>
-<div class="paragraph"><p>-b URL, --bus=URL
-: URL of the messaging bus to connect to (default 0.0.0.0)</p></div>
-<div class="paragraph"><p>-r ROUTER-ID, --router=ROUTER-ID
-: Router to be queried</p></div>
-<div class="paragraph"><p>-t SECS, --timeout=SECS
-: Maximum time to wait for connection in seconds (default 5)</p></div>
-<div class="paragraph"><p>--ssl-certificate=CERT
-: Client SSL certificate (PEM Format)</p></div>
-<div class="paragraph"><p>--ssl-key=KEY
-: Client SSL private key (PEM Format)</p></div>
-<div class="paragraph"><p>--ssl-trustfile=TRUSTED-CA-DB
-: Trusted Certificate Authority Database file (PEM Format)</p></div>
-<div class="paragraph"><p>--ssl-password=PASSWORD
-: Certificate password, will be prompted if not specifed.</p></div>
-<div class="paragraph"><p>--ssl-password-file=SSL-PASSWORD-FILE
-: Certificate password, will be prompted if not specifed.</p></div>
-<div class="paragraph"><p>--sasl-mechanisms=SASL-MECHANISMS
-: Allowed sasl mechanisms to be supplied during the sasl handshake.</p></div>
-<div class="paragraph"><p>--sasl-username=SASL-USERNAME
-: User name for SASL plain authentication</p></div>
-<div class="paragraph"><p>--sasl-password=SASL-PASSWORD
-: Password for SASL plain authentication</p></div>
-<div class="paragraph"><p>--sasl-password-file=SASL-PASSWORD-FILE
-: Password for SASL plain authentication</p></div>
-<div class="paragraph"><p>--ssl-disable-peer-name-verify
-: Disables SSL peer name verification. WARNING - This option is insecure and must not be used in production environments</p></div>
-</div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_output_columns">OUTPUT COLUMNS</h2>
-<div class="sectionbody">
-<div class="sect2">
-<h3 id="_qdstat_c">qdstat -c</h3>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-id
-</dt>
-<dd>
-<p>
-Unique connection identifier
-</p>
-</dd>
-<dt class="hdlist1">
-host
-</dt>
-<dd>
-<p>
-The hostname or internet address of the remotely connected AMQP container
-</p>
-</dd>
-<dt class="hdlist1">
-container
-</dt>
-<dd>
-<p>
-The container-name of the remotely connected AMQP container
-</p>
-</dd>
-<dt class="hdlist1">
-role
-</dt>
-<dd>
-<p>
-The configured role of the connection
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-normal - Normal connections from client to router
-</p>
-</li>
-<li>
-<p>
-inter-router - Connection between routers to form a network
-</p>
-</li>
-<li>
-<p>
-route-container - Connection to/from a Broker or other host to receive link-routes and waypoints
-</p>
-</li>
-</ul></div>
-</dd>
-<dt class="hdlist1">
-dir
-</dt>
-<dd>
-<p>
-The direction of connection establishment
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-in - The connection was initiated by the remote container
-</p>
-</li>
-<li>
-<p>
-out - The connection was initiated by this router
-</p>
-</li>
-</ul></div>
-</dd>
-<dt class="hdlist1">
-security
-</dt>
-<dd>
-<p>
-A description of the security/encryption in effect for this
-connection
-</p>
-</dd>
-<dt class="hdlist1">
-authentication
-</dt>
-<dd>
-<p>
-The method and user-id of the authenticated user for
-this connection
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_qdstat_l">qdstat -l</h3>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-type
-</dt>
-<dd>
-<p>
-Type of link
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-router-control - An inter-router link that is reserved for control messages exchanged between routers
-</p>
-</li>
-<li>
-<p>
-inter-router - An inter-router link that is used for normal message-routed deliveries
-</p>
-</li>
-<li>
-<p>
-endpoint - A normal link to an external endpoint container
-</p>
-</li>
-</ul></div>
-</dd>
-<dt class="hdlist1">
-dir
-</dt>
-<dd>
-<p>
-The direction of message flow on the link
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-in - Deliveries flow inbound to the router
-</p>
-</li>
-<li>
-<p>
-out - Deliveries flow outbound from the router
-</p>
-</li>
-</ul></div>
-</dd>
-<dt class="hdlist1">
-conn id
-</dt>
-<dd>
-<p>
-Unique identifier of the connection over which this link is
-attached
-</p>
-</dd>
-<dt class="hdlist1">
-id
-</dt>
-<dd>
-<p>
-Unique identifier of this link
-</p>
-</dd>
-<dt class="hdlist1">
-peer
-</dt>
-<dd>
-<p>
-For link-routed links, the unique identifier of the peer link. In
-link routing, an inbound link is paired with an outbound link
-</p>
-</dd>
-<dt class="hdlist1">
-class
-</dt>
-<dd>
-<p>
-Class of the address bound to the link
-</p>
-</dd>
-<dt class="hdlist1">
-addr
-</dt>
-<dd>
-<p>
-The address bound to the link
-</p>
-</dd>
-<dt class="hdlist1">
-phs
-</dt>
-<dd>
-<p>
-The phase of the address bound to the link
-</p>
-</dd>
-<dt class="hdlist1">
-cap
-</dt>
-<dd>
-<p>
-The capacity, in deliveries, of the link
-</p>
-</dd>
-<dt class="hdlist1">
-undel
-</dt>
-<dd>
-<p>
-The number of undelivered messages stored on the link’s FIFO
-</p>
-</dd>
-<dt class="hdlist1">
-unsettled
-</dt>
-<dd>
-<p>
-The number of unsettled deliveries being tracked by the link
-</p>
-</dd>
-<dt class="hdlist1">
-deliveries
-</dt>
-<dd>
-<p>
-The total number of deliveries that have transited this link
-</p>
-</dd>
-<dt class="hdlist1">
-admin
-</dt>
-<dd>
-<p>
-The administrative status of the link
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-enabled - The link is enabled for normal operation
-</p>
-</li>
-<li>
-<p>
-disabled - The link is disabled and should be quiescing or stopped (not yet supported)
-</p>
-</li>
-</ul></div>
-</dd>
-<dt class="hdlist1">
-oper
-</dt>
-<dd>
-<p>
-The operational status of the link
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-up - The link is operational
-</p>
-</li>
-<li>
-<p>
-down - The link is not attached
-</p>
-</li>
-<li>
-<p>
-quiescing - The link is in the process of quiescing (not yet supported)
-</p>
-</li>
-<li>
-<p>
-idle - The link has completed quiescing and is idle (not yet supported)
-</p>
-</li>
-</ul></div>
-</dd>
-<dt class="hdlist1">
-name
-</dt>
-<dd>
-<p>
-The link name (only shown if the -v option is provided)
-</p>
-</dd>
-</dl></div>
-<div class="sect3">
-<h4 id="_qdstat_n">qdstat -n</h4>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-router-id
-</dt>
-<dd>
-<p>
-Identifier of the router
-</p>
-</dd>
-<dt class="hdlist1">
-next-hop
-</dt>
-<dd>
-<p>
-If this router is not a neighbor, identifies the next-hop neighbor used to reach this router
-</p>
-</dd>
-<dt class="hdlist1">
-link
-</dt>
-<dd>
-<p>
-Unique identifier of the link to the neighbor router
-</p>
-</dd>
-<dt class="hdlist1">
-cost
-</dt>
-<dd>
-<p>
-The topology cost to this remote router (with -v option only)
-</p>
-</dd>
-<dt class="hdlist1">
-neighbors
-</dt>
-<dd>
-<p>
-The list of neighbor routers (the router’s link-state) (with -v option only)
-</p>
-</dd>
-<dt class="hdlist1">
-valid-origins
-</dt>
-<dd>
-<p>
-The list of origin routers for which the best path to the listed router passes through this router (with -v option only)
-</p>
-</dd>
-</dl></div>
-</div>
-</div>
-<div class="sect2">
-<h3 id="_qdstat_a">qdstat -a</h3>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-class
-</dt>
-<dd>
-<p>
-The class of the listed address
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-local - Address that is local to this router
-</p>
-</li>
-<li>
-<p>
-topo - Topological address used for router control messages
-</p>
-</li>
-<li>
-<p>
-router - A summary router address used to route messages to a remote router’s local addresses
-</p>
-</li>
-<li>
-<p>
-mobile - A mobile address for an attached consumer or producer
-</p>
-</li>
-</ul></div>
-</dd>
-<dt class="hdlist1">
-addr
-</dt>
-<dd>
-<p>
-The address text
-</p>
-</dd>
-<dt class="hdlist1">
-phs
-</dt>
-<dd>
-<p>
-For mobile addresses only, the phase of the address. Direct addresses have only a phase 0. Waypoint addresses have multiple phases, normally 0 and 1.
-</p>
-</dd>
-<dt class="hdlist1">
-distrib
-</dt>
-<dd>
-<p>
-Distribution method used for this address
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-multicast - A copy of each message is delivered once to each consumer for the address
-</p>
-</li>
-<li>
-<p>
-closest - Each message is delivered to only one consumer for the address. The closest (lowest cost) consumer will be chosen. If there are multiple lowest-cost consumers, deliveries will be spread across those consumers.
-</p>
-</li>
-<li>
-<p>
-balanced - Each message is delivered to only one consumer for the address. The consumer with the fewest outstanding (unsettled) deliveries will be chosen. The cost of the route to the consumer is a threshold for delivery (i.e. higher cost consumers will only receive deliveries if closer consumers are backed up).
-</p>
-</li>
-<li>
-<p>
-flood - Used only for router-control traffic. This is multicast without prevention of duplicate deliveries.
-</p>
-</li>
-</ul></div>
-</dd>
-<dt class="hdlist1">
-in-proc
-</dt>
-<dd>
-<p>
-The number of in-process consumers for this address
-</p>
-</dd>
-<dt class="hdlist1">
-local
-</dt>
-<dd>
-<p>
-The number of local (on this router) consumers for this address
-</p>
-</dd>
-<dt class="hdlist1">
-remote
-</dt>
-<dd>
-<p>
-The number of remote routers that have at least one consumer for this address
-</p>
-</dd>
-<dt class="hdlist1">
-cntnr
-</dt>
-<dd>
-<p>
-The number of locally attached containers that are destinations for link-routes on this address
-</p>
-</dd>
-<dt class="hdlist1">
-in
-</dt>
-<dd>
-<p>
-The number of deliveries for this address that entered the network on this router
-</p>
-</dd>
-<dt class="hdlist1">
-out
-</dt>
-<dd>
-<p>
-The number of deliveries for this address that exited the network on this router
-</p>
-</dd>
-<dt class="hdlist1">
-thru
-</dt>
-<dd>
-<p>
-The number of deliveries for this address that were forwarded to other routers
-</p>
-</dd>
-<dt class="hdlist1">
-to-proc
-</dt>
-<dd>
-<p>
-The number of deliveries for this address that were delivered to an in-process consumer
-</p>
-</dd>
-<dt class="hdlist1">
-from-proc
-</dt>
-<dd>
-<p>
-The number of deliveries for this address that were received from an in-process producer
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_qdstat_linkroutes">qdstat --linkroutes</h3>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-prefix
-</dt>
-<dd>
-<p>
-The prefix for matching addresses of routed links
-</p>
-</dd>
-<dt class="hdlist1">
-dir
-</dt>
-<dd>
-<p>
-The direction (from the router’s perspective) of matching links
-</p>
-</dd>
-<dt class="hdlist1">
-distrib
-</dt>
-<dd>
-<p>
-The distribution method used for routed links
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-linkBalanced - the only supported distribution for routed links
-</p>
-</li>
-</ul></div>
-</dd>
-<dt class="hdlist1">
-status
-</dt>
-<dd>
-<p>
-Operational status of the link route
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-active - Route is actively routing attaches (i.e. ready for use)
-</p>
-</li>
-<li>
-<p>
-inactive - Route is inactive because there is no local destination connected
-</p>
-</li>
-</ul></div>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_qstat_autolinks">qstat --autolinks</h3>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-addr
-</dt>
-<dd>
-<p>
-The address of the auto link
-</p>
-</dd>
-<dt class="hdlist1">
-dir
-</dt>
-<dd>
-<p>
-The direction of message flow for the auto link
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-in - Messages flow in from the route-container to the router network
-</p>
-</li>
-<li>
-<p>
-out - Messages flow out to the route-container from the router network
-</p>
-</li>
-</ul></div>
-</dd>
-<dt class="hdlist1">
-phs
-</dt>
-<dd>
-<p>
-Phase of the address for this auto link
-</p>
-</dd>
-<dt class="hdlist1">
-link
-</dt>
-<dd>
-<p>
-Unique identifier of the link managed by this auto link
-</p>
-</dd>
-<dt class="hdlist1">
-status
-</dt>
-<dd>
-<p>
-The operational status of this auto link
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-inactive - There is no connected container for this auto link
-</p>
-</li>
-<li>
-<p>
-attaching - The link is attaching to the container
-</p>
-</li>
-<li>
-<p>
-failed - The link-attach failed
-</p>
-</li>
-<li>
-<p>
-active - The link is operational
-</p>
-</li>
-<li>
-<p>
-quiescing - The link is quiescing (not yet supported)
-</p>
-</li>
-<li>
-<p>
-idle - The link is idle (not yet supported)
-</p>
-</li>
-</ul></div>
-</dd>
-<dt class="hdlist1">
-lastErr
-</dt>
-<dd>
-<p>
-The description of the last attach failure that occurred on this auto link
-</p>
-</dd>
-</dl></div>
-</div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_see_also">SEE ALSO</h2>
-<div class="sectionbody">
-<div class="paragraph"><p><em>qdrouterd(8)</em>, <em>qdmanage(8)</em>, <em>qdrouterd.conf(5)</em></p></div>
-<div class="paragraph"><p><a href="http://qpid.apache.org/components/dispatch-router">http://qpid.apache.org/components/dispatch-router</a></p></div>
-</div>
-</div>
-
-
- <hr/>
-
- <ul id="-apache-navigation">
- <li><a href="http://www.apache.org/">Apache</a></li>
- <li><a href="http://www.apache.org/licenses/">License</a></li>
- <li><a href="http://www.apache.org/foundation/sponsorship.html">Sponsorship</a></li>
- <li><a href="http://www.apache.org/foundation/thanks.html">Thanks!</a></li>
- <li><a href="/security.html">Security</a></li>
- <li><a href="http://www.apache.org/"><img id="-apache-feather" width="48" height="14" src="" alt="Apache"/></a></li>
- </ul>
-
- <p id="-legal">
- Apache Qpid, Messaging built on AMQP; Copyright © 2015
- The Apache Software Foundation; Licensed under
- the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache
- License, Version 2.0</a>; Apache Qpid, Qpid, Qpid Proton,
- Proton, Apache, the Apache feather logo, and the Apache Qpid
- project logo are trademarks of The Apache Software
- Foundation; All other marks mentioned may be trademarks or
- registered trademarks of their respective owners
- </p>
- </div>
- </div>
- </div>
- </body>
-</html>
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org
[11/13] qpid-site git commit: QPID-8015: Prepare the dispatch release
scripts for the new user guide
Posted by jr...@apache.org.
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/book/book.html
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/book/book.html b/content/releases/qpid-dispatch-master/book/book.html
deleted file mode 100644
index 32a2fb8..0000000
--- a/content/releases/qpid-dispatch-master/book/book.html
+++ /dev/null
@@ -1,5020 +0,0 @@
-<!DOCTYPE html>
-<!--
- -
- - Licensed to the Apache Software Foundation (ASF) under one
- - or more contributor license agreements. See the NOTICE file
- - distributed with this work for additional information
- - regarding copyright ownership. The ASF licenses this file
- - to you under the Apache License, Version 2.0 (the
- - "License"); you may not use this file except in compliance
- - with the License. You may obtain a copy of the License at
- -
- - http://www.apache.org/licenses/LICENSE-2.0
- -
- - Unless required by applicable law or agreed to in writing,
- - software distributed under the License is distributed on an
- - "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- - KIND, either express or implied. See the License for the
- - specific language governing permissions and limitations
- - under the License.
- -
--->
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
- <head>
- <title>1. Introduction - Apache Qpid™</title>
- <meta http-equiv="X-UA-Compatible" content="IE=edge"/>
- <meta name="viewport" content="width=device-width, initial-scale=1.0"/>
- <link rel="stylesheet" href="/site.css" type="text/css" async="async"/>
- <link rel="stylesheet" href="/deferred.css" type="text/css" defer="defer"/>
- <script type="text/javascript">var _deferredFunctions = [];</script>
- <script type="text/javascript" src="/deferred.js" defer="defer"></script>
- <!--[if lte IE 8]>
- <link rel="stylesheet" href="/ie.css" type="text/css"/>
- <script type="text/javascript" src="/html5shiv.js"></script>
- <![endif]-->
-
- <!-- Redirects for `go get` and godoc.org -->
- <meta name="go-import"
- content="qpid.apache.org git https://git-wip-us.apache.org/repos/asf/qpid-proton.git"/>
- <meta name="go-source"
- content="qpid.apache.org
-https://github.com/apache/qpid-proton/blob/go1/README.md
-https://github.com/apache/qpid-proton/tree/go1{/dir}
-https://github.com/apache/qpid-proton/blob/go1{/dir}/{file}#L{line}"/>
- </head>
- <body>
- <div id="-content">
- <div id="-top" class="panel">
- <a id="-menu-link"><img width="16" height="16" src="" alt="Menu"/></a>
-
- <a id="-search-link"><img width="22" height="16" src="" alt="Search"/></a>
-
- <ul id="-global-navigation">
- <li><a id="-logotype" href="/index.html">Apache Qpid<sup>™</sup></a></li>
- <li><a href="/documentation.html">Documentation</a></li>
- <li><a href="/download.html">Download</a></li>
- <li><a href="/discussion.html">Discussion</a></li>
- </ul>
- </div>
-
- <div id="-menu" class="panel" style="display: none;">
- <div class="flex">
- <section>
- <h3>Project</h3>
-
- <ul>
- <li><a href="/overview.html">Overview</a></li>
- <li><a href="/components/index.html">Components</a></li>
- <li><a href="/releases/index.html">Releases</a></li>
- </ul>
- </section>
-
- <section>
- <h3>Messaging APIs</h3>
-
- <ul>
- <li><a href="/proton/index.html">Qpid Proton</a></li>
- <li><a href="/components/jms/index.html">Qpid JMS</a></li>
- <li><a href="/components/messaging-api/index.html">Qpid Messaging API</a></li>
- </ul>
- </section>
-
- <section>
- <h3>Servers and tools</h3>
-
- <ul>
- <li><a href="/components/broker-j/index.html">Broker-J</a></li>
- <li><a href="/components/cpp-broker/index.html">C++ broker</a></li>
- <li><a href="/components/dispatch-router/index.html">Dispatch router</a></li>
- </ul>
- </section>
-
- <section>
- <h3>Resources</h3>
-
- <ul>
- <li><a href="/dashboard.html">Dashboard</a></li>
- <li><a href="https://cwiki.apache.org/confluence/display/qpid/Index">Wiki</a></li>
- <li><a href="/resources.html">More resources</a></li>
- </ul>
- </section>
- </div>
- </div>
-
- <div id="-search" class="panel" style="display: none;">
- <form action="http://www.google.com/search" method="get">
- <input type="hidden" name="sitesearch" value="qpid.apache.org"/>
- <input type="text" name="q" maxlength="255" autofocus="autofocus" tabindex="1"/>
- <button type="submit">Search</button>
- <a href="/search.html">More ways to search</a>
- </form>
- </div>
-
- <div id="-middle" class="panel">
- <ul id="-path-navigation"><li><a href="/index.html">Home</a></li><li><a href="/releases/index.html">Releases</a></li><li><a href="/releases/qpid-dispatch-master/index.html">Qpid Dispatch documentation snapshot</a></li><li>1. Introduction</li></ul>
-
- <div id="-middle-content">
- <div class="sect1">
-<h2 id="introduction">1. Introduction</h2>
-<div class="sectionbody">
-<div class="sect2">
-<h3 id="overview">1.1. Overview</h3>
-<div class="paragraph"><p>The Dispatch router is an AMQP 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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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>
-<div class="sect2">
-<h3 id="benefits">1.2. Benefits</h3>
-<div class="paragraph"><p>Simplifies connectivity</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-An endpoint can do all of its messaging through a single transport
-connection
-</p>
-</li>
-<li>
-<p>
-Avoid opening holes in firewalls for incoming connections
-</p>
-</li>
-</ul></div>
-<div class="paragraph"><p>Provides messaging connectivity where there is no TCP/IP connectivity</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-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).
-</p>
-</li>
-</ul></div>
-<div class="paragraph"><p>Simplifies reliability</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-Reliability and availability are provided using redundant topology,
-not server clustering
-</p>
-</li>
-<li>
-<p>
-Reliable end-to-end messaging without persistent stores
-</p>
-</li>
-<li>
-<p>
-Use a message broker only when you need store-and-forward semantics
-</p>
-</li>
-</ul></div>
-</div>
-<div class="sect2">
-<h3 id="features">1.3. Features</h3>
-<div class="ulist"><ul>
-<li>
-<p>
-Can be deployed stand-alone or in a network of routers
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-Supports arbitrary network topology - no restrictions on redundancy
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-Automatic route computation - adjusts quickly to changes in topology
-</p>
-</li>
-</ul></div>
-</li>
-</ul></div>
-</li>
-<li>
-<p>
-Provides remote access to brokers or other AMQP servers
-</p>
-</li>
-<li>
-<p>
-Security
-</p>
-</li>
-</ul></div>
-</div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_theory_of_operation">2. Theory of Operation</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>This section introduces some key concepts about the router.</p></div>
-<div class="sect2">
-<h3 id="_overview">2.1. Overview</h3>
-<div class="paragraph"><p>The router is an <em>application layer</em> program running as a normal
-user program or as a daemon.</p></div>
-<div class="paragraph"><p>The router accepts AMQP connections from clients and creates AMQP
-connections to brokers or AMQP-based services. The router classifies
-incoming AMQP messages and routes the
-messages between message producers and message consumers.</p></div>
-<div class="paragraph"><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 message source to every message
-destination and to recover quickly from failures. The router relies on
-redundant network paths to provide continued connectivity in the face
-of system or network failure.</p></div>
-<div class="paragraph"><p>A messaging client can make a single AMQP connection into a messaging
-bus built with routers and, over that connection, exchange messages
-with one or more message brokers connected to any router in the
-network. At the same time the client can exchange messages directly
-with other endpoints without involving a broker at all.</p></div>
-</div>
-<div class="sect2">
-<h3 id="_connections">2.2. Connections</h3>
-<div class="paragraph"><p>The router connects clients, servers, AMQP services, and other
-routers through network connections.</p></div>
-<div class="sect3">
-<h4 id="_listener">2.2.1. Listener</h4>
-<div class="paragraph"><p>The router provides <em>listeners</em> that accept client connections.
-A client connecting to a router listener uses the
-same methods that it would use to connect to a broker. From the
-client’s perspective the router connection and link establishment are
-identical to broker connection and link establishment.</p></div>
-<div class="paragraph"><p>Several types of listeners are defined by their role.</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="20%" />
-<col width="80%" />
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">Role</p></td>
-<td align="left" valign="top"><p class="table">Description</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">normal</p></td>
-<td align="left" valign="top"><p class="table">The connection is used for AMQP clients using normal message delivery.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">inter-router</p></td>
-<td align="left" valign="top"><p class="table">The connection is assumed to be to another router in the network. Inter-router discovery and routing protocols can only be used over inter-router connections.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">route-container</p></td>
-<td align="left" valign="top"><p class="table">The connection is a broker or other resource that holds known addresses. The router will use this connection to create links as necessary. The addresses are available for routing only after the remote resource has created a connection.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-<div class="sect3">
-<h4 id="_connector">2.2.2. Connector</h4>
-<div class="paragraph"><p>The router can also be configured to create outbound connections to
-messaging brokers or other AMQP entities using <em>connectors</em>. A
-connector is defined with the network address of the broker and the
-name or names of the resources that are available in that broker. When
-a router connects to a broker through a connector it uses the same
-methods a normal messaging client would use when connecting to the
-broker.</p></div>
-<div class="paragraph"><p>Several types of connectors are defined by their role.</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="20%" />
-<col width="80%" />
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">Role</p></td>
-<td align="left" valign="top"><p class="table">Description</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">normal</p></td>
-<td align="left" valign="top"><p class="table">The connection is used for AMQP clients using normal message delivery. On this connector the router will initiate the connection but it will never create any links. Links are to be created by the peer that accepts the connection.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">inter-router</p></td>
-<td align="left" valign="top"><p class="table">The connection is assumed to be to another router in the network. Inter-router discovery and routing protocols can only be used over inter-router connections.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">route-container</p></td>
-<td align="left" valign="top"><p class="table">The connection is to a broker or other resource that holds known addresses. The router will use this connection to create links as necessary. The addresses are available for routing only after the router has created a connection to the remote resource.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-</div>
-<div class="sect2">
-<h3 id="_addresses">2.3. Addresses</h3>
-<div class="paragraph"><p>AMQP addresses are used to control the flow of messages across a
-network of routers. Addresses are used in a number of different places
-in the AMQP 1.0 protocol. They can be used in a specific message in
-the <em>to</em> and <em>reply-to</em> fields of a message’s properties. They are also
-used during the creation of links in the <em>address</em> field of a <em>source</em> or
-a <em>target</em>.</p></div>
-<div class="admonitionblock">
-<table><tr>
-<td class="icon">
-<div class="title">Note</div>
-</td>
-<td class="content">
-<div class="paragraph"><p>Addresses in this discussion refer to AMQP protocol addresses and not
-to TCP/IP network addresses. TCP/IP network addresses are used by
-messaging clients, brokers, and routers to create AMQP connections.
-AMQP protocol addresses are the names of source and destination
-endpoints for messages within the messaging network.</p></div>
-</td>
-</tr></table>
-</div>
-<div class="paragraph"><p>Addresses designate various kinds of entities in a messaging network:</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-Endpoint processes that consume data or offer a service
-</p>
-</li>
-<li>
-<p>
-Topics that match multiple consumers to multiple producers
-</p>
-</li>
-<li>
-<p>
-Entities within a messaging broker:
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-Queues
-</p>
-</li>
-<li>
-<p>
-Durable Topics
-</p>
-</li>
-<li>
-<p>
-Exchanges
-</p>
-</li>
-</ul></div>
-</li>
-</ul></div>
-<div class="paragraph"><p>The syntax of an AMQP address is opaque as far as the router network
-is concerned. A syntactical structure may be used by the administrator
-who creates addresses but the router treats them as opaque
-strings.</p></div>
-<div class="paragraph"><p>The router maintains several classes of address based on how the address is
-configured or discovered.</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="25%" />
-<col width="75%" />
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">Address Type</p></td>
-<td align="left" valign="top"><p class="table">Description</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">mobile</p></td>
-<td align="left" valign="top"><p class="table">The address is a rendezvous point between senders and receivers. The router aggregates and serializes messages from senders and distributes messages to receivers.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">link route</p></td>
-<td align="left" valign="top"><p class="table">The address defines a private messaging path between a sender and a receiver. The router simply passes messages between the end points.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-<div class="sect3">
-<h4 id="_mobile_addresses">2.3.1. Mobile Addresses</h4>
-<div class="paragraph"><p>Routers consider addresses to be mobile such that any users of an
-address may be directly connected to any router in a network and may
-move around the topology. In cases where messages are broadcast to or
-balanced across multiple consumers, the address users may be connected
-to multiple routers in the network.</p></div>
-<div class="paragraph"><p>Mobile addresses are rendezvous points for senders and receivers.
-Messages arrive at the mobile address and are dispatched to their
-destinations according to the routing defined for the mobile address.
-The details of these routing patterns are discussed later.</p></div>
-<div class="paragraph"><p>Mobile addresses may be discovered during normal router operation or
-configured through management settings.</p></div>
-<div class="sect4">
-<h5 id="_discovered_mobile_addresses">Discovered Mobile Addresses</h5>
-<div class="paragraph"><p>Mobile addresses are created when a client creates a link to a source
-or destination address that is unknown to the router network.</p></div>
-<div class="paragraph"><p>Suppose a service provider wants to offer <em>my-service</em> that clients
-may use. The service provider must open a receiver link with source
-address <em>my-service</em>. The router creates a mobile address
-<em>my-service</em> and propagates the address so that it is known to every
-router in the network.</p></div>
-<div class="paragraph"><p>Later a client wants to use the service and creates a sending link
-with target address <em>my-service</em>. The router matches the service
-provider’s receiver having source address <em>my-service</em> to the client’s
-sender having target address <em>my-service</em> and routes messages between
-the two.</p></div>
-<div class="paragraph"><p>Any number of other clients can create links to the service as
-well. The clients do not have to know where in the router network the
-service provider is physically located nor are the clients required to
-connect to a specific router to use the service. Regardless of how
-many clients are using the service the service provider needs only a
-single connection and link into the router network.</p></div>
-<div class="paragraph"><p>Another view of this same scenario is when a client tries to use the
-service before service provider has connected to the network. In this
-case the router network creates the mobile address <em>my-service</em> as
-before. However, since the mobile address has only client sender links
-and no receiver links the router stalls the clients and prevents them
-from sending any messages. Later, after the service provider connects
-and creates the receiver link, the router will issue credits to the
-clients and the messages will begin to flow between the clients and
-the service.</p></div>
-<div class="paragraph"><p>The service provider can connect, disconnect, and reconnect from a
-different location without having to change any of the clients or
-their connections. Imagine having the service running on a
-laptop. One day the connection is from corporate headquarters and the
-next day the connection is from some remote location. In this case the
-service provider’s computer will typically have different host IP
-addresses for each connection. Using the router network the service
-provider connects to the router network and offers the named service
-and the clients connect to the router network and consume from the
-named service. The router network routes messages between the mobile
-addresses effectively masking host IP addresses of the service
-provider and the client systems.</p></div>
-</div>
-<div class="sect4">
-<h5 id="_configured_mobile_addresses">Configured Mobile Addresses</h5>
-<div class="paragraph"><p>Mobile addresses may be configured using the router <em>autoLink</em>
-object. An address created via an <em>autoLink</em> represents a queue,
-topic, or other service in an external broker. Logically the
-<em>autoLink</em> addresses are treated by the router network as if the
-broker had connected to the router and offered the services itself.</p></div>
-<div class="paragraph"><p>For each configured mobile address the router will create a single
-link to the external resource. Messages flow between sender links and
-receiver links the same regardless if the mobile address was
-discovered or configured.</p></div>
-<div class="paragraph"><p>Multiple <em>autoLink</em> objects may define the same address on multiple
-brokers. In this case the router network creates a sharded resource
-split between the brokers. Any client can seamlessly send and receive
-messages from either broker.</p></div>
-<div class="paragraph"><p>Note that the brokers do not need to be clustered or federated to
-receive this treatment. The brokers may even be from different vendors
-or be different versions of the same broker yet still work together to
-provide a larger service platform.</p></div>
-</div>
-</div>
-<div class="sect3">
-<h4 id="_link_route_addresses">2.3.2. Link Route Addresses</h4>
-<div class="paragraph"><p>Link route addresses may be configured using the router <em>linkRoute</em>
-object. An link route address represents a queue, topic, or other
-service in an external broker similar to addresses configured by
-<em>autoLink</em> objects. For link route addresses the router propagates a
-separate link attachment to the broker resource for each incoming
-client link. The router does not automatically create any links to the
-broker resource.</p></div>
-<div class="paragraph"><p>Using link route addresses the router network does not participate in
-aggregated message distribution. The router simply passes message
-delivery and settlement between the two end points.</p></div>
-</div>
-</div>
-<div class="sect2">
-<h3 id="_message_routing">2.4. Message Routing</h3>
-<div class="paragraph"><p>Addresses have semantics associated with them that are assigned when
-the address is provisioned or discovered. The semantics of an address
-control how routers behave when they see the address being
-used. Address semantics include the following considerations:</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-Routing pattern - balanced, closest, multicast
-</p>
-</li>
-<li>
-<p>
-Routing mechanism - message routed, link routed
-</p>
-</li>
-</ul></div>
-<div class="sect3">
-<h4 id="_routing_patterns">2.4.1. Routing Patterns</h4>
-<div class="paragraph"><p>Routing patterns define the paths that a message with a mobile address can take across a network. These routing patterns can be used for both direct routing, in which the router distributes messages between clients without a broker, and indirect routing, in which the router enables clients to exchange messages through a broker.</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="20%" />
-<col width="80%" />
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">Pattern</p></td>
-<td align="left" valign="top"><p class="table">Description</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">Balanced</p></td>
-<td align="left" valign="top"><p class="table">An anycast method which allows multiple receivers to use the same address. In this case, messages (or links) are routed to exactly one of the receivers and the network attempts to balance the traffic load across the set of receivers using the same address. This routing delivers messages to receivers based on how quickly they settle the deliveries. Faster receivers get more messages.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">Closest</p></td>
-<td align="left" valign="top"><p class="table">An anycast method in which even if there are more receivers for the same address, every message is sent along the shortest path to reach the destination. This means that only one receiver will get the message. Each message is delivered to the closest receivers in terms of topology cost. If there are multiple receivers with the same lowest cost, deliveries will be spread evenly among those receivers.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">Multicast</p></td>
-<td align="left" valign="top"><p class="table">Having multiple consumers on the same address at the same time, messages are routed such that each consumer receives one copy of the message.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-<div class="sect3">
-<h4 id="_routing_mechanisms">2.4.2. Routing Mechanisms</h4>
-<div class="paragraph"><p>The fact that addresses can be used in different ways suggests that
-message routing can be accomplished in different ways. Before going
-into the specifics of the different routing mechanisms, it would be
-good to first define what is meant by the term <em>routing</em>:</p></div>
-<div class="literalblock">
-<div class="content">
-<pre><code>In a network built of multiple, interconnected routers 'routing'
-determines which connection to use to send a message directly
-to its destination or one step closer to its destination.</code></pre>
-</div></div>
-<div class="paragraph"><p>Each router serves as the terminus of a collection of incoming and
-outgoing links. Some of the links are designated for message routing,
-and others are designated for link routing. In both cases, the links
-either connect directly to endpoints that produce and consume
-messages, or they connect to other routers in the network along
-previously established connections.</p></div>
-<div class="sect4">
-<h5 id="_message_routed">Message Routed</h5>
-<div class="paragraph"><p>Message routing occurs upon delivery of a message and is done based on
-the address in the message’s <em>to</em> field.</p></div>
-<div class="paragraph"><p>When a delivery arrives on an incoming message-routing link, the
-router extracts the address from the delivered message’s <em>to</em> field and
-looks the address up in its routing table. The lookup results in zero
-or more outgoing links onto which the message shall be resent.</p></div>
-<div class="paragraph"><p>Message routing can also occur without an address in the
-message’s <em>to</em> field if the incoming link has a target address. In
-fact, if the sender uses a link with a target address, the <em>to</em> field
-shall be ignored even if used.</p></div>
-</div>
-<div class="sect4">
-<h5 id="_link_routed">Link Routed</h5>
-<div class="paragraph"><p>Link routing occurs when a new link is attached to the router across
-one of its AMQP connections. It is done based on the <em>target.address</em>
-field of an inbound link and the <em>source.address</em> field of an outbound
-link.</p></div>
-<div class="paragraph"><p>Link routing uses the same routing table that message routing
-uses. The difference is that the routing occurs during the link-attach
-operation, and link attaches are propagated along the appropriate path
-to the destination. What results is a chain of links, connected
-end-to-end, from source to destination. It is similar to a virtual
-circuit in a telecom system.</p></div>
-<div class="paragraph"><p>Each router in the chain holds pairs of link termini that are tied
-together. The router then simply exchanges all deliveries, delivery
-state changes, and link state changes between the two termini.</p></div>
-<div class="paragraph"><p>The endpoints that use the link chain do not see any difference in
-behavior between a link chain and a single point-to-point link. All of
-the features available in the link protocol (flow control,
-transactional delivery, etc.) are available over a routed link-chain.</p></div>
-</div>
-</div>
-<div class="sect3">
-<h4 id="_message_settlement">2.4.3. Message Settlement</h4>
-<div class="paragraph"><p>Messages may be delivered with varying degrees of reliability.</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-At most once
-</p>
-</li>
-<li>
-<p>
-At least once
-</p>
-</li>
-<li>
-<p>
-Exactly once
-</p>
-</li>
-</ul></div>
-<div class="paragraph"><p>The reliability is negotiated between the client and server during
-link establishment. The router handles all levels of reliability by treating
-messages as either <em>pre-settled</em> or <em>unsettled</em>.</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="20%" />
-<col width="80%" />
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">Delivery</p></td>
-<td align="left" valign="top"><p class="table">Handling</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">pre-settled</p></td>
-<td align="left" valign="top"><p class="table">If the arriving delivery is pre-settled (i.e., fire and forget), the incoming delivery shall be settled by the router, and the outgoing deliveries shall also be pre-settled. In other words, the pre-settled nature of the message delivery is propagated across the network to the message’s destination.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">unsettled</p></td>
-<td align="left" valign="top"><p class="table">Unsettled delivery is also propagated across the network. Because unsettled delivery records cannot be discarded, the router tracks the incoming deliveries and keeps the association of the incoming deliveries to the resulting outgoing deliveries. This kept association allows the router to continue to propagate changes in delivery state (settlement and disposition) back and forth along the path which the message traveled.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-</div>
-<div class="sect2">
-<h3 id="_security">2.5. Security</h3>
-<div class="paragraph"><p>The router uses the SSL protocol and related certificates and SASL
-protocol mechanisms to encrypt and authenticate remote peers. Router
-listeners act as network servers and router connectors act as network
-clients. Both connection types may be configured securely with SSL
-and SASL.</p></div>
-<div class="paragraph"><p>The router Policy module is an optional authorization mechanism
-enforcing user connection restrictions and AMQP resource access
-control.</p></div>
-</div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="using-qpid-dispatch">3. Using Qpid Dispatch</h2>
-<div class="sectionbody">
-<div class="sect2">
-<h3 id="configuration">3.1. Configuration</h3>
-<div class="paragraph"><p>The default configuration file is installed in
-<em>/usr/local/etc/qpid-dispatch/qdrouterd.conf</em>. 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></div>
-<div class="paragraph"><p>To run the router, invoke the executable: <code>qdrouterd [-c my-config-file]</code></p></div>
-<div class="paragraph"><p>For more details of the configuration file see the <em>qdrouterd.conf(5)</em> man
-page.</p></div>
-</div>
-<div class="sect2">
-<h3 id="tools">3.2. Tools</h3>
-<div class="sect3">
-<h4 id="qdstat">3.2.1. qdstat</h4>
-<div class="paragraph"><p><em>qdstat</em> is a command line tool that lets you view the status of a
-Dispatch Router. The following options are useful for seeing what the
-router is doing:</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="17%" />
-<col width="83%" />
-<thead>
-<tr>
-<th align="left" valign="top"><em>Option</em> </th>
-<th align="left" valign="top"><em>Description</em></th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">-l</p></td>
-<td align="left" valign="top"><p class="table">Print a list of AMQP links attached to the router. Links are
-unidirectional. Outgoing links are usually associated with a
-subscription address. The tool distinguishes between <em>endpoint</em> links
-and <em>router</em> links. Endpoint links are attached to clients using the
-router. Router links are attached to other routers in a network of
-routbers.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">-a</p></td>
-<td align="left" valign="top"><p class="table">Print a list of addresses known to the router.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">-n</p></td>
-<td align="left" valign="top"><p class="table">Print a list of known routers in the network.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">-c</p></td>
-<td align="left" valign="top"><p class="table">Print a list of connections to the router.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">--autolinks</p></td>
-<td align="left" valign="top"><p class="table">Print a list of configured auto-links.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">--linkroutes</p></td>
-<td align="left" valign="top"><p class="table">Print a list of configures link-routes.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-<div class="paragraph"><p>For complete details see the <em>qdstat(8)</em> man page and the output of
-<code>qdstat --help</code>.</p></div>
-</div>
-<div class="sect3">
-<h4 id="qdmanage">3.2.2. qdmanage</h4>
-<div class="paragraph"><p><em>qdmanage</em> is a general-purpose AMQP management client that allows you
-to not only view but modify the configuration of a running dispatch
-router.</p></div>
-<div class="paragraph"><p>For example you can query all the connection entities in the router:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdmanage query --type connection</code></pre>
-</div></div>
-<div class="paragraph"><p>To enable logging debug and higher level messages by default:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdmanage update log/DEFAULT enable=debug+</code></pre>
-</div></div>
-<div class="paragraph"><p>In fact, everything that can be configured in the configuration file can
-also be created in a running router via management. For example to
-create a new listener in a running router:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdmanage create type=listener port=5555</code></pre>
-</div></div>
-<div class="paragraph"><p>Now you can connect to port 5555, for exampple:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdmanage query -b localhost:5555 --type listener</code></pre>
-</div></div>
-<div class="paragraph"><p>For complete details see the <em>qdmanage(8)</em> man page and the output of
-<code>qdmanage --help</code>. Also for details of what can be configured see the
-<em>qdrouterd.conf(5)</em> man page.</p></div>
-</div>
-</div>
-<div class="sect2">
-<h3 id="basic-usage-and-examples">3.3. Basic Usage and Examples</h3>
-<div class="sect3">
-<h4 id="standalone-and-interior-modes">3.3.1. Standalone and Interior Modes</h4>
-<div class="paragraph"><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></div>
-<div class="paragraph"><p>If your router is running in stand-alone mode, <em>qdstat -a</em> will look
-like the following:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ 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</code></pre>
-</div></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ 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</code></pre>
-</div></div>
-</div>
-<div class="sect3">
-<h4 id="mobile-subscribers">3.3.2. Mobile Subscribers</h4>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ python ./simple_recv.py -a 127.0.0.1/my-address</code></pre>
-</div></div>
-<div class="paragraph"><p>This command creates a receiving link subscribed to the specified
-address. To verify the subscription:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ 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</code></pre>
-</div></div>
-<div class="paragraph"><p>You can then, in a separate command window, run a sender to produce
-messages to that address:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ python ./simple_send.py -a 127.0.0.1/my-address</code></pre>
-</div></div>
-</div>
-<div class="sect3">
-<h4 id="dynamic-reply-to">3.3.3. Dynamic Reply-To</h4>
-<div class="paragraph"><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>
-<div class="listingblock">
-<div class="content">
-<pre><code>#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();
-}</code></pre>
-</div></div>
-<div class="paragraph"><p>The equivalent program written in Python against the Proton Messenger
-API:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>from proton import Messenger, Message
-
-def main():
- host = "0.0.0.0:5672"
-
- messenger = Messenger()
- messenger.start()
- messenger.route("amqp:/*", "amqp://%s/$1" % host)
- reply_subscription = messenger.subscribe("amqp:/#")
- reply_address = reply_subscription.address
-
- request = Message()
- response = Message()
-
- request.address = "amqp:/_local/$management"
- request.reply_to = reply_address
- request.properties = {u'operation' : u'DISCOVER-MGMT-NODES',
- u'type' : u'org.amqp.management',
- u'name' : u'self'}
-
- messenger.put(request)
- messenger.send()
- messenger.recv()
- messenger.get(response)
-
- print "Response: %r" % response.body
-
- messenger.stop()
-
-main()</code></pre>
-</div></div>
-</div>
-</div>
-<div class="sect2">
-<h3 id="link-routing">3.4. Link Routing</h3>
-<div class="paragraph"><p>This feature was introduced in Qpid Dispatch 0.4. This feature was
-significantly updated in Qpid Dispatch 0.6.</p></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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>
-<div class="listingblock">
-<div class="content">
-<pre><code> Public Network
- +-----------------+
- | +-----+ |
- | B1 | Rp | |
- | +/--\-+ |
- | / \ |
- | / \ |
- +----/--------\---+
- / \
- / \
- / \
- Private Net A / \ Private Net B
- +--------------/--+ +---\-------------+
- | +---/-+ | | +--\--+ |
- | B2 | Ra | | | | Rb | C1 |
- | +-----+ | | +-----+ |
- | | | |
- | | | |
- +-----------------+ +-----------------+</code></pre>
-</div></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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>
-<div class="sect3">
-<h4 id="link-routing-configuration">3.4.1. Configuration</h4>
-<div class="paragraph"><p>Starting with the configured topology shown above, how is link-routing
-configured to support the example described above?</p></div>
-<div class="paragraph"><p>First, router Ra needs to be told how to make a connection to the broker
-B2:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>connector {
- name: broker
- role: route-container
- host: <B2-url>
- port: <B2-port>
- saslMechanisms: ANONYMOUS
-}</code></pre>
-</div></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><p>Now, the router must be configured to route certain addresses to B2:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>linkRoute {
- prefix: b2
- dir: in
- connection: broker
-}
-
-linkRoute {
- prefix: b2
- dir: out
- connection: broker
-}</code></pre>
-</div></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><p>Examples of addresses that "begin with <em>b2</em>" include:</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-b2
-</p>
-</li>
-<li>
-<p>
-b2.queues
-</p>
-</li>
-<li>
-<p>
-b2.queues.app1
-</p>
-</li>
-</ul></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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>
-</div>
-<div class="sect2">
-<h3 id="indirect-waypoints-and-auto-links">3.5. Indirect Waypoints and Auto-Links</h3>
-<div class="paragraph"><p>This feature was introduced in Qpid Dispatch 0.6. It is a significant
-improvement on an earlier somewhat experimental feature called
-Waypoints.</p></div>
-<div class="paragraph"><p>Auto-link is a feature of Qpid Dispatch Router that enables a router to
-actively attach a link to a node on an external AMQP container. The
-obvious application for this feature is to route messages through a
-queue on a broker, but other applications are possible as well.</p></div>
-<div class="paragraph"><p>An auto-link manages the lifecycle of one AMQP link. If messages are to
-be routed to and from a queue on a broker, then two auto-links are
-needed: one for sending messages to the queue and another for receiving
-messages from the queue. The container to which an auto-link attempts to
-attach may be identified in one of two ways:</p></div>
-<div class="quoteblock">
-<div class="content">
-<div class="ulist"><ul>
-<li>
-<p>
-The name of the connector/listener that resulted in the connection of
-the container, or
-</p>
-</li>
-<li>
-<p>
-The AMQP container-id of the remote container.
-</p>
-</li>
-</ul></div>
-</div>
-<div class="attribution">
-</div></div>
-<div class="sect3">
-<h4 id="queue-waypoint-example">3.5.1. Queue Waypoint Example</h4>
-<div class="paragraph"><p>Here is an example configuration for routing messages deliveries through
-a pair of queues on a broker:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>connector {
- name: broker
- role: route-container
- host: <hostname>
- port: <port>
- saslMechanisms: ANONYMOUS
-}
-
-address {
- prefix: queue
- waypoint: yes
-}
-
-autoLink {
- addr: queue.first
- dir: in
- connection: broker
-}
-
-autoLink {
- addr: queue.first
- dir: out
- connection: broker
-}
-
-autoLink {
- addr: queue.second
- dir: in
- connection: broker
-}
-
-autoLink {
- addr: queue.second
- dir: out
- connection: broker
-}</code></pre>
-</div></div>
-<div class="paragraph"><p>The <code>address</code> entity identifies a namespace <em>queue.</em> that will be used
-for routing messages through queues via autolinks. The four <code>autoLink</code> entities
-identify the head and tail of two queues on the broker that will be connected
-via auto-links.</p></div>
-<div class="paragraph"><p>If there is no broker connected, the auto-links shall remain
-<em>inactive</em>. This can be observed by using the <code>qdstat</code> tool:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdstat --autolinks
-AutoLinks
- addr dir phs extAddr link status lastErr
- ========================================================
- queue.first in 1 inactive
- queue.first out 0 inactive
- queue.second in 1 inactive
- queue.second out 0 inactive</code></pre>
-</div></div>
-<div class="paragraph"><p>If a broker comes online with a queue called <em>queue.first</em>, the
-auto-links will attempt to activate:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdstat --autolinks
-AutoLinks
- addr dir phs extAddr link status lastErr
- ===========================================================================
- queue.first in 1 6 active
- queue.first out 0 7 active
- queue.second in 1 failed Node not found: queue.second
- queue.second out 0 failed Node not found: queue.second</code></pre>
-</div></div>
-<div class="paragraph"><p>Note that two of the auto-links are in <em>failed</em> state because the queue
-does not exist on the broker.</p></div>
-<div class="paragraph"><p>If we now use the Qpid Proton example application <code>simple_send.py</code> to send
-three messages to <em>queue.first</em> via the router:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ python simple_send.py -a 127.0.0.1/queue.first -m3
-all messages confirmed</code></pre>
-</div></div>
-<div class="paragraph"><p>and then look at the address statistics on the router:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdstat -a
-Router Addresses
- class addr phs distrib in-proc local remote cntnr in out thru to-proc from-proc
- ========================================================================================================
- mobile queue.first 1 balanced 0 0 0 0 0 0 0 0 0
- mobile queue.first 0 balanced 0 1 0 0 3 3 0 0 0</code></pre>
-</div></div>
-<div class="paragraph"><p>we see that <em>queue.first</em> appears twice in the list of addresses. The
-<code>phs</code>, or phase column shows that there are two phases for the
-address. Phase <em>0</em> is for routing message deliveries from producers to
-the tail of the queue (the <code>out</code> auto-link associated with the queue).
-Phase 1 is for routing deliveries from the head of the queue to
-subscribed consumers.</p></div>
-<div class="paragraph"><p>Note that three deliveries have been counted in the "in" and "out"
-columns for phase <em>0</em>. The "in" column represents the three messages
-that arrived from <code>simple_send.py</code> and the <code>out</code> column represents the three
-deliveries to the queue on the broker.</p></div>
-<div class="paragraph"><p>If we now use <code>simple_recv.py</code> to receive three messages from this address:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ python simple_recv.py -a 127.0.0.1:5672/queue.first -m3
-{u'sequence': int32(1)}
-{u'sequence': int32(2)}
-{u'sequence': int32(3)}</code></pre>
-</div></div>
-<div class="paragraph"><p>We receive the three queued messages. Looking at the addresses again, we
-see that phase 1 was used to deliver those messages from the queue to
-the consumer.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdstat -a
-Router Addresses
- class addr phs distrib in-proc local remote cntnr in out thru to-proc from-proc
- ========================================================================================================
- mobile queue.first 1 balanced 0 0 0 0 3 3 0 0 0
- mobile queue.first 0 balanced 0 1 0 0 3 3 0 0 0</code></pre>
-</div></div>
-<div class="paragraph"><p>Note that even in a multi-router network, and with multiple producers
-and consumers for <em>queue.first</em>, all deliveries will be routed through
-the queue on the connected broker.</p></div>
-</div>
-<div class="sect3">
-<h4 id="sharded-queue-example">3.5.2. Sharded Queue Example</h4>
-<div class="paragraph"><p>Here is an extension of the above example to illustrate how Qpid
-Dispatch Router can be used to create a distributed queue in which
-multiple brokers share the message-queueing load.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>connector {
- name: broker1
- role: route-container
- host: <hostname>
- port: <port>
- saslMechanisms: ANONYMOUS
-}
-
-connector {
- name: broker2
- role: route-container
- host: <hostname>
- port: <port>
- saslMechanisms: ANONYMOUS
-}
-
-address {
- prefix: queue
- waypoint: yes
-}
-
-autoLink {
- addr: queue.first
- dir: in
- connection: broker1
-}
-
-autoLink {
- addr: queue.first
- dir: out
- connection: broker1
-}
-
-autoLink {
- addr: queue.first
- dir: in
- connection: broker2
-}
-
-autoLink {
- addr: queue.first
- dir: out
- connection: broker2
-}</code></pre>
-</div></div>
-<div class="paragraph"><p>In the above configuration, there are two instances of <em>queue.first</em> on
-brokers 1 and 2. Message traffic from producers to address <em>queue.first</em>
-shall be balanced between the two instance and messages from the queues
-shall be balanced across the collection of subscribers to the same
-address.</p></div>
-</div>
-<div class="sect3">
-<h4 id="dynamically-adding-shards">3.5.3. Dynamically Adding Shards</h4>
-<div class="paragraph"><p>Since configurable entities in the router can also be accessed via the
-management protocol, we can remotely add a shard to the above example
-using <code>qdmanage</code>:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>qdmanage create --type org.apache.qpid.dispatch.connector host=<host> port=<port> name=broker3
-qdmanage create --type org.apache.qpid.dispatch.router.config.autoLink addr=queue.first dir=in connection=broker3
-qdmanage create --type org.apache.qpid.dispatch.router.config.autoLink addr=queue.first dir=out connection=broker3</code></pre>
-</div></div>
-</div>
-<div class="sect3">
-<h4 id="address-renaming">3.5.4. Using a Different External Address on an Auto-Link</h4>
-<div class="paragraph"><p>Sometimes, greater flexibility is needed with regard to the addressing
-of a waypoint. For example, the above sharded-queue example requires
-that the two instances of the queue have the same name/address.
-Auto-links can be configured with an independent <code>externalAddr</code> that
-allows the waypoint to have a different address than that which is
-used by the senders and receivers.</p></div>
-<div class="paragraph"><p>Here’s an example:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>connector {
- name: broker
- role: route-container
- host: <hostname>
- port: <port>
- saslMechanisms: ANONYMOUS
-}
-
-address {
- prefix: queue
- waypoint: yes
-}
-
-autoLink {
- addr: queue.first
- externalAddr: broker_queue
- dir: in
- connection: broker
-}
-
-autoLink {
- addr: queue.first
- externalAddr: broker_queue
- dir: out
- connection: broker
-}</code></pre>
-</div></div>
-<div class="paragraph"><p>In the above configuration, the router network provides waypoint
-routing for the address <em>queue.first</em>, where senders and receivers use
-that address to send and receive messages. However, the queue on the
-broker is named "broker_queue". The address is translated through the
-auto-link that is established to the broker.</p></div>
-<div class="paragraph"><p>In this example, the endpoints (senders and receivers) are unaware of
-the <em>broker_queue</em> address and simply interact with <em>queue.first</em>.
-Likewise, the broker is unaware of the <em>queue.first</em> address and
-behaves as though a sender and a receiver is attached each using the
-address <em>broker_queue</em>.</p></div>
-<div class="paragraph"><p>The <code>qdstat</code> tool shows the external address for auto-links.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdstat --autolinks
-AutoLinks
- addr dir phs extAddr link status lastErr
- ===========================================================
- queue.first in 1 broker_queue 6 active
- queue.first out 0 broker_queue 7 active</code></pre>
-</div></div>
-</div>
-</div>
-<div class="sect2">
-<h3 id="policy">3.6. Policy</h3>
-<div class="paragraph"><p>The Policy module is an optional authorization mechanism enforcing
-user connection restrictions and AMQP resource access control.</p></div>
-<div class="paragraph"><p>Policy is assigned when a connection is created. The connection
-properties <strong>AMQP virtual host</strong>, <strong>authenticated user name</strong>, and <strong>connection
-remote host</strong> are passed to the policy engine for a connection
-allow/deny decision. If the connection is allowed then the user is
-assigned to a group that names a set of AMQP resource limits that are
-enforced for the lifetime of the connection.</p></div>
-<div class="admonitionblock">
-<table><tr>
-<td class="icon">
-<div class="title">Note</div>
-</td>
-<td class="content">
-<div class="paragraph"><p>Policy limits are applied only to incoming user network connections.
-Policy limits are not applied to interrouter connections nor are they
-applied to router connections outbound to waypoints.</p></div>
-</td>
-</tr></table>
-</div>
-<div class="sect3">
-<h4 id="_definitions">3.6.1. Definitions</h4>
-<div class="sect4">
-<h5 id="_vhost">vhost</h5>
-<div class="paragraph"><p>A <em>vhost</em> is typically the name of the host to which the client AMQP
-connection is directed. For example, suppose a client application opens
-connection URL:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>amqp://bigbroker.example.com:5672/favorite_subject</code></pre>
-</div></div>
-<div class="paragraph"><p>The client will signal virtual host name <em>bigbroker.example.com</em> to
-the router during AMQP connection startup. Router Policy intercepts
-the virtual host <em>bigbroker.example.com</em> and applies a vhost policy
-with that name to the connection.</p></div>
-</div>
-</div>
-<div class="sect3">
-<h4 id="_policy_features">3.6.2. Policy Features</h4>
-<div class="sect4">
-<h5 id="_total_connection_limit">Total Connection Limit</h5>
-<div class="paragraph"><p>A router may be configured with a total connection limit. This limit
-controls the maximum number of simultaneous incoming user connections
-that are allowed at any time. It protects the router from file
-descriptor resource exhaustion in the face of many incoming client
-connections. This limit is specified and enforced independently of
-any other Policy settings.</p></div>
-</div>
-<div class="sect4">
-<h5 id="_vhost_policy">Vhost Policy</h5>
-<div class="paragraph"><p>Vhost policy defines users and assigns them to user groups. Each
-user group defines the remote hosts from which the members may connect
-to the router network, and what resources in the router network the
-group members are allowed to access.</p></div>
-<div class="paragraph"><p>Vhost policy also defines connection count limits to control the
-number of users that may be simultaneously connected to the vhost.</p></div>
-<div class="admonitionblock">
-<table><tr>
-<td class="icon">
-<div class="title">Note</div>
-</td>
-<td class="content">
-<div class="paragraph"><p>A vhost user may be assigned to one user group only.</p></div>
-</td>
-</tr></table>
-</div>
-</div>
-<div class="sect4">
-<h5 id="_default_vhost">Default Vhost</h5>
-<div class="paragraph"><p>A default vhost may be defined. The default vhost policy is used for
-connections whose vhost is otherwise not defined in the policy database.</p></div>
-<div class="paragraph"><p><a href="#example2">Example 2</a> illustrates how the default vhost feature can
-be used to apply a single vhost policy set of restrictions to any
-number of vhost connections.</p></div>
-</div>
-</div>
-<div class="sect3">
-<h4 id="_policy_schema">3.6.3. Policy Schema</h4>
-<div class="paragraph"><p>Policy configuration is specified in two schema objects.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>policy = {
- <global settings>
-}
-
-vhost = {
- id: vhost-name
- <connection limits>
- groups: {
- group-name: {
- <user group settings>
- }
- }
-}</code></pre>
-</div></div>
-<div class="paragraph"><p>The <em>policy</em> object is a singleton. Multiple <em>vhost</em> objects may be
-created as needed.</p></div>
-<div class="sect4">
-<h5 id="_global_policy">Global Policy</h5>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="35%" />
-<col width="15%" />
-<col width="50%" />
-<thead>
-<tr>
-<th align="left" valign="top"> attribute </th>
-<th align="left" valign="top"> default </th>
-<th align="left" valign="top"> description</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">maxConnections</p></td>
-<td align="left" valign="top"><p class="table">65535</p></td>
-<td align="left" valign="top"><p class="table">Global maximum number of concurrent client connections allowed. This limit is always enforced even if no other policy settings have been defined. This limit is applied to all incoming connections regardless of remote host, authenticated user, or targeted vhost.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">enableVhostPolicy</p></td>
-<td align="left" valign="top"><p class="table">false</p></td>
-<td align="left" valign="top"><p class="table">Enable vhost policy connection denial, and resource limit enforcement.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">policyDir</p></td>
-<td align="left" valign="top"><p class="table">""</p></td>
-<td align="left" valign="top"><p class="table">Absolute path to a directory that holds vhost definition .json files. All vhost definitions in all .json files in this directory are processed.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">defaultVhost</p></td>
-<td align="left" valign="top"><p class="table">"$default"</p></td>
-<td align="left" valign="top"><p class="table">Vhost rule set name to use for connections with a vhost that is otherwise not defined. Default vhost processing may be disabled either by erasing the definition of <em>defaultVhost</em> or by not defining a <em>vhost</em> object named <em>$default</em>.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-<div class="sect4">
-<h5 id="_vhost_policy_2">Vhost Policy</h5>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="35%" />
-<col width="15%" />
-<col width="50%" />
-<thead>
-<tr>
-<th align="left" valign="top"> attribute </th>
-<th align="left" valign="top"> default </th>
-<th align="left" valign="top"> description</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">id</p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-<td align="left" valign="top"><p class="table">Vhost name must be unique.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxConnections</p></td>
-<td align="left" valign="top"><p class="table">65535</p></td>
-<td align="left" valign="top"><p class="table">Maximum number of concurrent client connections allowed.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxConnectionsPerUser</p></td>
-<td align="left" valign="top"><p class="table">65535</p></td>
-<td align="left" valign="top"><p class="table">Maximum number of concurrent client connections allowed for any user.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxConnectionsPerRemoteHost</p></td>
-<td align="left" valign="top"><p class="table">65535</p></td>
-<td align="left" valign="top"><p class="table">Maximum number of concurrent client connections allowed for any remote host.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">allowUnknownUser</p></td>
-<td align="left" valign="top"><p class="table">false</p></td>
-<td align="left" valign="top"><p class="table">Allow unknown users who are not members of a defined user group. Unknown users are assigned to the <em>$default</em> user group and receive <em>$default</em> settings.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">groups</p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-<td align="left" valign="top"><p class="table">A map where each key is a user group name and the value is a Vhost User Group Settings map.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-<div class="sect4">
-<h5 id="_vhost_user_group_settings_map">Vhost User Group Settings Map</h5>
-<div class="paragraph"><p>This object is the data value contained in entries in the policy/groups map.</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="35%" />
-<col width="15%" />
-<col width="50%" />
-<thead>
-<tr>
-<th align="left" valign="top"> Section/Attribute </th>
-<th align="left" valign="top"> default </th>
-<th align="left" valign="top"> description</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table"><strong>Group Membership</strong></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">users</p></td>
-<td align="left" valign="top"><p class="table">""</p></td>
-<td align="left" valign="top"><p class="table">Comma separated list of authenticated users in this group.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><strong>Connection Restrictions</strong></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">remoteHosts</p></td>
-<td align="left" valign="top"><p class="table">""</p></td>
-<td align="left" valign="top"><p class="table">List of remote hosts from which the users may connect. List values may be host names, numeric IP addresses, numeric IP address ranges, or the wildcard <em>*</em>. An empty list denies all access.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><strong>AMQP Connection Open Limits</strong></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxFrameSize</p></td>
-<td align="left" valign="top"><p class="table">2^31-1</p></td>
-<td align="left" valign="top"><p class="table">Largest frame that may be sent on this connection. (AMQP Open, max-frame-size)</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxSessions</p></td>
-<td align="left" valign="top"><p class="table">65535</p></td>
-<td align="left" valign="top"><p class="table">Maximum number of sessions that may be created on this connection. (AMQP Open, channel-max)</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><strong>AMQP Session Begin Limits</strong></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxSessionWindow</p></td>
-<td align="left" valign="top"><p class="table">2^31-1</p></td>
-<td align="left" valign="top"><p class="table">Incoming capacity for new sessions. (AMQP Begin, incoming-window)</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><strong>AMQP Link Attach</strong></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxMessageSize</p></td>
-<td align="left" valign="top"><p class="table">0</p></td>
-<td align="left" valign="top"><p class="table">Largest message size supported by links created on this connection. If this field is zero there is no maximum size imposed by the link endpoint. (AMQP Attach, max-message-size)</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxSenders</p></td>
-<td align="left" valign="top"><p class="table">2^31-1</p></td>
-<td align="left" valign="top"><p class="table">Maximum number of sending links that may be created on this connection.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxReceivers</p></td>
-<td align="left" valign="top"><p class="table">2^31-1</p></td>
-<td align="left" valign="top"><p class="table">Maximum number of receiving links that may be created on this connection.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">allowDynamicSource</p></td>
-<td align="left" valign="top"><p class="table">false</p></td>
-<td align="left" valign="top"><p class="table">This connection is allowed to create receiving links using the Dynamic Link Source feature.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">allowAnonymousSender</p></td>
-<td align="left" valign="top"><p class="table">false</p></td>
-<td align="left" valign="top"><p class="table">This connection is allowed to create sending links using the Anonymous Sender feature.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">allowUserIdProxy</p></td>
-<td align="left" valign="top"><p class="table">false</p></td>
-<td align="left" valign="top"><p class="table">This connection is allowed to send messages with a user_id property that differs from the connection’s authenticated user id.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">sources</p></td>
-<td align="left" valign="top"><p class="table">""</p></td>
-<td align="left" valign="top"><p class="table">List of Source addresses allowed when creating receiving links. This list may be expressed as a CSV string or as a list of strings. An empty list denies all access.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">targets</p></td>
-<td align="left" valign="top"><p class="table">""</p></td>
-<td align="left" valign="top"><p class="table">List of Target addresses allowed when creating sending links. This list may be expressed as a CSV string or as a list of strings. An empty list denies all access.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-</div>
-<div class="sect3">
-<h4 id="_policy_wildcard_and_user_name_substitution">3.6.4. Policy Wildcard and User Name Substitution</h4>
-<div class="paragraph"><p>Policy provides several conventions to make writing rules easier.</p></div>
-<div class="sect4">
-<h5 id="_remote_host_wildcard">Remote Host Wildcard</h5>
-<div class="paragraph"><p>Remote host rules may consist of a single asterisk character to
-specify all hosts.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code> remoteHosts: *</code></pre>
-</div></div>
-<div class="paragraph"><p>The asterisk must stand alone and cannot be appended to a host name
-or to an IP address fragment.</p></div>
-</div>
-<div class="sect4">
-<h5 id="_amqp_source_and_target_wildcard_and_name_substitution">AMQP Source and Target Wildcard and Name Substitution</h5>
-<div class="paragraph"><p>The rule definitions for <code>sources</code> and <code>targets</code> may include the username
-substitution token</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code> {user}</code></pre>
-</div></div>
-<div class="paragraph"><p>or a trailing asterisk.</p></div>
-<div class="paragraph"><p>The username substitution token is replaced with the authenticated user name for
-the connection. Using this token, an administrator may allow access to
-some resources specific to each user without having to name each user
-individually. This token is substituted once for the leftmost
-occurrence in the link name.</p></div>
-<div class="paragraph"><p>The asterisk is recognized only if it is the last character in the
-link name.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code> sources: tmp_{user}, temp*, {user}-home-*</code></pre>
-</div></div>
-</div>
-</div>
-<div class="sect3">
-<h4 id="_composing_policies">3.6.5. Composing Policies</h4>
-<div class="paragraph"><p>This section shows policy examples designed to illustrate some common use cases.</p></div>
-<div class="sect4">
-<h5 id="_example_1_user_policy_disabled">Example 1. User Policy Disabled</h5>
-<div class="paragraph"><p>Policy is disabled when no policy configuation objects are defined.
-Any number of connections are allowed and all users have
-access to all AMQP resources in the network.</p></div>
-</div>
-<div class="sect4">
-<h5 id="example2">Example 2. All Users Have Simple Connection Limits</h5>
-<div class="paragraph"><p>This example shows how to keep users from overwhelming the router with
-connections. Any user can create up to ten connections and the router
-will limit the aggregated user connection count to 100 connections
-total. No other restrictions apply.</p></div>
-<div class="paragraph"><p>This example also shows how to use a default vhost policy effectively.
-Only one vhost policy is defined and all user connections regardless
-of the requested vhost use that policy.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>policy {
- maxConnections: 100 <b><1></b>
-}
-
-vhost {
- name: $default <b><2></b>
- maxConnectionsPerUser: 10 <b><3></b>
- allowUnknownUser: true <b><4></b>
- groups: {
- $default: {
- remoteHosts: * <b><5></b>
- sources: * <b><6></b>
- targets: * <b><6></b>
- }
- }
-}</code></pre>
-</div></div>
-<div class="colist arabic"><ol>
-<li>
-<p>
-The global maxConnections limit of 100 is enforced.
-</p>
-</li>
-<li>
-<p>
-No normal vhost names are defined; user is assigned to default vhost <em>$default</em>.
-</p>
-</li>
-<li>
-<p>
-The vhost maxConnectionsPerUser limit of 10 is enforced.
-</p>
-</li>
-<li>
-<p>
-No groups are defined to have any users but allowUnknownUser is true so all users are assigned to group $default.
-</p>
-</li>
-<li>
-<p>
-The user is allowed to connect from any remote host.
-</p>
-</li>
-<li>
-<p>
-The user is allowed to connect to any source or target in the AMQP network. Router system-wide values are used for the other AMQP settings that are unspecified in the vhost rules.
-</p>
-</li>
-</ol></div>
-</div>
-<div class="sect4">
-<h5 id="_example_3_admins_must_connect_from_localhost">Example 3. Admins Must Connect From Localhost</h5>
-<div class="paragraph"><p>This example shows how an admin group may be created and restricted
-to accessing a vhost only from localhost. The admin users are allowed
-to connect to any AMQP resources while normal users are restricted.</p></div>
-<div class="paragraph"><p>In this example a user connects to vhost <em>example.com</em>.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>vhost {
- name: example.com <b><1></b>
- allowUnknownUser: true <b><3></b>
- groups: {
- admin: {
- users: alice, bob <b><2></b>
- remoteHosts: 127.0.0.1, ::1 <b><4></b>
- sources: * <b><5></b>
- targets: * <b><5></b>
- },
- $default: {
- remoteHosts: * <b><6></b>
- sources: news*, sports*, chat* <b><7></b>
- targets: chat* <b><7></b>
- }
- }
-}</code></pre>
-</div></div>
-<div class="colist arabic"><ol>
-<li>
-<p>
-A connection to vhost <em>example.com</em> locates this vhost rule set.
-</p>
-</li>
-<li>
-<p>
-If one of users <em>alice</em> or <em>bob</em> is connecting then she or he is assigned to the <em>admin</em> user group.
-</p>
-</li>
-<li>
-<p>
-Any other user is not defined by a user group. However, since the <em>allowUnknownUser</em> setting is true then this user is assigned to the <em>$default</em> user group.
-</p>
-</li>
-<li>
-<p>
-Users in the <em>admin</em> user group must connect from localhost. Connections for an <em>admin</em> user from other hosts on the network are denied.
-</p>
-</li>
-<li>
-<p>
-Users in the <em>admin</em> user group are allowed to access any resource offered by the vhost service.
-</p>
-</li>
-<li>
-<p>
-Other users are allowed to connect from any host.
-</p>
-</li>
-<li>
-<p>
-Other users have source and target name lists that restrict the resources they are allowed to access.
-</p>
-</li>
-</ol></div>
-</div>
-<div class="sect4">
-<h5 id="_example_4_limiting_possible_memory_consumption">Example 4. Limiting Possible Memory Consumption</h5>
-<div class="paragraph"><p>Policy provides a mechanism to control how much system buffer memory a
-user connection can potentially consume. The formula for computing
-buffer memory consumption for each session is</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code> potential buffer usage = maxFrameSize * maxSessionWindow</code></pre>
-</div></div>
-<div class="paragraph"><p>By adjusting <em>maxFrameSize</em>, <em>maxSessions</em>, and <em>maxSessionWindow</em> an
-administrator can prevent a user from consuming too much memory by
-buffering messages in flight.</p></div>
-<div class="admonitionblock">
-<table><tr>
-<td class="icon">
-<div class="title">Note</div>
-</td>
-<td class="content">
-<div class="paragraph"><p>The settings passed into the AMQP protocol connection and session
-negotiations. Normal AMQP session flow control limits buffer
-consumption in due course with no processing cycles required by the
-router.</p></div>
-</td>
-</tr></table>
-</div>
-<div class="paragraph"><p>In this example normal users, the traders, are given smaller buffer
-allocations while high-capacity, automated data feeds are given a
-higher buffer allocation. This example skips the details of se
<TRUNCATED>
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/book/console1.png
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/book/console1.png b/content/releases/qpid-dispatch-master/book/console1.png
deleted file mode 100755
index f131884..0000000
Binary files a/content/releases/qpid-dispatch-master/book/console1.png and /dev/null differ
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org
[06/13] qpid-site git commit: QPID-8015: Prepare the dispatch release
scripts for the new user guide
Posted by jr...@apache.org.
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/book.html.in
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/book.html.in b/input/releases/qpid-dispatch-master/book.html.in
deleted file mode 100644
index 3bb4a74..0000000
--- a/input/releases/qpid-dispatch-master/book.html.in
+++ /dev/null
@@ -1,4115 +0,0 @@
-<div class="sect1">
-<h2 id="introduction">1. Introduction</h2>
-<div class="sectionbody">
-<div class="sect2">
-<h3 id="overview">1.1. Overview</h3>
-<div class="paragraph"><p>The Dispatch router is an AMQP 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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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>
-<div class="sect2">
-<h3 id="benefits">1.2. Benefits</h3>
-<div class="paragraph"><p>Simplifies connectivity</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-An endpoint can do all of its messaging through a single transport
-connection
-</p>
-</li>
-<li>
-<p>
-Avoid opening holes in firewalls for incoming connections
-</p>
-</li>
-</ul></div>
-<div class="paragraph"><p>Provides messaging connectivity where there is no TCP/IP connectivity</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-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).
-</p>
-</li>
-</ul></div>
-<div class="paragraph"><p>Simplifies reliability</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-Reliability and availability are provided using redundant topology,
-not server clustering
-</p>
-</li>
-<li>
-<p>
-Reliable end-to-end messaging without persistent stores
-</p>
-</li>
-<li>
-<p>
-Use a message broker only when you need store-and-forward semantics
-</p>
-</li>
-</ul></div>
-</div>
-<div class="sect2">
-<h3 id="features">1.3. Features</h3>
-<div class="ulist"><ul>
-<li>
-<p>
-Can be deployed stand-alone or in a network of routers
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-Supports arbitrary network topology - no restrictions on redundancy
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-Automatic route computation - adjusts quickly to changes in topology
-</p>
-</li>
-</ul></div>
-</li>
-</ul></div>
-</li>
-<li>
-<p>
-Provides remote access to brokers or other AMQP servers
-</p>
-</li>
-<li>
-<p>
-Security
-</p>
-</li>
-</ul></div>
-</div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="using-qpid-dispatch">2. Using Qpid Dispatch</h2>
-<div class="sectionbody">
-<div class="sect2">
-<h3 id="configuration">2.1. Configuration</h3>
-<div class="paragraph"><p>The default configuration file is installed in
-<em>/usr/local/etc/qpid-dispatch/qdrouterd.conf</em>. 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></div>
-<div class="paragraph"><p>To run the router, invoke the executable: <code>qdrouterd [-c my-config-file]</code></p></div>
-<div class="paragraph"><p>For more details of the configuration file see the <em>qdrouterd.conf(5)</em> man
-page.</p></div>
-</div>
-<div class="sect2">
-<h3 id="tools">2.2. Tools</h3>
-<div class="sect3">
-<h4 id="qdstat">2.2.1. qdstat</h4>
-<div class="paragraph"><p><em>qdstat</em> is a command line tool that lets you view the status of a
-Dispatch Router. The following options are useful for seeing what the
-router is doing:</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="17%" />
-<col width="83%" />
-<thead>
-<tr>
-<th align="left" valign="top"><em>Option</em> </th>
-<th align="left" valign="top"><em>Description</em></th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">-l</p></td>
-<td align="left" valign="top"><p class="table">Print a list of AMQP links attached to the router. Links are
-unidirectional. Outgoing links are usually associated with a
-subscription address. The tool distinguishes between <em>endpoint</em> links
-and <em>router</em> links. Endpoint links are attached to clients using the
-router. Router links are attached to other routers in a network of
-routbers.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">-a</p></td>
-<td align="left" valign="top"><p class="table">Print a list of addresses known to the router.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">-n</p></td>
-<td align="left" valign="top"><p class="table">Print a list of known routers in the network.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">-c</p></td>
-<td align="left" valign="top"><p class="table">Print a list of connections to the router.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">--autolinks</p></td>
-<td align="left" valign="top"><p class="table">Print a list of configured auto-links.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">--linkroutes</p></td>
-<td align="left" valign="top"><p class="table">Print a list of configures link-routes.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-<div class="paragraph"><p>For complete details see the <em>qdstat(8)</em> man page and the output of
-<code>qdstat --help</code>.</p></div>
-</div>
-<div class="sect3">
-<h4 id="qdmanage">2.2.2. qdmanage</h4>
-<div class="paragraph"><p><em>qdmanage</em> is a general-purpose AMQP management client that allows you
-to not only view but modify the configuration of a running dispatch
-router.</p></div>
-<div class="paragraph"><p>For example you can query all the connection entities in the router:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdmanage query --type connection</code></pre>
-</div></div>
-<div class="paragraph"><p>To enable logging debug and higher level messages by default:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdmanage update log/DEFAULT enable=debug+</code></pre>
-</div></div>
-<div class="paragraph"><p>In fact, everything that can be configured in the configuration file can
-also be created in a running router via management. For example to
-create a new listener in a running router:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdmanage create type=listener port=5555</code></pre>
-</div></div>
-<div class="paragraph"><p>Now you can connect to port 5555, for exampple:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdmanage query -b localhost:5555 --type listener</code></pre>
-</div></div>
-<div class="paragraph"><p>For complete details see the <em>qdmanage(8)</em> man page and the output of
-<code>qdmanage --help</code>. Also for details of what can be configured see the
-<em>qdrouterd.conf(5)</em> man page.</p></div>
-</div>
-</div>
-<div class="sect2">
-<h3 id="basic-usage-and-examples">2.3. Basic Usage and Examples</h3>
-<div class="sect3">
-<h4 id="standalone-and-interior-modes">2.3.1. Standalone and Interior Modes</h4>
-<div class="paragraph"><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></div>
-<div class="paragraph"><p>If your router is running in stand-alone mode, <em>qdstat -a</em> will look
-like the following:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ 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</code></pre>
-</div></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ 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</code></pre>
-</div></div>
-</div>
-<div class="sect3">
-<h4 id="mobile-subscribers">2.3.2. Mobile Subscribers</h4>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ python ./simple_recv.py -a 127.0.0.1/my-address</code></pre>
-</div></div>
-<div class="paragraph"><p>This command creates a receiving link subscribed to the specified
-address. To verify the subscription:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ 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</code></pre>
-</div></div>
-<div class="paragraph"><p>You can then, in a separate command window, run a sender to produce
-messages to that address:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ python ./simple_send.py -a 127.0.0.1/my-address</code></pre>
-</div></div>
-</div>
-<div class="sect3">
-<h4 id="dynamic-reply-to">2.3.3. Dynamic Reply-To</h4>
-<div class="paragraph"><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>
-<div class="listingblock">
-<div class="content">
-<pre><code>#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();
-}</code></pre>
-</div></div>
-<div class="paragraph"><p>The equivalent program written in Python against the Proton Messenger
-API:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>from proton import Messenger, Message
-
-def main():
- host = "0.0.0.0:5672"
-
- messenger = Messenger()
- messenger.start()
- messenger.route("amqp:/*", "amqp://%s/$1" % host)
- reply_subscription = messenger.subscribe("amqp:/#")
- reply_address = reply_subscription.address
-
- request = Message()
- response = Message()
-
- request.address = "amqp:/_local/$management"
- request.reply_to = reply_address
- request.properties = {u'operation' : u'DISCOVER-MGMT-NODES',
- u'type' : u'org.amqp.management',
- u'name' : u'self'}
-
- messenger.put(request)
- messenger.send()
- messenger.recv()
- messenger.get(response)
-
- print "Response: %r" % response.body
-
- messenger.stop()
-
-main()</code></pre>
-</div></div>
-</div>
-</div>
-<div class="sect2">
-<h3 id="link-routing">2.4. Link Routing</h3>
-<div class="paragraph"><p>This feature was introduced in Qpid Dispatch 0.4. This feature was
-significantly updated in Qpid Dispatch 0.6.</p></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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>
-<div class="listingblock">
-<div class="content">
-<pre><code> Public Network
- +-----------------+
- | +-----+ |
- | B1 | Rp | |
- | +/--\-+ |
- | / \ |
- | / \ |
- +----/--------\---+
- / \
- / \
- / \
- Private Net A / \ Private Net B
- +--------------/--+ +---\-------------+
- | +---/-+ | | +--\--+ |
- | B2 | Ra | | | | Rb | C1 |
- | +-----+ | | +-----+ |
- | | | |
- | | | |
- +-----------------+ +-----------------+</code></pre>
-</div></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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>
-<div class="sect3">
-<h4 id="link-routing-configuration">2.4.1. Configuration</h4>
-<div class="paragraph"><p>Starting with the configured topology shown above, how is link-routing
-configured to support the example described above?</p></div>
-<div class="paragraph"><p>First, router Ra needs to be told how to make a connection to the broker
-B2:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>connector {
- name: broker
- role: route-container
- host: <B2-url>
- port: <B2-port>
- saslMechanisms: ANONYMOUS
-}</code></pre>
-</div></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><p>Now, the router must be configured to route certain addresses to B2:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>linkRoute {
- prefix: b2
- dir: in
- connection: broker
-}
-
-linkRoute {
- prefix: b2
- dir: out
- connection: broker
-}</code></pre>
-</div></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><p>Examples of addresses that "begin with <em>b2</em>" include:</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-b2
-</p>
-</li>
-<li>
-<p>
-b2.queues
-</p>
-</li>
-<li>
-<p>
-b2.queues.app1
-</p>
-</li>
-</ul></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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></div>
-<div class="paragraph"><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>
-</div>
-<div class="sect2">
-<h3 id="indirect-waypoints-and-auto-links">2.5. Indirect Waypoints and Auto-Links</h3>
-<div class="paragraph"><p>This feature was introduced in Qpid Dispatch 0.6. It is a significant
-improvement on an earlier somewhat experimental feature called
-Waypoints.</p></div>
-<div class="paragraph"><p>Auto-link is a feature of Qpid Dispatch Router that enables a router to
-actively attach a link to a node on an external AMQP container. The
-obvious application for this feature is to route messages through a
-queue on a broker, but other applications are possible as well.</p></div>
-<div class="paragraph"><p>An auto-link manages the lifecycle of one AMQP link. If messages are to
-be routed to and from a queue on a broker, then two auto-links are
-needed: one for sending messages to the queue and another for receiving
-messages from the queue. The container to which an auto-link attempts to
-attach may be identified in one of two ways:</p></div>
-<div class="quoteblock">
-<div class="content">
-<div class="ulist"><ul>
-<li>
-<p>
-The name of the connector/listener that resulted in the connection of
-the container, or
-</p>
-</li>
-<li>
-<p>
-The AMQP container-id of the remote container.
-</p>
-</li>
-</ul></div>
-</div>
-<div class="attribution">
-</div></div>
-<div class="sect3">
-<h4 id="queue-waypoint-example">2.5.1. Queue Waypoint Example</h4>
-<div class="paragraph"><p>Here is an example configuration for routing messages deliveries through
-a pair of queues on a broker:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>connector {
- name: broker
- role: route-container
- host: <hostname>
- port: <port>
- saslMechanisms: ANONYMOUS
-}
-
-address {
- prefix: queue
- waypoint: yes
-}
-
-autoLink {
- addr: queue.first
- dir: in
- connection: broker
-}
-
-autoLink {
- addr: queue.first
- dir: out
- connection: broker
-}
-
-autoLink {
- addr: queue.second
- dir: in
- connection: broker
-}
-
-autoLink {
- addr: queue.second
- dir: out
- connection: broker
-}</code></pre>
-</div></div>
-<div class="paragraph"><p>The <code>address</code> entity identifies a namespace <em>queue.</em> that will be used
-for routing messages through queues via autolinks. The four <code>autoLink</code> entities
-identify the head and tail of two queues on the broker that will be connected
-via auto-links.</p></div>
-<div class="paragraph"><p>If there is no broker connected, the auto-links shall remain
-<em>inactive</em>. This can be observed by using the <code>qdstat</code> tool:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdstat --autolinks
-AutoLinks
- addr dir phase link status lastErr
- ===================================================
- queue.first in 1 inactive
- queue.first out 0 inactive
- queue.second in 1 inactive
- queue.second out 0 inactive</code></pre>
-</div></div>
-<div class="paragraph"><p>If a broker comes online with a queue called <em>queue.first</em>, the
-auto-links will attempt to activate:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdstat --autolinks
-AutoLinks
- addr dir phase link status lastErr
- ======================================================================
- queue.first in 1 6 active
- queue.first out 0 7 active
- queue.second in 1 failed Node not found: queue.second
- queue.second out 0 failed Node not found: queue.second</code></pre>
-</div></div>
-<div class="paragraph"><p>Note that two of the auto-links are in <em>failed</em> state because the queue
-does not exist on the broker.</p></div>
-<div class="paragraph"><p>If we now use the Qpid Proton example application <code>simple_send.py</code> to send
-three messages to <em>queue.first</em> via the router:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ python simple_send.py -a 127.0.0.1/queue.first -m3
-all messages confirmed</code></pre>
-</div></div>
-<div class="paragraph"><p>and then look at the address statistics on the router:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdstat -a
-Router Addresses
- class addr phs distrib in-proc local remote cntnr in out thru to-proc from-proc
- ========================================================================================================
- mobile queue.first 1 balanced 0 0 0 0 0 0 0 0 0
- mobile queue.first 0 balanced 0 1 0 0 3 3 0 0 0</code></pre>
-</div></div>
-<div class="paragraph"><p>we see that <em>queue.first</em> appears twice in the list of addresses. The
-<code>phs</code>, or phase column shows that there are two phases for the
-address. Phase <em>0</em> is for routing message deliveries from producers to
-the tail of the queue (the <code>out</code> auto-link associated with the queue).
-Phase 1 is for routing deliveries from the head of the queue to
-subscribed consumers.</p></div>
-<div class="paragraph"><p>Note that three deliveries have been counted in the "in" and "out"
-columns for phase <em>0</em>. The "in" column represents the three messages
-that arrived from <code>simple_send.py</code> and the <code>out</code> column represents the three
-deliveries to the queue on the broker.</p></div>
-<div class="paragraph"><p>If we now use <code>simple_recv.py</code> to receive three messages from this address:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ python simple_recv.py -a 127.0.0.1:5672/queue.first -m3
-{u'sequence': int32(1)}
-{u'sequence': int32(2)}
-{u'sequence': int32(3)}</code></pre>
-</div></div>
-<div class="paragraph"><p>We receive the three queued messages. Looking at the addresses again, we
-see that phase 1 was used to deliver those messages from the queue to
-the consumer.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>$ qdstat -a
-Router Addresses
- class addr phs distrib in-proc local remote cntnr in out thru to-proc from-proc
- ========================================================================================================
- mobile queue.first 1 balanced 0 0 0 0 3 3 0 0 0
- mobile queue.first 0 balanced 0 1 0 0 3 3 0 0 0</code></pre>
-</div></div>
-<div class="paragraph"><p>Note that even in a multi-router network, and with multiple producers
-and consumers for <em>queue.first</em>, all deliveries will be routed through
-the queue on the connected broker.</p></div>
-</div>
-<div class="sect3">
-<h4 id="sharded-queue-example">2.5.2. Sharded Queue Example</h4>
-<div class="paragraph"><p>Here is an extension of the above example to illustrate how Qpid
-Dispatch Router can be used to create a distributed queue in which
-multiple brokers share the message-queueing load.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>connector {
- name: broker1
- role: route-container
- host: <hostname>
- port: <port>
- saslMechanisms: ANONYMOUS
-}
-
-connector {
- name: broker2
- role: route-container
- host: <hostname>
- port: <port>
- saslMechanisms: ANONYMOUS
-}
-
-address {
- prefix: queue
- waypoint: yes
-}
-
-autoLink {
- addr: queue.first
- dir: in
- connection: broker1
-}
-
-autoLink {
- addr: queue.first
- dir: out
- connection: broker1
-}
-
-autoLink {
- addr: queue.first
- dir: in
- connection: broker2
-}
-
-autoLink {
- addr: queue.first
- dir: out
- connection: broker2
-}</code></pre>
-</div></div>
-<div class="paragraph"><p>In the above configuration, there are two instances of <em>queue.first</em> on
-brokers 1 and 2. Message traffic from producers to address <em>queue.first</em>
-shall be balanced between the two instance and messages from the queues
-shall be balanced across the collection of subscribers to the same
-address.</p></div>
-</div>
-<div class="sect3">
-<h4 id="dynamically-adding-shards">2.5.3. Dynamically Adding Shards</h4>
-<div class="paragraph"><p>Since configurable entities in the router can also be accessed via the
-management protocol, we can remotely add a shard to the above example
-using <code>qdmanage</code>:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>qdmanage create --type org.apache.qpid.dispatch.connector host=<host> port=<port> name=broker3
-qdmanage create --type org.apache.qpid.dispatch.router.config.autoLink addr=queue.first dir=in connection=broker3
-qdmanage create --type org.apache.qpid.dispatch.router.config.autoLink addr=queue.first dir=out connection=broker3</code></pre>
-</div></div>
-</div>
-</div>
-<div class="sect2">
-<h3 id="policy">2.6. Policy</h3>
-<div class="paragraph"><p>The Policy module is an optional authorization mechanism enforcing
-user connection restrictions and AMQP resource access control.</p></div>
-<div class="paragraph"><p>Policy is assigned when a connection is created. The connection
-properties <strong>AMQP virtual host</strong>, <strong>authenticated user name</strong>, and <strong>connection
-remote host</strong> are passed to the policy engine for a connection
-allow/deny decision. If the connection is allowed then the user is
-assigned to a group that names a set of AMQP resource limits that are
-enforced for the lifetime of the connection.</p></div>
-<div class="admonitionblock">
-<table><tr>
-<td class="icon">
-<div class="title">Note</div>
-</td>
-<td class="content">
-<div class="paragraph"><p>Policy limits are applied only to incoming user network connections.
-Policy limits are not applied to interrouter connections nor are they
-applied to router connections outbound to waypoints.</p></div>
-</td>
-</tr></table>
-</div>
-<div class="sect3">
-<h4 id="_definitions">2.6.1. Definitions</h4>
-<div class="sect4">
-<h5 id="_vhost">vhost</h5>
-<div class="paragraph"><p>A <em>vhost</em> is typically the name of the host to which the client AMQP
-connection is directed. For example, suppose a client application opens
-connection URL:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>amqp://bigbroker.example.com:5672/favorite_subject</code></pre>
-</div></div>
-<div class="paragraph"><p>The client will signal virtual host name <em>bigbroker.example.com</em> to
-the router during AMQP connection startup. Router Policy intercepts
-the virtual host <em>bigbroker.example.com</em> and applies a vhost policy
-with that name to the connection.</p></div>
-</div>
-</div>
-<div class="sect3">
-<h4 id="_policy_features">2.6.2. Policy Features</h4>
-<div class="sect4">
-<h5 id="_total_connection_limit">Total Connection Limit</h5>
-<div class="paragraph"><p>A router may be configured with a total connection limit. This limit
-controls the maximum number of simultaneous incoming user connections
-that are allowed at any time. It protects the router from file
-descriptor resource exhaustion in the face of many incoming client
-connections. This limit is specified and enforced independently of
-any other Policy settings.</p></div>
-</div>
-<div class="sect4">
-<h5 id="_vhost_policy">Vhost Policy</h5>
-<div class="paragraph"><p>Vhost policy defines users and assigns them to user groups. Each
-user group defines the remote hosts from which the members may connect
-to the router network, and what resources in the router network the
-group members are allowed to access.</p></div>
-<div class="paragraph"><p>Vhost policy also defines connection count limits to control the
-number of users that may be simultaneously connected to the vhost.</p></div>
-<div class="admonitionblock">
-<table><tr>
-<td class="icon">
-<div class="title">Note</div>
-</td>
-<td class="content">
-<div class="paragraph"><p>A vhost user may be assigned to one user group only.</p></div>
-</td>
-</tr></table>
-</div>
-</div>
-<div class="sect4">
-<h5 id="_default_vhost">Default Vhost</h5>
-<div class="paragraph"><p>A default vhost may be defined. The default vhost policy is used for
-connections whose vhost is otherwise not defined in the policy database.</p></div>
-<div class="paragraph"><p><a href="#example2">Example 2</a> illustrates how the default vhost feature can
-be used to apply a single vhost policy set of restrictions to any
-number of vhost connections.</p></div>
-</div>
-</div>
-<div class="sect3">
-<h4 id="_policy_schema">2.6.3. Policy Schema</h4>
-<div class="paragraph"><p>Policy configuration is specified in two schema objects.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>policy = {
- <global settings>
-}
-
-vhost = {
- id: vhost-name
- <connection limits>
- groups: {
- group-name: {
- <user group settings>
- }
- }
-}</code></pre>
-</div></div>
-<div class="paragraph"><p>The <em>policy</em> object is a singleton. Multiple <em>vhost</em> objects may be
-created as needed.</p></div>
-<div class="sect4">
-<h5 id="_global_policy">Global Policy</h5>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="35%" />
-<col width="15%" />
-<col width="50%" />
-<thead>
-<tr>
-<th align="left" valign="top"> attribute </th>
-<th align="left" valign="top"> default </th>
-<th align="left" valign="top"> description</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">maxConnections</p></td>
-<td align="left" valign="top"><p class="table">65535</p></td>
-<td align="left" valign="top"><p class="table">Global maximum number of concurrent client connections allowed. This limit is always enforced even if no other policy settings have been defined. This limit is applied to all incoming connections regardless of remote host, authenticated user, or targeted vhost.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">enableVhostPolicy</p></td>
-<td align="left" valign="top"><p class="table">false</p></td>
-<td align="left" valign="top"><p class="table">Enable vhost policy connection denial, and resource limit enforcement.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">policyDir</p></td>
-<td align="left" valign="top"><p class="table">""</p></td>
-<td align="left" valign="top"><p class="table">Absolute path to a directory that holds vhost definition .json files. All vhost definitions in all .json files in this directory are processed.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">defaultVhost</p></td>
-<td align="left" valign="top"><p class="table">"$default"</p></td>
-<td align="left" valign="top"><p class="table">Vhost rule set name to use for connections with a vhost that is otherwise not defined. Default vhost processing may be disabled either by erasing the definition of <em>defaultVhost</em> or by not defining a <em>vhost</em> object named <em>$default</em>.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-<div class="sect4">
-<h5 id="_vhost_policy_2">Vhost Policy</h5>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="35%" />
-<col width="15%" />
-<col width="50%" />
-<thead>
-<tr>
-<th align="left" valign="top"> attribute </th>
-<th align="left" valign="top"> default </th>
-<th align="left" valign="top"> description</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">id</p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-<td align="left" valign="top"><p class="table">Vhost name must be unique.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxConnections</p></td>
-<td align="left" valign="top"><p class="table">65535</p></td>
-<td align="left" valign="top"><p class="table">Maximum number of concurrent client connections allowed.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxConnectionsPerUser</p></td>
-<td align="left" valign="top"><p class="table">65535</p></td>
-<td align="left" valign="top"><p class="table">Maximum number of concurrent client connections allowed for any user.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxConnectionsPerRemoteHost</p></td>
-<td align="left" valign="top"><p class="table">65535</p></td>
-<td align="left" valign="top"><p class="table">Maximum number of concurrent client connections allowed for any remote host.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">allowUnknownUser</p></td>
-<td align="left" valign="top"><p class="table">false</p></td>
-<td align="left" valign="top"><p class="table">Allow unknown users who are not members of a defined user group. Unknown users are assigned to the <em>$default</em> user group and receive <em>$default</em> settings.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">groups</p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-<td align="left" valign="top"><p class="table">A map where each key is a user group name and the value is a Vhost User Group Settings map.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-<div class="sect4">
-<h5 id="_vhost_user_group_settings_map">Vhost User Group Settings Map</h5>
-<div class="paragraph"><p>This object is the data value contained in entries in the policy/groups map.</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="35%" />
-<col width="15%" />
-<col width="50%" />
-<thead>
-<tr>
-<th align="left" valign="top"> Section/Attribute </th>
-<th align="left" valign="top"> default </th>
-<th align="left" valign="top"> description</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table"><strong>Group Membership</strong></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">users</p></td>
-<td align="left" valign="top"><p class="table">""</p></td>
-<td align="left" valign="top"><p class="table">List of authenticated users in this group.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><strong>Connection Restrictions</strong></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">remoteHosts</p></td>
-<td align="left" valign="top"><p class="table">""</p></td>
-<td align="left" valign="top"><p class="table">List of remote hosts from which the users may connect. List values may be host names, numeric IP addresses, numeric IP address ranges, or the wildcard <em>*</em>. An empty list denies all access.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><strong>AMQP Connection Open Limits</strong></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxFrameSize</p></td>
-<td align="left" valign="top"><p class="table">2^31-1</p></td>
-<td align="left" valign="top"><p class="table">Largest frame that may be sent on this connection. (AMQP Open, max-frame-size)</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxSessions</p></td>
-<td align="left" valign="top"><p class="table">65535</p></td>
-<td align="left" valign="top"><p class="table">Maximum number of sessions that may be created on this connection. (AMQP Open, channel-max)</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><strong>AMQP Session Begin Limits</strong></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxSessionWindow</p></td>
-<td align="left" valign="top"><p class="table">2^31-1</p></td>
-<td align="left" valign="top"><p class="table">Incoming capacity for new sessions. (AMQP Begin, incoming-window)</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><strong>AMQP Link Attach</strong></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-<td align="left" valign="top"><p class="table"></p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxMessageSize</p></td>
-<td align="left" valign="top"><p class="table">0</p></td>
-<td align="left" valign="top"><p class="table">Largest message size supported by links created on this connection. If this field is zero there is no maximum size imposed by the link endpoint. (AMQP Attach, max-message-size)</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxSenders</p></td>
-<td align="left" valign="top"><p class="table">2^31-1</p></td>
-<td align="left" valign="top"><p class="table">Maximum number of sending links that may be created on this connection.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">maxReceivers</p></td>
-<td align="left" valign="top"><p class="table">2^31-1</p></td>
-<td align="left" valign="top"><p class="table">Maximum number of receiving links that may be created on this connection.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">allowDynamicSource</p></td>
-<td align="left" valign="top"><p class="table">false</p></td>
-<td align="left" valign="top"><p class="table">This connection is allowed to create receiving links using the Dynamic Link Source feature.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">allowAnonymousSender</p></td>
-<td align="left" valign="top"><p class="table">false</p></td>
-<td align="left" valign="top"><p class="table">This connection is allowed to create sending links using the Anonymous Sender feature.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">sources</p></td>
-<td align="left" valign="top"><p class="table">""</p></td>
-<td align="left" valign="top"><p class="table">List of Source addresses allowed when creating receiving links. This list may be expressed as a CSV string or as a list of strings. An empty list denies all access.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">targets</p></td>
-<td align="left" valign="top"><p class="table">""</p></td>
-<td align="left" valign="top"><p class="table">List of Target addresses allowed when creating sending links. This list may be expressed as a CSV string or as a list of strings. An empty list denies all access.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-</div>
-<div class="sect3">
-<h4 id="_policy_wildcard_and_user_name_substitution">2.6.4. Policy Wildcard and User Name Substitution</h4>
-<div class="paragraph"><p>Policy provides several conventions to make writing rules easier.</p></div>
-<div class="sect4">
-<h5 id="_remote_host_wildcard">Remote Host Wildcard</h5>
-<div class="paragraph"><p>Remote host rules may consist of a single asterisk character to
-specify all hosts.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code> remoteHosts: *</code></pre>
-</div></div>
-<div class="paragraph"><p>The asterisk must stand alone and cannot be appended to a host name
-or to an IP address fragment.</p></div>
-</div>
-<div class="sect4">
-<h5 id="_amqp_source_and_target_wildcard_and_name_substitution">AMQP Source and Target Wildcard and Name Substitution</h5>
-<div class="paragraph"><p>The rule definitions for <code>sources</code> and <code>targets</code> may include the username
-substitution token</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code> {user}</code></pre>
-</div></div>
-<div class="paragraph"><p>or a trailing asterisk.</p></div>
-<div class="paragraph"><p>The username substitution token is replaced with the authenticated user name for
-the connection. Using this token, an administrator may allow access to
-some resources specific to each user without having to name each user
-individually. This token is substituted once for the leftmost
-occurrence in the link name.</p></div>
-<div class="paragraph"><p>The asterisk is recognized only if it is the last character in the
-link name.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code> sources: tmp_{user}, temp*, {user}-home-*</code></pre>
-</div></div>
-</div>
-</div>
-<div class="sect3">
-<h4 id="_composing_policies">2.6.5. Composing Policies</h4>
-<div class="paragraph"><p>This section shows policy examples designed to illustrate some common use cases.</p></div>
-<div class="sect4">
-<h5 id="_example_1_user_policy_disabled">Example 1. User Policy Disabled</h5>
-<div class="paragraph"><p>Policy is disabled when no policy configuation objects are defined.
-Any number of connections are allowed and all users have
-access to all AMQP resources in the network.</p></div>
-</div>
-<div class="sect4">
-<h5 id="example2">Example 2. All Users Have Simple Connection Limits</h5>
-<div class="paragraph"><p>This example shows how to keep users from overwhelming the router with
-connections. Any user can create up to ten connections and the router
-will limit the aggregated user connection count to 100 connections
-total. No other restrictions apply.</p></div>
-<div class="paragraph"><p>This example also shows how to use a default vhost policy effectively.
-Only one vhost policy is defined and all user connections regardless
-of the requested vhost use that policy.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>policy {
- maxConnections: 100 <b><1></b>
-}
-
-vhost {
- name: $default <b><2></b>
- maxConnectionsPerUser: 10 <b><3></b>
- allowUnknownUser: true <b><4></b>
- groups: {
- $default: {
- remoteHosts: * <b><5></b>
- sources: * <b><6></b>
- targets: * <b><6></b>
- }
- }
-}</code></pre>
-</div></div>
-<div class="colist arabic"><ol>
-<li>
-<p>
-The global maxConnections limit of 100 is enforced.
-</p>
-</li>
-<li>
-<p>
-No normal vhost names are defined; user is assigned to default vhost <em>$default</em>.
-</p>
-</li>
-<li>
-<p>
-The vhost maxConnectionsPerUser limit of 10 is enforced.
-</p>
-</li>
-<li>
-<p>
-No groups are defined to have any users but allowUnknownUser is true so all users are assigned to group $default.
-</p>
-</li>
-<li>
-<p>
-The user is allowed to connect from any remote host.
-</p>
-</li>
-<li>
-<p>
-The user is allowed to connect to any source or target in the AMQP network. Router system-wide values are used for the other AMQP settings that are unspecified in the vhost rules.
-</p>
-</li>
-</ol></div>
-</div>
-<div class="sect4">
-<h5 id="_example_3_admins_must_connect_from_localhost">Example 3. Admins Must Connect From Localhost</h5>
-<div class="paragraph"><p>This example shows how an admin group may be created and restricted
-to accessing a vhost only from localhost. The admin users are allowed
-to connect to any AMQP resources while normal users are restricted.</p></div>
-<div class="paragraph"><p>In this example a user connects to vhost <em>example.com</em>.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>vhost {
- name: example.com <b><1></b>
- allowUnknownUser: true <b><3></b>
- groups: {
- admin: {
- users: alice, bob <b><2></b>
- remoteHosts: 127.0.0.1, ::1 <b><4></b>
- sources: * <b><5></b>
- targets: * <b><5></b>
- },
- $default: {
- remoteHosts: * <b><6></b>
- sources: news*, sports*, chat* <b><7></b>
- targets: chat* <b><7></b>
- }
- }
-}</code></pre>
-</div></div>
-<div class="colist arabic"><ol>
-<li>
-<p>
-A connection to vhost <em>example.com</em> locates this vhost rule set.
-</p>
-</li>
-<li>
-<p>
-If one of users <em>alice</em> or <em>bob</em> is connecting then she or he is assigned to the <em>admin</em> user group.
-</p>
-</li>
-<li>
-<p>
-Any other user is not defined by a user group. However, since the <em>allowUnknownUser</em> setting is true then this user is assigned to the <em>$default</em> user group.
-</p>
-</li>
-<li>
-<p>
-Users in the <em>admin</em> user group must connect from localhost. Connections for an <em>admin</em> user from other hosts on the network are denied.
-</p>
-</li>
-<li>
-<p>
-Users in the <em>admin</em> user group are allowed to access any resource offered by the vhost service.
-</p>
-</li>
-<li>
-<p>
-Other users are allowed to connect from any host.
-</p>
-</li>
-<li>
-<p>
-Other users have source and target name lists that restrict the resources they are allowed to access.
-</p>
-</li>
-</ol></div>
-</div>
-<div class="sect4">
-<h5 id="_example_4_limiting_possible_memory_consumption">Example 4. Limiting Possible Memory Consumption</h5>
-<div class="paragraph"><p>Policy provides a mechanism to control how much system buffer memory a
-user connection can potentially consume. The formula for computing
-buffer memory consumption for each session is</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code> potential buffer usage = maxFrameSize * maxSessionWindow</code></pre>
-</div></div>
-<div class="paragraph"><p>By adjusting <em>maxFrameSize</em>, <em>maxSessions</em>, and <em>maxSessionWindow</em> an
-administrator can prevent a user from consuming too much memory by
-buffering messages in flight.</p></div>
-<div class="admonitionblock">
-<table><tr>
-<td class="icon">
-<div class="title">Note</div>
-</td>
-<td class="content">
-<div class="paragraph"><p>The settings passed into the AMQP protocol connection and session
-negotiations. Normal AMQP session flow control limits buffer
-consumption in due course with no processing cycles required by the
-router.</p></div>
-</td>
-</tr></table>
-</div>
-<div class="paragraph"><p>In this example normal users, the traders, are given smaller buffer
-allocations while high-capacity, automated data feeds are given a
-higher buffer allocation. This example skips the details of settings
-unrelated to buffer allocation.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>vhost {
- name: traders.com <b><1></b>
- groups: {
- traders: {
- users: trader-1, trader-2, ... <b><2></b>
- maxFrameSize: 10000 <b><3></b>
- maxSessionWindow: 500 <b><3></b>
- maxSessions: 1 <b><4></b>
- ...
- },
- feeds: {
- users: nyse-feed, nasdaq-feed <b><5></b>
- maxFrameSize: 60000 <b><6></b>
- maxSessionWindow: 20000 <b><6></b>
- maxSessions: 3 <b><7></b>
- ...
- }
- }
-}</code></pre>
-</div></div>
-<div class="colist arabic"><ol>
-<li>
-<p>
-These rules are for vhost traders.com.
-</p>
-</li>
-<li>
-<p>
-The <em>traders</em> group includes trader-1, trader-2, and any other user defined in the list.
-</p>
-</li>
-<li>
-<p>
-<em>maxFrameSize</em> and <em>maxSessionWindow</em> allow for at most 5,000,000 bytes of data to be in flight on each session.
-</p>
-</li>
-<li>
-<p>
-Only one session per connection is allowed.
-</p>
-</li>
-<li>
-<p>
-In the <em>feeds</em> group two users are defined.
-</p>
-</li>
-<li>
-<p>
-<em>maxFrameSize</em> and <em>maxSessionWindow</em> allow for at most 1,200,000,000 bytes of data to be in flight on each session.
-</p>
-</li>
-<li>
-<p>
-Up to three sessions per connection are allowed.
-</p>
-</li>
-</ol></div>
-</div>
-</div>
-</div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="technical-details-and-specifications">3. Technical Details and Specifications</h2>
-<div class="sectionbody">
-<div class="sect2">
-<h3 id="client-compatibility">3.1. Client Compatibility</h3>
-<div class="paragraph"><p>Dispatch Router should, in theory, work with any client that is
-compatible with AMQP 1.0. The following clients have been tested:</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="22%" />
-<col width="78%" />
-<thead>
-<tr>
-<th align="left" valign="top"><em>Client</em> </th>
-<th align="left" valign="top"><em>Notes</em></th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">qpid::messaging</p></td>
-<td align="left" valign="top"><p class="table">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.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">Proton Reactor</p></td>
-<td align="left" valign="top"><p class="table">The Proton Reactor API is compatible with Dispatch
-Router.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">Proton Messenger</p></td>
-<td align="left" valign="top"><p class="table">Messenger works with Dispatch Router.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-<div class="sect2">
-<h3 id="addressing">3.2. Addressing</h3>
-<div class="paragraph"><p>AMQP addresses are used to control the flow of messages across a network
-of routers. Addresses are used in a number of different places in the
-AMQP 1.0 protocol. They can be used in a specific message in the <code>to</code>
-and <code>reply-to</code> fields of a message’s properties. They are also used
-during the creation of links in the <code>address</code> field of a <code>source</code> or
-a <code>target</code>.</p></div>
-<div class="paragraph"><p>Addresses designate various kinds of entities in a messaging network:</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-Endpoint processes that consume data or offer a service
-</p>
-</li>
-<li>
-<p>
-Topics that match multiple consumers to multiple producers
-</p>
-</li>
-<li>
-<p>
-Entities within a messaging broker:
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-Queues
-</p>
-</li>
-<li>
-<p>
-Durable Topics
-</p>
-</li>
-<li>
-<p>
-Exchanges
-</p>
-</li>
-</ul></div>
-</li>
-</ul></div>
-<div class="paragraph"><p>The syntax of an AMQP address is opaque as far as the router network is
-concerned. A syntactical structure may be used by the administrator that
-creates addresses, but the router treats them as opaque strings. Routers
-consider addresses to be mobile such that any address may be directly
-connected to any router in a network and may move around the topology.
-In cases where messages are broadcast to or balanced across multiple
-consumers, an address may be connected to multiple routers in the
-network.</p></div>
-<div class="paragraph"><p>Addresses have semantics associated with them. When an address is
-created in the network, it is assigned a set of semantics (and access
-rules) during a process called provisioning. The semantics of an address
-control how routers behave when they see the address being used.</p></div>
-<div class="paragraph"><p>Address semantics include the following considerations:</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-<em>Routing pattern</em> - direct, multicast, balanced
-</p>
-</li>
-<li>
-<p>
-<em>Undeliverable action</em> - drop, hold and retry, redirect
-</p>
-</li>
-<li>
-<p>
-<em>Reliability</em> - N destinations, etc.
-</p>
-</li>
-</ul></div>
-<div class="sect3">
-<h4 id="routing-patterns">3.2.1. Routing patterns</h4>
-<div class="paragraph"><p>Routing patterns constrain the paths that a message can take across a
-network.</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="18%" />
-<col width="82%" />
-<thead>
-<tr>
-<th align="left" valign="top"><em>Pattern</em> </th>
-<th align="left" valign="top"><em>Description</em></th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table"><em>Direct</em></p></td>
-<td align="left" valign="top"><p class="table">Direct routing allows for only one consumer to use an address
-at a time. Messages (or links) follow the lowest cost path across the
-network from the sender to the one receiver.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><em>Multicast</em></p></td>
-<td align="left" valign="top"><p class="table">Multicast routing allows multiple consumers to use the
-same address at the same time. Messages are routed such that each
-consumer receives a copy of the message.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><em>Balanced</em></p></td>
-<td align="left" valign="top"><p class="table">Balanced routing also allows multiple consumers to use the
-same address. In this case, messages are routed to exactly one of the
-consumers, and the network attempts to balance the traffic load across
-the set of consumers using the same address.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-<div class="sect3">
-<h4 id="routing-mechanisms">3.2.2. Routing mechanisms</h4>
-<div class="paragraph"><p>The fact that addresses can be used in different ways suggests that
-message routing can be accomplished in different ways. Before going into
-the specifics of the different routing mechanisms, it would be good to
-first define what is meant by the term <em>routing</em>:</p></div>
-<div class="quoteblock">
-<div class="content">
-<div class="paragraph"><p>In a network built of multiple routers connected by connections (i.e.,
-nodes and edges in a graph), <em>routing</em> determines which connection to
-use to send a message directly to its destination or one step closer to
-its destination.</p></div>
-</div>
-<div class="attribution">
-</div></div>
-<div class="paragraph"><p>Each router serves as the terminus of a collection of incoming and
-outgoing links. The links either connect directly to endpoints that
-produce and consume messages, or they connect to other routers in the
-network along previously established connections.</p></div>
-<div class="sect4">
-<h5 id="message-routing">Message routing</h5>
-<div class="paragraph"><p>Message routing occurs upon delivery of a message and is done based on
-the address in the message’s <code>to</code> field.</p></div>
-<div class="paragraph"><p>When a delivery arrives on an incoming link, the router extracts the
-address from the delivered message’s <code>to</code> field and looks the address up
-in its routing table. The lookup results in zero or more outgoing links
-onto which the message shall be resent.</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="20%" />
-<col width="80%" />
-<thead>
-<tr>
-<th align="left" valign="top"><em>Delivery</em> </th>
-<th align="left" valign="top"><em>Handling</em></th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table"><em>pre-settled</em></p></td>
-<td align="left" valign="top"><p class="table">If the arriving delivery is pre-settled (i.e., fire and
-forget), the incoming delivery shall be settled by the router, and the
-outgoing deliveries shall also be pre-settled. In other words, the
-pre-settled nature of the message delivery is propagated across the
-network to the message’s destination.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><em>unsettled</em></p></td>
-<td align="left" valign="top"><p class="table">Unsettled delivery is also propagated across the network.
-Because unsettled delivery records cannot be discarded, the router
-tracks the incoming deliveries and keeps the association of the incoming
-deliveries to the resulting outgoing deliveries. This kept association
-allows the router to continue to propagate changes in delivery state
-(settlement and disposition) back and forth along the path which the
-message traveled.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-</div>
-</div>
-<div class="sect2">
-<h3 id="amqp-mapping">3.3. AMQP Mapping</h3>
-<div class="paragraph"><p>Dispatch Router is an AMQP router and as such, it provides extensions,
-code-points, and semantics for routing over AMQP. This page documents the
-details of Dispatch Router’s use of AMQP.</p></div>
-<div class="sect3">
-<h4 id="message-annotations">3.3.1. Message Annotations</h4>
-<div class="paragraph"><p>The following Message Annotation fields are defined by Dispatch Router:</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="23%" />
-<col width="19%" />
-<col width="58%" />
-<thead>
-<tr>
-<th align="left" valign="top"><em>Field</em> </th>
-<th align="left" valign="top"><em>Type</em> </th>
-<th align="left" valign="top"><em>Description</em></th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">x-opt-qd.ingress</p></td>
-<td align="left" valign="top"><p class="table">string</p></td>
-<td align="left" valign="top"><p class="table">The identity of the ingress router for a
-message-routed message. The ingress router is the first router
-encountered by a transiting message. The router will, if this field is
-present, leave it unaltered. If the field is not present, the router
-shall insert the field with its own identity.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">x-opt-qd.trace</p></td>
-<td align="left" valign="top"><p class="table">list of string</p></td>
-<td align="left" valign="top"><p class="table">The list of routers through which this
-message-routed message has transited. If this field is not present, the
-router shall do nothing. If the field is present, the router shall
-append its own identity to the end of the list.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">x-opt-qd.to</p></td>
-<td align="left" valign="top"><p class="table">string</p></td>
-<td align="left" valign="top"><p class="table">To-Override for message-routed messages. If this
-field is present, the address in this field shall be used for routing in
-lieu of the <em>to</em> field in the message properties. A router may append,
-remove, or modify this annotation field depending on the policy in place
-for routing the message.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">x-opt-qd.phase</p></td>
-<td align="left" valign="top"><p class="table">integer</p></td>
-<td align="left" valign="top"><p class="table">The address-phase, if not zero, for messages
-flowing between routers.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-<div class="sect3">
-<h4 id="sourcetarget-capabilities">3.3.2. Source/Target Capabilities</h4>
-<div class="paragraph"><p>The following Capability values are used in Sources and Targets.</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="19%" />
-<col width="81%" />
-<thead>
-<tr>
-<th align="left" valign="top"><em>Capability</em> </th>
-<th align="left" valign="top"><em>Description</em></th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">qd.router</p></td>
-<td align="left" valign="top"><p class="table">This capability is added to sources and targets that are
-used for inter-router message exchange. This capability denotes a link
-used for router-control messages flowing between routers.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table">qd.router-data</p></td>
-<td align="left" valign="top"><p class="table">This capability is added to sources and targets that
-are used for inter-router message exchange. This capability denotes a
-link used for user messages being message-routed across an inter-router
-connection.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-<div class="sect3">
-<h4 id="dynamic-node-properties">3.3.3. Dynamic-Node-Properties</h4>
-<div class="paragraph"><p>The following dynamic-node-properties are used by Dispatch in Sources.</p></div>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="23%" />
-<col width="77%" />
-<thead>
-<tr>
-<th align="left" valign="top"><em>Property</em> </th>
-<th align="left" valign="top"><em>Description</em></th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table">x-opt-qd.address</p></td>
-<td align="left" valign="top"><p class="table">The node address describing the destination desired
-for a dynamic source. If this is absent, the router will terminate any
-dynamic receivers. If this address is present, the router will use the
-address to route the dynamic link attach to the proper destination
-container.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-<div class="sect3">
-<h4 id="addresses-and-address-formats">3.3.4. Addresses and Address Formats</h4>
-<div class="paragraph"><p>The following AMQP addresses and address patterns are used within
-Dispatch Router.</p></div>
-<div class="sect4">
-<h5 id="address-patterns">Address Patterns</h5>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="38%" />
-<col width="62%" />
-<thead>
-<tr>
-<th align="left" valign="top"><em>Pattern</em> </th>
-<th align="left" valign="top"><em>Description</em></th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table"><code>_local/<addr></code></p></td>
-<td align="left" valign="top"><p class="table">An address that references a locally attached endpoint.
-Messages using this address pattern shall not be routed over more than
-one link.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><code>_topo/0/<router>/<addr></code></p></td>
-<td align="left" valign="top"><p class="table">An address that references an endpoint attached to a specific router
-node in the network topology. Messages with addresses that follow this
-pattern shall be routed along the shortest path to the specified router.
-Note that addresses of this form are a-priori routable in that the
-address itself contains enough information to route the message to its
-destination.</p>
-<p class="table">The <em>0</em> component immediately preceding the router-id is a placeholder
-for an <em>area</em> which may be used in the future if area routing is
-implemented.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><code><addr></code></p></td>
-<td align="left" valign="top"><p class="table">A mobile address. An address of this format represents an
-endpoint or a set of distinct endpoints that are attached to the network
-in arbitrary locations. It is the responsibility of the router network
-to determine which router nodes are valid destinations for mobile
-addresses.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-<div class="sect4">
-<h5 id="supported-addresses">Supported Addresses</h5>
-<div class="tableblock">
-<table rules="all"
-width="100%"
-frame="border"
-cellspacing="0" cellpadding="4">
-<col width="36%" />
-<col width="64%" />
-<thead>
-<tr>
-<th align="left" valign="top"><em>Address</em> </th>
-<th align="left" valign="top"><em>Description</em></th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td align="left" valign="top"><p class="table"><code>$management</code></p></td>
-<td align="left" valign="top"><p class="table">The management agent on the attached router/container.
-This address would be used by an endpoint that is a management
-client/console/tool wishing to access management data from the attached
-container.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><code>_topo/0/Router.E/$management</code></p></td>
-<td align="left" valign="top"><p class="table">The management agent at Router.E in area
-0. This address would be used by a management client wishing to access
-management data from a specific container that is reachable within the
-network.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><code>_local/qdhello</code></p></td>
-<td align="left" valign="top"><p class="table">The router entity in each of the connected routers.
-This address is used to communicate with neighbor routers and is
-exclusively for the HELLO discovery protocol.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><code>_local/qdrouter</code></p></td>
-<td align="left" valign="top"><p class="table">The router entity in each of the connected routers.
-This address is used by a router to communicate with other routers in
-the network.</p></td>
-</tr>
-<tr>
-<td align="left" valign="top"><p class="table"><code>_topo/0/Router.E/qdrouter</code></p></td>
-<td align="left" valign="top"><p class="table">The router entity at the specifically
-indicated router. This address form is used by a router to communicate
-with a specific router that may or may not be a neighbor.</p></td>
-</tr>
-</tbody>
-</table>
-</div>
-</div>
-</div>
-<div class="sect3">
-<h4 id="implementation-of-the-amqp-management-specification">3.3.5. Implementation of the AMQP Management Specification</h4>
-<div class="paragraph"><p>Qpid Dispatch is manageable remotely via AMQP. It is compliant with the
-emerging AMQP Management specification (draft 9).</p></div>
-<div class="paragraph"><p>Differences from the specification:</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-The <code>name</code> attribute is not required when an entity is created. If
- not supplied it will be set to the same value as the system-generated
- "identity" attribute. Otherwise it is treated as per the standard.
-</p>
-</li>
-<li>
-<p>
-The <code>REGISTER</code> and <code>DEREGISTER</code> operations are not implemented. The router
- automatically discovers peer routers via the router network and makes
- their management addresses available via the standard <code>GET-MGMT-NODES</code>
- operation.
-= Management Schema
-</p>
-</li>
-</ul></div>
-<div class="paragraph"><p>This chapter documents the set of <strong>management entity types</strong> that define
-configuration and management of a Dispatch Router. A management entity type has
-a set of <strong>attributes</strong> that can be read, some attributes can also be
-updated. Some entity types also support <strong>operations</strong> that can be called.</p></div>
-<div class="paragraph"><p>All management entity types have the following standard attributes:</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-type
-</dt>
-<dd>
-<p>
- The fully qualified type of the entity,
- e.g. <code>org.apache.qpid.dispatch.router</code>. This document uses the short name
- without the <code>org.apache.qpid.dispatch</code> prefix e.g. <code>router</code>. The dispatch
- tools will accept the short or long name.
-</p>
-</dd>
-<dt class="hdlist1">
-name
-</dt>
-<dd>
-<p>
- A user-generated identity for the entity. This can be used in other entities
- that need to refer to the named entity.
-</p>
-</dd>
-<dt class="hdlist1">
-identity
-</dt>
-<dd>
-<p>
- A system-generated identity of the entity. It includes
- the short type name and some identifying information. E.g. <code>log/AGENT</code> or
- <code>listener/localhost:amqp</code>
-</p>
-</dd>
-</dl></div>
-<div class="paragraph"><p>There are two main categories of management entity type.</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-Configuration Entities
-</dt>
-<dd>
-<p>
- Parameters that can be set in the configuration file
- (see <code>qdrouterd.conf(5)</code> man page) or set at run-time with the <code>qdmanage(8)</code>
- tool.
-</p>
-</dd>
-<dt class="hdlist1">
-Operational Entities
-</dt>
-<dd>
-<p>
- Run-time status values that can be queried using <code>qdstat(8)</code> or <code>qdmanage(8)</code> tools.
-</p>
-</dd>
-</dl></div>
-</div>
-</div>
-<div class="sect2">
-<h3 id="_configuration_entities">3.4. Configuration Entities</h3>
-<div class="paragraph"><p>Configuration entities define the attributes allowed in the configuration file
-(see <code>qdrouterd.conf(5)</code>) but you can also create entities once the router is
-running using the <code>qdrouterd(8)</code> tool’s <code>create</code> operation. Some entities can also
-be modified using the <code>update</code> operation, see the entity descriptions below.</p></div>
-<div class="sect3">
-<h4 id="_router">3.4.1. router</h4>
-<div class="paragraph"><p>Tracks peer routers and computes routes to destinations.</p></div>
-<div class="paragraph"><p>Operations allowed: <code>READ</code></p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>id</em> (string, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- Router’s unique identity. One of id or routerId is required. The router will fail to start without id or routerId
-</p>
-</dd>
-<dt class="hdlist1">
-<em>mode</em> (One of [<em>standalone</em>, <em>interior</em>], default=<em>standalone</em>, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- In standalone mode, the router operates as a single component. It does not participate in the routing protocol and therefore will not cooperate with other routers. In interior mode, the router operates in cooperation with other interior routers in an interconnected network.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>area</em> (string)
-</dt>
-<dd>
-<p>
- Unused placeholder.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>helloInterval</em> (integer, default=1, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- Interval in seconds between HELLO messages sent to neighbor routers.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>helloMaxAge</em> (integer, default=3, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- Time in seconds after which a neighbor is declared lost if no HELLO is received.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>raInterval</em> (integer, default=30, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- Interval in seconds between Router-Advertisements sent to all routers in a stable network.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>raIntervalFlux</em> (integer, default=4, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- Interval in seconds between Router-Advertisements sent to all routers during topology fluctuations.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>remoteLsMaxAge</em> (integer, default=60, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- Time in seconds after which link state is declared stale if no RA is received.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>addrCount</em> (integer)
-</dt>
-<dd>
-<p>
- Number of addresses known to the router.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>linkCount</em> (integer)
-</dt>
-<dd>
-<p>
- Number of links attached to the router node.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>nodeCount</em> (integer)
-</dt>
-<dd>
-<p>
- Number of known peer router nodes.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>workerThreads</em> (integer, default=4, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- The number of threads that will be created to process message traffic and other application work (timers, non-amqp file descriptors, etc.) .
-</p>
-</dd>
-<dt class="hdlist1">
-<em>debugDump</em> (path, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- A file to dump debugging information that can’t be logged normally.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>saslConfigPath</em> (path, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- Absolute path to the SASL configuration file.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>saslConfigName</em> (string, default=<em>qdrouterd</em>, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- Name of the SASL configuration. This string + <em>.conf</em> is the name of the configuration file.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>routerId</em> (string, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- (DEPRECATED) Router’s unique identity. This attribute has been deprecated. Use id instead
-</p>
-</dd>
-<dt class="hdlist1">
-<em>mobileAddrMaxAge</em> (integer, default=60, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- (DEPRECATED) This value is no longer used in the router.
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect3">
-<h4 id="_sslprofile">3.4.2. sslProfile</h4>
-<div class="paragraph"><p>Attributes for setting TLS/SSL configuration for connections.</p></div>
-<div class="paragraph"><p>Operations allowed: <code>CREATE</code>, <code>DELETE</code>, <code>READ</code></p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>certDb</em> (path, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- The absolute path to the database that contains the public certificates of trusted certificate authorities (CA).
-</p>
-</dd>
-<dt class="hdlist1">
-<em>certFile</em> (path, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- The absolute path to the file containing the PEM-formatted public certificate to be used on the local end of any connections using this profile.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>keyFile</em> (path, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- The absolute path to the file containing the PEM-formatted private key for the above certificate.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>passwordFile</em> (path, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- If the above private key is password protected, this is the absolute path to a file containing the password that unlocks the certificate key.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>password</em> (string, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- An alternative to storing the password in a file referenced by passwordFile is to supply the password right here in the configuration file. This option can be used by supplying the password in the <em>password</em> option. Don’t use both password and passwordFile in the same profile.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>uidFormat</em> (string, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- A list of x509 client certificate fields that will be used to build a string that will uniquely identify the client certificate owner. For e.g. a value of <em>cou</em> indicates that the uid will consist of c - common name concatenated with o - organization-company name concatenated with u - organization unit; or a value of <em>o2</em> indicates that the uid will consist of o (organization name) concatenated with 2 (the sha256 fingerprint of the entire certificate) . Allowed values can be any combination of <em>c</em>( ISO3166 two character country code), <em>s</em>(state or province), <em>l</em>(Locality; generally - city), <em>o</em>(Organization - Company Name), <em>u</em>(Organization Unit - typically certificate type or brand), <em>n</em>(CommonName - typically a user name for client certificates) and <em>1</em>(sha1 certificate fingerprint, as displayed in the fingerprints section when looking at a certificate with say a web browser is the hash of the entire certificate) and
2 (sha256 certificate fingerprint) and 5 (sha512 certificate fingerprint).
-</p>
-</dd>
-<dt class="hdlist1">
-<em>displayNameFile</em> (string, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- The absolute path to the file containing the unique id to dispay name mapping
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect3">
-<h4 id="_listener">3.4.3. listener</h4>
-<div class="paragraph"><p>Listens for incoming connections to the router.</p></div>
-<div class="paragraph"><p>Operations allowed: <code>CREATE</code>, <code>DELETE</code>, <code>READ</code></p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>host</em> (string, default=<em>127.0.0.1</em>, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- IP address: ipv4 or ipv6 literal or a host name
-</p>
-</dd>
-<dt class="hdlist1">
-<em>port</em> (string, default=<em>amqp</em>, <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- Port number or symbolic service name.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>protocolFamily</em> (One of [<em>IPv4</em>, <em>IPv6</em>], <code>CREATE</code>)
-</dt>
-<dd>
-<p>
- [<em>IPv4</em>, <em>IPv6</em>] IPv4: Internet Protocol version 4; IPv6: Internet Protocol version 6. If not specified, the protocol family will be automatically determined from the address.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>role</em> (One of [<em>normal</em>, <em
<TRUNCATED>
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/book.pdf
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/book.pdf b/input/releases/qpid-dispatch-master/book.pdf
deleted file mode 100644
index 90fc389..0000000
Binary files a/input/releases/qpid-dispatch-master/book.pdf and /dev/null differ
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org
[07/13] qpid-site git commit: QPID-8015: Prepare the dispatch release
scripts for the new user guide
Posted by jr...@apache.org.
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/deferred.css
----------------------------------------------------------------------
diff --git a/input/deferred.css b/input/deferred.css
index 2170e7b..586435c 100644
--- a/input/deferred.css
+++ b/input/deferred.css
@@ -379,6 +379,21 @@ a[href]:visited {
font-weight: 400;
}
+/* Adjustments for asciidoctor output */
+
+div.sect1, div.sect2, div.paragraph, div.listingblock, div.ulist, div.tableblock, div.toc {
+ margin-bottom: 1em;
+}
+
+div.ulist > ul > li > p {
+ margin-bottom: 0;
+}
+
+div.tableblock td, div.tableblock th {
+ border: 0;
+ border-bottom: 1px solid #efefef;
+}
+
/* Media */
@media screen and (max-width: 800px) {
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/_images/console1.png
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/_images/console1.png b/input/releases/qpid-dispatch-master/_images/console1.png
deleted file mode 100644
index f131884..0000000
Binary files a/input/releases/qpid-dispatch-master/_images/console1.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/_images/console_charts.png
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/_images/console_charts.png b/input/releases/qpid-dispatch-master/_images/console_charts.png
deleted file mode 100644
index 169c2ca..0000000
Binary files a/input/releases/qpid-dispatch-master/_images/console_charts.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/_images/console_entity.png
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/_images/console_entity.png b/input/releases/qpid-dispatch-master/_images/console_entity.png
deleted file mode 100644
index 130c7e7..0000000
Binary files a/input/releases/qpid-dispatch-master/_images/console_entity.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/_images/console_login.png
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/_images/console_login.png b/input/releases/qpid-dispatch-master/_images/console_login.png
deleted file mode 100644
index 63e22c6..0000000
Binary files a/input/releases/qpid-dispatch-master/_images/console_login.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/_images/console_overview.png
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/_images/console_overview.png b/input/releases/qpid-dispatch-master/_images/console_overview.png
deleted file mode 100644
index af25f36..0000000
Binary files a/input/releases/qpid-dispatch-master/_images/console_overview.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/_images/console_schema.png
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/_images/console_schema.png b/input/releases/qpid-dispatch-master/_images/console_schema.png
deleted file mode 100644
index ba56c7b..0000000
Binary files a/input/releases/qpid-dispatch-master/_images/console_schema.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/_images/console_topology.png
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/_images/console_topology.png b/input/releases/qpid-dispatch-master/_images/console_topology.png
deleted file mode 100644
index ae4b22a..0000000
Binary files a/input/releases/qpid-dispatch-master/_images/console_topology.png and /dev/null differ
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org
[03/13] qpid-site git commit: QPID-8015: Prepare the dispatch release
scripts for the new user guide
Posted by jr...@apache.org.
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/qdrouterd.conf.5.html.in
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/qdrouterd.conf.5.html.in b/input/releases/qpid-dispatch-master/qdrouterd.conf.5.html.in
deleted file mode 100644
index b21f67f..0000000
--- a/input/releases/qpid-dispatch-master/qdrouterd.conf.5.html.in
+++ /dev/null
@@ -1,1012 +0,0 @@
-<div class="sect1">
-<h2 id="_synopsis">SYNOPSIS</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>Provides the initial configuration when <em>qdrouterd(8)</em> starts. The configuration
-of a running router can be modified using <em>qdmanage(8)</em>.</p></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_description">DESCRIPTION</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>The configuration file is made up of sections with this syntax:</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>sectionName {
- attributeName: attributeValue
- attributeName: attributeValue
- ...
-}</code></pre>
-</div></div>
-<div class="paragraph"><p>For example you can define a router using the <em>router</em> section</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>router {
- mode: standalone
- id: Router.A
- ...
-}</code></pre>
-</div></div>
-<div class="paragraph"><p>or define a listener using the <em>listener</em> section</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>listener {
- host: 0.0.0.0
- port: 20102
- saslMechanisms: ANONYMOUS
- ...
-}</code></pre>
-</div></div>
-<div class="paragraph"><p>or define a connector using the <em>connector</em> section</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>connector {
- role: inter-router
- host: 0.0.0.0
- port: 20003
- saslMechanisms: ANONYMOUS
- ...
-}</code></pre>
-</div></div>
-<div class="paragraph"><p>An <em>sslProfile</em> section with SSL credentials can be included in multiple <em>listener</em> or <em>connector</em> entities. Here’s an example, note
-how the <em>sslProfile</em> attribute of <em>listener</em> sections references the <em>name</em>
-attribute of <em>sslProfile</em> sections.</p></div>
-<div class="listingblock">
-<div class="content">
-<pre><code>sslProfile {
- name: my-ssl
- certDb: ca-certificate-1.pem
- certFile: server-certificate-1.pem
- keyFile: server-private-key.pem
-}
-
-listener {
- sslProfile: my-ssl
- host: 0.0.0.0
- port: 20102
- saslMechanisms: ANONYMOUS
-}</code></pre>
-</div></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_configuration_sections">Configuration Sections</h2>
-<div class="sectionbody">
-<div class="sect2">
-<h3 id="_router">router</h3>
-<div class="paragraph"><p>Tracks peer routers and computes routes to destinations.</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>id</em> (string)
-</dt>
-<dd>
-<p>
- Router’s unique identity. One of id or routerId is required. The router will fail to start without id or routerId
-</p>
-</dd>
-<dt class="hdlist1">
-<em>mode</em> (One of [<em>standalone</em>, <em>interior</em>], default=<em>standalone</em>)
-</dt>
-<dd>
-<p>
- In standalone mode, the router operates as a single component. It does not participate in the routing protocol and therefore will not cooperate with other routers. In interior mode, the router operates in cooperation with other interior routers in an interconnected network.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>helloInterval</em> (integer, default=1)
-</dt>
-<dd>
-<p>
- Interval in seconds between HELLO messages sent to neighbor routers.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>helloMaxAge</em> (integer, default=3)
-</dt>
-<dd>
-<p>
- Time in seconds after which a neighbor is declared lost if no HELLO is received.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>raInterval</em> (integer, default=30)
-</dt>
-<dd>
-<p>
- Interval in seconds between Router-Advertisements sent to all routers in a stable network.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>raIntervalFlux</em> (integer, default=4)
-</dt>
-<dd>
-<p>
- Interval in seconds between Router-Advertisements sent to all routers during topology fluctuations.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>remoteLsMaxAge</em> (integer, default=60)
-</dt>
-<dd>
-<p>
- Time in seconds after which link state is declared stale if no RA is received.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>workerThreads</em> (integer, default=4)
-</dt>
-<dd>
-<p>
- The number of threads that will be created to process message traffic and other application work (timers, non-amqp file descriptors, etc.) .
-</p>
-</dd>
-<dt class="hdlist1">
-<em>debugDump</em> (path)
-</dt>
-<dd>
-<p>
- A file to dump debugging information that can’t be logged normally.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>saslConfigPath</em> (path)
-</dt>
-<dd>
-<p>
- Absolute path to the SASL configuration file.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>saslConfigName</em> (string, default=<em>qdrouterd</em>)
-</dt>
-<dd>
-<p>
- Name of the SASL configuration. This string + <em>.conf</em> is the name of the configuration file.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>routerId</em> (string)
-</dt>
-<dd>
-<p>
- (DEPRECATED) Router’s unique identity. This attribute has been deprecated. Use id instead
-</p>
-</dd>
-<dt class="hdlist1">
-<em>mobileAddrMaxAge</em> (integer, default=60)
-</dt>
-<dd>
-<p>
- (DEPRECATED) This value is no longer used in the router.
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_sslprofile">sslProfile</h3>
-<div class="paragraph"><p>Attributes for setting TLS/SSL configuration for connections.</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>certDb</em> (path)
-</dt>
-<dd>
-<p>
- The absolute path to the database that contains the public certificates of trusted certificate authorities (CA).
-</p>
-</dd>
-<dt class="hdlist1">
-<em>certFile</em> (path)
-</dt>
-<dd>
-<p>
- The absolute path to the file containing the PEM-formatted public certificate to be used on the local end of any connections using this profile.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>keyFile</em> (path)
-</dt>
-<dd>
-<p>
- The absolute path to the file containing the PEM-formatted private key for the above certificate.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>passwordFile</em> (path)
-</dt>
-<dd>
-<p>
- If the above private key is password protected, this is the absolute path to a file containing the password that unlocks the certificate key.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>password</em> (string)
-</dt>
-<dd>
-<p>
- An alternative to storing the password in a file referenced by passwordFile is to supply the password right here in the configuration file. This option can be used by supplying the password in the <em>password</em> option. Don’t use both password and passwordFile in the same profile.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>uidFormat</em> (string)
-</dt>
-<dd>
-<p>
- A list of x509 client certificate fields that will be used to build a string that will uniquely identify the client certificate owner. For e.g. a value of <em>cou</em> indicates that the uid will consist of c - common name concatenated with o - organization-company name concatenated with u - organization unit; or a value of <em>o2</em> indicates that the uid will consist of o (organization name) concatenated with 2 (the sha256 fingerprint of the entire certificate) . Allowed values can be any combination of <em>c</em>( ISO3166 two character country code), <em>s</em>(state or province), <em>l</em>(Locality; generally - city), <em>o</em>(Organization - Company Name), <em>u</em>(Organization Unit - typically certificate type or brand), <em>n</em>(CommonName - typically a user name for client certificates) and <em>1</em>(sha1 certificate fingerprint, as displayed in the fingerprints section when looking at a certificate with say a web browser is the hash of the entire certificate) and
2 (sha256 certificate fingerprint) and 5 (sha512 certificate fingerprint).
-</p>
-</dd>
-<dt class="hdlist1">
-<em>displayNameFile</em> (string)
-</dt>
-<dd>
-<p>
- The absolute path to the file containing the unique id to dispay name mapping
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_listener">listener</h3>
-<div class="paragraph"><p>Listens for incoming connections to the router.</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>host</em> (string, default=<em>127.0.0.1</em>)
-</dt>
-<dd>
-<p>
- IP address: ipv4 or ipv6 literal or a host name
-</p>
-</dd>
-<dt class="hdlist1">
-<em>port</em> (string, default=<em>amqp</em>)
-</dt>
-<dd>
-<p>
- Port number or symbolic service name.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>protocolFamily</em> (One of [<em>IPv4</em>, <em>IPv6</em>])
-</dt>
-<dd>
-<p>
- [<em>IPv4</em>, <em>IPv6</em>] IPv4: Internet Protocol version 4; IPv6: Internet Protocol version 6. If not specified, the protocol family will be automatically determined from the address.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>role</em> (One of [<em>normal</em>, <em>inter-router</em>, <em>route-container</em>, <em>on-demand</em>], default=<em>normal</em>)
-</dt>
-<dd>
-<p>
- The role of an established connection. In the normal role, the connection is assumed to be used for AMQP clients that are doing normal message delivery over the connection. In the inter-router role, the connection is assumed to be to another router in the network. Inter-router discovery and routing protocols can only be used over inter-router connections. route-container role can be used for router-container connections, for example, a router-broker connection. on-demand role has been deprecated.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>cost</em> (integer, default=<em>1</em>)
-</dt>
-<dd>
-<p>
- For the <em>inter-router</em> role only. This value assigns a cost metric to the inter-router connection. The default (and minimum) value is one. Higher values represent higher costs. The cost is used to influence the routing algorithm as it attempts to use the path with the lowest total cost from ingress to egress.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>sslProfile</em> (string)
-</dt>
-<dd>
-<p>
- Name of the sslProfile.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>saslMechanisms</em> (string)
-</dt>
-<dd>
-<p>
- Space separated list of accepted SASL authentication mechanisms.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>authenticatePeer</em> (boolean)
-</dt>
-<dd>
-<p>
- yes: Require the peer’s identity to be authenticated; no: Do not require any authentication.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>requireEncryption</em> (boolean)
-</dt>
-<dd>
-<p>
- yes: Require the connection to the peer to be encrypted; no: Permit non-encrypted communication with the peer
-</p>
-</dd>
-<dt class="hdlist1">
-<em>requireSsl</em> (boolean)
-</dt>
-<dd>
-<p>
- yes: Require the use of SSL or TLS on the connection; no: Allow clients to connect without SSL or TLS.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>trustedCerts</em> (path)
-</dt>
-<dd>
-<p>
- This optional setting can be used to reduce the set of available CAs for client authentication. If used, this setting must provide the absolute path to a PEM file that contains the trusted certificates.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>maxFrameSize</em> (integer, default=16384)
-</dt>
-<dd>
-<p>
- Defaults to 16384. If specified, it is the maximum frame size in octets that will be used in the connection-open negotiation with a connected peer. The frame size is the largest contiguous set of uninterrupted data that can be sent for a message delivery over the connection. Interleaving of messages on different links is done at frame granularity.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>idleTimeoutSeconds</em> (integer, default=16)
-</dt>
-<dd>
-<p>
- The idle timeout, in seconds, for connections through this listener. If no frames are received on the connection for this time interval, the connection shall be closed.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>stripAnnotations</em> (One of [<em>in</em>, <em>out</em>, <em>both</em>, <em>no</em>], default=<em>both</em>)
-</dt>
-<dd>
-<p>
- [<em>in</em>, <em>out</em>, <em>both</em>, <em>no</em>] in: Strip the dispatch router specific annotations only on ingress; out: Strip the dispatch router specific annotations only on egress; both: Strip the dispatch router specific annotations on both ingress and egress; no - do not strip dispatch router specific annotations
-</p>
-</dd>
-<dt class="hdlist1">
-<em>linkCapacity</em> (integer)
-</dt>
-<dd>
-<p>
- The capacity of links within this connection, in terms of message deliveries. The capacity is the number of messages that can be in-flight concurrently for each link.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>addr</em> (string, default=<em>127.0.0.1</em>)
-</dt>
-<dd>
-<p>
- (DEPRECATED)IP address: ipv4 or ipv6 literal or a host name. This attribute has been deprecated. Use host instead
-</p>
-</dd>
-<dt class="hdlist1">
-<em>allowNoSasl</em> (boolean)
-</dt>
-<dd>
-<p>
- (DEPRECATED) This attribute is now controlled by the authenticatePeer attribute.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>requirePeerAuth</em> (boolean)
-</dt>
-<dd>
-<p>
- (DEPRECATED) This attribute is now controlled by the authenticatePeer attribute.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>allowUnsecured</em> (boolean)
-</dt>
-<dd>
-<p>
- (DEPRECATED) This attribute is now controlled by the requireEncryption attribute.
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_connector">connector</h3>
-<div class="paragraph"><p>Establishes an outgoing connection from the router.</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>host</em> (string, default=<em>127.0.0.1</em>)
-</dt>
-<dd>
-<p>
- IP address: ipv4 or ipv6 literal or a host name
-</p>
-</dd>
-<dt class="hdlist1">
-<em>port</em> (string, default=<em>amqp</em>)
-</dt>
-<dd>
-<p>
- Port number or symbolic service name.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>protocolFamily</em> (One of [<em>IPv4</em>, <em>IPv6</em>])
-</dt>
-<dd>
-<p>
- [<em>IPv4</em>, <em>IPv6</em>] IPv4: Internet Protocol version 4; IPv6: Internet Protocol version 6. If not specified, the protocol family will be automatically determined from the address.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>role</em> (One of [<em>normal</em>, <em>inter-router</em>, <em>route-container</em>, <em>on-demand</em>], default=<em>normal</em>)
-</dt>
-<dd>
-<p>
- The role of an established connection. In the normal role, the connection is assumed to be used for AMQP clients that are doing normal message delivery over the connection. In the inter-router role, the connection is assumed to be to another router in the network. Inter-router discovery and routing protocols can only be used over inter-router connections. route-container role can be used for router-container connections, for example, a router-broker connection. on-demand role has been deprecated.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>cost</em> (integer, default=<em>1</em>)
-</dt>
-<dd>
-<p>
- For the <em>inter-router</em> role only. This value assigns a cost metric to the inter-router connection. The default (and minimum) value is one. Higher values represent higher costs. The cost is used to influence the routing algorithm as it attempts to use the path with the lowest total cost from ingress to egress.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>sslProfile</em> (string)
-</dt>
-<dd>
-<p>
- Name of the sslProfile.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>saslMechanisms</em> (string)
-</dt>
-<dd>
-<p>
- Space separated list of accepted SASL authentication mechanisms.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>allowRedirect</em> (boolean, default=True)
-</dt>
-<dd>
-<p>
- Allow the peer to redirect this connection to another address.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>maxFrameSize</em> (integer, default=65536)
-</dt>
-<dd>
-<p>
- Maximum frame size in octets that will be used in the connection-open negotiation with a connected peer. The frame size is the largest contiguous set of uninterrupted data that can be sent for a message delivery over the connection. Interleaving of messages on different links is done at frame granularity.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>idleTimeoutSeconds</em> (integer, default=16)
-</dt>
-<dd>
-<p>
- The idle timeout, in seconds, for connections through this connector. If no frames are received on the connection for this time interval, the connection shall be closed.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>stripAnnotations</em> (One of [<em>in</em>, <em>out</em>, <em>both</em>, <em>no</em>], default=<em>both</em>)
-</dt>
-<dd>
-<p>
- [<em>in</em>, <em>out</em>, <em>both</em>, <em>no</em>] in: Strip the dispatch router specific annotations only on ingress; out: Strip the dispatch router specific annotations only on egress; both: Strip the dispatch router specific annotations on both ingress and egress; no - do not strip dispatch router specific annotations
-</p>
-</dd>
-<dt class="hdlist1">
-<em>linkCapacity</em> (integer)
-</dt>
-<dd>
-<p>
- The capacity of links within this connection, in terms of message deliveries. The capacity is the number of messages that can be in-flight concurrently for each link.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>verifyHostName</em> (boolean, default=True)
-</dt>
-<dd>
-<p>
- yes: Ensures that when initiating a connection (as a client) the host name in the URL to which this connector connects to matches the host name in the digital certificate that the peer sends back as part of the SSL connection; no: Does not perform host name verification
-</p>
-</dd>
-<dt class="hdlist1">
-<em>saslUsername</em> (string)
-</dt>
-<dd>
-<p>
- The user name that the connector is using to connect to a peer.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>saslPassword</em> (string)
-</dt>
-<dd>
-<p>
- The password that the connector is using to connect to a peer.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>addr</em> (string, default=<em>127.0.0.1</em>)
-</dt>
-<dd>
-<p>
- (DEPRECATED)IP address: ipv4 or ipv6 literal or a host name. This attribute has been deprecated. Use host instead
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_log">log</h3>
-<div class="paragraph"><p>Configure logging for a particular module. You can use the <code>UPDATE</code> operation to change log settings while the router is running.</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>module</em> (One of [<em>ROUTER</em>, <em>ROUTER_CORE</em>, <em>ROUTER_HELLO</em>, <em>ROUTER_LS</em>, <em>ROUTER_MA</em>, <em>MESSAGE</em>, <em>SERVER</em>, <em>AGENT</em>, <em>CONTAINER</em>, <em>ERROR</em>, <em>POLICY</em>, <em>DEFAULT</em>], required)
-</dt>
-<dd>
-<p>
- Module to configure. The special module <em>DEFAULT</em> specifies defaults for all modules.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>enable</em> (string)
-</dt>
-<dd>
-<p>
- Levels are: trace, debug, info, notice, warning, error, critical. The enable string is a comma-separated list of levels. A level may have a trailing <em>+</em> to enable that level and above. For example <em>trace,debug,warning+</em> means enable trace, debug, warning, error and critical. The value <em>none</em> means disable logging for the module.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>timestamp</em> (boolean)
-</dt>
-<dd>
-<p>
- Include timestamp in log messages.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>source</em> (boolean)
-</dt>
-<dd>
-<p>
- Include source file and line number in log messages.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>output</em> (string)
-</dt>
-<dd>
-<p>
- Where to send log messages. Can be <em>stderr</em>, <em>stdout</em>, <em>syslog</em> or a file name.
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_address">address</h3>
-<div class="paragraph"><p>Entity type for address configuration. This is used to configure the treatment of message-routed deliveries within a particular address-space. The configuration controls distribution and address phasing.</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>prefix</em> (string, required)
-</dt>
-<dd>
-<p>
- The address prefix for the configured settings
-</p>
-</dd>
-<dt class="hdlist1">
-<em>distribution</em> (One of [<em>multicast</em>, <em>closest</em>, <em>balanced</em>], default=<em>balanced</em>)
-</dt>
-<dd>
-<p>
- Treatment of traffic associated with the address
-</p>
-</dd>
-<dt class="hdlist1">
-<em>waypoint</em> (boolean)
-</dt>
-<dd>
-<p>
- Designates this address space as being used for waypoints. This will cause the proper address-phasing to be used.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>ingressPhase</em> (integer)
-</dt>
-<dd>
-<p>
- Advanced - Override the ingress phase for this address
-</p>
-</dd>
-<dt class="hdlist1">
-<em>egressPhase</em> (integer)
-</dt>
-<dd>
-<p>
- Advanced - Override the egress phase for this address
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_linkroute">linkRoute</h3>
-<div class="paragraph"><p>Entity type for link-route configuration. This is used to identify remote containers that shall be destinations for routed link-attaches. The link-routing configuration applies to an addressing space defined by a prefix.</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>prefix</em> (string, required)
-</dt>
-<dd>
-<p>
- The address prefix for the configured settings
-</p>
-</dd>
-<dt class="hdlist1">
-<em>containerId</em> (string)
-</dt>
-<dd>
-<p>
- ContainerID for the target container
-</p>
-</dd>
-<dt class="hdlist1">
-<em>connection</em> (string)
-</dt>
-<dd>
-<p>
- The name from a connector or listener
-</p>
-</dd>
-<dt class="hdlist1">
-<em>distribution</em> (One of [<em>linkBalanced</em>], default=<em>linkBalanced</em>)
-</dt>
-<dd>
-<p>
- Treatment of traffic associated with the address
-</p>
-</dd>
-<dt class="hdlist1">
-<em>dir</em> (One of [<em>in</em>, <em>out</em>], required)
-</dt>
-<dd>
-<p>
- The permitted direction of links: <em>in</em> means client senders; <em>out</em> means client receivers
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_autolink">autoLink</h3>
-<div class="paragraph"><p>Entity type for configuring auto-links. Auto-links are links whose lifecycle is managed by the router. These are typically used to attach to waypoints on remote containers (brokers, etc.).</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>addr</em> (string, required)
-</dt>
-<dd>
-<p>
- The address of the provisioned object
-</p>
-</dd>
-<dt class="hdlist1">
-<em>dir</em> (One of [<em>in</em>, <em>out</em>], required)
-</dt>
-<dd>
-<p>
- The direction of the link to be created. In means into the router, out means out of the router.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>phase</em> (integer)
-</dt>
-<dd>
-<p>
- The address phase for this link. Defaults to <em>0</em> for <em>out</em> links and <em>1</em> for <em>in</em> links.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>containerId</em> (string)
-</dt>
-<dd>
-<p>
- ContainerID for the target container
-</p>
-</dd>
-<dt class="hdlist1">
-<em>connection</em> (string)
-</dt>
-<dd>
-<p>
- The name from a connector or listener
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_console">console</h3>
-<div class="paragraph"><p>Start a websocket/tcp proxy and http file server to serve the web console</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>listener</em> (string)
-</dt>
-<dd>
-<p>
- The name of the listener to send the proxied tcp traffic to.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>wsport</em> (integer, default=5673)
-</dt>
-<dd>
-<p>
- port on which to listen for websocket traffic
-</p>
-</dd>
-<dt class="hdlist1">
-<em>proxy</em> (string)
-</dt>
-<dd>
-<p>
- The full path to the proxy program to run.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>home</em> (string)
-</dt>
-<dd>
-<p>
- The full path to the html/css/js files for the console.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>args</em> (string)
-</dt>
-<dd>
-<p>
- Optional args to pass the proxy program for logging, authentication, etc.
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_policy">policy</h3>
-<div class="paragraph"><p>Defines global connection limit</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>maxConnections</em> (integer, default=65535)
-</dt>
-<dd>
-<p>
- Global maximum number of concurrent client connections allowed. This limit is always enforced even if no other policy settings have been defined.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>enableVhostPolicy</em> (boolean)
-</dt>
-<dd>
-<p>
- Enable vhost policy user groups, connection denial, and resource limit enforcement
-</p>
-</dd>
-<dt class="hdlist1">
-<em>policyDir</em> (path)
-</dt>
-<dd>
-<p>
- Absolute path to a directory that holds vhost definition .json files. All vhost definitions in all .json files in this directory are processed.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>defaultVhost</em> (string)
-</dt>
-<dd>
-<p>
- Vhost rule set name to use for connections with a vhost that is otherwise not defined. Default vhost processing may be disabled either by erasing the definition of defaultVhost or by not defining a vhost object named <em>$default</em>.
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_vhost">vhost</h3>
-<div class="paragraph"><p>AMQP virtual host policy definition of users, user groups, allowed remote hosts, and AMQP restrictions.</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>maxConnections</em> (integer, default=65535)
-</dt>
-<dd>
-<p>
- Maximum number of concurrent client connections allowed.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>maxConnectionsPerUser</em> (integer, default=65535)
-</dt>
-<dd>
-<p>
- Maximum number of concurrent client connections allowed for any single user.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>maxConnectionsPerHost</em> (integer, default=65535)
-</dt>
-<dd>
-<p>
- Maximum number of concurrent client connections allowed for any remote host.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>allowUnknownUser</em> (boolean)
-</dt>
-<dd>
-<p>
- Unrestricted users, those who are not members of a defined user group, are allowed to connect to this application. Unrestricted users are assigned to the <em>default</em> user group and receive <em>default</em> settings.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>groups</em> (map)
-</dt>
-<dd>
-<p>
- A map where each key is a user group name and the value is a map of the corresponding settings for that group.
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_container">container</h3>
-<div class="paragraph"><p>(DEPRECATED)Attributes related to the AMQP container. This entity has been deprecated. Use the router entity instead.</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>containerName</em> (string)
-</dt>
-<dd>
-<p>
- The name of the AMQP container. If not specified, the container name will be set to a value of the container’s choosing. The automatically assigned container name is not guaranteed to be persistent across restarts of the container.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>workerThreads</em> (integer, default=4)
-</dt>
-<dd>
-<p>
- The number of threads that will be created to process message traffic and other application work (timers, non-amqp file descriptors, etc.) .
-</p>
-</dd>
-<dt class="hdlist1">
-<em>debugDump</em> (path)
-</dt>
-<dd>
-<p>
- A file to dump debugging information that can’t be logged normally.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>saslConfigPath</em> (path)
-</dt>
-<dd>
-<p>
- Absolute path to the SASL configuration file.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>saslConfigName</em> (string)
-</dt>
-<dd>
-<p>
- Name of the SASL configuration. This string + <em>.conf</em> is the name of the configuration file.
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_waypoint">waypoint</h3>
-<div class="paragraph"><p>(DEPRECATED) A remote node that messages for an address pass through. This entity has been deprecated. Use autoLink instead</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>address</em> (string, required)
-</dt>
-<dd>
-<p>
- The AMQP address of the waypoint.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>connector</em> (string, required)
-</dt>
-<dd>
-<p>
- The name of the on-demand connector used to reach the waypoint’s container.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>inPhase</em> (integer, default=-1)
-</dt>
-<dd>
-<p>
- The phase of the address as it is routed <em>to</em> the waypoint.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>outPhase</em> (integer, default=-1)
-</dt>
-<dd>
-<p>
- The phase of the address as it is routed <em>from</em> the waypoint.
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_fixedaddress">fixedAddress</h3>
-<div class="paragraph"><p>(DEPRECATED) Establishes treatment for addresses starting with a prefix. This entity has been deprecated. Use address instead</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>prefix</em> (string, required)
-</dt>
-<dd>
-<p>
- The address prefix (always starting with <em>/</em>).
-</p>
-</dd>
-<dt class="hdlist1">
-<em>phase</em> (integer)
-</dt>
-<dd>
-<p>
- The phase of a multi-hop address passing through one or more waypoints.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>fanout</em> (One of [<em>multiple</em>, <em>single</em>], default=<em>multiple</em>)
-</dt>
-<dd>
-<p>
- One of <em>multiple</em> or <em>single</em>. Multiple fanout is a non-competing pattern. If there are multiple consumers using the same address, each consumer will receive its own copy of every message sent to the address. Single fanout is a competing pattern where each message is sent to only one consumer.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>bias</em> (One of [<em>closest</em>, <em>spread</em>], default=<em>closest</em>)
-</dt>
-<dd>
-<p>
- Only if fanout is single. One of <em>closest</em> or <em>spread</em>. Closest bias means that messages to an address will always be delivered to the closest (lowest cost) subscribed consumer. Spread bias will distribute the messages across subscribers in an approximately even manner.
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_linkroutepattern">linkRoutePattern</h3>
-<div class="paragraph"><p>(DEPRECATED) An address pattern to match against link sources and targets to cause the router to link-route the attach across the network to a remote node. This entity has been deprecated. Use linkRoute instead</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>prefix</em> (string, required)
-</dt>
-<dd>
-<p>
- An address prefix to match against target and source addresses. This pattern must be of the form <em><text>.<text1>.<textN></em> or <em><text></em> or <em><text>.</em> and matches any address that contains that prefix. For example, if the prefix is set to org.apache (or org.apache.), any address that has the prefix <em>org.apache</em> (like org.apache.dev) will match. Note that a prefix must not start with a (.), can end in a (.) and can contain zero or more dots (.). Any characters between the dots are simply treated as part of the address
-</p>
-</dd>
-<dt class="hdlist1">
-<em>dir</em> (One of [<em>in</em>, <em>out</em>, <em>both</em>], default=<em>both</em>)
-</dt>
-<dd>
-<p>
- Link direction for match: <em>in</em> matches only links inbound to the client; <em>out</em> matches only links outbound from the client; <em>both</em> matches any link.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>connector</em> (string)
-</dt>
-<dd>
-<p>
- The name of the on-demand connector used to reach the target node’s container. If this value is not provided, it means that the target container is expected to be connected to a different router in the network. This prevents links to a link-routable address from being misinterpreted as message-routing links when there is no route to a valid destination available.
-</p>
-</dd>
-</dl></div>
-</div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_see_also">SEE ALSO</h2>
-<div class="sectionbody">
-<div class="paragraph"><p><strong>qdrouterd(8)</strong>, <strong>qdmanage(8)</strong></p></div>
-<div class="paragraph"><p><a href="http://qpid.apache.org/components/dispatch-router">http://qpid.apache.org/components/dispatch-router</a></p></div>
-</div>
-</div>
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/qdstat.8.html.in
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/qdstat.8.html.in b/input/releases/qpid-dispatch-master/qdstat.8.html.in
deleted file mode 100644
index c33ee2f..0000000
--- a/input/releases/qpid-dispatch-master/qdstat.8.html.in
+++ /dev/null
@@ -1,726 +0,0 @@
-<div class="sect1">
-<h2 id="_synopsis">SYNOPSIS</h2>
-<div class="sectionbody">
-<div class="paragraph"><p><strong>qdstat</strong> [<em>OPTIONS</em>]</p></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_description">DESCRIPTION</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>Shows status information about networks of Dispatch routers. It can display
-connections, network nodes and links, and router stats such as memory use.</p></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_options">OPTIONS</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>-h, --help
-: show this help message and exit</p></div>
-<div class="paragraph"><p>--version
-: Print version and exit.</p></div>
-<div class="paragraph"><p>-g, --general
-: Show General Router Stats</p></div>
-<div class="paragraph"><p>-c, --connections
-: Show Connections</p></div>
-<div class="paragraph"><p>-l, --links
-: Show Router Links</p></div>
-<div class="paragraph"><p>-n, --nodes
-: Show Router Nodes</p></div>
-<div class="paragraph"><p>-a, --address
-: Show Router Addresses</p></div>
-<div class="paragraph"><p>-m, --memory
-: Show Router Memory Stats</p></div>
-<div class="paragraph"><p>--autolinks
-: Show Auto Links</p></div>
-<div class="paragraph"><p>--linkroutes
-: Show Link Routes</p></div>
-<div class="paragraph"><p>-v, --verbose
-: Show maximum detail</p></div>
-<div class="paragraph"><p>--log
-: Show recent log entries</p></div>
-<div class="paragraph"><p>--limit=LIMIT
-: Limit number of log entries</p></div>
-<div class="sect2">
-<h3 id="_connection_options">Connection Options</h3>
-<div class="paragraph"><p>-b URL, --bus=URL
-: URL of the messaging bus to connect to (default 0.0.0.0)</p></div>
-<div class="paragraph"><p>-r ROUTER-ID, --router=ROUTER-ID
-: Router to be queried</p></div>
-<div class="paragraph"><p>-t SECS, --timeout=SECS
-: Maximum time to wait for connection in seconds (default 5)</p></div>
-<div class="paragraph"><p>--ssl-certificate=CERT
-: Client SSL certificate (PEM Format)</p></div>
-<div class="paragraph"><p>--ssl-key=KEY
-: Client SSL private key (PEM Format)</p></div>
-<div class="paragraph"><p>--ssl-trustfile=TRUSTED-CA-DB
-: Trusted Certificate Authority Database file (PEM Format)</p></div>
-<div class="paragraph"><p>--ssl-password=PASSWORD
-: Certificate password, will be prompted if not specifed.</p></div>
-<div class="paragraph"><p>--ssl-password-file=SSL-PASSWORD-FILE
-: Certificate password, will be prompted if not specifed.</p></div>
-<div class="paragraph"><p>--sasl-mechanisms=SASL-MECHANISMS
-: Allowed sasl mechanisms to be supplied during the sasl handshake.</p></div>
-<div class="paragraph"><p>--sasl-username=SASL-USERNAME
-: User name for SASL plain authentication</p></div>
-<div class="paragraph"><p>--sasl-password=SASL-PASSWORD
-: Password for SASL plain authentication</p></div>
-<div class="paragraph"><p>--sasl-password-file=SASL-PASSWORD-FILE
-: Password for SASL plain authentication</p></div>
-<div class="paragraph"><p>--ssl-disable-peer-name-verify
-: Disables SSL peer name verification. WARNING - This option is insecure and must not be used in production environments</p></div>
-</div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_output_columns">OUTPUT COLUMNS</h2>
-<div class="sectionbody">
-<div class="sect2">
-<h3 id="_qdstat_c">qdstat -c</h3>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-id
-</dt>
-<dd>
-<p>
-Unique connection identifier
-</p>
-</dd>
-<dt class="hdlist1">
-host
-</dt>
-<dd>
-<p>
-The hostname or internet address of the remotely connected AMQP container
-</p>
-</dd>
-<dt class="hdlist1">
-container
-</dt>
-<dd>
-<p>
-The container-name of the remotely connected AMQP container
-</p>
-</dd>
-<dt class="hdlist1">
-role
-</dt>
-<dd>
-<p>
-The configured role of the connection
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-normal - Normal connections from client to router
-</p>
-</li>
-<li>
-<p>
-inter-router - Connection between routers to form a network
-</p>
-</li>
-<li>
-<p>
-route-container - Connection to/from a Broker or other host to receive link-routes and waypoints
-</p>
-</li>
-</ul></div>
-</dd>
-<dt class="hdlist1">
-dir
-</dt>
-<dd>
-<p>
-The direction of connection establishment
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-in - The connection was initiated by the remote container
-</p>
-</li>
-<li>
-<p>
-out - The connection was initiated by this router
-</p>
-</li>
-</ul></div>
-</dd>
-<dt class="hdlist1">
-security
-</dt>
-<dd>
-<p>
-A description of the security/encryption in effect for this
-connection
-</p>
-</dd>
-<dt class="hdlist1">
-authentication
-</dt>
-<dd>
-<p>
-The method and user-id of the authenticated user for
-this connection
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_qdstat_l">qdstat -l</h3>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-type
-</dt>
-<dd>
-<p>
-Type of link
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-router-control - An inter-router link that is reserved for control messages exchanged between routers
-</p>
-</li>
-<li>
-<p>
-inter-router - An inter-router link that is used for normal message-routed deliveries
-</p>
-</li>
-<li>
-<p>
-endpoint - A normal link to an external endpoint container
-</p>
-</li>
-</ul></div>
-</dd>
-<dt class="hdlist1">
-dir
-</dt>
-<dd>
-<p>
-The direction of message flow on the link
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-in - Deliveries flow inbound to the router
-</p>
-</li>
-<li>
-<p>
-out - Deliveries flow outbound from the router
-</p>
-</li>
-</ul></div>
-</dd>
-<dt class="hdlist1">
-conn id
-</dt>
-<dd>
-<p>
-Unique identifier of the connection over which this link is
-attached
-</p>
-</dd>
-<dt class="hdlist1">
-id
-</dt>
-<dd>
-<p>
-Unique identifier of this link
-</p>
-</dd>
-<dt class="hdlist1">
-peer
-</dt>
-<dd>
-<p>
-For link-routed links, the unique identifier of the peer link. In
-link routing, an inbound link is paired with an outbound link
-</p>
-</dd>
-<dt class="hdlist1">
-class
-</dt>
-<dd>
-<p>
-Class of the address bound to the link
-</p>
-</dd>
-<dt class="hdlist1">
-addr
-</dt>
-<dd>
-<p>
-The address bound to the link
-</p>
-</dd>
-<dt class="hdlist1">
-phs
-</dt>
-<dd>
-<p>
-The phase of the address bound to the link
-</p>
-</dd>
-<dt class="hdlist1">
-cap
-</dt>
-<dd>
-<p>
-The capacity, in deliveries, of the link
-</p>
-</dd>
-<dt class="hdlist1">
-undel
-</dt>
-<dd>
-<p>
-The number of undelivered messages stored on the link’s FIFO
-</p>
-</dd>
-<dt class="hdlist1">
-unsettled
-</dt>
-<dd>
-<p>
-The number of unsettled deliveries being tracked by the link
-</p>
-</dd>
-<dt class="hdlist1">
-deliveries
-</dt>
-<dd>
-<p>
-The total number of deliveries that have transited this link
-</p>
-</dd>
-<dt class="hdlist1">
-admin
-</dt>
-<dd>
-<p>
-The administrative status of the link
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-enabled - The link is enabled for normal operation
-</p>
-</li>
-<li>
-<p>
-disabled - The link is disabled and should be quiescing or stopped (not yet supported)
-</p>
-</li>
-</ul></div>
-</dd>
-<dt class="hdlist1">
-oper
-</dt>
-<dd>
-<p>
-The operational status of the link
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-up - The link is operational
-</p>
-</li>
-<li>
-<p>
-down - The link is not attached
-</p>
-</li>
-<li>
-<p>
-quiescing - The link is in the process of quiescing (not yet supported)
-</p>
-</li>
-<li>
-<p>
-idle - The link has completed quiescing and is idle (not yet supported)
-</p>
-</li>
-</ul></div>
-</dd>
-<dt class="hdlist1">
-name
-</dt>
-<dd>
-<p>
-The link name (only shown if the -v option is provided)
-</p>
-</dd>
-</dl></div>
-<div class="sect3">
-<h4 id="_qdstat_n">qdstat -n</h4>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-router-id
-</dt>
-<dd>
-<p>
-Identifier of the router
-</p>
-</dd>
-<dt class="hdlist1">
-next-hop
-</dt>
-<dd>
-<p>
-If this router is not a neighbor, identifies the next-hop neighbor used to reach this router
-</p>
-</dd>
-<dt class="hdlist1">
-link
-</dt>
-<dd>
-<p>
-Unique identifier of the link to the neighbor router
-</p>
-</dd>
-<dt class="hdlist1">
-cost
-</dt>
-<dd>
-<p>
-The topology cost to this remote router (with -v option only)
-</p>
-</dd>
-<dt class="hdlist1">
-neighbors
-</dt>
-<dd>
-<p>
-The list of neighbor routers (the router’s link-state) (with -v option only)
-</p>
-</dd>
-<dt class="hdlist1">
-valid-origins
-</dt>
-<dd>
-<p>
-The list of origin routers for which the best path to the listed router passes through this router (with -v option only)
-</p>
-</dd>
-</dl></div>
-</div>
-</div>
-<div class="sect2">
-<h3 id="_qdstat_a">qdstat -a</h3>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-class
-</dt>
-<dd>
-<p>
-The class of the listed address
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-local - Address that is local to this router
-</p>
-</li>
-<li>
-<p>
-topo - Topological address used for router control messages
-</p>
-</li>
-<li>
-<p>
-router - A summary router address used to route messages to a remote router’s local addresses
-</p>
-</li>
-<li>
-<p>
-mobile - A mobile address for an attached consumer or producer
-</p>
-</li>
-</ul></div>
-</dd>
-<dt class="hdlist1">
-addr
-</dt>
-<dd>
-<p>
-The address text
-</p>
-</dd>
-<dt class="hdlist1">
-phs
-</dt>
-<dd>
-<p>
-For mobile addresses only, the phase of the address. Direct addresses have only a phase 0. Waypoint addresses have multiple phases, normally 0 and 1.
-</p>
-</dd>
-<dt class="hdlist1">
-distrib
-</dt>
-<dd>
-<p>
-Distribution method used for this address
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-multicast - A copy of each message is delivered once to each consumer for the address
-</p>
-</li>
-<li>
-<p>
-closest - Each message is delivered to only one consumer for the address. The closest (lowest cost) consumer will be chosen. If there are multiple lowest-cost consumers, deliveries will be spread across those consumers.
-</p>
-</li>
-<li>
-<p>
-balanced - Each message is delivered to only one consumer for the address. The consumer with the fewest outstanding (unsettled) deliveries will be chosen. The cost of the route to the consumer is a threshold for delivery (i.e. higher cost consumers will only receive deliveries if closer consumers are backed up).
-</p>
-</li>
-<li>
-<p>
-flood - Used only for router-control traffic. This is multicast without prevention of duplicate deliveries.
-</p>
-</li>
-</ul></div>
-</dd>
-<dt class="hdlist1">
-in-proc
-</dt>
-<dd>
-<p>
-The number of in-process consumers for this address
-</p>
-</dd>
-<dt class="hdlist1">
-local
-</dt>
-<dd>
-<p>
-The number of local (on this router) consumers for this address
-</p>
-</dd>
-<dt class="hdlist1">
-remote
-</dt>
-<dd>
-<p>
-The number of remote routers that have at least one consumer for this address
-</p>
-</dd>
-<dt class="hdlist1">
-cntnr
-</dt>
-<dd>
-<p>
-The number of locally attached containers that are destinations for link-routes on this address
-</p>
-</dd>
-<dt class="hdlist1">
-in
-</dt>
-<dd>
-<p>
-The number of deliveries for this address that entered the network on this router
-</p>
-</dd>
-<dt class="hdlist1">
-out
-</dt>
-<dd>
-<p>
-The number of deliveries for this address that exited the network on this router
-</p>
-</dd>
-<dt class="hdlist1">
-thru
-</dt>
-<dd>
-<p>
-The number of deliveries for this address that were forwarded to other routers
-</p>
-</dd>
-<dt class="hdlist1">
-to-proc
-</dt>
-<dd>
-<p>
-The number of deliveries for this address that were delivered to an in-process consumer
-</p>
-</dd>
-<dt class="hdlist1">
-from-proc
-</dt>
-<dd>
-<p>
-The number of deliveries for this address that were received from an in-process producer
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_qdstat_linkroutes">qdstat --linkroutes</h3>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-prefix
-</dt>
-<dd>
-<p>
-The prefix for matching addresses of routed links
-</p>
-</dd>
-<dt class="hdlist1">
-dir
-</dt>
-<dd>
-<p>
-The direction (from the router’s perspective) of matching links
-</p>
-</dd>
-<dt class="hdlist1">
-distrib
-</dt>
-<dd>
-<p>
-The distribution method used for routed links
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-linkBalanced - the only supported distribution for routed links
-</p>
-</li>
-</ul></div>
-</dd>
-<dt class="hdlist1">
-status
-</dt>
-<dd>
-<p>
-Operational status of the link route
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-active - Route is actively routing attaches (i.e. ready for use)
-</p>
-</li>
-<li>
-<p>
-inactive - Route is inactive because there is no local destination connected
-</p>
-</li>
-</ul></div>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_qstat_autolinks">qstat --autolinks</h3>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-addr
-</dt>
-<dd>
-<p>
-The address of the auto link
-</p>
-</dd>
-<dt class="hdlist1">
-dir
-</dt>
-<dd>
-<p>
-The direction of message flow for the auto link
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-in - Messages flow in from the route-container to the router network
-</p>
-</li>
-<li>
-<p>
-out - Messages flow out to the route-container from the router network
-</p>
-</li>
-</ul></div>
-</dd>
-<dt class="hdlist1">
-phs
-</dt>
-<dd>
-<p>
-Phase of the address for this auto link
-</p>
-</dd>
-<dt class="hdlist1">
-link
-</dt>
-<dd>
-<p>
-Unique identifier of the link managed by this auto link
-</p>
-</dd>
-<dt class="hdlist1">
-status
-</dt>
-<dd>
-<p>
-The operational status of this auto link
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-inactive - There is no connected container for this auto link
-</p>
-</li>
-<li>
-<p>
-attaching - The link is attaching to the container
-</p>
-</li>
-<li>
-<p>
-failed - The link-attach failed
-</p>
-</li>
-<li>
-<p>
-active - The link is operational
-</p>
-</li>
-<li>
-<p>
-quiescing - The link is quiescing (not yet supported)
-</p>
-</li>
-<li>
-<p>
-idle - The link is idle (not yet supported)
-</p>
-</li>
-</ul></div>
-</dd>
-<dt class="hdlist1">
-lastErr
-</dt>
-<dd>
-<p>
-The description of the last attach failure that occurred on this auto link
-</p>
-</dd>
-</dl></div>
-</div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_see_also">SEE ALSO</h2>
-<div class="sectionbody">
-<div class="paragraph"><p><em>qdrouterd(8)</em>, <em>qdmanage(8)</em>, <em>qdrouterd.conf(5)</em></p></div>
-<div class="paragraph"><p><a href="http://qpid.apache.org/components/dispatch-router">http://qpid.apache.org/components/dispatch-router</a></p></div>
-</div>
-</div>
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org
[10/13] qpid-site git commit: QPID-8015: Prepare the dispatch release
scripts for the new user guide
Posted by jr...@apache.org.
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/book/console_charts.png
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/book/console_charts.png b/content/releases/qpid-dispatch-master/book/console_charts.png
deleted file mode 100755
index 169c2ca..0000000
Binary files a/content/releases/qpid-dispatch-master/book/console_charts.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/book/console_entity.png
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/book/console_entity.png b/content/releases/qpid-dispatch-master/book/console_entity.png
deleted file mode 100755
index 130c7e7..0000000
Binary files a/content/releases/qpid-dispatch-master/book/console_entity.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/book/console_login.png
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/book/console_login.png b/content/releases/qpid-dispatch-master/book/console_login.png
deleted file mode 100755
index 63e22c6..0000000
Binary files a/content/releases/qpid-dispatch-master/book/console_login.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/book/console_overview.png
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/book/console_overview.png b/content/releases/qpid-dispatch-master/book/console_overview.png
deleted file mode 100755
index af25f36..0000000
Binary files a/content/releases/qpid-dispatch-master/book/console_overview.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/book/console_schema.png
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/book/console_schema.png b/content/releases/qpid-dispatch-master/book/console_schema.png
deleted file mode 100755
index ba56c7b..0000000
Binary files a/content/releases/qpid-dispatch-master/book/console_schema.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/book/console_topology.png
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/book/console_topology.png b/content/releases/qpid-dispatch-master/book/console_topology.png
deleted file mode 100755
index ae4b22a..0000000
Binary files a/content/releases/qpid-dispatch-master/book/console_topology.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/console1.png
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/console1.png b/content/releases/qpid-dispatch-master/console1.png
deleted file mode 100755
index f131884..0000000
Binary files a/content/releases/qpid-dispatch-master/console1.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/console_charts.png
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/console_charts.png b/content/releases/qpid-dispatch-master/console_charts.png
deleted file mode 100755
index 169c2ca..0000000
Binary files a/content/releases/qpid-dispatch-master/console_charts.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/console_entity.png
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/console_entity.png b/content/releases/qpid-dispatch-master/console_entity.png
deleted file mode 100755
index 130c7e7..0000000
Binary files a/content/releases/qpid-dispatch-master/console_entity.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/console_login.png
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/console_login.png b/content/releases/qpid-dispatch-master/console_login.png
deleted file mode 100755
index 63e22c6..0000000
Binary files a/content/releases/qpid-dispatch-master/console_login.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/console_overview.png
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/console_overview.png b/content/releases/qpid-dispatch-master/console_overview.png
deleted file mode 100755
index af25f36..0000000
Binary files a/content/releases/qpid-dispatch-master/console_overview.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/console_schema.png
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/console_schema.png b/content/releases/qpid-dispatch-master/console_schema.png
deleted file mode 100755
index ba56c7b..0000000
Binary files a/content/releases/qpid-dispatch-master/console_schema.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/console_topology.png
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/console_topology.png b/content/releases/qpid-dispatch-master/console_topology.png
deleted file mode 100755
index ae4b22a..0000000
Binary files a/content/releases/qpid-dispatch-master/console_topology.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/index.html
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/index.html b/content/releases/qpid-dispatch-master/index.html
index 0f3a57f..ce117cc 100644
--- a/content/releases/qpid-dispatch-master/index.html
+++ b/content/releases/qpid-dispatch-master/index.html
@@ -124,7 +124,7 @@ https://github.com/apache/qpid-proton/blob/go1{/dir}/{file}#L{line}"/>
smoother experience, see the <a href="/releases/qpid-dispatch-1.0.0/index.html">current stable
release</a>.</p>
-<p>This content was generated at 15:51 on Tuesday, 02 May 2017.</p>
+<p>This content was generated at 11:21 on Tuesday, 28 November 2017.</p>
</div>
@@ -133,8 +133,9 @@ release</a>.</p>
<div class="two-column">
<ul>
-<li><a href="https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;a=blob_plain;f=README;hb=master">Installing Qpid Dispatch</a></li>
-<li><a href="book/book.html">Dispatch Router User Guide</a></li>
+<li><a href="user-guide/index.html">Using Qpid Dispatch</a></li>
+<li><a href="https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;a=blob_plain;f=README;hb=master">Installing Qpid Dispatch from
+source</a></li>
<li><a href="man/qdrouterd.html">qdrouterd</a> - Router daemon</li>
<li><a href="man/qdrouterd.conf.html">qdrouterd.conf</a> - Daemon configuration</li>
<li><a href="man/qdstat.html">qdstat</a> - Get router statistics</li>
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/man/qdmanage.html
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/man/qdmanage.html b/content/releases/qpid-dispatch-master/man/qdmanage.html
index 0a93e1d..f295a91 100644
--- a/content/releases/qpid-dispatch-master/man/qdmanage.html
+++ b/content/releases/qpid-dispatch-master/man/qdmanage.html
@@ -123,10 +123,11 @@ https://github.com/apache/qpid-proton/blob/go1{/dir}/{file}#L{line}"/>
<div class="sect1">
<h2 id="_description">DESCRIPTION</h2>
<div class="sectionbody">
-<div class="paragraph"><p>An AMQP management client for use with qdrouterd. Sends AMQP management
-operations requests and prints the response in JSON format. This is a
-generic AMQP management tool and can be used with any standard AMQP
-managed endpoint, not just with qdrouter.</p></div>
+<div class="paragraph"><p>An AMQP management client for use with the Dispatch router daemon
+(<em>qdrouterd</em>). Sends AMQP management operations requests and prints
+the response in JSON format. This is a generic AMQP management tool
+and can be used with any standard AMQP managed endpoint, not just
+with <em>qdrouterd</em>.</p></div>
</div>
</div>
<div class="sect1">
@@ -143,17 +144,17 @@ managed endpoint, not just with qdrouter.</p></div>
<div class="paragraph"><p>--identity=ID
: Identity of entity to operate on.</p></div>
<div class="paragraph"><p>--indent=INDENT
-: Pretty-printing indent. -1 means don’t pretty-print</p></div>
+: Pretty-printing indent. -1 means don’t pretty-print (default 2)</p></div>
<div class="paragraph"><p>--stdin
-: Read attributes as JSON map or list of maps from</p></div>
+: Read attributes as JSON map or list of maps from stdin.</p></div>
<div class="paragraph"><p>--body=BODY
-: JSON value to use as body of a non-standard operation</p></div>
+: JSON value to use as body of a non-standard operation call.</p></div>
<div class="paragraph"><p>--properties=PROPERTIES
: JSON map to use as properties for a non-standard operation call.</p></div>
<div class="sect2">
<h3 id="_connection_options">Connection Options</h3>
<div class="paragraph"><p>-b URL, --bus=URL
-: URL of the messaging bus to connect to (default</p></div>
+: URL of the messaging bus to connect to (default 0.0.0.0)</p></div>
<div class="paragraph"><p>-r ROUTER-ID, --router=ROUTER-ID
: Router to be queried</p></div>
<div class="paragraph"><p>-t SECS, --timeout=SECS
@@ -212,7 +213,7 @@ managed endpoint, not just with qdrouter.</p></div>
</dt>
<dd>
<p>
- Print all the attributes of a single entity, specified by the --name or
+ Print all of the attributes of a single entity, specified by the --name or
--identity options.
</p>
</dd>
@@ -240,7 +241,7 @@ managed endpoint, not just with qdrouter.</p></div>
</dt>
<dd>
<p>
- List entity types with their base types. With no arguments list all
+ List entity types with their base types. With no arguments, list all
types.
</p>
</dd>
@@ -249,7 +250,7 @@ managed endpoint, not just with qdrouter.</p></div>
</dt>
<dd>
<p>
- List entity types with their operations. With no arguments list all
+ List entity types with their operations. With no arguments, list all
types.
</p>
</dd>
@@ -258,7 +259,7 @@ managed endpoint, not just with qdrouter.</p></div>
</dt>
<dd>
<p>
- List entity types with their attributes. With no arguments list all
+ List entity types with their attributes. With no arguments, list all
types.
</p>
</dd>
@@ -267,7 +268,7 @@ managed endpoint, not just with qdrouter.</p></div>
</dt>
<dd>
<p>
- List entity types with their annotations. With no arguments list all
+ List entity types with their annotations. With no arguments, list all
types.
</p>
</dd>
@@ -308,7 +309,7 @@ managed endpoint, not just with qdrouter.</p></div>
</dt>
<dd>
<p>
- Management schema for qdrouterd.
+ Management schema for <em>qdrouterd</em>.
</p>
</dd>
<dt class="hdlist1">
@@ -326,7 +327,7 @@ managed endpoint, not just with qdrouter.</p></div>
<h2 id="_examples">EXAMPLES</h2>
<div class="sectionbody">
<div class="listingblock">
-<div class="title">Show the logging configuration</div>
+<div class="title">Show the logging configuration:</div>
<div class="content">
<pre><code>qdmanage query --type=log</code></pre>
</div></div>
@@ -336,17 +337,17 @@ managed endpoint, not just with qdrouter.</p></div>
<pre><code>qdmanage update name=log/DEFAULT enable=debug+</code></pre>
</div></div>
<div class="listingblock">
-<div class="title">Enable trace log messages only for the MESSAGE module and direct MESSAGE logs to the file "test.log"</div>
+<div class="title">Enable trace log messages only for the MESSAGE module, and direct MESSAGE logs to the file <em>test.log</em>:</div>
<div class="content">
<pre><code>qdmanage update name=log/MESSAGE enable=trace output=test.log</code></pre>
</div></div>
<div class="listingblock">
-<div class="title">Set MESSAGE logging back to the default</div>
+<div class="title">Set MESSAGE logging back to the default:</div>
<div class="content">
<pre><code>qdmanage update name=log/MESSAGE enable=default</code></pre>
</div></div>
<div class="listingblock">
-<div class="title">Disable MESSAGE logging</div>
+<div class="title">Disable MESSAGE logging:</div>
<div class="content">
<pre><code>qdmanage update name=log/MESSAGE enable=none</code></pre>
</div></div>
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/man/qdrouterd.conf.html
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/man/qdrouterd.conf.html b/content/releases/qpid-dispatch-master/man/qdrouterd.conf.html
index 0332aaa..aa4dc83 100644
--- a/content/releases/qpid-dispatch-master/man/qdrouterd.conf.html
+++ b/content/releases/qpid-dispatch-master/man/qdrouterd.conf.html
@@ -196,7 +196,7 @@ listener {
</dt>
<dd>
<p>
- Router’s unique identity. One of id or routerId is required. The router will fail to start without id or routerId
+ Router’s unique identity. The router will fail to start without id.
</p>
</dd>
<dt class="hdlist1">
@@ -288,19 +288,11 @@ listener {
</p>
</dd>
<dt class="hdlist1">
-<em>routerId</em> (string)
+<em>defaultDistribution</em> (One of [<em>multicast</em>, <em>closest</em>, <em>balanced</em>, <em>unavailable</em>], default=<em>balanced</em>)
</dt>
<dd>
<p>
- (DEPRECATED) Router’s unique identity. This attribute has been deprecated. Use id instead
-</p>
-</dd>
-<dt class="hdlist1">
-<em>mobileAddrMaxAge</em> (integer, default=<em>60</em>)
-</dt>
-<dd>
-<p>
- (DEPRECATED) This value is no longer used in the router.
+ Default forwarding treatment for any address without a specified treatment. multicast - one copy of each message delivered to all subscribers; closest - messages delivered to only the closest subscriber; balanced - messages delivered to one subscriber with load balanced across subscribers; unavailable - this address is unavailable, link attaches to an address of unavilable distribution will be rejected.
</p>
</dd>
</dl></div>
@@ -310,6 +302,14 @@ listener {
<div class="paragraph"><p>Attributes for setting TLS/SSL configuration for connections.</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
+<em>ciphers</em> (string)
+</dt>
+<dd>
+<p>
+ Specifies the enabled ciphers so the SSL Ciphers can be hardened. In other words, use this field to disable weak ciphers. The ciphers are specified in the format understood by the OpenSSL library. For example, ciphers can be set to ALL:!aNULL:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP; — The full list of allowed ciphers can be viewed using the openssl ciphers command
+</p>
+</dd>
+<dt class="hdlist1">
<em>certDb</em> (path)
</dt>
<dd>
@@ -368,6 +368,36 @@ listener {
</dl></div>
</div>
<div class="sect2">
+<h3 id="_authserviceplugin">authServicePlugin</h3>
+<div class="paragraph"><p>EXPERIMENTAL. Attributes for setting SASL plugin.</p></div>
+<div class="dlist"><dl>
+<dt class="hdlist1">
+<em>authService</em> (string, required)
+</dt>
+<dd>
+<p>
+ Address of a service to delegate authentication to.
+</p>
+</dd>
+<dt class="hdlist1">
+<em>saslInitHostname</em> (string)
+</dt>
+<dd>
+<p>
+ Value to set for hostname field on sasl-init
+</p>
+</dd>
+<dt class="hdlist1">
+<em>authSslProfile</em> (string)
+</dt>
+<dd>
+<p>
+ Name of the sslProfile to use for the authentication service.
+</p>
+</dd>
+</dl></div>
+</div>
+<div class="sect2">
<h3 id="_listener">listener</h3>
<div class="paragraph"><p>Listens for incoming connections to the router.</p></div>
<div class="dlist"><dl>
@@ -396,11 +426,11 @@ listener {
</p>
</dd>
<dt class="hdlist1">
-<em>role</em> (One of [<em>normal</em>, <em>inter-router</em>, <em>route-container</em>, <em>on-demand</em>], default=<em>normal</em>)
+<em>role</em> (One of [<em>normal</em>, <em>inter-router</em>, <em>route-container</em>], default=<em>normal</em>)
</dt>
<dd>
<p>
- The role of an established connection. In the normal role, the connection is assumed to be used for AMQP clients that are doing normal message delivery over the connection. In the inter-router role, the connection is assumed to be to another router in the network. Inter-router discovery and routing protocols can only be used over inter-router connections. route-container role can be used for router-container connections, for example, a router-broker connection. on-demand role has been deprecated.
+ The role of an established connection. In the normal role, the connection is assumed to be used for AMQP clients that are doing normal message delivery over the connection. In the inter-router role, the connection is assumed to be to another router in the network. Inter-router discovery and routing protocols can only be used over inter-router connections. route-container role can be used for router-container connections, for example, a router-broker connection.
</p>
</dd>
<dt class="hdlist1">
@@ -436,6 +466,14 @@ listener {
</p>
</dd>
<dt class="hdlist1">
+<em>saslPlugin</em> (string)
+</dt>
+<dd>
+<p>
+ EXPERIMENTAL. Name of the a sasl plugin configuration section to use for this listener (e.g. authServicePlugin).
+</p>
+</dd>
+<dt class="hdlist1">
<em>requireEncryption</em> (boolean)
</dt>
<dd>
@@ -492,6 +530,14 @@ listener {
</p>
</dd>
<dt class="hdlist1">
+<em>initialHandshakeTimeoutSeconds</em> (integer)
+</dt>
+<dd>
+<p>
+ The timeout, in seconds, for the initial handshake for connections coming in through listeners. If the time interval expires before the peer sends the AMQP OPEN frame, the connection shall be closed. A value of zero (the default) disables this timeout.
+</p>
+</dd>
+<dt class="hdlist1">
<em>stripAnnotations</em> (One of [<em>in</em>, <em>out</em>, <em>both</em>, <em>no</em>], default=<em>both</em>)
</dt>
<dd>
@@ -524,43 +570,11 @@ listener {
</p>
</dd>
<dt class="hdlist1">
-<em>addr</em> (string, default=<em>127.0.0.1</em>)
-</dt>
-<dd>
-<p>
- (DEPRECATED)IP address: ipv4 or ipv6 literal or a host name. This attribute has been deprecated. Use host instead
-</p>
-</dd>
-<dt class="hdlist1">
-<em>allowNoSasl</em> (boolean)
-</dt>
-<dd>
-<p>
- (DEPRECATED) This attribute is now controlled by the authenticatePeer attribute.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>requirePeerAuth</em> (boolean)
-</dt>
-<dd>
-<p>
- (DEPRECATED) This attribute is now controlled by the authenticatePeer attribute.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>allowUnsecured</em> (boolean)
-</dt>
-<dd>
-<p>
- (DEPRECATED) This attribute is now controlled by the requireEncryption attribute.
-</p>
-</dd>
-<dt class="hdlist1">
<em>http</em> (boolean)
</dt>
<dd>
<p>
- Accept HTTP connections that can upgrade to AMQP over WebSocket
+ Accept HTTP connections that can upgrade to AMQP over WebSocket. Plain AMQP connections are not accepted on this listener.
</p>
</dd>
<dt class="hdlist1">
@@ -610,11 +624,11 @@ listener {
</p>
</dd>
<dt class="hdlist1">
-<em>role</em> (One of [<em>normal</em>, <em>inter-router</em>, <em>route-container</em>, <em>on-demand</em>], default=<em>normal</em>)
+<em>role</em> (One of [<em>normal</em>, <em>inter-router</em>, <em>route-container</em>], default=<em>normal</em>)
</dt>
<dd>
<p>
- The role of an established connection. In the normal role, the connection is assumed to be used for AMQP clients that are doing normal message delivery over the connection. In the inter-router role, the connection is assumed to be to another router in the network. Inter-router discovery and routing protocols can only be used over inter-router connections. route-container role can be used for router-container connections, for example, a router-broker connection. on-demand role has been deprecated.
+ The role of an established connection. In the normal role, the connection is assumed to be used for AMQP clients that are doing normal message delivery over the connection. In the inter-router role, the connection is assumed to be to another router in the network. Inter-router discovery and routing protocols can only be used over inter-router connections. route-container role can be used for router-container connections, for example, a router-broker connection.
</p>
</dd>
<dt class="hdlist1">
@@ -722,19 +736,11 @@ listener {
</p>
</dd>
<dt class="hdlist1">
-<em>addr</em> (string, default=<em>127.0.0.1</em>)
-</dt>
-<dd>
-<p>
- (DEPRECATED)IP address: ipv4 or ipv6 literal or a host name. This attribute has been deprecated. Use host instead
-</p>
-</dd>
-<dt class="hdlist1">
<em>logMessage</em> (string, default=<em>none</em>)
</dt>
<dd>
<p>
- A comma separated list that indicates which components of the message should be logged. Defaults to <em>none</em> (log nothing). If you want all properties and application properties of the message logged use <em>all</em>. Specific components of the message can be logged by indicating the components via a comma separated list. The components are message-id, user-id, to, subject, reply-to, correlation-id, content-type, content-encoding, absolute-expiry-time, creation-time, group-id, group-sequence, reply-to-group-id, app-properties. The application-data part of the bare message will not be logged. No spaces are allowed
+ A comma separated list that indicates which components of the message should be logged (no spaces allowed between list components). Defaults to <em>none</em> (log nothing). If you want all properties and application properties of the message logged use <em>all</em>. Specific components of the message can be logged by indicating the components via a comma separated list. The components are message-id, user-id, to, subject, reply-to, correlation-id, content-type, content-encoding, absolute-expiry-time, creation-time, group-id, group-sequence, reply-to-group-id, app-properties. The application-data part of the bare message will not be logged. This log message is written to the MESSAGE logging module. In the <em>log</em> entity, set <em>module</em> property to MESSAGE or DEFAULT and <em>enable</em> to trace+ to see this log message
</p>
</dd>
</dl></div>
@@ -790,15 +796,23 @@ listener {
<div class="paragraph"><p>Entity type for address configuration. This is used to configure the treatment of message-routed deliveries within a particular address-space. The configuration controls distribution and address phasing.</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
-<em>prefix</em> (string, required)
+<em>prefix</em> (string)
+</dt>
+<dd>
+<p>
+ The address prefix for the configured settings. Cannot be used with a pattern attribute.
+</p>
+</dd>
+<dt class="hdlist1">
+<em>pattern</em> (string)
</dt>
<dd>
<p>
- The address prefix for the configured settings
+ A wildcarded pattern for address matching. Incoming addresses are matched against this pattern. Matching addresses use the configured settings. The pattern consists of one or more tokens separated by a forward slash <em>/</em>. A token can be one of the following: a * character, a # character, or a sequence of characters that do not include /, *, or #. The * token matches any single token. The # token matches zero or more tokens. * has higher precedence than #, and exact match has the highest precedence. Cannot be used with a prefix attribute.
</p>
</dd>
<dt class="hdlist1">
-<em>distribution</em> (One of [<em>multicast</em>, <em>closest</em>, <em>balanced</em>], default=<em>balanced</em>)
+<em>distribution</em> (One of [<em>multicast</em>, <em>closest</em>, <em>balanced</em>, <em>unavailable</em>], default=<em>balanced</em>)
</dt>
<dd>
<p>
@@ -833,14 +847,22 @@ listener {
</div>
<div class="sect2">
<h3 id="_linkroute">linkRoute</h3>
-<div class="paragraph"><p>Entity type for link-route configuration. This is used to identify remote containers that shall be destinations for routed link-attaches. The link-routing configuration applies to an addressing space defined by a prefix.</p></div>
+<div class="paragraph"><p>Entity type for link-route configuration. This is used to identify remote containers that shall be destinations for routed link-attaches. The link-routing configuration applies to an addressing space defined by a prefix or a pattern.</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
-<em>prefix</em> (string, required)
+<em>prefix</em> (string)
</dt>
<dd>
<p>
- The address prefix for the configured settings
+ The address prefix for the configured settings. Cannot be used with the pattern attribute.
+</p>
+</dd>
+<dt class="hdlist1">
+<em>pattern</em> (string)
+</dt>
+<dd>
+<p>
+ A wildcarded pattern for address matching. Link addresses are matched against this pattern. Matching addresses use the configured settings. The pattern consists of one or more tokens separated by a forward slash <em>/</em>. A token can be one of the following: a * character, a # character, or a sequence of characters that do not include /, *, or #. The * token matches any single token. The # token matches zero or more tokens. * has higher precedence than #, and exact match has the highest precedence. Cannot be used with the prefix attribute.
</p>
</dd>
<dt class="hdlist1">
@@ -933,7 +955,7 @@ listener {
</div>
<div class="sect2">
<h3 id="_console">console</h3>
-<div class="paragraph"><p>Start a websocket/tcp proxy and http file server to serve the web console</p></div>
+<div class="paragraph"><p>(DEPRECATED) Start a websocket/tcp proxy and http file server to serve the web console</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
<em>listener</em> (string)
@@ -952,7 +974,7 @@ listener {
</p>
</dd>
<dt class="hdlist1">
-<em>proxy</em> (string)
+<em>proxy</em> (string, required)
</dt>
<dd>
<p>
@@ -960,7 +982,7 @@ listener {
</p>
</dd>
<dt class="hdlist1">
-<em>home</em> (string)
+<em>home</em> (string, required)
</dt>
<dd>
<p>
@@ -1069,158 +1091,6 @@ listener {
</dd>
</dl></div>
</div>
-<div class="sect2">
-<h3 id="_container">container</h3>
-<div class="paragraph"><p>(DEPRECATED)Attributes related to the AMQP container. This entity has been deprecated. Use the router entity instead.</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>containerName</em> (string)
-</dt>
-<dd>
-<p>
- The name of the AMQP container. If not specified, the container name will be set to a value of the container’s choosing. The automatically assigned container name is not guaranteed to be persistent across restarts of the container.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>workerThreads</em> (integer, default=<em>4</em>)
-</dt>
-<dd>
-<p>
- The number of threads that will be created to process message traffic and other application work (timers, non-amqp file descriptors, etc.) .
-</p>
-</dd>
-<dt class="hdlist1">
-<em>debugDump</em> (path)
-</dt>
-<dd>
-<p>
- A file to dump debugging information that can’t be logged normally.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>saslConfigPath</em> (path)
-</dt>
-<dd>
-<p>
- Absolute path to the SASL configuration file.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>saslConfigName</em> (string)
-</dt>
-<dd>
-<p>
- Name of the SASL configuration. This string + <em>.conf</em> is the name of the configuration file.
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_waypoint">waypoint</h3>
-<div class="paragraph"><p>(DEPRECATED) A remote node that messages for an address pass through. This entity has been deprecated. Use autoLink instead</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>address</em> (string, required)
-</dt>
-<dd>
-<p>
- The AMQP address of the waypoint.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>connector</em> (string, required)
-</dt>
-<dd>
-<p>
- The name of the on-demand connector used to reach the waypoint’s container.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>inPhase</em> (integer, default=<em>-1</em>)
-</dt>
-<dd>
-<p>
- The phase of the address as it is routed <em>to</em> the waypoint.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>outPhase</em> (integer, default=<em>-1</em>)
-</dt>
-<dd>
-<p>
- The phase of the address as it is routed <em>from</em> the waypoint.
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_fixedaddress">fixedAddress</h3>
-<div class="paragraph"><p>(DEPRECATED) Establishes treatment for addresses starting with a prefix. This entity has been deprecated. Use address instead</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>prefix</em> (string, required)
-</dt>
-<dd>
-<p>
- The address prefix (always starting with <em>/</em>).
-</p>
-</dd>
-<dt class="hdlist1">
-<em>phase</em> (integer)
-</dt>
-<dd>
-<p>
- The phase of a multi-hop address passing through one or more waypoints.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>fanout</em> (One of [<em>multiple</em>, <em>single</em>], default=<em>multiple</em>)
-</dt>
-<dd>
-<p>
- One of <em>multiple</em> or <em>single</em>. Multiple fanout is a non-competing pattern. If there are multiple consumers using the same address, each consumer will receive its own copy of every message sent to the address. Single fanout is a competing pattern where each message is sent to only one consumer.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>bias</em> (One of [<em>closest</em>, <em>spread</em>], default=<em>closest</em>)
-</dt>
-<dd>
-<p>
- Only if fanout is single. One of <em>closest</em> or <em>spread</em>. Closest bias means that messages to an address will always be delivered to the closest (lowest cost) subscribed consumer. Spread bias will distribute the messages across subscribers in an approximately even manner.
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_linkroutepattern">linkRoutePattern</h3>
-<div class="paragraph"><p>(DEPRECATED) An address pattern to match against link sources and targets to cause the router to link-route the attach across the network to a remote node. This entity has been deprecated. Use linkRoute instead</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>prefix</em> (string, required)
-</dt>
-<dd>
-<p>
- An address prefix to match against target and source addresses. This pattern must be of the form <em><text>.<text1>.<textN></em> or <em><text></em> or <em><text>.</em> and matches any address that contains that prefix. For example, if the prefix is set to org.apache (or org.apache.), any address that has the prefix <em>org.apache</em> (like org.apache.dev) will match. Note that a prefix must not start with a (.), can end in a (.) and can contain zero or more dots (.). Any characters between the dots are simply treated as part of the address
-</p>
-</dd>
-<dt class="hdlist1">
-<em>dir</em> (One of [<em>in</em>, <em>out</em>, <em>both</em>], default=<em>both</em>)
-</dt>
-<dd>
-<p>
- Link direction for match: <em>in</em> matches only links inbound to the client; <em>out</em> matches only links outbound from the client; <em>both</em> matches any link.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>connector</em> (string)
-</dt>
-<dd>
-<p>
- The name of the on-demand connector used to reach the target node’s container. If this value is not provided, it means that the target container is expected to be connected to a different router in the network. This prevents links to a link-routable address from being misinterpreted as message-routing links when there is no route to a valid destination available.
-</p>
-</dd>
-</dl></div>
-</div>
</div>
</div>
<div class="sect1">
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/man/qdrouterd.html
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/man/qdrouterd.html b/content/releases/qpid-dispatch-master/man/qdrouterd.html
index d83cea2..ed74a86 100644
--- a/content/releases/qpid-dispatch-master/man/qdrouterd.html
+++ b/content/releases/qpid-dispatch-master/man/qdrouterd.html
@@ -123,7 +123,7 @@ https://github.com/apache/qpid-proton/blob/go1{/dir}/{file}#L{line}"/>
<div class="sect1">
<h2 id="_description">DESCRIPTION</h2>
<div class="sectionbody">
-<div class="paragraph"><p>The Qpid Dispatch router (qdrouterd) is a network daemon that directs
+<div class="paragraph"><p>The Qpid Dispatch router (<em>qdrouterd</em>) is a network daemon that directs
AMQP 1.0 messages between endpoints, such as messaging clients and
servers.</p></div>
</div>
@@ -156,7 +156,7 @@ servers.</p></div>
</dt>
<dd>
<p>
- Configuration flie.
+ Configuration file.
</p>
</dd>
</dl></div>
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/man/qdstat.html
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/man/qdstat.html b/content/releases/qpid-dispatch-master/man/qdstat.html
index fb015a2..73315a8 100644
--- a/content/releases/qpid-dispatch-master/man/qdstat.html
+++ b/content/releases/qpid-dispatch-master/man/qdstat.html
@@ -123,8 +123,7 @@ https://github.com/apache/qpid-proton/blob/go1{/dir}/{file}#L{line}"/>
<div class="sect1">
<h2 id="_description">DESCRIPTION</h2>
<div class="sectionbody">
-<div class="paragraph"><p>Shows status information about networks of Dispatch routers. It can display
-connections, network nodes and links, and router stats such as memory use.</p></div>
+<div class="paragraph"><p>An AMQP monitoring tool that shows status information about networks of Dispatch routers. It can display connections, network nodes and links, and router stats such as memory use.</p></div>
</div>
</div>
<div class="sect1">
@@ -159,7 +158,7 @@ connections, network nodes and links, and router stats such as memory use.</p></
<div class="sect2">
<h3 id="_connection_options">Connection Options</h3>
<div class="paragraph"><p>-b URL, --bus=URL
-: URL of the messaging bus to connect to (default</p></div>
+: URL of the messaging bus to connect to (default 0.0.0.0)</p></div>
<div class="paragraph"><p>-r ROUTER-ID, --router=ROUTER-ID
: Router to be queried</p></div>
<div class="paragraph"><p>-t SECS, --timeout=SECS
@@ -198,7 +197,7 @@ id
</dt>
<dd>
<p>
-Unique connection identifier
+The connection’s unique identifier.
</p>
</dd>
<dt class="hdlist1">
@@ -206,7 +205,7 @@ host
</dt>
<dd>
<p>
-The hostname or internet address of the remotely connected AMQP container
+The hostname or internet address of the remotely-connected AMQP container.
</p>
</dd>
<dt class="hdlist1">
@@ -214,7 +213,7 @@ container
</dt>
<dd>
<p>
-The container-name of the remotely connected AMQP container
+The container name of the remotely-connected AMQP container.
</p>
</dd>
<dt class="hdlist1">
@@ -222,22 +221,22 @@ role
</dt>
<dd>
<p>
-The configured role of the connection
+The connection’s role:
</p>
<div class="ulist"><ul>
<li>
<p>
-normal - Normal connections from client to router
+<em>normal</em> - The normal connection from a client to a router.
</p>
</li>
<li>
<p>
-inter-router - Connection between routers to form a network
+<em>inter-router</em> - The connection between routers to form a network.
</p>
</li>
<li>
<p>
-route-container - Connection to/from a Broker or other host to receive link-routes and waypoints
+<em>route-container</em> - The connection to or from a broker or other host to receive link routes and waypoints.
</p>
</li>
</ul></div>
@@ -247,17 +246,17 @@ dir
</dt>
<dd>
<p>
-The direction of connection establishment
+The direction in which the connection was established:
</p>
<div class="ulist"><ul>
<li>
<p>
-in - The connection was initiated by the remote container
+<em>in</em> - The connection was initiated by the remote container.
</p>
</li>
<li>
<p>
-out - The connection was initiated by this router
+<em>out</em> - The connection was initiated by this router.
</p>
</li>
</ul></div>
@@ -267,8 +266,7 @@ security
</dt>
<dd>
<p>
-A description of the security/encryption in effect for this
-connection
+The security or encryption method, if any, used for this connection.
</p>
</dd>
<dt class="hdlist1">
@@ -276,8 +274,7 @@ authentication
</dt>
<dd>
<p>
-The method and user-id of the authenticated user for
-this connection
+The authentication method and user ID of the connection’s authenticated user.
</p>
</dd>
</dl></div>
@@ -290,22 +287,22 @@ type
</dt>
<dd>
<p>
-Type of link
+The type of link:
</p>
<div class="ulist"><ul>
<li>
<p>
-router-control - An inter-router link that is reserved for control messages exchanged between routers
+<em>router-control</em> - An inter-router link that is reserved for control messages exchanged between routers.
</p>
</li>
<li>
<p>
-inter-router - An inter-router link that is used for normal message-routed deliveries
+<em>inter-router</em> - An inter-router link that is used for normal message-routed deliveries.
</p>
</li>
<li>
<p>
-endpoint - A normal link to an external endpoint container
+<em>endpoint</em> - A normal link to an external endpoint container.
</p>
</li>
</ul></div>
@@ -315,17 +312,17 @@ dir
</dt>
<dd>
<p>
-The direction of message flow on the link
+The direction that messages flow on the link:
</p>
<div class="ulist"><ul>
<li>
<p>
-in - Deliveries flow inbound to the router
+<em>in</em> - Deliveries flow inbound to the router.
</p>
</li>
<li>
<p>
-out - Deliveries flow outbound from the router
+<em>out</em> - Deliveries flow outbound from the router.
</p>
</li>
</ul></div>
@@ -335,8 +332,8 @@ conn id
</dt>
<dd>
<p>
-Unique identifier of the connection over which this link is
-attached
+The unique identifier of the connection over which this link is
+attached.
</p>
</dd>
<dt class="hdlist1">
@@ -344,7 +341,7 @@ id
</dt>
<dd>
<p>
-Unique identifier of this link
+The unique identifier of this link.
</p>
</dd>
<dt class="hdlist1">
@@ -353,7 +350,7 @@ peer
<dd>
<p>
For link-routed links, the unique identifier of the peer link. In
-link routing, an inbound link is paired with an outbound link
+link routing, an inbound link is paired with an outbound link.
</p>
</dd>
<dt class="hdlist1">
@@ -361,15 +358,47 @@ class
</dt>
<dd>
<p>
-Class of the address bound to the link
+The class of the address bound to the link:
</p>
+<div class="ulist"><ul>
+<li>
+<p>
+<em>local</em> - The address that is local to this router (temporary).
+</p>
+</li>
+<li>
+<p>
+<em>topo</em> - A topological address used for router control messages.
+</p>
+</li>
+<li>
+<p>
+<em>router</em> - A summary router address used to route messages to a remote router’s local addresses.
+</p>
+</li>
+<li>
+<p>
+<em>mobile</em> - A mobile address for an attached consumer or producer.
+</p>
+</li>
+<li>
+<p>
+<em>link-in</em> - The address match for incoming routed links.
+</p>
+</li>
+<li>
+<p>
+<em>link-out</em> - The address match for outgoing routed links.
+</p>
+</li>
+</ul></div>
</dd>
<dt class="hdlist1">
addr
</dt>
<dd>
<p>
-The address bound to the link
+The address bound to the link.
</p>
</dd>
<dt class="hdlist1">
@@ -377,7 +406,7 @@ phs
</dt>
<dd>
<p>
-The phase of the address bound to the link
+The phase of the address bound to the link.
</p>
</dd>
<dt class="hdlist1">
@@ -385,7 +414,7 @@ cap
</dt>
<dd>
<p>
-The capacity, in deliveries, of the link
+The capacity, in deliveries, of the link.
</p>
</dd>
<dt class="hdlist1">
@@ -393,7 +422,7 @@ undel
</dt>
<dd>
<p>
-The number of undelivered messages stored on the link’s FIFO
+The number of undelivered messages stored on the link’s FIFO.
</p>
</dd>
<dt class="hdlist1">
@@ -401,7 +430,7 @@ unsett
</dt>
<dd>
<p>
-The number of unsettled deliveries being tracked by the link
+The number of unsettled deliveries being tracked by the link.
</p>
</dd>
<dt class="hdlist1">
@@ -409,37 +438,65 @@ del
</dt>
<dd>
<p>
-The total number of deliveries that have transited this link
+The total number of deliveries that have transited this link.
+</p>
+</dd>
+<dt class="hdlist1">
+presett
+</dt>
+<dd>
+<p>
+The number of pre-settled deliveries that transited this link.
+</p>
+</dd>
+<dt class="hdlist1">
+acc
+</dt>
+<dd>
+<p>
+The number of deliveries on this link that were accepted.
+</p>
+</dd>
+<dt class="hdlist1">
+rej
+</dt>
+<dd>
+<p>
+The number of deliveries on this link that were rejected.
+</p>
+</dd>
+<dt class="hdlist1">
+rel
+</dt>
+<dd>
+<p>
+The number of deliveries on this link that were released.
+</p>
+</dd>
+<dt class="hdlist1">
+mod
+</dt>
+<dd>
+<p>
+The number of deliveries on this link that were modified.
</p>
</dd>
-</dl></div>
-<div class="paragraph"><p>presett:
-The number of pre-settled deliveries that transited this link</p></div>
-<div class="paragraph"><p>acc:
-The number of deliveries on this link that were accepted</p></div>
-<div class="paragraph"><p>rej:
-The number of deliveries on this link that were rejected</p></div>
-<div class="paragraph"><p>rel:
-The number of deliveries on this link that were released</p></div>
-<div class="paragraph"><p>mod:
-The number of deliveries on this link that were modified</p></div>
-<div class="dlist"><dl>
<dt class="hdlist1">
admin
</dt>
<dd>
<p>
-The administrative status of the link
+The administrative status of the link:
</p>
<div class="ulist"><ul>
<li>
<p>
-enabled - The link is enabled for normal operation
+<em>enabled</em> - The link is enabled for normal operation.
</p>
</li>
<li>
<p>
-disabled - The link is disabled and should be quiescing or stopped (not yet supported)
+<em>disabled</em> - The link is disabled and should be quiescing or stopped (not yet supported).
</p>
</li>
</ul></div>
@@ -449,27 +506,27 @@ oper
</dt>
<dd>
<p>
-The operational status of the link
+The operational status of the link:
</p>
<div class="ulist"><ul>
<li>
<p>
-up - The link is operational
+<em>up</em> - The link is operational.
</p>
</li>
<li>
<p>
-down - The link is not attached
+<em>down</em> - The link is not attached.
</p>
</li>
<li>
<p>
-quiescing - The link is in the process of quiescing (not yet supported)
+<em>quiescing</em> - The link is in the process of quiescing (not yet supported).
</p>
</li>
<li>
<p>
-idle - The link has completed quiescing and is idle (not yet supported)
+<em>idle</em> - The link has completed quiescing and is idle (not yet supported).
</p>
</li>
</ul></div>
@@ -479,7 +536,7 @@ name
</dt>
<dd>
<p>
-The link name (only shown if the -v option is provided)
+The link name (only shown if the -v option is provided).
</p>
</dd>
</dl></div>
@@ -491,7 +548,7 @@ router-id
</dt>
<dd>
<p>
-Identifier of the router
+The router’s ID.
</p>
</dd>
<dt class="hdlist1">
@@ -499,7 +556,7 @@ next-hop
</dt>
<dd>
<p>
-If this router is not a neighbor, identifies the next-hop neighbor used to reach this router
+If this router is not a neighbor, this field identifies the next-hop neighbor used to reach this router.
</p>
</dd>
<dt class="hdlist1">
@@ -507,7 +564,7 @@ link
</dt>
<dd>
<p>
-Unique identifier of the link to the neighbor router
+The ID of the link to the neighbor router.
</p>
</dd>
<dt class="hdlist1">
@@ -515,7 +572,7 @@ cost
</dt>
<dd>
<p>
-The topology cost to this remote router (with -v option only)
+The topology cost to this remote router (with -v option only).
</p>
</dd>
<dt class="hdlist1">
@@ -523,7 +580,7 @@ neighbors
</dt>
<dd>
<p>
-The list of neighbor routers (the router’s link-state) (with -v option only)
+The list of neighbor routers (the router’s link-state). This field is available only if you specify the -v option.
</p>
</dd>
<dt class="hdlist1">
@@ -531,7 +588,7 @@ valid-origins
</dt>
<dd>
<p>
-The list of origin routers for which the best path to the listed router passes through this router (with -v option only)
+The list of origin routers for which the best path to the listed router passes through this router (available only with the -v option).
</p>
</dd>
</dl></div>
@@ -545,27 +602,27 @@ class
</dt>
<dd>
<p>
-The class of the listed address
+The class of the address:
</p>
<div class="ulist"><ul>
<li>
<p>
-local - Address that is local to this router
+<em>local</em> - The address that is local to this router.
</p>
</li>
<li>
<p>
-topo - Topological address used for router control messages
+<em>topo</em> - The topological address used for router control messages.
</p>
</li>
<li>
<p>
-router - A summary router address used to route messages to a remote router’s local addresses
+<em>router</em> - A summary router address used to route messages to a remote router’s local addresses.
</p>
</li>
<li>
<p>
-mobile - A mobile address for an attached consumer or producer
+<em>mobile</em> - A mobile address for an attached consumer or producer.
</p>
</li>
</ul></div>
@@ -575,7 +632,7 @@ addr
</dt>
<dd>
<p>
-The address text
+The address text.
</p>
</dd>
<dt class="hdlist1">
@@ -591,27 +648,27 @@ distrib
</dt>
<dd>
<p>
-Distribution method used for this address
+One of the following distribution methods used for this address:
</p>
<div class="ulist"><ul>
<li>
<p>
-multicast - A copy of each message is delivered once to each consumer for the address
+<em>multicast</em> - A copy of each message is delivered once to each consumer for the address.
</p>
</li>
<li>
<p>
-closest - Each message is delivered to only one consumer for the address. The closest (lowest cost) consumer will be chosen. If there are multiple lowest-cost consumers, deliveries will be spread across those consumers.
+<em>closest</em> - Each message is delivered to only one consumer for the address. The closest (lowest cost) consumer will be chosen. If there are multiple lowest-cost consumers, deliveries will be spread across those consumers.
</p>
</li>
<li>
<p>
-balanced - Each message is delivered to only one consumer for the address. The consumer with the fewest outstanding (unsettled) deliveries will be chosen. The cost of the route to the consumer is a threshold for delivery (i.e. higher cost consumers will only receive deliveries if closer consumers are backed up).
+<em>balanced</em> - Each message is delivered to only one consumer for the address. The consumer with the fewest outstanding (unsettled) deliveries will be chosen. The cost of the route to the consumer is a threshold for delivery (that is, higher cost consumers will only receive deliveries if closer consumers are backed up).
</p>
</li>
<li>
<p>
-flood - Used only for router-control traffic. This is multicast without prevention of duplicate deliveries.
+<em>flood</em> - Used only for router-control traffic. This is multicast without the prevention of duplicate deliveries.
</p>
</li>
</ul></div>
@@ -621,7 +678,7 @@ in-proc
</dt>
<dd>
<p>
-The number of in-process consumers for this address
+The number of in-process consumers for this address.
</p>
</dd>
<dt class="hdlist1">
@@ -629,7 +686,7 @@ local
</dt>
<dd>
<p>
-The number of local (on this router) consumers for this address
+For this router, the number of local consumers for this address.
</p>
</dd>
<dt class="hdlist1">
@@ -637,7 +694,7 @@ remote
</dt>
<dd>
<p>
-The number of remote routers that have at least one consumer for this address
+The number of remote routers that have at least one consumer for this address.
</p>
</dd>
<dt class="hdlist1">
@@ -645,7 +702,7 @@ cntnr
</dt>
<dd>
<p>
-The number of locally attached containers that are destinations for link-routes on this address
+The number of locally-attached containers that are destinations for link routes on this address.
</p>
</dd>
<dt class="hdlist1">
@@ -653,7 +710,7 @@ in
</dt>
<dd>
<p>
-The number of deliveries for this address that entered the network on this router
+The number of deliveries for this address that entered the network on this router.
</p>
</dd>
<dt class="hdlist1">
@@ -661,7 +718,7 @@ out
</dt>
<dd>
<p>
-The number of deliveries for this address that exited the network on this router
+The number of deliveries for this address that exited the network on this router.
</p>
</dd>
<dt class="hdlist1">
@@ -669,7 +726,7 @@ thru
</dt>
<dd>
<p>
-The number of deliveries for this address that were forwarded to other routers
+The number of deliveries for this address that were forwarded to other routers.
</p>
</dd>
<dt class="hdlist1">
@@ -677,7 +734,7 @@ to-proc
</dt>
<dd>
<p>
-The number of deliveries for this address that were delivered to an in-process consumer
+The number of deliveries for this address that were delivered to an in-process consumer.
</p>
</dd>
<dt class="hdlist1">
@@ -685,7 +742,7 @@ from-proc
</dt>
<dd>
<p>
-The number of deliveries for this address that were received from an in-process producer
+The number of deliveries for this address that were received from an in-process producer.
</p>
</dd>
</dl></div>
@@ -698,7 +755,7 @@ prefix
</dt>
<dd>
<p>
-The prefix for matching addresses of routed links
+The address prefix of the link route.
</p>
</dd>
<dt class="hdlist1">
@@ -706,7 +763,7 @@ dir
</dt>
<dd>
<p>
-The direction (from the router’s perspective) of matching links
+The direction of matching links (from this router’s perspective).
</p>
</dd>
<dt class="hdlist1">
@@ -714,32 +771,25 @@ distrib
</dt>
<dd>
<p>
-The distribution method used for routed links
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-linkBalanced - the only supported distribution for routed links
+The distribution method used for routed links. This value should always be <em>linkBalanced</em>, which is the only supported distribution for routed links.
</p>
-</li>
-</ul></div>
</dd>
<dt class="hdlist1">
status
</dt>
<dd>
<p>
-Operational status of the link route
+The operational status of the link route:
</p>
<div class="ulist"><ul>
<li>
<p>
-active - Route is actively routing attaches (i.e. ready for use)
+<em>active</em> - The route is actively routing attaches (it is ready for use).
</p>
</li>
<li>
<p>
-inactive - Route is inactive because there is no local destination connected
+<em>inactive</em> - The route is inactive, because no local destination is connected.
</p>
</li>
</ul></div>
@@ -754,7 +804,7 @@ addr
</dt>
<dd>
<p>
-The address of the auto link
+The auto link’s address.
</p>
</dd>
<dt class="hdlist1">
@@ -762,17 +812,17 @@ dir
</dt>
<dd>
<p>
-The direction of message flow for the auto link
+The direction that messages flow over the auto link:
</p>
<div class="ulist"><ul>
<li>
<p>
-in - Messages flow in from the route-container to the router network
+<em>in</em> - Messages flow in from the route-container to the router network.
</p>
</li>
<li>
<p>
-out - Messages flow out to the route-container from the router network
+<em>out</em> - Messages flow out to the route-container from the router network.
</p>
</li>
</ul></div>
@@ -782,7 +832,7 @@ phs
</dt>
<dd>
<p>
-Phase of the address for this auto link
+The address phase for this auto link.
</p>
</dd>
<dt class="hdlist1">
@@ -790,7 +840,7 @@ link
</dt>
<dd>
<p>
-Unique identifier of the link managed by this auto link
+The ID of the link managed by this auto link.
</p>
</dd>
<dt class="hdlist1">
@@ -798,37 +848,37 @@ status
</dt>
<dd>
<p>
-The operational status of this auto link
+The operational status of this auto link:
</p>
<div class="ulist"><ul>
<li>
<p>
-inactive - There is no connected container for this auto link
+<em>inactive</em> - There is no connected container for this auto link.
</p>
</li>
<li>
<p>
-attaching - The link is attaching to the container
+<em>attaching</em> - The link is attaching to the container.
</p>
</li>
<li>
<p>
-failed - The link-attach failed
+<em>failed</em> - The link-attach failed.
</p>
</li>
<li>
<p>
-active - The link is operational
+<em>active</em> - The link is operational.
</p>
</li>
<li>
<p>
-quiescing - The link is quiescing (not yet supported)
+<em>quiescing</em> - The link is quiescing (not yet supported).
</p>
</li>
<li>
<p>
-idle - The link is idle (not yet supported)
+<em>idle</em> - The link is idle (not yet supported).
</p>
</li>
</ul></div>
@@ -838,7 +888,7 @@ lastErr
</dt>
<dd>
<p>
-The description of the last attach failure that occurred on this auto link
+The description of the last attach failure that occurred on this auto link.
</p>
</dd>
</dl></div>
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/qdmanage.8.html
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/qdmanage.8.html b/content/releases/qpid-dispatch-master/qdmanage.8.html
deleted file mode 100644
index a83b8b0..0000000
--- a/content/releases/qpid-dispatch-master/qdmanage.8.html
+++ /dev/null
@@ -1,389 +0,0 @@
-<!DOCTYPE html>
-<!--
- -
- - Licensed to the Apache Software Foundation (ASF) under one
- - or more contributor license agreements. See the NOTICE file
- - distributed with this work for additional information
- - regarding copyright ownership. The ASF licenses this file
- - to you under the Apache License, Version 2.0 (the
- - "License"); you may not use this file except in compliance
- - with the License. You may obtain a copy of the License at
- -
- - http://www.apache.org/licenses/LICENSE-2.0
- -
- - Unless required by applicable law or agreed to in writing,
- - software distributed under the License is distributed on an
- - "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- - KIND, either express or implied. See the License for the
- - specific language governing permissions and limitations
- - under the License.
- -
--->
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
- <head>
- <title>SYNOPSIS - Apache Qpid™</title>
- <meta http-equiv="X-UA-Compatible" content="IE=edge"/>
- <meta name="viewport" content="width=device-width, initial-scale=1.0"/>
- <link rel="stylesheet" href="/site.css" type="text/css" async="async"/>
- <link rel="stylesheet" href="/deferred.css" type="text/css" defer="defer"/>
- <script type="text/javascript">var _deferredFunctions = [];</script>
- <script type="text/javascript" src="/deferred.js" defer="defer"></script>
- <!--[if lte IE 8]>
- <link rel="stylesheet" href="/ie.css" type="text/css"/>
- <script type="text/javascript" src="/html5shiv.js"></script>
- <![endif]-->
-
- <!-- Redirects for `go get` and godoc.org -->
- <meta name="go-import"
- content="qpid.apache.org git https://git-wip-us.apache.org/repos/asf/qpid-proton.git"/>
- <meta name="go-source"
- content="qpid.apache.org
-https://github.com/apache/qpid-proton/blob/go1/README.md
-https://github.com/apache/qpid-proton/tree/go1{/dir}
-https://github.com/apache/qpid-proton/blob/go1{/dir}/{file}#L{line}"/>
- </head>
- <body>
- <div id="-content">
- <div id="-top" class="panel">
- <a id="-menu-link"><img width="16" height="16" src="" alt="Menu"/></a>
-
- <a id="-search-link"><img width="22" height="16" src="" alt="Search"/></a>
-
- <ul id="-global-navigation">
- <li><a id="-logotype" href="/index.html">Apache Qpid<sup>™</sup></a></li>
- <li><a href="/documentation.html">Documentation</a></li>
- <li><a href="/download.html">Download</a></li>
- <li><a href="/discussion.html">Discussion</a></li>
- </ul>
- </div>
-
- <div id="-menu" class="panel" style="display: none;">
- <div class="flex">
- <section>
- <h3>Project</h3>
-
- <ul>
- <li><a href="/overview.html">Overview</a></li>
- <li><a href="/components/index.html">Components</a></li>
- <li><a href="/releases/index.html">Releases</a></li>
- </ul>
- </section>
-
- <section>
- <h3>Messaging APIs</h3>
-
- <ul>
- <li><a href="/proton/index.html">Qpid Proton</a></li>
- <li><a href="/components/jms/index.html">Qpid JMS</a></li>
- <li><a href="/components/messaging-api/index.html">Qpid Messaging API</a></li>
- </ul>
- </section>
-
- <section>
- <h3>Servers and tools</h3>
-
- <ul>
- <li><a href="/components/broker-j/index.html">Broker-J</a></li>
- <li><a href="/components/cpp-broker/index.html">C++ broker</a></li>
- <li><a href="/components/dispatch-router/index.html">Dispatch router</a></li>
- </ul>
- </section>
-
- <section>
- <h3>Resources</h3>
-
- <ul>
- <li><a href="/dashboard.html">Dashboard</a></li>
- <li><a href="https://cwiki.apache.org/confluence/display/qpid/Index">Wiki</a></li>
- <li><a href="/resources.html">More resources</a></li>
- </ul>
- </section>
- </div>
- </div>
-
- <div id="-search" class="panel" style="display: none;">
- <form action="http://www.google.com/search" method="get">
- <input type="hidden" name="sitesearch" value="qpid.apache.org"/>
- <input type="text" name="q" maxlength="255" autofocus="autofocus" tabindex="1"/>
- <button type="submit">Search</button>
- <a href="/search.html">More ways to search</a>
- </form>
- </div>
-
- <div id="-middle" class="panel">
- <ul id="-path-navigation"><li><a href="/index.html">Home</a></li><li><a href="/releases/index.html">Releases</a></li><li><a href="/releases/qpid-dispatch-master/index.html">Qpid Dispatch documentation snapshot</a></li><li>SYNOPSIS</li></ul>
-
- <div id="-middle-content">
- <div class="sect1">
-<h2 id="_synopsis">SYNOPSIS</h2>
-<div class="sectionbody">
-<div class="paragraph"><p><strong>qdmanage</strong> [<em>OPTIONS</em>] <em>OPERATION</em> [<em>ARGUMENTS</em>]</p></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_description">DESCRIPTION</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>An AMQP management client for use with qdrouterd. Sends AMQP management
-operations requests and prints the response in JSON format. This is a
-generic AMQP management tool and can be used with any standard AMQP
-managed endpoint, not just with qdrouter.</p></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_options">OPTIONS</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>-h, --help
-: show this help message and exit</p></div>
-<div class="paragraph"><p>--version
-: Print version and exit.</p></div>
-<div class="paragraph"><p>--type=TYPE
-: Type of entity to operate on.</p></div>
-<div class="paragraph"><p>--name=NAME
-: Name of entity to operate on.</p></div>
-<div class="paragraph"><p>--identity=ID
-: Identity of entity to operate on.</p></div>
-<div class="paragraph"><p>--indent=INDENT
-: Pretty-printing indent. -1 means don’t pretty-print</p></div>
-<div class="paragraph"><p>--stdin
-: Read attributes as JSON map or list of maps from</p></div>
-<div class="paragraph"><p>--body=BODY
-: JSON value to use as body of a non-standard operation</p></div>
-<div class="paragraph"><p>--properties=PROPERTIES
-: JSON map to use as properties for a non-standard operation call.</p></div>
-<div class="sect2">
-<h3 id="_connection_options">Connection Options</h3>
-<div class="paragraph"><p>-b URL, --bus=URL
-: URL of the messaging bus to connect to (default 0.0.0.0)</p></div>
-<div class="paragraph"><p>-r ROUTER-ID, --router=ROUTER-ID
-: Router to be queried</p></div>
-<div class="paragraph"><p>-t SECS, --timeout=SECS
-: Maximum time to wait for connection in seconds (default 5)</p></div>
-<div class="paragraph"><p>--ssl-certificate=CERT
-: Client SSL certificate (PEM Format)</p></div>
-<div class="paragraph"><p>--ssl-key=KEY
-: Client SSL private key (PEM Format)</p></div>
-<div class="paragraph"><p>--ssl-trustfile=TRUSTED-CA-DB
-: Trusted Certificate Authority Database file (PEM Format)</p></div>
-<div class="paragraph"><p>--ssl-password=PASSWORD
-: Certificate password, will be prompted if not specifed.</p></div>
-<div class="paragraph"><p>--ssl-password-file=SSL-PASSWORD-FILE
-: Certificate password, will be prompted if not specifed.</p></div>
-<div class="paragraph"><p>--sasl-mechanisms=SASL-MECHANISMS
-: Allowed sasl mechanisms to be supplied during the sasl handshake.</p></div>
-<div class="paragraph"><p>--sasl-username=SASL-USERNAME
-: User name for SASL plain authentication</p></div>
-<div class="paragraph"><p>--sasl-password=SASL-PASSWORD
-: Password for SASL plain authentication</p></div>
-<div class="paragraph"><p>--sasl-password-file=SASL-PASSWORD-FILE
-: Password for SASL plain authentication</p></div>
-<div class="paragraph"><p>--ssl-disable-peer-name-verify
-: Disables SSL peer name verification. WARNING - This option is insecure and must not be used in production environments</p></div>
-</div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_operations">OPERATIONS</h2>
-<div class="sectionbody">
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<code>query</code> [<em>ATTR</em>…]
-</dt>
-<dd>
-<p>
- Print attributes for multiple entities. Prints all entities by default, use
- --type, --name or --identity options to restrict which entities are printed.
- Prints the attributes named in the ATTR list, or all attributes if none are
- listed.
-</p>
-</dd>
-<dt class="hdlist1">
-<code>create</code> [<em>ATTR=VALUE</em>…]
-</dt>
-<dd>
-<p>
- Create a new entity with the specified attributes. With the --stdin
- option, read attributes from stdin. This can be a JSON map of
- attributes to create a single entity, or a JSON list of maps to create
- multiple entities.
-</p>
-</dd>
-<dt class="hdlist1">
-<code>read</code>
-</dt>
-<dd>
-<p>
- Print all the attributes of a single entity, specified by the --name or
- --identity options.
-</p>
-</dd>
-<dt class="hdlist1">
-<code>update</code> [<em>ATTR=VALUE</em>…]
-</dt>
-<dd>
-<p>
- Update the attributes of an existing entity. If an ATTR name is listed with
- no =VALUE, that attribute will be deleted from the entity. With the --stdin
- option, read attributes from stdin. This can be a JSON map of attributes to
- update a single entity, or a JSON list of maps to update multiple entities.
-</p>
-</dd>
-<dt class="hdlist1">
-<code>delete</code>
-</dt>
-<dd>
-<p>
- Delete an entity specified by the --name or --identity options.
-</p>
-</dd>
-<dt class="hdlist1">
-<code>get-types</code> [<em>TYPE</em>]
-</dt>
-<dd>
-<p>
- List entity types with their base types. With no arguments list all
- types.
-</p>
-</dd>
-<dt class="hdlist1">
-<code>get-operations</code> [<em>TYPE</em>]
-</dt>
-<dd>
-<p>
- List entity types with their operations. With no arguments list all
- types.
-</p>
-</dd>
-<dt class="hdlist1">
-<code>get-attributes</code> [<em>TYPE</em>]
-</dt>
-<dd>
-<p>
- List entity types with their attributes. With no arguments list all
- types.
-</p>
-</dd>
-<dt class="hdlist1">
-<code>get-annotations</code> [<em>TYPE</em>]
-</dt>
-<dd>
-<p>
- List entity types with their annotations. With no arguments list all
- types.
-</p>
-</dd>
-<dt class="hdlist1">
-<code>get-mgmt-nodes</code>
-</dt>
-<dd>
-<p>
- List all other known management nodes connected to this one.
-</p>
-</dd>
-<dt class="hdlist1">
-<code>get-json-schema</code> [<em>INDENT</em>]
-</dt>
-<dd>
-<p>
- Get the router schema in JSON format. Optional integer indent for
- formatted output.
-</p>
-</dd>
-<dt class="hdlist1">
-<code>get-log</code> [<em>INDENT</em>]
-</dt>
-<dd>
-<p>
- Get recent log entries from the router.
-</p>
-</dd>
-</dl></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_files">FILES</h2>
-<div class="sectionbody">
-<div class="dlist"><dl>
-<dt class="hdlist1">
-/usr/local/share/doc/qpid-dispatch/qdrouter.json
-</dt>
-<dd>
-<p>
- Management schema for qdrouterd.
-</p>
-</dd>
-<dt class="hdlist1">
-/usr/local/share/doc/qpid-dispatch/qdrouter.json.readme.txt
-</dt>
-<dd>
-<p>
- Explanation of the management schema.
-</p>
-</dd>
-</dl></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_examples">EXAMPLES</h2>
-<div class="sectionbody">
-<div class="listingblock">
-<div class="title">Show the logging configuration</div>
-<div class="content">
-<pre><code>qdmanage query --type=log</code></pre>
-</div></div>
-<div class="listingblock">
-<div class="title">Enable debug and higher log messages by default:</div>
-<div class="content">
-<pre><code>qdmanage update name=log/DEFAULT enable=debug+</code></pre>
-</div></div>
-<div class="listingblock">
-<div class="title">Enable trace log messages only for the MESSAGE module and direct MESSAGE logs to the file "test.log"</div>
-<div class="content">
-<pre><code>qdmanage update name=log/MESSAGE enable=trace output=test.log</code></pre>
-</div></div>
-<div class="listingblock">
-<div class="title">Set MESSAGE logging back to the default</div>
-<div class="content">
-<pre><code>qdmanage update name=log/MESSAGE enable=default</code></pre>
-</div></div>
-<div class="listingblock">
-<div class="title">Disable MESSAGE logging</div>
-<div class="content">
-<pre><code>qdmanage update name=log/MESSAGE enable=none</code></pre>
-</div></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_see_also">SEE ALSO</h2>
-<div class="sectionbody">
-<div class="paragraph"><p><em>qdrouterd(8)</em>, <em>qdstat(8)</em>, <em>qdrouterd.conf(5)</em></p></div>
-<div class="paragraph"><p><a href="http://qpid.apache.org/components/dispatch-router">http://qpid.apache.org/components/dispatch-router</a></p></div>
-</div>
-</div>
-
-
- <hr/>
-
- <ul id="-apache-navigation">
- <li><a href="http://www.apache.org/">Apache</a></li>
- <li><a href="http://www.apache.org/licenses/">License</a></li>
- <li><a href="http://www.apache.org/foundation/sponsorship.html">Sponsorship</a></li>
- <li><a href="http://www.apache.org/foundation/thanks.html">Thanks!</a></li>
- <li><a href="/security.html">Security</a></li>
- <li><a href="http://www.apache.org/"><img id="-apache-feather" width="48" height="14" src="" alt="Apache"/></a></li>
- </ul>
-
- <p id="-legal">
- Apache Qpid, Messaging built on AMQP; Copyright © 2015
- The Apache Software Foundation; Licensed under
- the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache
- License, Version 2.0</a>; Apache Qpid, Qpid, Qpid Proton,
- Proton, Apache, the Apache feather logo, and the Apache Qpid
- project logo are trademarks of The Apache Software
- Foundation; All other marks mentioned may be trademarks or
- registered trademarks of their respective owners
- </p>
- </div>
- </div>
- </div>
- </body>
-</html>
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/content/releases/qpid-dispatch-master/qdrouterd.8.html
----------------------------------------------------------------------
diff --git a/content/releases/qpid-dispatch-master/qdrouterd.8.html b/content/releases/qpid-dispatch-master/qdrouterd.8.html
deleted file mode 100644
index 8e1d54f..0000000
--- a/content/releases/qpid-dispatch-master/qdrouterd.8.html
+++ /dev/null
@@ -1,197 +0,0 @@
-<!DOCTYPE html>
-<!--
- -
- - Licensed to the Apache Software Foundation (ASF) under one
- - or more contributor license agreements. See the NOTICE file
- - distributed with this work for additional information
- - regarding copyright ownership. The ASF licenses this file
- - to you under the Apache License, Version 2.0 (the
- - "License"); you may not use this file except in compliance
- - with the License. You may obtain a copy of the License at
- -
- - http://www.apache.org/licenses/LICENSE-2.0
- -
- - Unless required by applicable law or agreed to in writing,
- - software distributed under the License is distributed on an
- - "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- - KIND, either express or implied. See the License for the
- - specific language governing permissions and limitations
- - under the License.
- -
--->
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
- <head>
- <title>SYNOPSIS - Apache Qpid™</title>
- <meta http-equiv="X-UA-Compatible" content="IE=edge"/>
- <meta name="viewport" content="width=device-width, initial-scale=1.0"/>
- <link rel="stylesheet" href="/site.css" type="text/css" async="async"/>
- <link rel="stylesheet" href="/deferred.css" type="text/css" defer="defer"/>
- <script type="text/javascript">var _deferredFunctions = [];</script>
- <script type="text/javascript" src="/deferred.js" defer="defer"></script>
- <!--[if lte IE 8]>
- <link rel="stylesheet" href="/ie.css" type="text/css"/>
- <script type="text/javascript" src="/html5shiv.js"></script>
- <![endif]-->
-
- <!-- Redirects for `go get` and godoc.org -->
- <meta name="go-import"
- content="qpid.apache.org git https://git-wip-us.apache.org/repos/asf/qpid-proton.git"/>
- <meta name="go-source"
- content="qpid.apache.org
-https://github.com/apache/qpid-proton/blob/go1/README.md
-https://github.com/apache/qpid-proton/tree/go1{/dir}
-https://github.com/apache/qpid-proton/blob/go1{/dir}/{file}#L{line}"/>
- </head>
- <body>
- <div id="-content">
- <div id="-top" class="panel">
- <a id="-menu-link"><img width="16" height="16" src="" alt="Menu"/></a>
-
- <a id="-search-link"><img width="22" height="16" src="" alt="Search"/></a>
-
- <ul id="-global-navigation">
- <li><a id="-logotype" href="/index.html">Apache Qpid<sup>™</sup></a></li>
- <li><a href="/documentation.html">Documentation</a></li>
- <li><a href="/download.html">Download</a></li>
- <li><a href="/discussion.html">Discussion</a></li>
- </ul>
- </div>
-
- <div id="-menu" class="panel" style="display: none;">
- <div class="flex">
- <section>
- <h3>Project</h3>
-
- <ul>
- <li><a href="/overview.html">Overview</a></li>
- <li><a href="/components/index.html">Components</a></li>
- <li><a href="/releases/index.html">Releases</a></li>
- </ul>
- </section>
-
- <section>
- <h3>Messaging APIs</h3>
-
- <ul>
- <li><a href="/proton/index.html">Qpid Proton</a></li>
- <li><a href="/components/jms/index.html">Qpid JMS</a></li>
- <li><a href="/components/messaging-api/index.html">Qpid Messaging API</a></li>
- </ul>
- </section>
-
- <section>
- <h3>Servers and tools</h3>
-
- <ul>
- <li><a href="/components/broker-j/index.html">Broker-J</a></li>
- <li><a href="/components/cpp-broker/index.html">C++ broker</a></li>
- <li><a href="/components/dispatch-router/index.html">Dispatch router</a></li>
- </ul>
- </section>
-
- <section>
- <h3>Resources</h3>
-
- <ul>
- <li><a href="/dashboard.html">Dashboard</a></li>
- <li><a href="https://cwiki.apache.org/confluence/display/qpid/Index">Wiki</a></li>
- <li><a href="/resources.html">More resources</a></li>
- </ul>
- </section>
- </div>
- </div>
-
- <div id="-search" class="panel" style="display: none;">
- <form action="http://www.google.com/search" method="get">
- <input type="hidden" name="sitesearch" value="qpid.apache.org"/>
- <input type="text" name="q" maxlength="255" autofocus="autofocus" tabindex="1"/>
- <button type="submit">Search</button>
- <a href="/search.html">More ways to search</a>
- </form>
- </div>
-
- <div id="-middle" class="panel">
- <ul id="-path-navigation"><li><a href="/index.html">Home</a></li><li><a href="/releases/index.html">Releases</a></li><li><a href="/releases/qpid-dispatch-master/index.html">Qpid Dispatch documentation snapshot</a></li><li>SYNOPSIS</li></ul>
-
- <div id="-middle-content">
- <div class="sect1">
-<h2 id="_synopsis">SYNOPSIS</h2>
-<div class="sectionbody">
-<div class="paragraph"><p><strong>qdrouterd</strong> [<em>OPTIONS</em>]</p></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_description">DESCRIPTION</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>The Qpid Dispatch router (qdrouterd) is a network daemon that directs
-AMQP 1.0 messages between endpoints, such as messaging clients and
-servers.</p></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_options">OPTIONS</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>-c, --config=PATH (/usr/local/etc/qpid-dispatch/qdrouterd.conf)
-: Load configuration from file at PATH</p></div>
-<div class="paragraph"><p>-I, --include=PATH (/usr/local/lib/qpid-dispatch/python)
-: Location of Dispatch’s Python library</p></div>
-<div class="paragraph"><p>-d, --daemon
-: Run process as a SysV-style daemon</p></div>
-<div class="paragraph"><p>-P, --pidfile
-: If daemon, the file for the stored daemon pid</p></div>
-<div class="paragraph"><p>-U, --user
-: If daemon, the username to run as</p></div>
-<div class="paragraph"><p>-h, --help
-: Print this help</p></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_files">FILES</h2>
-<div class="sectionbody">
-<div class="dlist"><dl>
-<dt class="hdlist1">
-/usr/local/etc/qdrouterd.conf
-</dt>
-<dd>
-<p>
- Configuration flie.
-</p>
-</dd>
-</dl></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_see_also">SEE ALSO</h2>
-<div class="sectionbody">
-<div class="paragraph"><p><em>qdrouterd.conf(5)</em>, <em>qdstat(8)</em>, <em>qdmanage(8)</em></p></div>
-<div class="paragraph"><p><a href="http://qpid.apache.org/components/dispatch-router">http://qpid.apache.org/components/dispatch-router</a></p></div>
-</div>
-</div>
-
-
- <hr/>
-
- <ul id="-apache-navigation">
- <li><a href="http://www.apache.org/">Apache</a></li>
- <li><a href="http://www.apache.org/licenses/">License</a></li>
- <li><a href="http://www.apache.org/foundation/sponsorship.html">Sponsorship</a></li>
- <li><a href="http://www.apache.org/foundation/thanks.html">Thanks!</a></li>
- <li><a href="/security.html">Security</a></li>
- <li><a href="http://www.apache.org/"><img id="-apache-feather" width="48" height="14" src="" alt="Apache"/></a></li>
- </ul>
-
- <p id="-legal">
- Apache Qpid, Messaging built on AMQP; Copyright © 2015
- The Apache Software Foundation; Licensed under
- the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache
- License, Version 2.0</a>; Apache Qpid, Qpid, Qpid Proton,
- Proton, Apache, the Apache feather logo, and the Apache Qpid
- project logo are trademarks of The Apache Software
- Foundation; All other marks mentioned may be trademarks or
- registered trademarks of their respective owners
- </p>
- </div>
- </div>
- </div>
- </body>
-</html>
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org
[04/13] qpid-site git commit: QPID-8015: Prepare the dispatch release
scripts for the new user guide
Posted by jr...@apache.org.
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/book/console_charts.png
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/book/console_charts.png b/input/releases/qpid-dispatch-master/book/console_charts.png
deleted file mode 100644
index 169c2ca..0000000
Binary files a/input/releases/qpid-dispatch-master/book/console_charts.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/book/console_entity.png
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/book/console_entity.png b/input/releases/qpid-dispatch-master/book/console_entity.png
deleted file mode 100644
index 130c7e7..0000000
Binary files a/input/releases/qpid-dispatch-master/book/console_entity.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/book/console_login.png
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/book/console_login.png b/input/releases/qpid-dispatch-master/book/console_login.png
deleted file mode 100644
index 63e22c6..0000000
Binary files a/input/releases/qpid-dispatch-master/book/console_login.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/book/console_overview.png
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/book/console_overview.png b/input/releases/qpid-dispatch-master/book/console_overview.png
deleted file mode 100644
index af25f36..0000000
Binary files a/input/releases/qpid-dispatch-master/book/console_overview.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/book/console_schema.png
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/book/console_schema.png b/input/releases/qpid-dispatch-master/book/console_schema.png
deleted file mode 100644
index ba56c7b..0000000
Binary files a/input/releases/qpid-dispatch-master/book/console_schema.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/book/console_topology.png
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/book/console_topology.png b/input/releases/qpid-dispatch-master/book/console_topology.png
deleted file mode 100644
index ae4b22a..0000000
Binary files a/input/releases/qpid-dispatch-master/book/console_topology.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/console1.png
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/console1.png b/input/releases/qpid-dispatch-master/console1.png
deleted file mode 100644
index f131884..0000000
Binary files a/input/releases/qpid-dispatch-master/console1.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/console_charts.png
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/console_charts.png b/input/releases/qpid-dispatch-master/console_charts.png
deleted file mode 100644
index 169c2ca..0000000
Binary files a/input/releases/qpid-dispatch-master/console_charts.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/console_entity.png
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/console_entity.png b/input/releases/qpid-dispatch-master/console_entity.png
deleted file mode 100644
index 130c7e7..0000000
Binary files a/input/releases/qpid-dispatch-master/console_entity.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/console_login.png
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/console_login.png b/input/releases/qpid-dispatch-master/console_login.png
deleted file mode 100644
index 63e22c6..0000000
Binary files a/input/releases/qpid-dispatch-master/console_login.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/console_overview.png
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/console_overview.png b/input/releases/qpid-dispatch-master/console_overview.png
deleted file mode 100644
index af25f36..0000000
Binary files a/input/releases/qpid-dispatch-master/console_overview.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/console_schema.png
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/console_schema.png b/input/releases/qpid-dispatch-master/console_schema.png
deleted file mode 100644
index ba56c7b..0000000
Binary files a/input/releases/qpid-dispatch-master/console_schema.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/console_topology.png
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/console_topology.png b/input/releases/qpid-dispatch-master/console_topology.png
deleted file mode 100644
index ae4b22a..0000000
Binary files a/input/releases/qpid-dispatch-master/console_topology.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/index.md
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/index.md b/input/releases/qpid-dispatch-master/index.md
index dc25335..321aa48 100644
--- a/input/releases/qpid-dispatch-master/index.md
+++ b/input/releases/qpid-dispatch-master/index.md
@@ -27,7 +27,7 @@ Documentation found here may be incorrect or incomplete. For a
smoother experience, see the [current stable
release]({{current_dispatch_release_url}}/index.html).
-This content was generated at 15:51 on Tuesday, 02 May 2017.
+This content was generated at 11:21 on Tuesday, 28 November 2017.
</div>
@@ -36,8 +36,9 @@ This content was generated at 15:51 on Tuesday, 02 May 2017.
<div class="two-column" markdown="1">
- - [Installing Qpid Dispatch](https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;a=blob_plain;f=README;hb=master)
- - [Dispatch Router User Guide](book/book.html)
+ - [Using Qpid Dispatch](user-guide/index.html)
+ - [Installing Qpid Dispatch from
+ source](https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;a=blob_plain;f=README;hb=master)
- [qdrouterd](man/qdrouterd.html) - Router daemon
- [qdrouterd.conf](man/qdrouterd.conf.html) - Daemon configuration
- [qdstat](man/qdstat.html) - Get router statistics
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/man/qdmanage.html.in
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/man/qdmanage.html.in b/input/releases/qpid-dispatch-master/man/qdmanage.html.in
index 384c8f7..46750fb 100644
--- a/input/releases/qpid-dispatch-master/man/qdmanage.html.in
+++ b/input/releases/qpid-dispatch-master/man/qdmanage.html.in
@@ -7,10 +7,11 @@
<div class="sect1">
<h2 id="_description">DESCRIPTION</h2>
<div class="sectionbody">
-<div class="paragraph"><p>An AMQP management client for use with qdrouterd. Sends AMQP management
-operations requests and prints the response in JSON format. This is a
-generic AMQP management tool and can be used with any standard AMQP
-managed endpoint, not just with qdrouter.</p></div>
+<div class="paragraph"><p>An AMQP management client for use with the Dispatch router daemon
+(<em>qdrouterd</em>). Sends AMQP management operations requests and prints
+the response in JSON format. This is a generic AMQP management tool
+and can be used with any standard AMQP managed endpoint, not just
+with <em>qdrouterd</em>.</p></div>
</div>
</div>
<div class="sect1">
@@ -27,17 +28,17 @@ managed endpoint, not just with qdrouter.</p></div>
<div class="paragraph"><p>--identity=ID
: Identity of entity to operate on.</p></div>
<div class="paragraph"><p>--indent=INDENT
-: Pretty-printing indent. -1 means don’t pretty-print</p></div>
+: Pretty-printing indent. -1 means don’t pretty-print (default 2)</p></div>
<div class="paragraph"><p>--stdin
-: Read attributes as JSON map or list of maps from</p></div>
+: Read attributes as JSON map or list of maps from stdin.</p></div>
<div class="paragraph"><p>--body=BODY
-: JSON value to use as body of a non-standard operation</p></div>
+: JSON value to use as body of a non-standard operation call.</p></div>
<div class="paragraph"><p>--properties=PROPERTIES
: JSON map to use as properties for a non-standard operation call.</p></div>
<div class="sect2">
<h3 id="_connection_options">Connection Options</h3>
<div class="paragraph"><p>-b URL, --bus=URL
-: URL of the messaging bus to connect to (default</p></div>
+: URL of the messaging bus to connect to (default 0.0.0.0)</p></div>
<div class="paragraph"><p>-r ROUTER-ID, --router=ROUTER-ID
: Router to be queried</p></div>
<div class="paragraph"><p>-t SECS, --timeout=SECS
@@ -96,7 +97,7 @@ managed endpoint, not just with qdrouter.</p></div>
</dt>
<dd>
<p>
- Print all the attributes of a single entity, specified by the --name or
+ Print all of the attributes of a single entity, specified by the --name or
--identity options.
</p>
</dd>
@@ -124,7 +125,7 @@ managed endpoint, not just with qdrouter.</p></div>
</dt>
<dd>
<p>
- List entity types with their base types. With no arguments list all
+ List entity types with their base types. With no arguments, list all
types.
</p>
</dd>
@@ -133,7 +134,7 @@ managed endpoint, not just with qdrouter.</p></div>
</dt>
<dd>
<p>
- List entity types with their operations. With no arguments list all
+ List entity types with their operations. With no arguments, list all
types.
</p>
</dd>
@@ -142,7 +143,7 @@ managed endpoint, not just with qdrouter.</p></div>
</dt>
<dd>
<p>
- List entity types with their attributes. With no arguments list all
+ List entity types with their attributes. With no arguments, list all
types.
</p>
</dd>
@@ -151,7 +152,7 @@ managed endpoint, not just with qdrouter.</p></div>
</dt>
<dd>
<p>
- List entity types with their annotations. With no arguments list all
+ List entity types with their annotations. With no arguments, list all
types.
</p>
</dd>
@@ -192,7 +193,7 @@ managed endpoint, not just with qdrouter.</p></div>
</dt>
<dd>
<p>
- Management schema for qdrouterd.
+ Management schema for <em>qdrouterd</em>.
</p>
</dd>
<dt class="hdlist1">
@@ -210,7 +211,7 @@ managed endpoint, not just with qdrouter.</p></div>
<h2 id="_examples">EXAMPLES</h2>
<div class="sectionbody">
<div class="listingblock">
-<div class="title">Show the logging configuration</div>
+<div class="title">Show the logging configuration:</div>
<div class="content">
<pre><code>qdmanage query --type=log</code></pre>
</div></div>
@@ -220,17 +221,17 @@ managed endpoint, not just with qdrouter.</p></div>
<pre><code>qdmanage update name=log/DEFAULT enable=debug+</code></pre>
</div></div>
<div class="listingblock">
-<div class="title">Enable trace log messages only for the MESSAGE module and direct MESSAGE logs to the file "test.log"</div>
+<div class="title">Enable trace log messages only for the MESSAGE module, and direct MESSAGE logs to the file <em>test.log</em>:</div>
<div class="content">
<pre><code>qdmanage update name=log/MESSAGE enable=trace output=test.log</code></pre>
</div></div>
<div class="listingblock">
-<div class="title">Set MESSAGE logging back to the default</div>
+<div class="title">Set MESSAGE logging back to the default:</div>
<div class="content">
<pre><code>qdmanage update name=log/MESSAGE enable=default</code></pre>
</div></div>
<div class="listingblock">
-<div class="title">Disable MESSAGE logging</div>
+<div class="title">Disable MESSAGE logging:</div>
<div class="content">
<pre><code>qdmanage update name=log/MESSAGE enable=none</code></pre>
</div></div>
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/man/qdrouterd.conf.html.in
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/man/qdrouterd.conf.html.in b/input/releases/qpid-dispatch-master/man/qdrouterd.conf.html.in
index 81d39c8..fd6853a 100644
--- a/input/releases/qpid-dispatch-master/man/qdrouterd.conf.html.in
+++ b/input/releases/qpid-dispatch-master/man/qdrouterd.conf.html.in
@@ -80,7 +80,7 @@ listener {
</dt>
<dd>
<p>
- Router’s unique identity. One of id or routerId is required. The router will fail to start without id or routerId
+ Router’s unique identity. The router will fail to start without id.
</p>
</dd>
<dt class="hdlist1">
@@ -172,19 +172,11 @@ listener {
</p>
</dd>
<dt class="hdlist1">
-<em>routerId</em> (string)
+<em>defaultDistribution</em> (One of [<em>multicast</em>, <em>closest</em>, <em>balanced</em>, <em>unavailable</em>], default=<em>balanced</em>)
</dt>
<dd>
<p>
- (DEPRECATED) Router’s unique identity. This attribute has been deprecated. Use id instead
-</p>
-</dd>
-<dt class="hdlist1">
-<em>mobileAddrMaxAge</em> (integer, default=<em>60</em>)
-</dt>
-<dd>
-<p>
- (DEPRECATED) This value is no longer used in the router.
+ Default forwarding treatment for any address without a specified treatment. multicast - one copy of each message delivered to all subscribers; closest - messages delivered to only the closest subscriber; balanced - messages delivered to one subscriber with load balanced across subscribers; unavailable - this address is unavailable, link attaches to an address of unavilable distribution will be rejected.
</p>
</dd>
</dl></div>
@@ -194,6 +186,14 @@ listener {
<div class="paragraph"><p>Attributes for setting TLS/SSL configuration for connections.</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
+<em>ciphers</em> (string)
+</dt>
+<dd>
+<p>
+ Specifies the enabled ciphers so the SSL Ciphers can be hardened. In other words, use this field to disable weak ciphers. The ciphers are specified in the format understood by the OpenSSL library. For example, ciphers can be set to ALL:!aNULL:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP; — The full list of allowed ciphers can be viewed using the openssl ciphers command
+</p>
+</dd>
+<dt class="hdlist1">
<em>certDb</em> (path)
</dt>
<dd>
@@ -252,6 +252,36 @@ listener {
</dl></div>
</div>
<div class="sect2">
+<h3 id="_authserviceplugin">authServicePlugin</h3>
+<div class="paragraph"><p>EXPERIMENTAL. Attributes for setting SASL plugin.</p></div>
+<div class="dlist"><dl>
+<dt class="hdlist1">
+<em>authService</em> (string, required)
+</dt>
+<dd>
+<p>
+ Address of a service to delegate authentication to.
+</p>
+</dd>
+<dt class="hdlist1">
+<em>saslInitHostname</em> (string)
+</dt>
+<dd>
+<p>
+ Value to set for hostname field on sasl-init
+</p>
+</dd>
+<dt class="hdlist1">
+<em>authSslProfile</em> (string)
+</dt>
+<dd>
+<p>
+ Name of the sslProfile to use for the authentication service.
+</p>
+</dd>
+</dl></div>
+</div>
+<div class="sect2">
<h3 id="_listener">listener</h3>
<div class="paragraph"><p>Listens for incoming connections to the router.</p></div>
<div class="dlist"><dl>
@@ -280,11 +310,11 @@ listener {
</p>
</dd>
<dt class="hdlist1">
-<em>role</em> (One of [<em>normal</em>, <em>inter-router</em>, <em>route-container</em>, <em>on-demand</em>], default=<em>normal</em>)
+<em>role</em> (One of [<em>normal</em>, <em>inter-router</em>, <em>route-container</em>], default=<em>normal</em>)
</dt>
<dd>
<p>
- The role of an established connection. In the normal role, the connection is assumed to be used for AMQP clients that are doing normal message delivery over the connection. In the inter-router role, the connection is assumed to be to another router in the network. Inter-router discovery and routing protocols can only be used over inter-router connections. route-container role can be used for router-container connections, for example, a router-broker connection. on-demand role has been deprecated.
+ The role of an established connection. In the normal role, the connection is assumed to be used for AMQP clients that are doing normal message delivery over the connection. In the inter-router role, the connection is assumed to be to another router in the network. Inter-router discovery and routing protocols can only be used over inter-router connections. route-container role can be used for router-container connections, for example, a router-broker connection.
</p>
</dd>
<dt class="hdlist1">
@@ -320,6 +350,14 @@ listener {
</p>
</dd>
<dt class="hdlist1">
+<em>saslPlugin</em> (string)
+</dt>
+<dd>
+<p>
+ EXPERIMENTAL. Name of the a sasl plugin configuration section to use for this listener (e.g. authServicePlugin).
+</p>
+</dd>
+<dt class="hdlist1">
<em>requireEncryption</em> (boolean)
</dt>
<dd>
@@ -376,6 +414,14 @@ listener {
</p>
</dd>
<dt class="hdlist1">
+<em>initialHandshakeTimeoutSeconds</em> (integer)
+</dt>
+<dd>
+<p>
+ The timeout, in seconds, for the initial handshake for connections coming in through listeners. If the time interval expires before the peer sends the AMQP OPEN frame, the connection shall be closed. A value of zero (the default) disables this timeout.
+</p>
+</dd>
+<dt class="hdlist1">
<em>stripAnnotations</em> (One of [<em>in</em>, <em>out</em>, <em>both</em>, <em>no</em>], default=<em>both</em>)
</dt>
<dd>
@@ -408,43 +454,11 @@ listener {
</p>
</dd>
<dt class="hdlist1">
-<em>addr</em> (string, default=<em>127.0.0.1</em>)
-</dt>
-<dd>
-<p>
- (DEPRECATED)IP address: ipv4 or ipv6 literal or a host name. This attribute has been deprecated. Use host instead
-</p>
-</dd>
-<dt class="hdlist1">
-<em>allowNoSasl</em> (boolean)
-</dt>
-<dd>
-<p>
- (DEPRECATED) This attribute is now controlled by the authenticatePeer attribute.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>requirePeerAuth</em> (boolean)
-</dt>
-<dd>
-<p>
- (DEPRECATED) This attribute is now controlled by the authenticatePeer attribute.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>allowUnsecured</em> (boolean)
-</dt>
-<dd>
-<p>
- (DEPRECATED) This attribute is now controlled by the requireEncryption attribute.
-</p>
-</dd>
-<dt class="hdlist1">
<em>http</em> (boolean)
</dt>
<dd>
<p>
- Accept HTTP connections that can upgrade to AMQP over WebSocket
+ Accept HTTP connections that can upgrade to AMQP over WebSocket. Plain AMQP connections are not accepted on this listener.
</p>
</dd>
<dt class="hdlist1">
@@ -494,11 +508,11 @@ listener {
</p>
</dd>
<dt class="hdlist1">
-<em>role</em> (One of [<em>normal</em>, <em>inter-router</em>, <em>route-container</em>, <em>on-demand</em>], default=<em>normal</em>)
+<em>role</em> (One of [<em>normal</em>, <em>inter-router</em>, <em>route-container</em>], default=<em>normal</em>)
</dt>
<dd>
<p>
- The role of an established connection. In the normal role, the connection is assumed to be used for AMQP clients that are doing normal message delivery over the connection. In the inter-router role, the connection is assumed to be to another router in the network. Inter-router discovery and routing protocols can only be used over inter-router connections. route-container role can be used for router-container connections, for example, a router-broker connection. on-demand role has been deprecated.
+ The role of an established connection. In the normal role, the connection is assumed to be used for AMQP clients that are doing normal message delivery over the connection. In the inter-router role, the connection is assumed to be to another router in the network. Inter-router discovery and routing protocols can only be used over inter-router connections. route-container role can be used for router-container connections, for example, a router-broker connection.
</p>
</dd>
<dt class="hdlist1">
@@ -606,19 +620,11 @@ listener {
</p>
</dd>
<dt class="hdlist1">
-<em>addr</em> (string, default=<em>127.0.0.1</em>)
-</dt>
-<dd>
-<p>
- (DEPRECATED)IP address: ipv4 or ipv6 literal or a host name. This attribute has been deprecated. Use host instead
-</p>
-</dd>
-<dt class="hdlist1">
<em>logMessage</em> (string, default=<em>none</em>)
</dt>
<dd>
<p>
- A comma separated list that indicates which components of the message should be logged. Defaults to <em>none</em> (log nothing). If you want all properties and application properties of the message logged use <em>all</em>. Specific components of the message can be logged by indicating the components via a comma separated list. The components are message-id, user-id, to, subject, reply-to, correlation-id, content-type, content-encoding, absolute-expiry-time, creation-time, group-id, group-sequence, reply-to-group-id, app-properties. The application-data part of the bare message will not be logged. No spaces are allowed
+ A comma separated list that indicates which components of the message should be logged (no spaces allowed between list components). Defaults to <em>none</em> (log nothing). If you want all properties and application properties of the message logged use <em>all</em>. Specific components of the message can be logged by indicating the components via a comma separated list. The components are message-id, user-id, to, subject, reply-to, correlation-id, content-type, content-encoding, absolute-expiry-time, creation-time, group-id, group-sequence, reply-to-group-id, app-properties. The application-data part of the bare message will not be logged. This log message is written to the MESSAGE logging module. In the <em>log</em> entity, set <em>module</em> property to MESSAGE or DEFAULT and <em>enable</em> to trace+ to see this log message
</p>
</dd>
</dl></div>
@@ -674,15 +680,23 @@ listener {
<div class="paragraph"><p>Entity type for address configuration. This is used to configure the treatment of message-routed deliveries within a particular address-space. The configuration controls distribution and address phasing.</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
-<em>prefix</em> (string, required)
+<em>prefix</em> (string)
+</dt>
+<dd>
+<p>
+ The address prefix for the configured settings. Cannot be used with a pattern attribute.
+</p>
+</dd>
+<dt class="hdlist1">
+<em>pattern</em> (string)
</dt>
<dd>
<p>
- The address prefix for the configured settings
+ A wildcarded pattern for address matching. Incoming addresses are matched against this pattern. Matching addresses use the configured settings. The pattern consists of one or more tokens separated by a forward slash <em>/</em>. A token can be one of the following: a * character, a # character, or a sequence of characters that do not include /, *, or #. The * token matches any single token. The # token matches zero or more tokens. * has higher precedence than #, and exact match has the highest precedence. Cannot be used with a prefix attribute.
</p>
</dd>
<dt class="hdlist1">
-<em>distribution</em> (One of [<em>multicast</em>, <em>closest</em>, <em>balanced</em>], default=<em>balanced</em>)
+<em>distribution</em> (One of [<em>multicast</em>, <em>closest</em>, <em>balanced</em>, <em>unavailable</em>], default=<em>balanced</em>)
</dt>
<dd>
<p>
@@ -717,14 +731,22 @@ listener {
</div>
<div class="sect2">
<h3 id="_linkroute">linkRoute</h3>
-<div class="paragraph"><p>Entity type for link-route configuration. This is used to identify remote containers that shall be destinations for routed link-attaches. The link-routing configuration applies to an addressing space defined by a prefix.</p></div>
+<div class="paragraph"><p>Entity type for link-route configuration. This is used to identify remote containers that shall be destinations for routed link-attaches. The link-routing configuration applies to an addressing space defined by a prefix or a pattern.</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
-<em>prefix</em> (string, required)
+<em>prefix</em> (string)
</dt>
<dd>
<p>
- The address prefix for the configured settings
+ The address prefix for the configured settings. Cannot be used with the pattern attribute.
+</p>
+</dd>
+<dt class="hdlist1">
+<em>pattern</em> (string)
+</dt>
+<dd>
+<p>
+ A wildcarded pattern for address matching. Link addresses are matched against this pattern. Matching addresses use the configured settings. The pattern consists of one or more tokens separated by a forward slash <em>/</em>. A token can be one of the following: a * character, a # character, or a sequence of characters that do not include /, *, or #. The * token matches any single token. The # token matches zero or more tokens. * has higher precedence than #, and exact match has the highest precedence. Cannot be used with the prefix attribute.
</p>
</dd>
<dt class="hdlist1">
@@ -817,7 +839,7 @@ listener {
</div>
<div class="sect2">
<h3 id="_console">console</h3>
-<div class="paragraph"><p>Start a websocket/tcp proxy and http file server to serve the web console</p></div>
+<div class="paragraph"><p>(DEPRECATED) Start a websocket/tcp proxy and http file server to serve the web console</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
<em>listener</em> (string)
@@ -836,7 +858,7 @@ listener {
</p>
</dd>
<dt class="hdlist1">
-<em>proxy</em> (string)
+<em>proxy</em> (string, required)
</dt>
<dd>
<p>
@@ -844,7 +866,7 @@ listener {
</p>
</dd>
<dt class="hdlist1">
-<em>home</em> (string)
+<em>home</em> (string, required)
</dt>
<dd>
<p>
@@ -953,158 +975,6 @@ listener {
</dd>
</dl></div>
</div>
-<div class="sect2">
-<h3 id="_container">container</h3>
-<div class="paragraph"><p>(DEPRECATED)Attributes related to the AMQP container. This entity has been deprecated. Use the router entity instead.</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>containerName</em> (string)
-</dt>
-<dd>
-<p>
- The name of the AMQP container. If not specified, the container name will be set to a value of the container’s choosing. The automatically assigned container name is not guaranteed to be persistent across restarts of the container.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>workerThreads</em> (integer, default=<em>4</em>)
-</dt>
-<dd>
-<p>
- The number of threads that will be created to process message traffic and other application work (timers, non-amqp file descriptors, etc.) .
-</p>
-</dd>
-<dt class="hdlist1">
-<em>debugDump</em> (path)
-</dt>
-<dd>
-<p>
- A file to dump debugging information that can’t be logged normally.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>saslConfigPath</em> (path)
-</dt>
-<dd>
-<p>
- Absolute path to the SASL configuration file.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>saslConfigName</em> (string)
-</dt>
-<dd>
-<p>
- Name of the SASL configuration. This string + <em>.conf</em> is the name of the configuration file.
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_waypoint">waypoint</h3>
-<div class="paragraph"><p>(DEPRECATED) A remote node that messages for an address pass through. This entity has been deprecated. Use autoLink instead</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>address</em> (string, required)
-</dt>
-<dd>
-<p>
- The AMQP address of the waypoint.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>connector</em> (string, required)
-</dt>
-<dd>
-<p>
- The name of the on-demand connector used to reach the waypoint’s container.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>inPhase</em> (integer, default=<em>-1</em>)
-</dt>
-<dd>
-<p>
- The phase of the address as it is routed <em>to</em> the waypoint.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>outPhase</em> (integer, default=<em>-1</em>)
-</dt>
-<dd>
-<p>
- The phase of the address as it is routed <em>from</em> the waypoint.
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_fixedaddress">fixedAddress</h3>
-<div class="paragraph"><p>(DEPRECATED) Establishes treatment for addresses starting with a prefix. This entity has been deprecated. Use address instead</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>prefix</em> (string, required)
-</dt>
-<dd>
-<p>
- The address prefix (always starting with <em>/</em>).
-</p>
-</dd>
-<dt class="hdlist1">
-<em>phase</em> (integer)
-</dt>
-<dd>
-<p>
- The phase of a multi-hop address passing through one or more waypoints.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>fanout</em> (One of [<em>multiple</em>, <em>single</em>], default=<em>multiple</em>)
-</dt>
-<dd>
-<p>
- One of <em>multiple</em> or <em>single</em>. Multiple fanout is a non-competing pattern. If there are multiple consumers using the same address, each consumer will receive its own copy of every message sent to the address. Single fanout is a competing pattern where each message is sent to only one consumer.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>bias</em> (One of [<em>closest</em>, <em>spread</em>], default=<em>closest</em>)
-</dt>
-<dd>
-<p>
- Only if fanout is single. One of <em>closest</em> or <em>spread</em>. Closest bias means that messages to an address will always be delivered to the closest (lowest cost) subscribed consumer. Spread bias will distribute the messages across subscribers in an approximately even manner.
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect2">
-<h3 id="_linkroutepattern">linkRoutePattern</h3>
-<div class="paragraph"><p>(DEPRECATED) An address pattern to match against link sources and targets to cause the router to link-route the attach across the network to a remote node. This entity has been deprecated. Use linkRoute instead</p></div>
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<em>prefix</em> (string, required)
-</dt>
-<dd>
-<p>
- An address prefix to match against target and source addresses. This pattern must be of the form <em><text>.<text1>.<textN></em> or <em><text></em> or <em><text>.</em> and matches any address that contains that prefix. For example, if the prefix is set to org.apache (or org.apache.), any address that has the prefix <em>org.apache</em> (like org.apache.dev) will match. Note that a prefix must not start with a (.), can end in a (.) and can contain zero or more dots (.). Any characters between the dots are simply treated as part of the address
-</p>
-</dd>
-<dt class="hdlist1">
-<em>dir</em> (One of [<em>in</em>, <em>out</em>, <em>both</em>], default=<em>both</em>)
-</dt>
-<dd>
-<p>
- Link direction for match: <em>in</em> matches only links inbound to the client; <em>out</em> matches only links outbound from the client; <em>both</em> matches any link.
-</p>
-</dd>
-<dt class="hdlist1">
-<em>connector</em> (string)
-</dt>
-<dd>
-<p>
- The name of the on-demand connector used to reach the target node’s container. If this value is not provided, it means that the target container is expected to be connected to a different router in the network. This prevents links to a link-routable address from being misinterpreted as message-routing links when there is no route to a valid destination available.
-</p>
-</dd>
-</dl></div>
-</div>
</div>
</div>
<div class="sect1">
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/man/qdrouterd.html.in
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/man/qdrouterd.html.in b/input/releases/qpid-dispatch-master/man/qdrouterd.html.in
index 0b85b2e..366c7e3 100644
--- a/input/releases/qpid-dispatch-master/man/qdrouterd.html.in
+++ b/input/releases/qpid-dispatch-master/man/qdrouterd.html.in
@@ -7,7 +7,7 @@
<div class="sect1">
<h2 id="_description">DESCRIPTION</h2>
<div class="sectionbody">
-<div class="paragraph"><p>The Qpid Dispatch router (qdrouterd) is a network daemon that directs
+<div class="paragraph"><p>The Qpid Dispatch router (<em>qdrouterd</em>) is a network daemon that directs
AMQP 1.0 messages between endpoints, such as messaging clients and
servers.</p></div>
</div>
@@ -40,7 +40,7 @@ servers.</p></div>
</dt>
<dd>
<p>
- Configuration flie.
+ Configuration file.
</p>
</dd>
</dl></div>
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/man/qdstat.html.in
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/man/qdstat.html.in b/input/releases/qpid-dispatch-master/man/qdstat.html.in
index 81f209e..2d15ae9 100644
--- a/input/releases/qpid-dispatch-master/man/qdstat.html.in
+++ b/input/releases/qpid-dispatch-master/man/qdstat.html.in
@@ -7,8 +7,7 @@
<div class="sect1">
<h2 id="_description">DESCRIPTION</h2>
<div class="sectionbody">
-<div class="paragraph"><p>Shows status information about networks of Dispatch routers. It can display
-connections, network nodes and links, and router stats such as memory use.</p></div>
+<div class="paragraph"><p>An AMQP monitoring tool that shows status information about networks of Dispatch routers. It can display connections, network nodes and links, and router stats such as memory use.</p></div>
</div>
</div>
<div class="sect1">
@@ -43,7 +42,7 @@ connections, network nodes and links, and router stats such as memory use.</p></
<div class="sect2">
<h3 id="_connection_options">Connection Options</h3>
<div class="paragraph"><p>-b URL, --bus=URL
-: URL of the messaging bus to connect to (default</p></div>
+: URL of the messaging bus to connect to (default 0.0.0.0)</p></div>
<div class="paragraph"><p>-r ROUTER-ID, --router=ROUTER-ID
: Router to be queried</p></div>
<div class="paragraph"><p>-t SECS, --timeout=SECS
@@ -82,7 +81,7 @@ id
</dt>
<dd>
<p>
-Unique connection identifier
+The connection’s unique identifier.
</p>
</dd>
<dt class="hdlist1">
@@ -90,7 +89,7 @@ host
</dt>
<dd>
<p>
-The hostname or internet address of the remotely connected AMQP container
+The hostname or internet address of the remotely-connected AMQP container.
</p>
</dd>
<dt class="hdlist1">
@@ -98,7 +97,7 @@ container
</dt>
<dd>
<p>
-The container-name of the remotely connected AMQP container
+The container name of the remotely-connected AMQP container.
</p>
</dd>
<dt class="hdlist1">
@@ -106,22 +105,22 @@ role
</dt>
<dd>
<p>
-The configured role of the connection
+The connection’s role:
</p>
<div class="ulist"><ul>
<li>
<p>
-normal - Normal connections from client to router
+<em>normal</em> - The normal connection from a client to a router.
</p>
</li>
<li>
<p>
-inter-router - Connection between routers to form a network
+<em>inter-router</em> - The connection between routers to form a network.
</p>
</li>
<li>
<p>
-route-container - Connection to/from a Broker or other host to receive link-routes and waypoints
+<em>route-container</em> - The connection to or from a broker or other host to receive link routes and waypoints.
</p>
</li>
</ul></div>
@@ -131,17 +130,17 @@ dir
</dt>
<dd>
<p>
-The direction of connection establishment
+The direction in which the connection was established:
</p>
<div class="ulist"><ul>
<li>
<p>
-in - The connection was initiated by the remote container
+<em>in</em> - The connection was initiated by the remote container.
</p>
</li>
<li>
<p>
-out - The connection was initiated by this router
+<em>out</em> - The connection was initiated by this router.
</p>
</li>
</ul></div>
@@ -151,8 +150,7 @@ security
</dt>
<dd>
<p>
-A description of the security/encryption in effect for this
-connection
+The security or encryption method, if any, used for this connection.
</p>
</dd>
<dt class="hdlist1">
@@ -160,8 +158,7 @@ authentication
</dt>
<dd>
<p>
-The method and user-id of the authenticated user for
-this connection
+The authentication method and user ID of the connection’s authenticated user.
</p>
</dd>
</dl></div>
@@ -174,22 +171,22 @@ type
</dt>
<dd>
<p>
-Type of link
+The type of link:
</p>
<div class="ulist"><ul>
<li>
<p>
-router-control - An inter-router link that is reserved for control messages exchanged between routers
+<em>router-control</em> - An inter-router link that is reserved for control messages exchanged between routers.
</p>
</li>
<li>
<p>
-inter-router - An inter-router link that is used for normal message-routed deliveries
+<em>inter-router</em> - An inter-router link that is used for normal message-routed deliveries.
</p>
</li>
<li>
<p>
-endpoint - A normal link to an external endpoint container
+<em>endpoint</em> - A normal link to an external endpoint container.
</p>
</li>
</ul></div>
@@ -199,17 +196,17 @@ dir
</dt>
<dd>
<p>
-The direction of message flow on the link
+The direction that messages flow on the link:
</p>
<div class="ulist"><ul>
<li>
<p>
-in - Deliveries flow inbound to the router
+<em>in</em> - Deliveries flow inbound to the router.
</p>
</li>
<li>
<p>
-out - Deliveries flow outbound from the router
+<em>out</em> - Deliveries flow outbound from the router.
</p>
</li>
</ul></div>
@@ -219,8 +216,8 @@ conn id
</dt>
<dd>
<p>
-Unique identifier of the connection over which this link is
-attached
+The unique identifier of the connection over which this link is
+attached.
</p>
</dd>
<dt class="hdlist1">
@@ -228,7 +225,7 @@ id
</dt>
<dd>
<p>
-Unique identifier of this link
+The unique identifier of this link.
</p>
</dd>
<dt class="hdlist1">
@@ -237,7 +234,7 @@ peer
<dd>
<p>
For link-routed links, the unique identifier of the peer link. In
-link routing, an inbound link is paired with an outbound link
+link routing, an inbound link is paired with an outbound link.
</p>
</dd>
<dt class="hdlist1">
@@ -245,15 +242,47 @@ class
</dt>
<dd>
<p>
-Class of the address bound to the link
+The class of the address bound to the link:
</p>
+<div class="ulist"><ul>
+<li>
+<p>
+<em>local</em> - The address that is local to this router (temporary).
+</p>
+</li>
+<li>
+<p>
+<em>topo</em> - A topological address used for router control messages.
+</p>
+</li>
+<li>
+<p>
+<em>router</em> - A summary router address used to route messages to a remote router’s local addresses.
+</p>
+</li>
+<li>
+<p>
+<em>mobile</em> - A mobile address for an attached consumer or producer.
+</p>
+</li>
+<li>
+<p>
+<em>link-in</em> - The address match for incoming routed links.
+</p>
+</li>
+<li>
+<p>
+<em>link-out</em> - The address match for outgoing routed links.
+</p>
+</li>
+</ul></div>
</dd>
<dt class="hdlist1">
addr
</dt>
<dd>
<p>
-The address bound to the link
+The address bound to the link.
</p>
</dd>
<dt class="hdlist1">
@@ -261,7 +290,7 @@ phs
</dt>
<dd>
<p>
-The phase of the address bound to the link
+The phase of the address bound to the link.
</p>
</dd>
<dt class="hdlist1">
@@ -269,7 +298,7 @@ cap
</dt>
<dd>
<p>
-The capacity, in deliveries, of the link
+The capacity, in deliveries, of the link.
</p>
</dd>
<dt class="hdlist1">
@@ -277,7 +306,7 @@ undel
</dt>
<dd>
<p>
-The number of undelivered messages stored on the link’s FIFO
+The number of undelivered messages stored on the link’s FIFO.
</p>
</dd>
<dt class="hdlist1">
@@ -285,7 +314,7 @@ unsett
</dt>
<dd>
<p>
-The number of unsettled deliveries being tracked by the link
+The number of unsettled deliveries being tracked by the link.
</p>
</dd>
<dt class="hdlist1">
@@ -293,37 +322,65 @@ del
</dt>
<dd>
<p>
-The total number of deliveries that have transited this link
+The total number of deliveries that have transited this link.
+</p>
+</dd>
+<dt class="hdlist1">
+presett
+</dt>
+<dd>
+<p>
+The number of pre-settled deliveries that transited this link.
+</p>
+</dd>
+<dt class="hdlist1">
+acc
+</dt>
+<dd>
+<p>
+The number of deliveries on this link that were accepted.
+</p>
+</dd>
+<dt class="hdlist1">
+rej
+</dt>
+<dd>
+<p>
+The number of deliveries on this link that were rejected.
+</p>
+</dd>
+<dt class="hdlist1">
+rel
+</dt>
+<dd>
+<p>
+The number of deliveries on this link that were released.
+</p>
+</dd>
+<dt class="hdlist1">
+mod
+</dt>
+<dd>
+<p>
+The number of deliveries on this link that were modified.
</p>
</dd>
-</dl></div>
-<div class="paragraph"><p>presett:
-The number of pre-settled deliveries that transited this link</p></div>
-<div class="paragraph"><p>acc:
-The number of deliveries on this link that were accepted</p></div>
-<div class="paragraph"><p>rej:
-The number of deliveries on this link that were rejected</p></div>
-<div class="paragraph"><p>rel:
-The number of deliveries on this link that were released</p></div>
-<div class="paragraph"><p>mod:
-The number of deliveries on this link that were modified</p></div>
-<div class="dlist"><dl>
<dt class="hdlist1">
admin
</dt>
<dd>
<p>
-The administrative status of the link
+The administrative status of the link:
</p>
<div class="ulist"><ul>
<li>
<p>
-enabled - The link is enabled for normal operation
+<em>enabled</em> - The link is enabled for normal operation.
</p>
</li>
<li>
<p>
-disabled - The link is disabled and should be quiescing or stopped (not yet supported)
+<em>disabled</em> - The link is disabled and should be quiescing or stopped (not yet supported).
</p>
</li>
</ul></div>
@@ -333,27 +390,27 @@ oper
</dt>
<dd>
<p>
-The operational status of the link
+The operational status of the link:
</p>
<div class="ulist"><ul>
<li>
<p>
-up - The link is operational
+<em>up</em> - The link is operational.
</p>
</li>
<li>
<p>
-down - The link is not attached
+<em>down</em> - The link is not attached.
</p>
</li>
<li>
<p>
-quiescing - The link is in the process of quiescing (not yet supported)
+<em>quiescing</em> - The link is in the process of quiescing (not yet supported).
</p>
</li>
<li>
<p>
-idle - The link has completed quiescing and is idle (not yet supported)
+<em>idle</em> - The link has completed quiescing and is idle (not yet supported).
</p>
</li>
</ul></div>
@@ -363,7 +420,7 @@ name
</dt>
<dd>
<p>
-The link name (only shown if the -v option is provided)
+The link name (only shown if the -v option is provided).
</p>
</dd>
</dl></div>
@@ -375,7 +432,7 @@ router-id
</dt>
<dd>
<p>
-Identifier of the router
+The router’s ID.
</p>
</dd>
<dt class="hdlist1">
@@ -383,7 +440,7 @@ next-hop
</dt>
<dd>
<p>
-If this router is not a neighbor, identifies the next-hop neighbor used to reach this router
+If this router is not a neighbor, this field identifies the next-hop neighbor used to reach this router.
</p>
</dd>
<dt class="hdlist1">
@@ -391,7 +448,7 @@ link
</dt>
<dd>
<p>
-Unique identifier of the link to the neighbor router
+The ID of the link to the neighbor router.
</p>
</dd>
<dt class="hdlist1">
@@ -399,7 +456,7 @@ cost
</dt>
<dd>
<p>
-The topology cost to this remote router (with -v option only)
+The topology cost to this remote router (with -v option only).
</p>
</dd>
<dt class="hdlist1">
@@ -407,7 +464,7 @@ neighbors
</dt>
<dd>
<p>
-The list of neighbor routers (the router’s link-state) (with -v option only)
+The list of neighbor routers (the router’s link-state). This field is available only if you specify the -v option.
</p>
</dd>
<dt class="hdlist1">
@@ -415,7 +472,7 @@ valid-origins
</dt>
<dd>
<p>
-The list of origin routers for which the best path to the listed router passes through this router (with -v option only)
+The list of origin routers for which the best path to the listed router passes through this router (available only with the -v option).
</p>
</dd>
</dl></div>
@@ -429,27 +486,27 @@ class
</dt>
<dd>
<p>
-The class of the listed address
+The class of the address:
</p>
<div class="ulist"><ul>
<li>
<p>
-local - Address that is local to this router
+<em>local</em> - The address that is local to this router.
</p>
</li>
<li>
<p>
-topo - Topological address used for router control messages
+<em>topo</em> - The topological address used for router control messages.
</p>
</li>
<li>
<p>
-router - A summary router address used to route messages to a remote router’s local addresses
+<em>router</em> - A summary router address used to route messages to a remote router’s local addresses.
</p>
</li>
<li>
<p>
-mobile - A mobile address for an attached consumer or producer
+<em>mobile</em> - A mobile address for an attached consumer or producer.
</p>
</li>
</ul></div>
@@ -459,7 +516,7 @@ addr
</dt>
<dd>
<p>
-The address text
+The address text.
</p>
</dd>
<dt class="hdlist1">
@@ -475,27 +532,27 @@ distrib
</dt>
<dd>
<p>
-Distribution method used for this address
+One of the following distribution methods used for this address:
</p>
<div class="ulist"><ul>
<li>
<p>
-multicast - A copy of each message is delivered once to each consumer for the address
+<em>multicast</em> - A copy of each message is delivered once to each consumer for the address.
</p>
</li>
<li>
<p>
-closest - Each message is delivered to only one consumer for the address. The closest (lowest cost) consumer will be chosen. If there are multiple lowest-cost consumers, deliveries will be spread across those consumers.
+<em>closest</em> - Each message is delivered to only one consumer for the address. The closest (lowest cost) consumer will be chosen. If there are multiple lowest-cost consumers, deliveries will be spread across those consumers.
</p>
</li>
<li>
<p>
-balanced - Each message is delivered to only one consumer for the address. The consumer with the fewest outstanding (unsettled) deliveries will be chosen. The cost of the route to the consumer is a threshold for delivery (i.e. higher cost consumers will only receive deliveries if closer consumers are backed up).
+<em>balanced</em> - Each message is delivered to only one consumer for the address. The consumer with the fewest outstanding (unsettled) deliveries will be chosen. The cost of the route to the consumer is a threshold for delivery (that is, higher cost consumers will only receive deliveries if closer consumers are backed up).
</p>
</li>
<li>
<p>
-flood - Used only for router-control traffic. This is multicast without prevention of duplicate deliveries.
+<em>flood</em> - Used only for router-control traffic. This is multicast without the prevention of duplicate deliveries.
</p>
</li>
</ul></div>
@@ -505,7 +562,7 @@ in-proc
</dt>
<dd>
<p>
-The number of in-process consumers for this address
+The number of in-process consumers for this address.
</p>
</dd>
<dt class="hdlist1">
@@ -513,7 +570,7 @@ local
</dt>
<dd>
<p>
-The number of local (on this router) consumers for this address
+For this router, the number of local consumers for this address.
</p>
</dd>
<dt class="hdlist1">
@@ -521,7 +578,7 @@ remote
</dt>
<dd>
<p>
-The number of remote routers that have at least one consumer for this address
+The number of remote routers that have at least one consumer for this address.
</p>
</dd>
<dt class="hdlist1">
@@ -529,7 +586,7 @@ cntnr
</dt>
<dd>
<p>
-The number of locally attached containers that are destinations for link-routes on this address
+The number of locally-attached containers that are destinations for link routes on this address.
</p>
</dd>
<dt class="hdlist1">
@@ -537,7 +594,7 @@ in
</dt>
<dd>
<p>
-The number of deliveries for this address that entered the network on this router
+The number of deliveries for this address that entered the network on this router.
</p>
</dd>
<dt class="hdlist1">
@@ -545,7 +602,7 @@ out
</dt>
<dd>
<p>
-The number of deliveries for this address that exited the network on this router
+The number of deliveries for this address that exited the network on this router.
</p>
</dd>
<dt class="hdlist1">
@@ -553,7 +610,7 @@ thru
</dt>
<dd>
<p>
-The number of deliveries for this address that were forwarded to other routers
+The number of deliveries for this address that were forwarded to other routers.
</p>
</dd>
<dt class="hdlist1">
@@ -561,7 +618,7 @@ to-proc
</dt>
<dd>
<p>
-The number of deliveries for this address that were delivered to an in-process consumer
+The number of deliveries for this address that were delivered to an in-process consumer.
</p>
</dd>
<dt class="hdlist1">
@@ -569,7 +626,7 @@ from-proc
</dt>
<dd>
<p>
-The number of deliveries for this address that were received from an in-process producer
+The number of deliveries for this address that were received from an in-process producer.
</p>
</dd>
</dl></div>
@@ -582,7 +639,7 @@ prefix
</dt>
<dd>
<p>
-The prefix for matching addresses of routed links
+The address prefix of the link route.
</p>
</dd>
<dt class="hdlist1">
@@ -590,7 +647,7 @@ dir
</dt>
<dd>
<p>
-The direction (from the router’s perspective) of matching links
+The direction of matching links (from this router’s perspective).
</p>
</dd>
<dt class="hdlist1">
@@ -598,32 +655,25 @@ distrib
</dt>
<dd>
<p>
-The distribution method used for routed links
-</p>
-<div class="ulist"><ul>
-<li>
-<p>
-linkBalanced - the only supported distribution for routed links
+The distribution method used for routed links. This value should always be <em>linkBalanced</em>, which is the only supported distribution for routed links.
</p>
-</li>
-</ul></div>
</dd>
<dt class="hdlist1">
status
</dt>
<dd>
<p>
-Operational status of the link route
+The operational status of the link route:
</p>
<div class="ulist"><ul>
<li>
<p>
-active - Route is actively routing attaches (i.e. ready for use)
+<em>active</em> - The route is actively routing attaches (it is ready for use).
</p>
</li>
<li>
<p>
-inactive - Route is inactive because there is no local destination connected
+<em>inactive</em> - The route is inactive, because no local destination is connected.
</p>
</li>
</ul></div>
@@ -638,7 +688,7 @@ addr
</dt>
<dd>
<p>
-The address of the auto link
+The auto link’s address.
</p>
</dd>
<dt class="hdlist1">
@@ -646,17 +696,17 @@ dir
</dt>
<dd>
<p>
-The direction of message flow for the auto link
+The direction that messages flow over the auto link:
</p>
<div class="ulist"><ul>
<li>
<p>
-in - Messages flow in from the route-container to the router network
+<em>in</em> - Messages flow in from the route-container to the router network.
</p>
</li>
<li>
<p>
-out - Messages flow out to the route-container from the router network
+<em>out</em> - Messages flow out to the route-container from the router network.
</p>
</li>
</ul></div>
@@ -666,7 +716,7 @@ phs
</dt>
<dd>
<p>
-Phase of the address for this auto link
+The address phase for this auto link.
</p>
</dd>
<dt class="hdlist1">
@@ -674,7 +724,7 @@ link
</dt>
<dd>
<p>
-Unique identifier of the link managed by this auto link
+The ID of the link managed by this auto link.
</p>
</dd>
<dt class="hdlist1">
@@ -682,37 +732,37 @@ status
</dt>
<dd>
<p>
-The operational status of this auto link
+The operational status of this auto link:
</p>
<div class="ulist"><ul>
<li>
<p>
-inactive - There is no connected container for this auto link
+<em>inactive</em> - There is no connected container for this auto link.
</p>
</li>
<li>
<p>
-attaching - The link is attaching to the container
+<em>attaching</em> - The link is attaching to the container.
</p>
</li>
<li>
<p>
-failed - The link-attach failed
+<em>failed</em> - The link-attach failed.
</p>
</li>
<li>
<p>
-active - The link is operational
+<em>active</em> - The link is operational.
</p>
</li>
<li>
<p>
-quiescing - The link is quiescing (not yet supported)
+<em>quiescing</em> - The link is quiescing (not yet supported).
</p>
</li>
<li>
<p>
-idle - The link is idle (not yet supported)
+<em>idle</em> - The link is idle (not yet supported).
</p>
</li>
</ul></div>
@@ -722,7 +772,7 @@ lastErr
</dt>
<dd>
<p>
-The description of the last attach failure that occurred on this auto link
+The description of the last attach failure that occurred on this auto link.
</p>
</dd>
</dl></div>
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/qdmanage.8.html.in
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/qdmanage.8.html.in b/input/releases/qpid-dispatch-master/qdmanage.8.html.in
deleted file mode 100644
index 576260c..0000000
--- a/input/releases/qpid-dispatch-master/qdmanage.8.html.in
+++ /dev/null
@@ -1,245 +0,0 @@
-<div class="sect1">
-<h2 id="_synopsis">SYNOPSIS</h2>
-<div class="sectionbody">
-<div class="paragraph"><p><strong>qdmanage</strong> [<em>OPTIONS</em>] <em>OPERATION</em> [<em>ARGUMENTS</em>]</p></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_description">DESCRIPTION</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>An AMQP management client for use with qdrouterd. Sends AMQP management
-operations requests and prints the response in JSON format. This is a
-generic AMQP management tool and can be used with any standard AMQP
-managed endpoint, not just with qdrouter.</p></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_options">OPTIONS</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>-h, --help
-: show this help message and exit</p></div>
-<div class="paragraph"><p>--version
-: Print version and exit.</p></div>
-<div class="paragraph"><p>--type=TYPE
-: Type of entity to operate on.</p></div>
-<div class="paragraph"><p>--name=NAME
-: Name of entity to operate on.</p></div>
-<div class="paragraph"><p>--identity=ID
-: Identity of entity to operate on.</p></div>
-<div class="paragraph"><p>--indent=INDENT
-: Pretty-printing indent. -1 means don’t pretty-print</p></div>
-<div class="paragraph"><p>--stdin
-: Read attributes as JSON map or list of maps from</p></div>
-<div class="paragraph"><p>--body=BODY
-: JSON value to use as body of a non-standard operation</p></div>
-<div class="paragraph"><p>--properties=PROPERTIES
-: JSON map to use as properties for a non-standard operation call.</p></div>
-<div class="sect2">
-<h3 id="_connection_options">Connection Options</h3>
-<div class="paragraph"><p>-b URL, --bus=URL
-: URL of the messaging bus to connect to (default 0.0.0.0)</p></div>
-<div class="paragraph"><p>-r ROUTER-ID, --router=ROUTER-ID
-: Router to be queried</p></div>
-<div class="paragraph"><p>-t SECS, --timeout=SECS
-: Maximum time to wait for connection in seconds (default 5)</p></div>
-<div class="paragraph"><p>--ssl-certificate=CERT
-: Client SSL certificate (PEM Format)</p></div>
-<div class="paragraph"><p>--ssl-key=KEY
-: Client SSL private key (PEM Format)</p></div>
-<div class="paragraph"><p>--ssl-trustfile=TRUSTED-CA-DB
-: Trusted Certificate Authority Database file (PEM Format)</p></div>
-<div class="paragraph"><p>--ssl-password=PASSWORD
-: Certificate password, will be prompted if not specifed.</p></div>
-<div class="paragraph"><p>--ssl-password-file=SSL-PASSWORD-FILE
-: Certificate password, will be prompted if not specifed.</p></div>
-<div class="paragraph"><p>--sasl-mechanisms=SASL-MECHANISMS
-: Allowed sasl mechanisms to be supplied during the sasl handshake.</p></div>
-<div class="paragraph"><p>--sasl-username=SASL-USERNAME
-: User name for SASL plain authentication</p></div>
-<div class="paragraph"><p>--sasl-password=SASL-PASSWORD
-: Password for SASL plain authentication</p></div>
-<div class="paragraph"><p>--sasl-password-file=SASL-PASSWORD-FILE
-: Password for SASL plain authentication</p></div>
-<div class="paragraph"><p>--ssl-disable-peer-name-verify
-: Disables SSL peer name verification. WARNING - This option is insecure and must not be used in production environments</p></div>
-</div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_operations">OPERATIONS</h2>
-<div class="sectionbody">
-<div class="dlist"><dl>
-<dt class="hdlist1">
-<code>query</code> [<em>ATTR</em>…]
-</dt>
-<dd>
-<p>
- Print attributes for multiple entities. Prints all entities by default, use
- --type, --name or --identity options to restrict which entities are printed.
- Prints the attributes named in the ATTR list, or all attributes if none are
- listed.
-</p>
-</dd>
-<dt class="hdlist1">
-<code>create</code> [<em>ATTR=VALUE</em>…]
-</dt>
-<dd>
-<p>
- Create a new entity with the specified attributes. With the --stdin
- option, read attributes from stdin. This can be a JSON map of
- attributes to create a single entity, or a JSON list of maps to create
- multiple entities.
-</p>
-</dd>
-<dt class="hdlist1">
-<code>read</code>
-</dt>
-<dd>
-<p>
- Print all the attributes of a single entity, specified by the --name or
- --identity options.
-</p>
-</dd>
-<dt class="hdlist1">
-<code>update</code> [<em>ATTR=VALUE</em>…]
-</dt>
-<dd>
-<p>
- Update the attributes of an existing entity. If an ATTR name is listed with
- no =VALUE, that attribute will be deleted from the entity. With the --stdin
- option, read attributes from stdin. This can be a JSON map of attributes to
- update a single entity, or a JSON list of maps to update multiple entities.
-</p>
-</dd>
-<dt class="hdlist1">
-<code>delete</code>
-</dt>
-<dd>
-<p>
- Delete an entity specified by the --name or --identity options.
-</p>
-</dd>
-<dt class="hdlist1">
-<code>get-types</code> [<em>TYPE</em>]
-</dt>
-<dd>
-<p>
- List entity types with their base types. With no arguments list all
- types.
-</p>
-</dd>
-<dt class="hdlist1">
-<code>get-operations</code> [<em>TYPE</em>]
-</dt>
-<dd>
-<p>
- List entity types with their operations. With no arguments list all
- types.
-</p>
-</dd>
-<dt class="hdlist1">
-<code>get-attributes</code> [<em>TYPE</em>]
-</dt>
-<dd>
-<p>
- List entity types with their attributes. With no arguments list all
- types.
-</p>
-</dd>
-<dt class="hdlist1">
-<code>get-annotations</code> [<em>TYPE</em>]
-</dt>
-<dd>
-<p>
- List entity types with their annotations. With no arguments list all
- types.
-</p>
-</dd>
-<dt class="hdlist1">
-<code>get-mgmt-nodes</code>
-</dt>
-<dd>
-<p>
- List all other known management nodes connected to this one.
-</p>
-</dd>
-<dt class="hdlist1">
-<code>get-json-schema</code> [<em>INDENT</em>]
-</dt>
-<dd>
-<p>
- Get the router schema in JSON format. Optional integer indent for
- formatted output.
-</p>
-</dd>
-<dt class="hdlist1">
-<code>get-log</code> [<em>INDENT</em>]
-</dt>
-<dd>
-<p>
- Get recent log entries from the router.
-</p>
-</dd>
-</dl></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_files">FILES</h2>
-<div class="sectionbody">
-<div class="dlist"><dl>
-<dt class="hdlist1">
-/usr/local/share/doc/qpid-dispatch/qdrouter.json
-</dt>
-<dd>
-<p>
- Management schema for qdrouterd.
-</p>
-</dd>
-<dt class="hdlist1">
-/usr/local/share/doc/qpid-dispatch/qdrouter.json.readme.txt
-</dt>
-<dd>
-<p>
- Explanation of the management schema.
-</p>
-</dd>
-</dl></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_examples">EXAMPLES</h2>
-<div class="sectionbody">
-<div class="listingblock">
-<div class="title">Show the logging configuration</div>
-<div class="content">
-<pre><code>qdmanage query --type=log</code></pre>
-</div></div>
-<div class="listingblock">
-<div class="title">Enable debug and higher log messages by default:</div>
-<div class="content">
-<pre><code>qdmanage update name=log/DEFAULT enable=debug+</code></pre>
-</div></div>
-<div class="listingblock">
-<div class="title">Enable trace log messages only for the MESSAGE module and direct MESSAGE logs to the file "test.log"</div>
-<div class="content">
-<pre><code>qdmanage update name=log/MESSAGE enable=trace output=test.log</code></pre>
-</div></div>
-<div class="listingblock">
-<div class="title">Set MESSAGE logging back to the default</div>
-<div class="content">
-<pre><code>qdmanage update name=log/MESSAGE enable=default</code></pre>
-</div></div>
-<div class="listingblock">
-<div class="title">Disable MESSAGE logging</div>
-<div class="content">
-<pre><code>qdmanage update name=log/MESSAGE enable=none</code></pre>
-</div></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_see_also">SEE ALSO</h2>
-<div class="sectionbody">
-<div class="paragraph"><p><em>qdrouterd(8)</em>, <em>qdstat(8)</em>, <em>qdrouterd.conf(5)</em></p></div>
-<div class="paragraph"><p><a href="http://qpid.apache.org/components/dispatch-router">http://qpid.apache.org/components/dispatch-router</a></p></div>
-</div>
-</div>
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/030c23a6/input/releases/qpid-dispatch-master/qdrouterd.8.html.in
----------------------------------------------------------------------
diff --git a/input/releases/qpid-dispatch-master/qdrouterd.8.html.in b/input/releases/qpid-dispatch-master/qdrouterd.8.html.in
deleted file mode 100644
index 965f0cd..0000000
--- a/input/releases/qpid-dispatch-master/qdrouterd.8.html.in
+++ /dev/null
@@ -1,53 +0,0 @@
-<div class="sect1">
-<h2 id="_synopsis">SYNOPSIS</h2>
-<div class="sectionbody">
-<div class="paragraph"><p><strong>qdrouterd</strong> [<em>OPTIONS</em>]</p></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_description">DESCRIPTION</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>The Qpid Dispatch router (qdrouterd) is a network daemon that directs
-AMQP 1.0 messages between endpoints, such as messaging clients and
-servers.</p></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_options">OPTIONS</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>-c, --config=PATH (/usr/local/etc/qpid-dispatch/qdrouterd.conf)
-: Load configuration from file at PATH</p></div>
-<div class="paragraph"><p>-I, --include=PATH (/usr/local/lib/qpid-dispatch/python)
-: Location of Dispatch’s Python library</p></div>
-<div class="paragraph"><p>-d, --daemon
-: Run process as a SysV-style daemon</p></div>
-<div class="paragraph"><p>-P, --pidfile
-: If daemon, the file for the stored daemon pid</p></div>
-<div class="paragraph"><p>-U, --user
-: If daemon, the username to run as</p></div>
-<div class="paragraph"><p>-h, --help
-: Print this help</p></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_files">FILES</h2>
-<div class="sectionbody">
-<div class="dlist"><dl>
-<dt class="hdlist1">
-/usr/local/etc/qdrouterd.conf
-</dt>
-<dd>
-<p>
- Configuration flie.
-</p>
-</dd>
-</dl></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_see_also">SEE ALSO</h2>
-<div class="sectionbody">
-<div class="paragraph"><p><em>qdrouterd.conf(5)</em>, <em>qdstat(8)</em>, <em>qdmanage(8)</em></p></div>
-<div class="paragraph"><p><a href="http://qpid.apache.org/components/dispatch-router">http://qpid.apache.org/components/dispatch-router</a></p></div>
-</div>
-</div>
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org