qpid-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gmur...@apache.org
Subject [6/7] qpid-site git commit: NO-JIRA - Updated qpid-dispatch-master documentation
Date Mon, 08 Aug 2016 14:00:22 GMT
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/3cbe9ebf/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
index dec4cc4..5a19e5c 100644
--- a/content/releases/qpid-dispatch-master/book.html
+++ b/content/releases/qpid-dispatch-master/book.html
@@ -114,20 +114,22 @@ https://github.com/apache/qpid-proton/blob/go1{/dir}/{file}#L{line}"/>
         <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 Master</a></li><li>1. Introduction</li></ul>
 
         <div id="-middle-content">
-          <hr>
-<h2><a name="introduction"></a>1. Introduction</h2>
-<h3><a name="overview"></a>1.1. Overview</h3>
-<p>The Dispatch router is an AMQP message router that provides
+          <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>
-<p>A messaging client can make a single AMQP connection into a messaging
+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>
-<p>The router is an intermediary for messages but it is <em>not</em> a broker. It
+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
@@ -137,14 +139,14 @@ the same path. This means that <em>responsibility</em> for the message is
 transfered from the original sender to the ultimate receiver <em>as if
 they were directly connected</em>. However this is done via a flexible
 network that allows highly configurable routing of the message
-transparent to both sender and receiver.</p>
-<p>There are some patterns where this enables "brokerless messaging"
+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>
-<p>For a "brokerless" example, consider the common brokered implementation
+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
@@ -153,8 +155,8 @@ discover this. With a dispatch network, the client can be informed
 immediately if its message cannot be delivered because nobody is
 listening. When the client receives acknowledgement of the request it
 knows not just that it is sitting on a queue, but that it has actually
-been received by the server.</p>
-<p>For an exampe of using dispatch to enhance the use of brokers, consider
+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
@@ -166,8 +168,8 @@ pattern with brokers alone. If a receiver is connected to a broker that
 has no messages, but there are messages on another broker, you have to
 somehow transfer them or leave them "stuck". With a dispatch network,
 <em>all</em> the receivers are connected to <em>all</em> the brokers. If there is a
-message anywhere it can be delivered to any receiver.</p>
-<p>The router is meant to be deployed in topologies of multiple routers,
+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
@@ -177,10 +179,12 @@ 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>
-<h3><a name="benefits"></a>1.2. Benefits</h3>
-<p>Simplifies connectivity</p>
-<ul>
+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
@@ -192,9 +196,9 @@ connection
 Avoid opening holes in firewalls for incoming connections
 </p>
 </li>
-</ul>
-<p>Provides messaging connectivity where there is no TCP/IP connectivity</p>
-<ul>
+</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
@@ -202,9 +206,9 @@ firewall) and be accessible by messaging endpoints in other networks
 (learn more).
 </p>
 </li>
-</ul>
-<p>Simplifies reliability</p>
-<ul>
+</ul></div>
+<div class="paragraph"><p>Simplifies reliability</p></div>
+<div class="ulist"><ul>
 <li>
 <p>
 Reliability and availability are provided using redundant topology,
@@ -221,27 +225,29 @@ Reliable end-to-end messaging without persistent stores
 Use a message broker only when you need store-and-forward semantics
 </p>
 </li>
-</ul>
-<h3><a name="features"></a>1.3. Features</h3>
-<ul>
+</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>
-<ul>
+<div class="ulist"><ul>
 <li>
 <p>
 Supports arbitrary network topology - no restrictions on redundancy
 </p>
-<ul>
+<div class="ulist"><ul>
 <li>
 <p>
 Automatic route computation - adjusts quickly to changes in topology
 </p>
 </li>
-</ul>
+</ul></div>
 </li>
-</ul>
+</ul></div>
 </li>
 <li>
 <p>
@@ -253,40 +259,50 @@ Provides remote access to brokers or other AMQP servers
 Security
 </p>
 </li>
-</ul>
-<hr>
-<h2><a name="using-qpid-dispatch"></a>2. Using Qpid Dispatch</h2>
-<h3><a name="configuration"></a>2.1. Configuration</h3>
-<p>The default configuration file is installed in
+</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>
-<p>To run the router, invoke the executable: <code>qdrouterd [-c my-config-file]</code></p>
-<p>For more details of the configuration file see the <em>qdrouterd.conf(5)</em> man
-page.</p>
-<h3><a name="tools"></a>2.2. Tools</h3>
-<h4><a name="qdstat"></a>2.2.1. qdstat</h4>
-<p><em>qdstat</em> is a command line tool that lets you view the status of a
+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>
+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" width="17%" valign="top"><em>Option</em> </th>
-<th align="left" width="83%" valign="top"><em>Description</em></th>
+<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" width="17%" valign="top"><p>-l</p></td>
-<td align="left" width="83%" valign="top"><p>Print a list of AMQP links attached to the router. Links are
+<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
@@ -294,65 +310,76 @@ router. Router links are attached to other routers in a network of
 routbers.</p></td>
 </tr>
 <tr>
-<td align="left" width="17%" valign="top"><p>-a</p></td>
-<td align="left" width="83%" valign="top"><p>Print a list of addresses known to the router.</p></td>
+<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" width="17%" valign="top"><p>-n</p></td>
-<td align="left" width="83%" valign="top"><p>Print a list of known routers in the network.</p></td>
+<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" width="17%" valign="top"><p>-c</p></td>
-<td align="left" width="83%" valign="top"><p>Print a list of connections to the router.</p></td>
+<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" width="17%" valign="top"><p>--autolinks</p></td>
-<td align="left" width="83%" valign="top"><p>Print a list of configured auto-links.</p></td>
+<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" width="17%" valign="top"><p>--linkroutes</p></td>
-<td align="left" width="83%" valign="top"><p>Print a list of configures link-routes.</p></td>
+<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>
-<p>For complete details see the <em>qdstat(8)</em> man page and the output of
-<code>qdstat --help</code>.</p>
-<h4><a name="qdmanage"></a>2.2.2. qdmanage</h4>
-<p><em>qdmanage</em> is a general-purpose AMQP management client that allows you
+<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>
-<p>For example you can query all the connection entities in the router:</p>
-<table border="0" bgcolor="#e8e8e8" width="100%" cellpadding="10"><tr><td>
+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>
-</td></tr></table>
-<p>To enable logging debug and higher level messages by default:</p>
-<table border="0" bgcolor="#e8e8e8" width="100%" cellpadding="10"><tr><td>
+</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>
-</td></tr></table>
-<p>In fact, everything that can be configured in the configuration file can
+</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>
-<table border="0" bgcolor="#e8e8e8" width="100%" cellpadding="10"><tr><td>
+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>
-</td></tr></table>
-<p>Now you can connect to port 5555, for exampple:</p>
-<table border="0" bgcolor="#e8e8e8" width="100%" cellpadding="10"><tr><td>
+</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>
-</td></tr></table>
-<p>For complete details see the <em>qdmanage(8)</em> man page and the output of
+</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>
-<h3><a name="basic-usage-and-examples"></a>2.3. Basic Usage and Examples</h3>
-<h4><a name="standalone-and-interior-modes"></a>2.3.1. Standalone and Interior Modes</h4>
-<p>The router can operate stand-alone or as a node in a network of routers.
+<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>
-<p>If your router is running in stand-alone mode, <em>qdstat -a</em> will look
-like the following:</p>
-<table border="0" bgcolor="#e8e8e8" width="100%" cellpadding="10"><tr><td>
+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
@@ -362,15 +389,16 @@ Router Addresses
   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>
-</td></tr></table>
-<p>Note that there are a number of known addresses. <em>$management</em> is the
+</div></div>
+<div class="paragraph"><p>Note that there are a number of known addresses. <em>$management</em> is the
 address of the router&#8217;s embedded management agent.
 <em>temp.1GThUllfR7N+BDP</em> is the temporary reply-to address of the <em>qdstat</em>
-client making requests to the agent.</p>
-<p>If you change the mode to interior and restart the processs, the same
+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>
-<table border="0" bgcolor="#e8e8e8" width="100%" cellpadding="10"><tr><td>
+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
@@ -385,21 +413,25 @@ Router Addresses
   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>
-</td></tr></table>
-<h4><a name="mobile-subscribers"></a>2.3.2. Mobile Subscribers</h4>
-<p>The term "mobile subscriber" simply refers to the fact that a client may
+</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>
-<p>To illustrate a subscription on a stand-alone router, you can use the
+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>
-<table border="0" bgcolor="#e8e8e8" width="100%" cellpadding="10"><tr><td>
+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>
-</td></tr></table>
-<p>This command creates a receiving link subscribed to the specified
-address. To verify the subscription:</p>
-<table border="0" bgcolor="#e8e8e8" width="100%" cellpadding="10"><tr><td>
+</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
@@ -410,20 +442,24 @@ Router Addresses
   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>
-</td></tr></table>
-<p>You can then, in a separate command window, run a sender to produce
-messages to that address:</p>
-<table border="0" bgcolor="#e8e8e8" width="100%" cellpadding="10"><tr><td>
+</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>
-</td></tr></table>
-<h4><a name="dynamic-reply-to"></a>2.3.3. Dynamic Reply-To</h4>
-<p>Dynamic reply-to can be used to obtain a reply-to address that routes
+</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&#8217;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>
-<table border="0" bgcolor="#e8e8e8" width="100%" cellpadding="10"><tr><td>
+routers' management addresses.</p></div>
+<div class="listingblock">
+<div class="content">
 <pre><code>#include &lt;qpid/messaging/Address.h&gt;
 #include &lt;qpid/messaging/Connection.h&gt;
 #include &lt;qpid/messaging/Message.h&gt;
@@ -464,10 +500,11 @@ int main() {
 
     connection.close();
 }</code></pre>
-</td></tr></table>
-<p>The equivalent program written in Python against the Proton Messenger
-API:</p>
-<table border="0" bgcolor="#e8e8e8" width="100%" cellpadding="10"><tr><td>
+</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():
@@ -498,11 +535,14 @@ def main():
     messenger.stop()
 
 main()</code></pre>
-</td></tr></table>
-<h3><a name="link-routing"></a>2.4. Link Routing</h3>
-<p>This feature was introduced in Qpid Dispatch 0.4. This feature was
-significantly updated in Qpid Dispatch 0.6.</p>
-<p>Link-routing is an alternative strategy for routing messages across a
+</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
@@ -510,17 +550,18 @@ decisions when link-attach frames arrive. A link is effectively chained
 across the network of routers from the establishing node to the
 destination node. Once the link is established, the transfer of message
 deliveries, flow frames, and dispositions is performed across the routed
-link.</p>
-<p>The main benefit to link-routing is that endpoints can use the full link
+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>
-<p>Why would one want to do this?  One reason is to provide client
-isolation.  A network like the following can be deployed:</p>
-<table border="0" bgcolor="#e8e8e8" width="100%" cellpadding="10"><tr><td>
+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
                        +-----------------+
                        |      +-----+    |
@@ -540,27 +581,29 @@ isolation.  A network like the following can be deployed:</p>
         |                 |           |                 |
         |                 |           |                 |
         +-----------------+           +-----------------+</code></pre>
-</td></tr></table>
-<p>The clients in Private Net B can be constrained (by firewall policy)
+</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>
-<p>For example, The router Ra can be configured to expose queues in
+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>
-<p>C1 is unable to create a TCP/IP connection to B1 because of its
+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>
-<p>Note that in this case, neither C1 nor B2 have been modified in any way
+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>
-<h4><a name="link-routing-configuration"></a>2.4.1. Configuration</h4>
-<p>Starting with the configured topology shown above, how is link-routing
-configured to support the example described above?</p>
-<p>First, router Ra needs to be told how to make a connection to the broker
-B2:</p>
-<table border="0" bgcolor="#e8e8e8" width="100%" cellpadding="10"><tr><td>
+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
@@ -568,12 +611,13 @@ B2:</p>
     port: &lt;B2-port&gt;
     saslMechanisms: ANONYMOUS
 }</code></pre>
-</td></tr></table>
-<p>This <em>route-container</em> connector tells the router how to connect to an
+</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>
-<p>Now, the router must be configured to route certain addresses to B2:</p>
-<table border="0" bgcolor="#e8e8e8" width="100%" cellpadding="10"><tr><td>
+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
@@ -585,18 +629,18 @@ linkRoute {
     dir: out
     connection: broker
 }</code></pre>
-</td></tr></table>
-<p>The linkRoute tells router Ra that any sender or receiver that is
+</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>
-<p>Note that receiving and sending links are configured and routed
+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>
-<p>Examples of addresses that "begin with <em>b2</em>" include:</p>
-<ul>
+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
@@ -612,40 +656,44 @@ b2.queues
 b2.queues.app1
 </p>
 </li>
-</ul>
-<p>When the route-container connector is configured, router Ra establishes
+</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>
-<p>On Rp and Rb, it is advisable to add the identical configuration. It is
+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>
-<p>This configuration tells the routers that link-routing is intended to be
+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>
-<p>The above configuration allows Rb and Rp to reject attaches that should
+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>
-<h3><a name="indirect-waypoints-and-auto-links"></a>2.5. Indirect Waypoints and Auto-Links</h3>
-<p>This feature was introduced in Qpid Dispatch 0.6. It is a significant
+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>
-<p>Auto-link is a feature of Qpid Dispatch Router that enables a router to
+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>
-<p>An auto-link manages the lifecycle of one AMQP link. If messages are to
+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>
-<blockquote>
-<ul>
+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
@@ -657,14 +705,16 @@ the container, or
 The AMQP container-id of the remote container.
 </p>
 </li>
-</ul>
-<p align="right">
-</p>
-</blockquote>
-<h4><a name="queue-waypoint-example"></a>2.5.1. Queue Waypoint Example</h4>
-<p>Here is an example configuration for routing messages deliveries through
-a pair of queues on a broker:</p>
-<table border="0" bgcolor="#e8e8e8" width="100%" cellpadding="10"><tr><td>
+</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
@@ -701,14 +751,15 @@ autoLink {
     dir: out
     connection: broker
 }</code></pre>
-</td></tr></table>
-<p>The <code>address</code> entity identifies a namespace <em>queue.</em> that will be used
+</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>
-<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>
-<table border="0" bgcolor="#e8e8e8" width="100%" cellpadding="10"><tr><td>
+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
@@ -717,10 +768,11 @@ AutoLinks
   queue.first   out  0            inactive
   queue.second  in   1            inactive
   queue.second  out  0            inactive</code></pre>
-</td></tr></table>
-<p>If a broker comes online with a queue called <em>queue.first</em>, the
-auto-links will attempt to activate:</p>
-<table border="0" bgcolor="#e8e8e8" width="100%" cellpadding="10"><tr><td>
+</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
@@ -729,60 +781,67 @@ AutoLinks
   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>
-</td></tr></table>
-<p>Note that two of the auto-links are in <em>failed</em> state because the queue
-does not exist on the broker.</p>
-<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>
-<table border="0" bgcolor="#e8e8e8" width="100%" cellpadding="10"><tr><td>
+</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>
-</td></tr></table>
-<p>and then look at the address statistics on the router:</p>
-<table border="0" bgcolor="#e8e8e8" width="100%" cellpadding="10"><tr><td>
+</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>
-</td></tr></table>
-<p>we see that <em>queue.first</em> appears twice in the list of addresses. The
+</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>
-<p>Note that three deliveries have been counted in the "in" and "out"
+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>
-<p>If we now use <code>simple_recv.py</code> to receive three messages from this address:</p>
-<table border="0" bgcolor="#e8e8e8" width="100%" cellpadding="10"><tr><td>
+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>
-</td></tr></table>
-<p>We receive the three queued messages. Looking at the addresses again, we
+</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>
-<table border="0" bgcolor="#e8e8e8" width="100%" cellpadding="10"><tr><td>
+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>
-</td></tr></table>
-<p>Note that even in a multi-router network, and with multiple producers
+</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>
-<h4><a name="sharded-queue-example"></a>2.5.2. Sharded Queue Example</h4>
-<p>Here is an extension of the above example to illustrate how Qpid
+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>
-<table border="0" bgcolor="#e8e8e8" width="100%" cellpadding="10"><tr><td>
+multiple brokers share the message-queueing load.</p></div>
+<div class="listingblock">
+<div class="content">
 <pre><code>connector {
     name: broker1
     role: route-container
@@ -827,66 +886,642 @@ autoLink {
     dir: out
     connection: broker2
 }</code></pre>
-</td></tr></table>
-<p>In the above configuration, there are two instances of <em>queue.first</em> on
+</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>
-<h4><a name="dynamically-adding-shards"></a>2.5.3. Dynamically Adding Shards</h4>
-<p>Since configurable entities in the router can also be accessed via the
+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>
-<table border="0" bgcolor="#e8e8e8" width="100%" cellpadding="10"><tr><td>
+using <code>qdmanage</code>:</p></div>
+<div class="listingblock">
+<div class="content">
 <pre><code>qdmanage create --type org.apache.qpid.dispatch.connector host=&lt;host&gt; port=&lt;port&gt; 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>
-</td></tr></table>
-<hr>
-<h2><a name="technical-details-and-specifications"></a>3. Technical Details and Specifications</h2>
-<h3><a name="client-compatibility"></a>3.1. Client Compatibility</h3>
-<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></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 = {
+    &lt;global settings&gt;
+}
+
+vhost = {
+    id: vhost-name
+    &lt;connection limits&gt;
+    groups: {
+        group-name: {
+            &lt;user group settings&gt;
+        }
+    }
+}</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>&lt;1&gt;</b>
+}
+
+vhost {
+    name: $default                 <b>&lt;2&gt;</b>
+    maxConnectionsPerUser: 10      <b>&lt;3&gt;</b>
+    allowUnknownUser: true         <b>&lt;4&gt;</b>
+    groups: {
+        $default: {
+            remoteHosts: *         <b>&lt;5&gt;</b>
+            sources: *             <b>&lt;6&gt;</b>
+            targets: *             <b>&lt;6&gt;</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>&lt;1&gt;</b>
+    allowUnknownUser: true                       <b>&lt;3&gt;</b>
+    groups: {
+        admin: {
+            users: alice, bob                    <b>&lt;2&gt;</b>
+            remoteHosts: 127.0.0.1, ::1          <b>&lt;4&gt;</b>
+            sources: *                           <b>&lt;5&gt;</b>
+            targets: *                           <b>&lt;5&gt;</b>
+        },
+        $default: {
+            remoteHosts: *                       <b>&lt;6&gt;</b>
+            sources: news*, sports*, chat*       <b>&lt;7&gt;</b>
+            targets: chat*                       <b>&lt;7&gt;</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>&lt;1&gt;</b>
+    groups: {
+        traders: {
+            users: trader-1, trader-2, ...       <b>&lt;2&gt;</b>
+            maxFrameSize: 10000                  <b>&lt;3&gt;</b>
+            maxSessionWindow: 500                <b>&lt;3&gt;</b>
+            maxSessions: 1                       <b>&lt;4&gt;</b>
+            ...
+        },
+        feeds: {
+            users: nyse-feed, nasdaq-feed        <b>&lt;5&gt;</b>
+            maxFrameSize: 60000                  <b>&lt;6&gt;</b>
+            maxSessionWindow: 20000              <b>&lt;6&gt;</b>
+            maxSessions: 3                       <b>&lt;7&gt;</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" width="22%" valign="top"><em>Client</em> </th>
-<th align="left" width="78%" valign="top"><em>Notes</em></th>
+<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" width="22%" valign="top"><p>qpid::messaging</p></td>
-<td align="left" width="78%" valign="top"><p>The Qpid messaging clients work with Dispatch Router
+<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" width="22%" valign="top"><p>Proton Reactor</p></td>
-<td align="left" width="78%" valign="top"><p>The Proton Reactor API is compatible with Dispatch
+<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" width="22%" valign="top"><p>Proton Messenger</p></td>
-<td align="left" width="78%" valign="top"><p>Messenger works with Dispatch Router.</p></td>
+<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>
-<h3><a name="addressing"></a>3.2. Addressing</h3>
-<p>AMQP addresses are used to control the flow of messages across a network
+</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&#8217;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>
-<p>Addresses designate various kinds of entities in a messaging network:</p>
-<ul>
+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
@@ -901,7 +1536,7 @@ Topics that match multiple consumers to multiple producers
 <p>
 Entities within a messaging broker:
 </p>
-<ul>
+<div class="ulist"><ul>
 <li>
 <p>
 Queues
@@ -917,23 +1552,23 @@ Durable Topics
 Exchanges
 </p>
 </li>
-</ul>
+</ul></div>
 </li>
-</ul>
-<p>The syntax of an AMQP address is opaque as far as the router network is
+</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>
-<p>Addresses have semantics associated with them. When an address is
+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>
-<p>Address semantics include the following considerations:</p>
-<ul>
+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
@@ -949,37 +1584,40 @@ control how routers behave when they see the address being used.</p>
 <em>Reliability</em> - N destinations, etc.
 </p>
 </li>
-</ul>
-<h4><a name="routing-patterns"></a>3.2.1. Routing patterns</h4>
-<p>Routing patterns constrain the paths that a message can take across a
-network.</p>
-<div>
+</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" width="18%" valign="top"><em>Pattern</em> </th>
-<th align="left" width="82%" valign="top"><em>Description</em></th>
+<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" width="18%" valign="top"><p><em>Direct</em></p></td>
-<td align="left" width="82%" valign="top"><p>Direct routing allows for only one consumer to use an address
+<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" width="18%" valign="top"><p><em>Multicast</em></p></td>
-<td align="left" width="82%" valign="top"><p>Multicast routing allows multiple consumers to use the
+<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" width="18%" valign="top"><p><em>Balanced</em></p></td>
-<td align="left" width="82%" valign="top"><p>Balanced routing also allows multiple consumers to use the
+<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>
@@ -987,53 +1625,59 @@ the set of consumers using the same address.</p></td>
 </tbody>
 </table>
 </div>
-<h4><a name="routing-mechanisms"></a>3.2.2. Routing mechanisms</h4>
-<p>The fact that addresses can be used in different ways suggests that
+</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>
-<blockquote>
-<p>In a network built of multiple routers connected by connections (i.e.,
+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>
-<p align="right">
-</p>
-</blockquote>
-<p>Each router serves as the terminus of a collection of incoming and
+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>
-<h5><a name="message-routing"></a>Message routing</h5>
-<p>Message routing occurs upon delivery of a message and is done based on
-the address in the message&#8217;s <code>to</code> field.</p>
-<p>When a delivery arrives on an incoming link, the router extracts 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&#8217;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&#8217;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>
+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" width="20%" valign="top"><em>Delivery</em> </th>
-<th align="left" width="80%" valign="top"><em>Handling</em></th>
+<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" width="20%" valign="top"><p><em>pre-settled</em></p></td>
-<td align="left" width="80%" valign="top"><p>If the arriving delivery is pre-settled (i.e., fire and
+<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&#8217;s destination.</p></td>
 </tr>
 <tr>
-<td align="left" width="20%" valign="top"><p><em>unsettled</em></p></td>
-<td align="left" width="80%" valign="top"><p>Unsettled delivery is also propagated across the network.
+<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
@@ -1044,83 +1688,95 @@ message traveled.</p></td>
 </tbody>
 </table>
 </div>
-<h3><a name="amqp-mapping"></a>3.3. AMQP Mapping</h3>
-<p>Dispatch Router is an AMQP router and as such, it provides extensions,
+</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&#8217;s use of AMQP.</p>
-<h4><a name="message-annotations"></a>3.3.1. Message Annotations</h4>
-<p>The following Message Annotation fields are defined by Dispatch Router:</p>
-<div>
+details of Dispatch Router&#8217;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" width="23%" valign="top"><em>Field</em> </th>
-<th align="left" width="19%" valign="top"><em>Type</em> </th>
-<th align="left" width="58%" valign="top"><em>Description</em></th>
+<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" width="23%" valign="top"><p>x-opt-qd.ingress</p></td>
-<td align="left" width="19%" valign="top"><p>string</p></td>
-<td align="left" width="58%" valign="top"><p>The identity of the ingress router for a
+<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" width="23%" valign="top"><p>x-opt-qd.trace</p></td>
-<td align="left" width="19%" valign="top"><p>list of string</p></td>
-<td align="left" width="58%" valign="top"><p>The list of routers through which this
+<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" width="23%" valign="top"><p>x-opt-qd.to</p></td>
-<td align="left" width="19%" valign="top"><p>string</p></td>
-<td align="left" width="58%" valign="top"><p>To-Override for message-routed messages. If this
+<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" width="23%" valign="top"><p>x-opt-qd.phase</p></td>
-<td align="left" width="19%" valign="top"><p>integer</p></td>
-<td align="left" width="58%" valign="top"><p>The address-phase, if not zero, for messages
+<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>
-<h4><a name="sourcetarget-capabilities"></a>3.3.2. Source/Target Capabilities</h4>
-<p>The following Capability values are used in Sources and Targets.</p>
-<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" width="19%" valign="top"><em>Capability</em> </th>
-<th align="left" width="81%" valign="top"><em>Description</em></th>
+<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" width="19%" valign="top"><p>qd.router</p></td>
-<td align="left" width="81%" valign="top"><p>This capability is added to sources and targets that are
+<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" width="19%" valign="top"><p>qd.router-data</p></td>
-<td align="left" width="81%" valign="top"><p>This capability is added to sources and targets that
+<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>
@@ -1128,23 +1784,27 @@ connection.</p></td>
 </tbody>
 </table>
 </div>
-<h4><a name="dynamic-node-properties"></a>3.3.3. Dynamic-Node-Properties</h4>
-<p>The following dynamic-node-properties are used by Dispatch in Sources.</p>
-<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" width="23%" valign="top"><em>Property</em> </th>
-<th align="left" width="77%" valign="top"><em>Description</em></th>
+<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" width="23%" valign="top"><p>x-opt-qd.address</p></td>
-<td align="left" width="77%" valign="top"><p>The node address describing the destination desired
+<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
@@ -1153,43 +1813,48 @@ container.</p></td>
 </tbody>
 </table>
 </div>
-<h4><a name="addresses-and-address-formats"></a>3.3.4. Addresses and Address Formats</h4>
-<p>The following AMQP addresses and address patterns are used within
-Dispatch Router.</p>
-<h5><a name="address-patterns"></a>Address Patterns</h5>
-<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" width="38%" valign="top"><em>Pattern</em> </th>
-<th align="left" width="62%" valign="top"><em>Description</em></th>
+<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" width="38%" valign="top"><p><code>_local/&lt;addr&gt;</code></p></td>
-<td align="left" width="62%" valign="top"><p>An address that references a locally attached endpoint.
+<td align="left" valign="top"><p class="table"><code>_local/&lt;addr&gt;</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" width="38%" valign="top"><p><code>_topo/0/&lt;router&gt;/&lt;addr&gt;</code></p></td>
-<td align="left" width="62%" valign="top"><p>An address that references an endpoint attached to a specific router
+<td align="left" valign="top"><p class="table"><code>_topo/0/&lt;router&gt;/&lt;addr&gt;</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>The <em>0</em> component immediately preceding the router-id is a placeholder
+<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" width="38%" valign="top"><p><code>&lt;addr&gt;</code></p></td>
-<td align="left" width="62%" valign="top"><p>A mobile address. An address of this format represents an
+<td align="left" valign="top"><p class="table"><code>&lt;addr&gt;</code></p></td>
+<td align="left" valign="top"><

<TRUNCATED>
http://git-wip-us.apache.org/repos/asf/qpid-site/blob/3cbe9ebf/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
index 4896e01..90fc389 100755
Binary files a/content/releases/qpid-dispatch-master/book.pdf and b/content/releases/qpid-dispatch-master/book.pdf differ


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


Mime
View raw message