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 2018/06/26 21:40:55 UTC
[01/11] qpid-dispatch git commit: DISPATCH-851: Move the new book
into primary position and reorg the docs
Repository: qpid-dispatch
Updated Branches:
refs/heads/master 7c8f31199 -> f77f92cbe
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/theory_of_operation.adoc
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/theory_of_operation.adoc b/docs/books/user-guide/theory_of_operation.adoc
new file mode 100644
index 0000000..dc50154
--- /dev/null
+++ b/docs/books/user-guide/theory_of_operation.adoc
@@ -0,0 +1,394 @@
+////
+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
+////
+
+= Theory of Operation
+
+This section introduces some key concepts about the router.
+
+== Overview
+
+The {RouterName} is an _application layer_ program running as a normal
+user program or as a daemon.
+
+{RouterName} accepts AMQP connections from clients and creates AMQP
+connections to brokers or AMQP-based services. {RouterName} classifies
+incoming AMQP messages and routes the
+messages between message producers and message consumers.
+
+{RouterName} 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. {RouterName} relies on
+redundant network paths to provide continued connectivity in the face
+of system or network failure.
+
+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.
+
+== Connections
+
+{RouterName} connects clients, servers, AMQP services, and other
+routers through network connections.
+
+=== Listener
+
+{RouterName} provides _listeners_ 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.
+
+Several types of listeners are defined by their role.
+
+[cols="20,80"]
+|===
+| Role | Description
+| normal | The connection is used for AMQP clients using normal message delivery.
+| inter-router | 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 | 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.
+|===
+
+=== Connector
+
+{RouterName} can also be configured to create outbound connections to
+messaging brokers or other AMQP entities using _connectors_. 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.
+
+Several types of connectors are defined by their role.
+
+[cols="20,80"]
+|===
+| Role | Description
+| normal | 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.
+| inter-router | 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 | 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.
+|===
+
+== Addresses
+
+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 _to_ and _reply-to_ fields of a message's properties. They are also
+used during the creation of links in the _address_ field of a _source_ or
+a _target_.
+
+[NOTE]
+====
+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.
+====
+
+Addresses designate various kinds of entities in a messaging network:
+
+* Endpoint processes that consume data or offer a service
+* Topics that match multiple consumers to multiple producers
+* Entities within a messaging broker:
+** Queues
+** Durable Topics
+** Exchanges
+
+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.
+
+{RouterName} maintains several classes of address based on how the address is
+configured or discovered.
+
+[cols="25,75"]
+|===
+| Address Type | Description
+| mobile | The address is a rendezvous point between senders and receivers. The router aggregates and serializes messages from senders and distributes messages to receivers.
+| link route | The address defines a private messaging path between a sender and a receiver. The router simply passes messages between the end points.
+|===
+
+=== Mobile Addresses
+
+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.
+
+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.
+
+Mobile addresses may be discovered during normal router operation or
+configured through management settings.
+
+==== Discovered Mobile Addresses
+
+Mobile addresses are created when a client creates a link to a source
+or destination address that is unknown to the router network.
+
+Suppose a service provider wants to offer _my-service_ that clients
+may use. The service provider must open a receiver link with source
+address _my-service_. The router creates a mobile address
+_my-service_ and propagates the address so that it is known to every
+router in the network.
+
+Later a client wants to use the service and creates a sending link
+with target address _my-service_. The router matches the service
+provider's receiver having source address _my-service_ to the client's
+sender having target address _my-service_ and routes messages between
+the two.
+
+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.
+
+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 _my-service_ 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.
+
+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.
+
+==== Configured Mobile Addresses
+
+Mobile addresses may be configured using the router _autoLink_
+object. An address created via an _autoLink_ represents a queue,
+topic, or other service in an external broker. Logically the
+_autoLink_ addresses are treated by the router network as if the
+broker had connected to the router and offered the services itself.
+
+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.
+
+Multiple _autoLink_ 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.
+
+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.
+
+=== Link Route Addresses
+
+Link route addresses may be configured using the router _linkRoute_
+object. An link route address represents a queue, topic, or other
+service in an external broker similar to addresses configured by
+_autoLink_ 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.
+
+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.
+
+== Message Routing
+
+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:
+
+* Routing pattern - balanced, closest, multicast
+* Routing mechanism - message routed, link routed
+
+// * TODO: describe these???
+// * Undeliverable action - drop, hold and retry, redirect
+// * Reliability - N destinations, etc.
+
+=== Routing Patterns
+
+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.
+
+Note that the routing patterns fall into two categories: Anycast
+(Balanced and Closest) and Multicast. There is no concept of
+"unicast" in which there is only one consumer for an address.
+
+Anycast distribution delivers each message to one consumer whereas
+multicast distribution delivers each message to all consumers.
+
+Anycast delivery is reliable when the message deliveries are
+unsettled. There is a reliability contract that the router network
+abides by when delivering unsettled messages to anycast addresses.
+For every such delivery sent by a producer, the router network
+guarantees that one of the following outcomes will occur:
+
+* The delivery shall be settled with ACCEPTED or REJECTED disposition
+ where the disposition is supplied by the consumer.
+* The delivery shall be settled with RELEASED disposition, meaning
+ that the message was not delivered to any consumer.
+* The delivery shall be settled with MODIFIED disposition, meaning
+ that the message may have been delivered to a consumer but should be
+ considered in-doubt and re-sent.
+* The connection to the producer shall be dropped, signifying that all
+ unsettled deliveries should now be considered in-doubt by the
+ producer and later re-sent.
+
+Multicast delivery is not reliable. If a producer sends an unsettled
+delivery, the ingress router shall settle the delivery with ACCEPTED
+disposition regardless of whether the message was delivered to any
+consumers.
+
+==== Balanced
+
+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.
+
+==== Closest
+
+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.
+
+==== Multicast
+
+Having multiple consumers on the same address at the same time,
+messages are routed such that each consumer receives one copy of the
+message.
+
+
+=== Routing Mechanisms
+
+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 _routing_:
+
+ 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.
+
+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.
+
+==== Message Routed
+
+Message routing occurs upon delivery of a message and is done based on
+the address in the message's _to_ field.
+
+When a delivery arrives on an incoming message-routing link, the
+router extracts the address from the delivered message's _to_ 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.
+
+Message routing can also occur without an address in the
+message's _to_ field if the incoming link has a target address. In
+fact, if the sender uses a link with a target address, the _to_ field
+shall be ignored even if used.
+
+==== Link Routed
+
+Link routing occurs when a new link is attached to the router across
+one of its AMQP connections. It is done based on the _target.address_
+field of an inbound link and the _source.address_ field of an outbound
+link.
+
+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.
+
+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.
+
+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.
+
+=== Message Settlement
+
+Messages may be delivered with varying degrees of reliability.
+
+* At most once
+* At least once
+* Exactly once
+
+The reliability is negotiated between the client and server during
+link establishment. The router handles all levels of reliability by treating
+messages as either _pre-settled_ or _unsettled_.
+
+[cols="20,80"]
+|===
+| Delivery | Handling
+| pre-settled | 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.
+| unsettled | 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.
+|===
+
+== Security
+
+{RouterName} 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.
+
+The router `policy` module is an optional authorization mechanism
+enforcing user connection restrictions and AMQP resource access
+control.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/understand-router-configuration.adoc
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/understand-router-configuration.adoc b/docs/books/user-guide/understand-router-configuration.adoc
new file mode 100644
index 0000000..a576f65
--- /dev/null
+++ b/docs/books/user-guide/understand-router-configuration.adoc
@@ -0,0 +1,206 @@
+////
+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
+////
+
+[id='router-configuration']
+= Configuration
+
+Before starting {RouterName}, 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.
+
+== Accessing the Router Configuration File
+
+The router's configuration is defined in the router configuration file. You can access this file to view and modify that configuration.
+
+.Procedure
+
+* Open the following file: `/etc/qpid-dispatch/qdrouterd.conf`.
++
+--
+When {RouterName} is installed, `qdrouterd.conf` is installed in this directory by default. When the router is started, it runs with the settings defined in this file.
+
+For more information about the router configuration file (including available entities and attributes), see the {qdrouterdManPageLink}.
+--
+
+== How the Router Configuration File is Structured
+
+Before you can make changes to a router configuration file, you should understand how the file is structured.
+
+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:
+
+[options="nowrap"]
+----
+sectionName {
+ attributeName: attributeValue
+ attributeName: attributeValue
+ ...
+}
+----
+
+[id='methods-for-changing-router-configuration']
+== Changing a Router's Configuration
+
+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.
+
+.Choices
+* xref:making-permanent-change-to-router-configuration[Make a permanent change to the router's configuration].
+* xref:changing-configuration-for-running-router[Change the configuration for a running router.]
+
+[id='making-permanent-change-to-router-configuration']
+=== Making a Permanent Change to the Router's Configuration
+
+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.
+
+.Procedure
+
+. Do one of the following:
++
+* Edit the default configuration file (`/etc/qpid-dispatch/qdrouterd.conf`).
+* Create a new configuration file.
+
+. Start (or restart) the router.
++
+If you created a new configuration file, you must specify the path using the `--conf` parameter. For example, the following command starts the router with a non-default configuration file:
++
+[options="nowrap"]
+----
+$ sudo qdrouterd -d --conf /etc/qpid-dispatch/new-configuration-file.conf
+----
+
+[id='changing-configuration-for-running-router']
+=== Changing the Configuration for a Running Router
+
+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.
+
+.Procedure
+
+* Use `qdmanage` to change the configuration.
++
+For more information about using `qdmanage`, see xref:managing-router[Managing {RouterName} Using _qdmanage_].
+
+== Default Configuration Settings
+
+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.
+
+When you installed {RouterName}, the default configuration file was added at the following path: `/etc/qpid-dispatch/qdrouterd.conf`. 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.
+
+.Default Configuration File
+
+[options="nowrap"]
+----
+router {
+ mode: standalone // <1>
+ id: Router.A // <2>
+}
+
+listener { // <3>
+ host: 0.0.0.0 // <4>
+ port: amqp // <5>
+ authenticatePeer: no // <6>
+}
+
+address { // <7>
+ prefix: closest
+ distribution: closest
+}
+
+address {
+ prefix: multicast
+ distribution: multicast
+}
+
+address {
+ prefix: unicast
+ distribution: closest
+}
+
+address {
+ prefix: exclusive
+ distribution: closest
+}
+
+address {
+ prefix: broadcast
+ distribution: multicast
+}
+----
+<1> By default, the router operates in _standalone_ 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.
+<2> The unique identifier of the router. This ID is used as the `container-id` (container name) at the AMQP protocol level. It is required, and the router will not start if this attribute is not defined.
+<3> The `listener` entity handles incoming connections from client endpoints.
+<4> The IP address on which the router will listen for incoming connections. By default, the router is configured to listen on all network interfaces.
+<5> 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.
+<6> Specifies whether the router should authenticate peers before they can connect to the router. By default, peer authentication is not required.
+<7> By default, the router is configured to use the message routing mechanism. Each `address` entity defines how messages that are received with a particular address `prefix` should be distributed. For example, all messages with addresses that start with `closest` will be distributed using the `closest` distribution pattern.
+
+[NOTE]
+====
+If a client requests a message with an address that is not defined in the router's configuration file, the `balanced` distribution pattern will be used automatically.
+====
+
+== Setting Essential Configuration Properties
+
+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.
+
+.Procedure
+
+. Open the router's configuration file.
++
+If you are changing the router's default configuration file, the file is located at `/etc/qpid-dispatch/qdrouterd.conf`.
+
+. To define essential router information, change the following attributes as needed in the `router` section:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+router {
+ mode: _STANDALONE/INTERIOR_
+ id: _ROUTER_ID_
+}
+----
+
+`mode`:: Specify one of the following modes:
++
+* `standalone` - 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.
+* `interior` - Use this mode if the router is part of a router network and needs to collaborate with other routers.
+`id`:: The unique identifier for the router. This ID will also be the container name at the AMQP protocol level.
+
+For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_router[router] in the `qdrouterd.conf` man page.
+--
+
+. If necessary for your environment, secure the router.
++
+--
+* xref:setting-up-ssl-for-encryption-and-authentication[Set up SSL/TLS for encryption, authentication, or both]
+* xref:setting-up-sasl-for-authentication-and-payload-encryption[Set up SASL for authentication and payload encryption]
+--
+
+. Connect the router to other routers, clients, and brokers.
++
+--
+* xref:adding-incoming-connections[Add incoming connections]
+* xref:adding-outgoing-connections[Add outgoing connections]
+--
+
+. Set up routing for your environment:
++
+--
+* xref:routing-messages-between-clients[Configure the router to route messages between clients directly]
+* xref:routing-messages-through-broker[Configure the router to route messages through a broker queue]
+* xref:creating-link-route[Create a link route to define a private messaging path between endpoints]
+--
+
+. xref:logging[Set up logging].
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/using-console.adoc
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/using-console.adoc b/docs/books/user-guide/using-console.adoc
new file mode 100644
index 0000000..4e03eb2
--- /dev/null
+++ b/docs/books/user-guide/using-console.adoc
@@ -0,0 +1,126 @@
+////
+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
+////
+
+= Using {ConsoleName}
+
+[[console-overview]]
+== Console Overview
+
+The console is an HTML based web site that displays information about a qpid dispatch router network.
+
+The console requires an HTML web server that can serve static html, javascript, style sheets, and images.
+
+The console only provides limited information about the clients that are attached to the router network and is therfore more appropriate for administrators needing to know the layout and health of the router network.
+
+[[console-installation]]
+== Console Installation
+
+[discrete]
+=== Prerequisites
+
+The following need to be installed before running a console:
+
+* One or more dispatch routers. See the documentation for the dispatch
+router for help in starting a router network.
+* A websockets to tcp proxy.
+* A web server. This can be any server capable of serving static
+html/js/css/image files.
+
+[discrete]
+=== Procedure
+
+To install a websockets to tcp proxy:
+
+----
+sudo dnf install python-websockify
+websockify localhost:5673 localhost:5672
+----
+
+This will start the proxy listening to ws traffic on port 5673 and
+translating it to tcp on port 5672. One of the routers in the network
+needs to have a listener configured on port 5672. That listener's role
+should be 'normal'. For example:
+
+----
+listener {
+ host: 0.0.0.0
+ role: normal
+ port: amqp
+ saslMechanisms: ANONYMOUS
+}
+----
+
+[[the-console-files]]
+=== The Console Files
+
+The files for the console are located under the console/stand-alone
+directory in the source tree
+* 'index.html'
+* 'plugin/'
+
+Copy these files to a directory under the the html or webapps directory
+of your web server. For example, for apache tomcat the files should be
+under webapps/dispatch. Then the console is available as 'http://localhost:8080/dispatch'
+
+[[console-operation]]
+== Console Operation
+
+[[logging-in-to-a-router-network]]
+=== Logging into a Router Network
+
+image:console_login.png[image]
+
+Enter the address of the websockets to tcp proxy that is connected to a router in the network.
+
+The Autostart checkbox, when checked, will automatically log in with the previous host:port the next time you start the console.
+
+[[overview-page]]
+=== Overview Page
+
+image:console_overview.png[image]
+
+On the overview page, aggregate information about routers, addresses, and connections is displayed.
+
+[[topology-page]]
+=== Topology Page
+
+image:console_topology.png[image]
+
+This page displays the router network in a graphical form showing how the routers are connected and information about the individual routers and links.
+
+[[list-page]]
+=== List Page
+
+image:console_entity.png[image]
+
+Displays detailed information about entities such as routers, links, addresses, memory.
+
+[[charts-page]]
+=== Charts Page
+
+image:console_charts.png[image]
+
+This page displays graphs of numeric values that are on the list page.
+
+[[schema-page]]
+=== Schema Page
+
+image:console_schema.png[image]
+
+This page displays the json schema that is used to manage the router network.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/man/CMakeLists.txt
----------------------------------------------------------------------
diff --git a/docs/man/CMakeLists.txt b/docs/man/CMakeLists.txt
new file mode 100644
index 0000000..bfc54f8
--- /dev/null
+++ b/docs/man/CMakeLists.txt
@@ -0,0 +1,125 @@
+##
+## 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.
+##
+
+# Popular locations
+set (src ${CMAKE_CURRENT_SOURCE_DIR})
+set (bin ${CMAKE_CURRENT_BINARY_DIR})
+set (tools ${CMAKE_SOURCE_DIR}/tools)
+set (schema ../../python/qpid_dispatch/management/qdrouter.json)
+set (py_management ../../python/qpid_dispatch_internal/management)
+set (schema_deps ${schema} ${py_management}/schema_doc.py ${py_management}/schema.py)
+
+# Flags for doc tools, based on cmake options
+set (ADOC_FLAGS "--conf-file=${bin}/asciidoc.conf")
+set (A2X_FLAGS "--asciidoc-opts=--conf-file=${bin}/asciidoc.conf" -D${bin})
+
+if (DOC_VERBOSE)
+ set (ADOC_FLAGS ${ADOC_FLAGS} -v)
+ set (A2X_FLAGS ${A2X_FLAGS} -v)
+endif ()
+
+if (NOT DOC_XMLLINT)
+ set (A2X_FLAGS ${A2X_FLAGS} --no-xmllint)
+endif ()
+
+# Generate asciidoc fragments from management schema to incorporate in text
+macro (schema_gen script output)
+ add_custom_command (
+ OUTPUT ${output}
+ COMMAND ${RUN} -s ${script} 1> ${output}
+ DEPENDS ${script} ${schema_deps})
+ list (APPEND generated_txt "${output}")
+endmacro ()
+
+schema_gen (${src}/qdrouterd.conf.5.py ${bin}/qdrouterd.conf.5.adoc)
+
+# Generate asciidoc .adoc from --help output for man pages
+macro (help2txt program)
+ get_filename_component (name ${program} NAME)
+ set (output ${bin}/${name}_help.adoc)
+ add_custom_command (
+ OUTPUT ${output}
+ COMMAND ${RUN} -s ${src}/help2txt.py ${program} --help 1> ${output}
+ DEPENDS ${program} ${schema_deps} ${src}/help2txt.py
+ )
+ list (APPEND generated_txt "${output}")
+endmacro ()
+
+help2txt (${CMAKE_BINARY_DIR}/router/qdrouterd)
+help2txt (${tools}/qdmanage)
+help2txt (${tools}/qdstat)
+
+add_custom_target (doc_gen ALL DEPENDS ${generated_txt})
+
+execute_process (COMMAND ${CMAKE_COMMAND} -E copy_directory ${src} ${bin})
+
+find_program (ASCIIDOC_EXE asciidoc DOC "Generate HTML documentation")
+
+if (ASCIIDOC_EXE)
+ configure_file (${src}/asciidoc.conf.in ${bin}/asciidoc.conf)
+
+ # Generate HTML
+ file (GLOB_RECURSE adoc_files *.adoc)
+ foreach (source qdmanage.8 qdrouterd.8 qdstat.8 qdrouterd.conf.5)
+ get_filename_component (name ${source} NAME)
+ get_filename_component (dir ${source} PATH)
+ string(FIND ${name} "." dot)
+ if (dot GREATER 0)
+ string (LENGTH ${name} length)
+ math (EXPR desired_length "${length}-2")
+ string (SUBSTRING ${name} "0" ${desired_length} name)
+ endif ()
+ set (output ${bin}/${dir}/${name}.html)
+ add_custom_command (
+ OUTPUT ${output} ${output}.in
+ # Pretty .html for direct viewing.
+ COMMAND ${ASCIIDOC_EXE} ${ADOC_FLAGS} -o ${output} ${source}.adoc
+ # Raw .html.in body for inclusion in Qpid website.
+ COMMAND ${ASCIIDOC_EXE} ${ADOC_FLAGS} -s -o ${output}.in ${source}.adoc
+ DEPENDS ${source}.adoc ${generated_txt} ${adoc_files} ${bin}/asciidoc.conf
+ WORKING_DIRECTORY ${bin}
+ )
+ list (APPEND docs_deps ${output})
+ endforeach ()
+
+ find_program(A2X_EXE a2x DOC DOC "Generate Unix man pages")
+ if (A2X_EXE)
+ # Generate man pages.
+ foreach (source ${bin}/qdmanage.8 ${bin}/qdrouterd.8 ${bin}/qdstat.8 ${bin}/qdrouterd.conf.5)
+ get_filename_component (name ${source} NAME)
+ get_filename_component (dir ${source} PATH)
+ string(REGEX REPLACE ".*\\.([0-9])$" "\\1" section ${source}) # Man section number
+ set (output ${bin}/${name})
+ add_custom_command (
+ OUTPUT ${output}
+ COMMAND ${A2X_EXE} ${A2X_FLAGS} -f manpage -D ${bin} ${source}.adoc
+ DEPENDS ${source}.adoc ${generated_txt}
+ )
+ list (APPEND docs_deps ${output})
+ install (FILES ${output} DESTINATION ${CMAKE_INSTALL_PREFIX}/${MAN_INSTALL_DIR}/man${section} OPTIONAL)
+ endforeach ()
+ else ()
+ message (STATUS "a2x not found: not generating man pages or PDF")
+ endif ()
+else ()
+ message (STATUS "asciidoc not found: not generating HTML, man pages or PDF")
+endif ()
+
+add_custom_target (man DEPENDS ${docs_deps})
+add_dependencies (docs man)
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/man/asciidoc.conf.in
----------------------------------------------------------------------
diff --git a/docs/man/asciidoc.conf.in b/docs/man/asciidoc.conf.in
new file mode 100644
index 0000000..6f1ea02
--- /dev/null
+++ b/docs/man/asciidoc.conf.in
@@ -0,0 +1,31 @@
+#
+# 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.
+#
+
+[attributes]
+SYSCONF_INSTALL_DIR=${SYSCONF_INSTALL_DIR}
+CMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}
+QD_DOC_INSTALL_DIR=${QD_DOC_INSTALL_DIR}
+QPID_DISPATCH_VERSION=${QPID_DISPATCH_VERSION}
+
+generated=${CMAKE_CURRENT_BINARY_DIR}
+generated_book=${CMAKE_CURRENT_BINARY_DIR}/book
+generated_man=${CMAKE_CURRENT_BINARY_DIR}
+
+[footer-text]
+Qpid Dispatch ${QPID_DISPATCH_VERSION} - generated {localdate} {localtime}
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/man/help2txt.py
----------------------------------------------------------------------
diff --git a/docs/man/help2txt.py b/docs/man/help2txt.py
new file mode 100644
index 0000000..24aeb53
--- /dev/null
+++ b/docs/man/help2txt.py
@@ -0,0 +1,69 @@
+#
+# 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
+#
+
+"""
+Convert --help output of a program into asciidoc text format.
+"""
+from __future__ import print_function
+from __future__ import unicode_literals
+from __future__ import division
+from __future__ import absolute_import
+
+
+import re, sys
+from qpid_dispatch_internal.compat import PY_STRING_TYPE
+from qpid_dispatch_internal.compat.subproc import check_output
+
+
+def help2txt(help_out):
+ VALUE = r"(?:[\w-]+|<[^>]+>)"
+ DEFAULT = r"(?: +\([^)]+\))?"
+ OPTION = r"-[\w-]+(?:[ =]%s)?%s" % (VALUE, DEFAULT) # -opt[(=| )value][(default)]
+ OPTIONS = r"%s(?:, *%s)*" % (OPTION, OPTION) # opt[,opt...]
+ HELP = r"(?:[ \t]+\w.*$)|(?:(?:\n[ \t]+[^-\s].*$)+)" # same line or following lines indented.
+ OPT_HELP = r"^\s+(%s)(%s)" % (OPTIONS, HELP)
+ SUBHEAD = r"^((?: +\w+)*):$"
+
+ # check_output returns binary in py3
+ if not isinstance(help_out, PY_STRING_TYPE):
+ help_out = help_out.decode()
+
+ options = re.search("^Options:$", help_out, re.IGNORECASE | re.MULTILINE)
+ if (options): help_out = help_out[options.end():]
+ result = ""
+
+ def heading(text, depth):
+ return "%s %s\n\n" % ("="*depth, text)
+
+ for item in re.finditer(r"%s|%s" % (OPT_HELP, SUBHEAD), help_out, re.IGNORECASE | re.MULTILINE):
+ if item.group(3):
+ result += heading(item.group(3).strip(), 3)
+ else:
+ result += "%s\n: %s\n\n" % (item.group(1), re.sub("\s+", " ", item.group(2)).strip())
+ return result
+
+def main(argv):
+ if len(argv) < 2: raise ValueError("Wrong number of arguments\nUsage %s"
+ " <program> [args,...]" % argv[0])
+ program = argv[1:]
+ print(help2txt(check_output(program)))
+
+if __name__ == "__main__":
+ main(sys.argv)
+
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/man/qdmanage.8.adoc
----------------------------------------------------------------------
diff --git a/docs/man/qdmanage.8.adoc b/docs/man/qdmanage.8.adoc
new file mode 100644
index 0000000..9f668b5
--- /dev/null
+++ b/docs/man/qdmanage.8.adoc
@@ -0,0 +1,139 @@
+////
+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
+////
+
+qdmanage(8)
+==========
+:doctype: manpage
+
+NAME
+----
+qdmanage - management client to control or query qdrouterd(8)
+
+SYNOPSIS
+--------
+*qdmanage* ['OPTIONS'] 'OPERATION' ['ARGUMENTS']
+
+DESCRIPTION
+-----------
+An AMQP management client for use with the Dispatch router daemon
+('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 'qdrouterd'.
+
+OPTIONS
+-------
+
+include::{generated_man}/qdmanage_help.adoc[]
+
+OPERATIONS
+----------
+
+`query` ['ATTR'...]::
+ 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.
+
+`create` ['ATTR=VALUE'...]::
+ 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.
+
+`read`::
+ Print all of the attributes of a single entity, specified by the --name or
+ --identity options.
+
+`update` ['ATTR=VALUE'...]::
+ 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.
+
+`delete`::
+ Delete an entity specified by the --name or --identity options.
+
+`get-types` ['TYPE']::
+ List entity types with their base types. With no arguments, list all
+ types.
+
+`get-operations` ['TYPE']::
+ List entity types with their operations. With no arguments, list all
+ types.
+
+`get-attributes` ['TYPE']::
+ List entity types with their attributes. With no arguments, list all
+ types.
+
+`get-annotations` ['TYPE']::
+ List entity types with their annotations. With no arguments, list all
+ types.
+
+`get-mgmt-nodes`::
+ List all other known management nodes connected to this one.
+
+`get-json-schema` ['INDENT']::
+ Get the router schema in JSON format. Optional integer indent for
+ formatted output.
+
+`get-log` ['INDENT']::
+ Get recent log entries from the router.
+
+FILES
+-----
+
+{CMAKE_INSTALL_PREFIX}/{QD_DOC_INSTALL_DIR}/qdrouter.json::
+ Management schema for 'qdrouterd'.
+{CMAKE_INSTALL_PREFIX}/{QD_DOC_INSTALL_DIR}/qdrouter.json.readme.txt::
+ Explanation of the management schema.
+
+EXAMPLES
+--------
+
+.Show the logging configuration:
+--------------------------------------------------------------
+qdmanage query --type=log
+--------------------------------------------------------------
+
+.Enable debug and higher log messages by default:
+--------------------------------------------------------------
+qdmanage update name=log/DEFAULT enable=debug+
+--------------------------------------------------------------
+
+.Enable trace log messages only for the MESSAGE module, and direct MESSAGE logs to the file _test.log_:
+--------------------------------------------------------------
+qdmanage update name=log/MESSAGE enable=trace output=test.log
+--------------------------------------------------------------
+
+.Set MESSAGE logging back to the default:
+------------------------------------------------
+qdmanage update name=log/MESSAGE enable=default
+------------------------------------------------
+
+.Disable MESSAGE logging:
+---------------------------------------------
+qdmanage update name=log/MESSAGE enable=none
+---------------------------------------------
+
+SEE ALSO
+----------
+'qdrouterd(8)', 'qdstat(8)', 'qdrouterd.conf(5)'
+
+http://qpid.apache.org/components/dispatch-router
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/man/qdrouterd.8.adoc
----------------------------------------------------------------------
diff --git a/docs/man/qdrouterd.8.adoc b/docs/man/qdrouterd.8.adoc
new file mode 100644
index 0000000..ae2c2a2
--- /dev/null
+++ b/docs/man/qdrouterd.8.adoc
@@ -0,0 +1,54 @@
+////
+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
+////
+
+qdrouterd(8)
+===========
+:doctype: manpage
+
+NAME
+----
+qdrouterd - routes AMQP messages.
+
+SYNOPSIS
+--------
+*qdrouterd* ['OPTIONS']
+
+
+DESCRIPTION
+-----------
+The Qpid Dispatch router ('qdrouterd') is a network daemon that directs
+AMQP 1.0 messages between endpoints, such as messaging clients and
+servers.
+
+OPTIONS
+-------
+
+include::{generated_man}/qdrouterd_help.adoc[]
+
+FILES
+-----
+
+{SYSCONF_INSTALL_DIR}/qdrouterd.conf::
+ Configuration file.
+
+SEE ALSO
+--------
+'qdrouterd.conf(5)', 'qdstat(8)', 'qdmanage(8)'
+
+http://qpid.apache.org/components/dispatch-router
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/man/qdrouterd.conf.5.py
----------------------------------------------------------------------
diff --git a/docs/man/qdrouterd.conf.5.py b/docs/man/qdrouterd.conf.5.py
new file mode 100644
index 0000000..e2bdd8e
--- /dev/null
+++ b/docs/man/qdrouterd.conf.5.py
@@ -0,0 +1,155 @@
+#
+# 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
+#
+
+"""
+Generate the qdrouterd.conf. man page from the qdrouterd management schema.
+"""
+
+from __future__ import unicode_literals
+from __future__ import division
+from __future__ import absolute_import
+from __future__ import print_function
+
+import sys
+from qpid_dispatch_internal.management.qdrouter import QdSchema
+from qpid_dispatch_internal.management.schema_doc import SchemaWriter
+from qpid_dispatch_internal.compat import dict_itervalues
+
+CONNECTOR = 'org.apache.qpid.dispatch.connector'
+LISTENER = 'org.apache.qpid.dispatch.listener'
+
+class ManPageWriter(SchemaWriter):
+
+ def __init__(self):
+ super(ManPageWriter, self).__init__(sys.stdout, QdSchema())
+
+ def attribute_type(self, attr, holder):
+ # Don't show read-only attributes
+ if not attr.create and not attr.update:
+ # It is ok to show the console attributes
+ if not holder.short_name == "console":
+ return
+ super(ManPageWriter, self).attribute_type(attr, holder, show_create=False, show_update=False)
+
+
+
+ def man_page(self):
+ self.writeln(r"""
+qdrouterd.conf(5)
+=================
+:doctype: manpage
+
+NAME
+----
+qdrouterd.conf - configuration file for the dispatch router.
+
+SYNOPSIS
+--------
+Provides the initial configuration when 'qdrouterd(8)' starts. The configuration
+of a running router can be modified using 'qdmanage(8)'.
+
+
+DESCRIPTION
+-----------
+
+The configuration file is made up of sections with this syntax:
+
+----
+sectionName {
+ attributeName: attributeValue
+ attributeName: attributeValue
+ ...
+}
+----
+
+For example you can define a router using the 'router' section
+
+----
+router {
+ mode: standalone
+ id: Router.A
+ ...
+}
+----
+
+or define a listener using the 'listener' section
+
+----
+listener {
+ host: 0.0.0.0
+ port: 20102
+ saslMechanisms: ANONYMOUS
+ ...
+}
+----
+
+or define a connector using the 'connector' section
+
+----
+connector {
+ role: inter-router
+ host: 0.0.0.0
+ port: 20003
+ saslMechanisms: ANONYMOUS
+ ...
+}
+----
+
+An 'sslProfile' section with SSL credentials can be included in multiple 'listener' or 'connector' entities. Here's an example, note
+how the 'sslProfile' attribute of 'listener' sections references the 'name'
+attribute of 'sslProfile' sections.
+
+----
+sslProfile {
+ name: my-ssl
+ caCertFile: ca-certificate-1.pem
+ certFile: server-certificate-1.pem
+ privateKeyFile: server-private-key.pem
+}
+
+listener {
+ sslProfile: my-ssl
+ host: 0.0.0.0
+ port: 20102
+ saslMechanisms: ANONYMOUS
+}
+----
+""")
+
+ with self.section("Configuration Sections"):
+
+ config = self.schema.entity_type("configurationEntity")
+ for entity_type in dict_itervalues(self.schema.entity_types):
+ if config in entity_type.all_bases:
+ with self.section(entity_type.short_name):
+ if entity_type.description:
+ self.para(entity_type.description)
+ self.attribute_types(entity_type)
+
+ self.writeln("""
+SEE ALSO
+--------
+
+*qdrouterd(8)*, *qdmanage(8)*
+
+http://qpid.apache.org/components/dispatch-router
+""")
+
+if __name__ == '__main__':
+ ManPageWriter().man_page()
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/man/qdstat.8.adoc
----------------------------------------------------------------------
diff --git a/docs/man/qdstat.8.adoc b/docs/man/qdstat.8.adoc
new file mode 100644
index 0000000..bd62be4
--- /dev/null
+++ b/docs/man/qdstat.8.adoc
@@ -0,0 +1,277 @@
+////
+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
+////
+
+qdstat(8)
+=========
+:doctype: manpage
+
+NAME
+----
+qdstat - show status and statistics for a running 'qdrouterd'
+
+SYNOPSIS
+--------
+*qdstat* ['OPTIONS']
+
+DESCRIPTION
+-----------
+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.
+
+OPTIONS
+-------
+
+include::{generated_man}/qdstat_help.adoc[]
+
+OUTPUT COLUMNS
+--------------
+
+qdstat -c
+~~~~~~~~~
+id::
+The connection's unique identifier.
+
+host::
+The hostname or internet address of the remotely-connected AMQP container.
+
+container::
+The container name of the remotely-connected AMQP container.
+
+role::
+The connection's role:
+ - 'normal' - The normal connection from a client to a router.
+ - 'inter-router' - The connection between routers to form a network.
+ - 'route-container' - The connection to or from a broker or other host to receive link routes and waypoints.
+
+dir::
+The direction in which the connection was established:
+ - 'in' - The connection was initiated by the remote container.
+ - 'out' - The connection was initiated by this router.
+
+security::
+The security or encryption method, if any, used for this connection.
+
+authentication::
+The authentication method and user ID of the connection's authenticated user.
+
+qdstat -l
+~~~~~~~~~
+type::
+The type of link:
+ - 'router-control' - An inter-router link that is reserved for control messages exchanged between routers.
+ - 'inter-router' - An inter-router link that is used for normal message-routed deliveries.
+ - 'endpoint' - A normal link to an external endpoint container.
+
+dir::
+The direction that messages flow on the link:
+ - 'in' - Deliveries flow inbound to the router.
+ - 'out' - Deliveries flow outbound from the router.
+
+conn id::
+The unique identifier of the connection over which this link is
+attached.
+
+id::
+The unique identifier of this link.
+
+peer::
+For link-routed links, the unique identifier of the peer link. In
+link routing, an inbound link is paired with an outbound link.
+
+class::
+The class of the address bound to the link:
+ - 'local' - The address that is local to this router (temporary).
+ - 'topo' - A topological address used for router control messages.
+ - 'router' - A summary router address used to route messages to a remote router’s local addresses.
+ - 'mobile' - A mobile address for an attached consumer or producer.
+ - 'link-in' - The address match for incoming routed links.
+ - 'link-out' - The address match for outgoing routed links.
+
+addr::
+The address bound to the link.
+
+phs::
+The phase of the address bound to the link.
+
+cap::
+The capacity, in deliveries, of the link.
+
+undel::
+The number of undelivered messages stored on the link's FIFO.
+
+unsett::
+The number of unsettled deliveries being tracked by the link.
+
+del::
+The total number of deliveries that have transited this link.
+
+presett::
+The number of pre-settled deliveries that transited this link.
+
+psdrop::
+The number of pre-settled deliveries that were dropped due to congestion.
+
+acc::
+The number of deliveries on this link that were accepted.
+
+rej::
+The number of deliveries on this link that were rejected.
+
+rel::
+The number of deliveries on this link that were released.
+
+mod::
+The number of deliveries on this link that were modified.
+
+admin::
+The administrative status of the link:
+ - 'enabled' - The link is enabled for normal operation.
+ - 'disabled' - The link is disabled and should be quiescing or stopped (not yet supported).
+
+oper::
+The operational status of the link:
+ - 'up' - The link is operational.
+ - 'down' - The link is not attached.
+ - 'quiescing' - The link is in the process of quiescing (not yet supported).
+ - 'idle' - The link has completed quiescing and is idle (not yet supported).
+
+name::
+The link name (only shown if the -v option is provided).
+
+qdstat -n
+^^^^^^^^^
+
+router-id::
+The router's ID.
+
+next-hop::
+If this router is not a neighbor, this field identifies the next-hop neighbor used to reach this router.
+
+link::
+The ID of the link to the neighbor router.
+
+cost::
+The topology cost to this remote router (with -v option only).
+
+neighbors::
+The list of neighbor routers (the router's link-state). This field is available only if you specify the -v option.
+
+valid-origins::
+The list of origin routers for which the best path to the listed router passes through this router (available only with the -v option).
+
+qdstat -a
+~~~~~~~~~
+
+class::
+The class of the address:
+ - 'local' - The address that is local to this router.
+ - 'topo' - The topological address used for router control messages.
+ - 'router' - A summary router address used to route messages to a remote router's local addresses.
+ - 'mobile' - A mobile address for an attached consumer or producer.
+
+addr::
+The address text.
+
+phs::
+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.
+
+distrib::
+One of the following distribution methods used for this address:
+ - 'multicast' - A copy of each message is delivered once to each consumer for the address.
+ - '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.
+ - '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 (that is, higher cost consumers will only receive deliveries if closer consumers are backed up).
+ - 'flood' - Used only for router-control traffic. This is multicast without the prevention of duplicate deliveries.
+
+in-proc::
+The number of in-process consumers for this address.
+
+local::
+For this router, the number of local consumers for this address.
+
+remote::
+The number of remote routers that have at least one consumer for this address.
+
+cntnr::
+The number of locally-attached containers that are destinations for link routes on this address.
+
+in::
+The number of deliveries for this address that entered the network on this router.
+
+out::
+The number of deliveries for this address that exited the network on this router.
+
+thru::
+The number of deliveries for this address that were forwarded to other routers.
+
+to-proc::
+The number of deliveries for this address that were delivered to an in-process consumer.
+
+from-proc::
+The number of deliveries for this address that were received from an in-process producer.
+
+qdstat --linkroutes
+~~~~~~~~~~~~~~~~~~~
+
+prefix::
+The address prefix of the link route.
+
+dir::
+The direction of matching links (from this router's perspective).
+
+distrib::
+The distribution method used for routed links. This value should always be 'linkBalanced', which is the only supported distribution for routed links.
+
+status::
+The operational status of the link route:
+ - 'active' - The route is actively routing attaches (it is ready for use).
+ - 'inactive' - The route is inactive, because no local destination is connected.
+
+qstat --autolinks
+~~~~~~~~~~~~~~~~~
+addr::
+The auto link's address.
+
+dir::
+The direction that messages flow over the auto link:
+ - 'in' - Messages flow in from the route-container to the router network.
+ - 'out' - Messages flow out to the route-container from the router network.
+
+phs::
+The address phase for this auto link.
+
+link::
+The ID of the link managed by this auto link.
+
+status::
+The operational status of this auto link:
+ - 'inactive' - There is no connected container for this auto link.
+ - 'attaching' - The link is attaching to the container.
+ - 'failed' - The link-attach failed.
+ - 'active' - The link is operational.
+ - 'quiescing' - The link is quiescing (not yet supported).
+ - 'idle' - The link is idle (not yet supported).
+
+lastErr::
+The description of the last attach failure that occurred on this auto link.
+
+SEE ALSO
+--------
+
+'qdrouterd(8)', 'qdmanage(8)', 'qdrouterd.conf(5)'
+
+http://qpid.apache.org/components/dispatch-router
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/notes/code-conventions.txt
----------------------------------------------------------------------
diff --git a/docs/notes/code-conventions.txt b/docs/notes/code-conventions.txt
new file mode 100644
index 0000000..fb0829c
--- /dev/null
+++ b/docs/notes/code-conventions.txt
@@ -0,0 +1,32 @@
+#
+# 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.
+#
+
+
+Code conventions
+================
+
+Python code
+-----------
+
+Python code should be http://www.python.org/dev/peps/pep-0008/[PEP-8]
+compliant. In particular:
+
+* Use four-space indents
+* Do not use studlyCaps for function, method, and variable names;
+instead use underscore_separated_names
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org
[07/11] qpid-dispatch git commit: DISPATCH-851: Move the new book
into primary position and reorg the docs
Posted by jr...@apache.org.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/reliability.adoc
----------------------------------------------------------------------
diff --git a/doc/new-book/reliability.adoc b/doc/new-book/reliability.adoc
deleted file mode 100644
index 2826c55..0000000
--- a/doc/new-book/reliability.adoc
+++ /dev/null
@@ -1,701 +0,0 @@
-////
-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
-////
-
-[id='reliability']
-= Reliability
-
-////
-There's a lot of really good information here, but most of it is best-suited at a level higher than this book. This book is really about configuring a router in an established topology, but most of the information in "Reliability" is about concepts and best practices to keep in mind as you design the topology. Alternatively, I could also see taking the examples presented here and turning them into a tutorial to teach some of the fundamental concepts inherent within router reliability.
-////
-
-In general, in a broker based architecture, the reliability feature is strictly related to the "store and forward" mechanism offered by each broker. Thanks to persistent journals, a broker can offer fault tolerance thus avoiding message loss; of course, it is not so true when messages are stored only in a volatile memory.
-
-This is completely different using {RouterName}, because each router neither takes ownership of messages nor stores them in a persistent storage. In this case, the reliability feature is offered by *path redundancy* which provides the possibility to reach the destination on different paths through the router network. In normal conditions, the best path is always chosen in terms of lowest cost but, when one or more routers go down, the topology is revisited by all remained routers and new paths are processed in order to reach always each destination. Of course, it means that the reliability is strictly related to the network topology the user chooses for his solution.
-
-Because a solution based on {RouterName} could be made not only by routers but by brokers too, the reliability is improved with persistent storage on them which add not only fault tolerance but temporal decoupling as well; without "store and forward" feature offered by brokers, the temporal decoupling is not possible only with routers and direct peers, both senders and receivers; the receiver must be online at same time of the sender in order to receive messages.
-
-== Path Redundancy
-
-Offering path redundancy means designing the network topology in a way that even when one or more routers go down or even connections between them, each destination is always reachable following alternate paths through the routers that are still part of the network.
-
-Consider the following simple scenario :
-
-* a network with three routers "Router.A", "Router.B" and "Router.C".
-* the "Router.A" is connected to both "Router.B" and "Router.C".
-* the "Router.C is connected to the "Router.B".
-* all three routers listen for client connections.
-* a sender client connects to the "Router.A" in order to send messages to a receiver client.
-* a receiver client connects to the "Router.B" initially in order to receive messages from the sender peer.
-
-.Path Redundancy Enabled Topology
-image::path-redundancy-01.png[Path Redundancy Enabled Topology, align="center"]
-
-The "Router.A" configuration is something like following.
-
-[options="nowrap"]
-----
-router {
- mode: interior
- id: Router.A
-}
-
-listener {
- host: 0.0.0.0
- port: 6000
- authenticatePeer: no
-}
-
-connector {
- name: INTER_ROUTER_B
- addr: 127.0.0.1
- port: 5001
- role: inter-router
-}
-
-connector {
- name: INTER_ROUTER_C
- addr: 127.0.0.1
- port: 5002
- role: inter-router
-}
-----
-
-There is only one _listener_ in order to accept client connections and two _connector_ entities for connecting to the other two routers.
-
-The "Router.B" configuration is the following.
-
-[options="nowrap"]
-----
-router {
- mode: interior
- id: Router.B
-}
-
-listener {
- addr: 0.0.0.0
- port: 5001
- authenticatePeer: no
- role: inter-router
-}
-
-listener {
- host: 0.0.0.0
- port: 6001
- authenticatePeer: no
-}
-----
-
-It has two _listener_ entities in order to listen for connections from clients and from other routers in the network (in this case from the "Router.A" and "Router.C").
-
-Finally, quite similar is the "Router.C" configuration.
-
-[options="nowrap"]
-----
-router {
- mode: interior
- id: Router.C
-}
-
-listener {
- addr: 0.0.0.0
- port: 5002
- authenticatePeer: no
- role: inter-router
-}
-
-listener {
- host: 0.0.0.0
- port: 6002
- authenticatePeer: no
-}
-
-connector {
- name: INTER_ROUTER_B
- addr: 127.0.0.1
- port: 5001
- role: inter-router
-}
-----
-
-It has two _listener_ entities in order to listen for connections from clients and from other routers in the network (in this case from the "Router.A") and finally it has a _connector_ (for connecting to the "Router.B")
-
-Consider a sender client connected to "Router.A" and attached to `my_address` address which start to send messages (that is, 10 messages) and a receiver client connected to the "Router.B" and attached to the same address.
-
-Starting the receiver, it waits for messages with no output on the console.
-
-[options="nowrap"]
-----
-$ sudo python simple_recv.py -a localhost:6001/my_queue -m 10
-----
-
-Starting the sender, all the messages flow through "Router.A" and "Router.B" reaching the receiver; at this point the messages are all confirmed at sender side.
-
-[options="nowrap"]
-----
-$ sudo python simple_send.py -a localhost:6001/my_queue -m 10
-all messages confirmed
-----
-
-At same time, the receivers shows the messages received through the "Router.B".
-
-[options="nowrap"]
-----
-{u'sequence': 1L}
-{u'sequence': 2L}
-{u'sequence': 3L}
-{u'sequence': 4L}
-{u'sequence': 5L}
-{u'sequence': 6L}
-{u'sequence': 7L}
-{u'sequence': 8L}
-{u'sequence': 9L}
-{u'sequence': 10L}
-----
-
-The path redundancy is provided by the other available path through the "Router.A", "Router.C" and then "Router.B". It means that if the connection between "Router.A" and "Router.B" goes down, the alternative path is used to reach the receiver.
-
-Now, consider a fault on the "Router.B"; the receiver is not reachable anymore on that path but it can connect to the "Router.C" in order to continue to receive messages from the sender which does not know what's happened and it can continue to send messages to the "Router.A" in order to reach the receiver.
-
-.Path Redundancy after Router Failure
-image::path-redundancy-02.png[Path Redundancy after Router Failure, align="center"]
-
-The receiver is still reachable in order to get messages from the sender as displayed in the console output.
-
-[options="nowrap"]
-----
-$ sudo python simple_recv.py -a localhost:6002/my_queue -m 10
-{u'sequence': 1L}
-{u'sequence': 2L}
-{u'sequence': 3L}
-{u'sequence': 4L}
-{u'sequence': 5L}
-{u'sequence': 6L}
-{u'sequence': 7L}
-{u'sequence': 8L}
-{u'sequence': 9L}
-{u'sequence': 10L}
-----
-
-== Path Redundancy and Temporal Decoupling
-
-In order to have temporal decoupling in a solution based on {RouterName}, adding one or more brokers is a must for its "store and forward" feature. Choosing the right topology, it is possible to have a solution which offers reliability with both path redundancy and permanent storing for messages.
-
-Consider the following simple scenario :
-
-* a network with three routers "Router.A", "Router.B" and "Router.C" and finally a broker.
-* the "Router.A" is connected to both "Router.B" and "Router.C".
-* initially only the "Router.B" is connected to the broker.
-* all three routers listen for client connections.
-* a sender client connects to the "Router.A" in order to send messages to a queue in the broker.
-* a receiver client connects to the "Router.A" in order to get messages from the queue in the broker.
-
-.Path Redundancy and Temporal Decoupling Enabled Topology
-image::path-redundancy-temp-decoupling-01.png[Path Redundancy and Temporal Decoupling Enabled Topology, align="center"]
-
-The receiver client can be offline when the sender starts to send messages because they'll be stored into the queue permanently; coming back online, the receiver can get messages from the queue itself without message loss.
-
-The "Router.A" configuration is something like following.
-
-[options="nowrap"]
-----
-router {
- mode: interior
- id: Router.A
-}
-
-listener {
- host: 0.0.0.0
- port: 6000
- authenticatePeer: no
-}
-
-connector {
- name: INTER_ROUTER_B
- addr: 127.0.0.1
- port: 5001
- role: inter-router
-}
-
-connector {
- name: INTER_ROUTER_C
- addr: 127.0.0.1
- port: 5002
- role: inter-router
-}
-
-address {
- prefix: my_queue
- waypoint: yes
-}
-----
-
-It has a _listener_ for accepting incoming connections from clients and two _connector_ entities in order to connect to the other routers. The queue named `my_queue` on the broker is exposed by a waypoint.
-
-The "Router.B" configuration is the following.
-
-[options="nowrap"]
-----
-router {
- mode: interior
- id: Router.B
-}
-
-listener {
- addr: 0.0.0.0
- port: 5001
- authenticatePeer: no
- role: inter-router
-}
-
-listener {
- host: 0.0.0.0
- port: 6001
- authenticatePeer: no
-}
-
-connector {
- name: BROKER
- addr: 127.0.0.1
- port: 5672
- role: route-container
-}
-
-address {
- prefix: my_queue
- waypoint: yes
-}
-
-autoLink {
- addr: my_queue
- connection: BROKER
- direction: in
-}
-
-autoLink {
- addr: my_queue
- connection: BROKER
- direction: out
-}
-----
-
-It can accept incoming connections from clients and from other routers (in this case the "Router.A") and connects to the broker. The queue named `my_queue` on the broker is exposed by a waypoint with the related auto-links in both directions in order to send and receive messages to/from the queue itself.
-
-Finally, the simple "Router.C" configuration.
-
-[options="nowrap"]
-----
-router {
- mode: interior
- id: Router.C
-}
-
-listener {
- addr: 0.0.0.0
- port: 5002
- authenticatePeer: no
- role: inter-router
-}
-
-listener {
- host: 0.0.0.0
- port: 6002
- authenticatePeer: no
-}
-----
-
-It can accept incoming connections from clients and from other routers (in this case the "Router.A"). Initially there is no connection between this router and the broker.
-
-First of all, thanks to the broker and its "store and forward" feature, the sender can connect to the "Router.A" and start to send messages even if the receiver is not online in that moment. Using the Python sample from the Qpid Proton library, the console output is like following.
-
-[options="nowrap"]
-----
-$ sudo python simple_send.py -a localhost:6000/my_queue -m 10
-all messages confirmed
-----
-
-All messages are confirmed because they reached the queue inside the broker through "Router.A" and "Router.B"; it is confirmed using the `qdstat` tool.
-
-[options="nowrap"]
-----
-$ sudo qdstat -b localhost:6001 -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
- router Router.A closest 0 0 1 0 0 0 6 0 6
- router Router.C closest 0 0 1 0 0 0 4 0 4
- mobile my_queue 1 balanced 0 0 0 0 0 0 0 0 0
- mobile my_queue 0 balanced 0 1 0 0 0 10 0 0 0
- local qdhello flood 1 1 0 0 0 0 0 97 117
- local qdrouter flood 1 0 0 0 0 0 0 7 0
- topo qdrouter flood 1 0 2 0 0 0 8 13 9
- local qdrouter.ma multicast 1 0 0 0 0 0 0 2 0
- topo qdrouter.ma multicast 1 0 2 0 0 0 0 0 1
- local temp.7f2u0zv9_U6QC5e closest 0 1 0 0 0 0 0 0 0
-----
-
-For the "Router.B", there are 10 messages as output (from the router to the broker) on the `my_queue` address.
-
-Starting the receiver connected to the "Router.A", it gets all the available messages from the queue.
-
-[options="nowrap"]
-----
-$ sudo python simple_recv.py -a localhost:6000/my_queue -m 10
-{u'sequence': 1L}
-{u'sequence': 2L}
-{u'sequence': 3L}
-{u'sequence': 4L}
-{u'sequence': 5L}
-{u'sequence': 6L}
-{u'sequence': 7L}
-{u'sequence': 8L}
-{u'sequence': 9L}
-{u'sequence': 10L}
-----
-
-Using the `qdstat` tool on the "Router.B" another time, the output is like following.
-
-[options="nowrap"]
-----
-$ sudo qdstat -b localhost:6001 -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
- router Router.A closest 0 0 1 0 0 0 6 0 6
- router Router.C closest 0 0 1 0 0 0 4 0 4
- mobile my_queue 1 balanced 0 0 0 0 10 0 10 0 0
- mobile my_queue 0 balanced 0 1 0 0 0 10 0 0 0
- local qdhello flood 1 1 0 0 0 0 0 156 182
- local qdrouter flood 1 0 0 0 0 0 0 7 0
- topo qdrouter flood 1 0 2 0 0 0 10 18 11
- local qdrouter.ma multicast 1 0 0 0 0 0 0 2 0
- topo qdrouter.ma multicast 1 0 2 0 0 0 0 2 1
- local temp.Xov_ZUcyti3jjXY closest 0 1 0 0 0 0 0 0 0
-----
-
-For the "Router.B", there are 10 messages as input (from the broker to the router) on the `my_queue` address.
-
-Now, consider a fault on the "Router.B"; in this case the broker is not reachable but it is possible to set up path redundancy through the "Router.C".
-
-.Path Redundancy and Temporal Decoupling after Router Failure
-image::path-redundancy-temp-decoupling-02.png[Path Redundancy and Temporal Decoupling after Router Failure, align="center"]
-
-Using the `qdmanage` tool, it is possible to configure the waypoint on `my_queue` address, the related auto-links in both directions and finally the _connector_ instance in order to enable the connection to the broker.
-
-[options="nowrap"]
-----
-$ sudo qdmanage -b localhost:6002 create --stdin
-[
-{ "type":"connector", "name":"BROKER", "port":5672, "role":"route-container" },
-{ "type":"address", "prefix":"my_queue", "waypoint":"yes" },
-{ "type":"autoLink", "addr":"my_queue", "connection":"BROKER", "direction":"in" },
-{ "type":"autoLink", "addr":"my_queue", "connection":"BROKER", "direction":"out" }
-]
-[
- {
- "verifyHostname": true,
- "stripAnnotations": "both",
- "name": "BROKER",
- "allowRedirect": true,
- "idleTimeoutSeconds": 16,
- "maxFrameSize": 65536,
- "host": "127.0.0.1",
- "cost": 1,
- "role": "route-container",
- "maxSessions": 32768,
- "type": "org.apache.qpid.dispatch.connector",
- "port": "5672",
- "identity": "connector/127.0.0.1:5672:BROKER",
- "addr": "127.0.0.1"
- },
- {
- "name": null,
- "prefix": "my_queue",
- "ingressPhase": 0,
- "waypoint": false,
- "distribution": "balanced",
- "type": "org.apache.qpid.dispatch.router.config.address",
- "identity": "7",
- "egressPhase": 0
- },
- {
- "addr": "my_queue",
- "name": null,
- "linkRef": null,
- "type": "org.apache.qpid.dispatch.router.config.autoLink",
- "operStatus": "inactive",
- "connection": "BROKER",
- "direction": "in",
- "phase": 1,
- "lastError": null,
- "externalAddr": null,
- "identity": "8",
- "containerId": null
- },
- {
- "addr": "my_queue",
- "name": null,
- "linkRef": null,
- "type": "org.apache.qpid.dispatch.router.config.autoLink",
- "operStatus": "inactive",
- "connection": "BROKER",
- "direction": "out",
- "phase": 0,
- "lastError": null,
- "externalAddr": null,
- "identity": "9",
- "containerId": null
- }
-]
-----
-
-The "Router.C" configuration changes in the same way as "Router.B". It can accept incoming connections from clients and from other routers (in this case the "Router.A") and connects to the broker. The queue named `my_queue` on the broker is exposed by a waypoint with the related auto-links in both directions in order to send and receive messages to/from the queue itself.
-
-At this point, the sender can connect to the "Router.A" for sending messages to the queue in the broker thanks to the "Router.C".
-
-[options="nowrap"]
-----
-$ sudo python simple_send.py -a localhost:6000/my_queue -m 10
-all messages confirmed
-----
-
-All messages are confirmed because they reached the queue inside the broker through "Router.A" and "Router.C"; it is confirmed using the `qdstat` tool.
-
-[options="nowrap"]
-----
-$ sudo qdstat -b localhost:6002 -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 1 1
- local $displayname closest 1 0 0 0 0 0 0 0 0
- mobile $management 0 closest 1 0 0 0 5 0 0 5 0
- local $management closest 1 0 0 0 0 0 0 0 0
- router Router.A closest 0 0 1 0 0 0 5 0 5
- mobile my_queue 0 balanced 0 1 0 0 0 10 0 0 0
- mobile my_queue 1 balanced 0 0 0 0 0 0 0 0 0
- local qdhello flood 1 1 0 0 0 0 0 665 647
- local qdrouter flood 1 0 0 0 0 0 0 8 0
- topo qdrouter flood 1 0 1 0 0 0 31 52 32
- local qdrouter.ma multicast 1 0 0 0 0 0 0 1 0
- topo qdrouter.ma multicast 1 0 1 0 0 0 1 2 1
- local temp.k6UMaS4P0JmtSlL closest 0 1 0 0 0 0 0 0 0
-
-----
-
-For the "Router.C", there are 10 messages as output (from the router to the broker) on the `my_queue` address.
-
-Starting the receiver connected to the "Router.A", it gets all the available messages from the queue.
-
-[options="nowrap"]
-----
-$ sudo python simple_recv.py -a localhost:6000/my_queue -m 10
-{u'sequence': 1L}
-{u'sequence': 2L}
-{u'sequence': 3L}
-{u'sequence': 4L}
-{u'sequence': 5L}
-{u'sequence': 6L}
-{u'sequence': 7L}
-{u'sequence': 8L}
-{u'sequence': 9L}
-{u'sequence': 10L}
-----
-
-Using the `qdstat` tool on the "Router.C" another time, the output is like following.
-
-[options="nowrap"]
-----
-$ sudo qdstat -b localhost:6002 -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 1 1
- local $displayname closest 1 0 0 0 0 0 0 0 0
- mobile $management 0 closest 1 0 0 0 6 0 0 6 0
- local $management closest 1 0 0 0 0 0 0 0 0
- router Router.A closest 0 0 1 0 0 0 5 0 5
- mobile my_queue 0 balanced 0 1 0 0 0 10 0 0 0
- mobile my_queue 1 balanced 0 0 0 0 10 0 10 0 0
- local qdhello flood 1 1 0 0 0 0 0 746 726
- local qdrouter flood 1 0 0 0 0 0 0 8 0
- topo qdrouter flood 1 0 1 0 0 0 34 55 35
- local qdrouter.ma multicast 1 0 0 0 0 0 0 1 0
- topo qdrouter.ma multicast 1 0 1 0 0 0 1 4 1
- local temp.Hso3moy3l+Sn+Fy closest 0 1 0 0 0 0 0 0 0
-----
-
-For the "Router.C", there are 10 messages as input (from the broker to the router) on the `my_queue` address.
-
-== Sharded Queue
-
-Every broker has limits in terms of queue size but in order to overcome this problem, one possible solution is "sharding" queues : in that way a single queue is divided in more "shards" (chunks) each on a different broker. It means that such solution needs more than one broker instance in order to host a shard on each of them. Of course, a sender connected to one of these brokers can send messages to the shard hosted only on that broker. At same time, a receiver connected to a broker can get messages from the shard that is hosted on that broker and can not see available messages in the shards hosted on the other brokers, even if they are all parts of the same queue.
-
-[NOTE]
-====
-Even if speaking about shards it is obvious that they are real queues all with same name but on different brokers. The "shard" concept is an abstract one because finally a shard is a real queue stored on a broker.
-====
-
-The big problem in this scenario, designed only with brokers, is that a receiver can be stucked on an empty shard without reading any messages while the shards on the other brokers have messages to deliver. it is a real problem because the receiver is interested in receiving messages from the whole queue and it does not take care if it is shared or not. Because of this problem, the receiver sees the queue as empty even if it is not so true due to the sharding and the messages available on the other shards.
-
-The above problem can be solved adding a {RouterName} instance in the network in front of the brokers and leverage on its waypoint feature with related auto-links.
-
-Consider the following simple scenario :
-
-* a network with one router "Router.A" and two brokers.
-* the "Router.A" listens for clients connections and it is connected to both brokers.
-* the brokers host shards for a queue; each broker has one shard.
-* a sender client connects to the "Router.A" in order to send messages to the queue.
-* a receiver client connects to the "Router.A" in order to get messages from the queue.
-
-.Sharded Queue Enabled Topology
-image::sharded-queue-01.png[Sharded Queue Enabled Topology, align="center"]
-
-With such solution and connecting to the "Router.A", sender and receiver do not know anything about sharding; they want send and receive messages to/from the whole queue that is the only thing they are aware of. They are both connected to the router and see only one address (related to the queue).
-
-The "Router.A" configuration is something like following.
-
-[options="nowrap"]
-----
-router {
- mode: standalone
- id: Router.A
-}
-
-listener {
- host: 0.0.0.0
- port: 6000
- authenticatePeer: no
-}
-
-connector {
- name: BROKER1
- addr: 127.0.0.1
- port: 5672
- role: route-container
-}
-
-connector {
- name: BROKER2
- addr: 127.0.0.1
- port: 5673
- role: route-container
-}
-
-address {
- prefix: my_queue
- waypoint: yes
-}
-
-autoLink {
- addr: my_queue
- connection: BROKER1
- direction: in
-}
-
-autoLink {
- addr: my_queue
- connection: BROKER1
- direction: out
-}
-
-autoLink {
- addr: my_queue
- connection: BROKER2
- direction: in
-}
-
-autoLink {
- addr: my_queue
- connection: BROKER2
- direction: out
-}
-----
-
-The router has a _listener_ for incoming connection from clients and two _connector_ instances in order to connect to both brokers. The whole queue is named `my_queue` hosted in terms of shards on both brokers and the router is configured with a waypoint for that address. Finally, there are two auto-links in both directions for that queue on both brokers.
-
-Using the Python sample from the Qpid Proton library, the sender can connect to the "Router.A" and start to send messages to the queue; the console output is like following.
-
-[options="nowrap"]
-----
-$ sudo python simple_send.py -a localhost:6000/my_queue -m 10
-all messages confirmed
-----
-
-All messages are confirmed because they reached the queue and, thanks to the default `balanced` distribution on the address, the messages are delivered to both shards on the brokers (5 messages per shard). Using the `qdstat` tool on the router, the distribution is clear.
-
-[options="nowrap"]
-----
-$ sudo qdstat -b localhost:6000 -l
-Router Links
- type dir conn id id peer class addr phs cap undel unsettled deliveries admin oper
- =======================================================================================================================
- endpoint in 1 6 mobile my_queue 1 250 0 0 0 enabled up
- endpoint out 1 7 mobile my_queue 0 250 0 0 5 enabled up
- endpoint in 2 8 mobile my_queue 1 250 0 0 0 enabled up
- endpoint out 2 9 mobile my_queue 0 250 0 0 5 enabled up
- endpoint in 8 19 mobile $management 0 250 0 0 1 enabled up
- endpoint out 8 20 local temp.qCGHruCa4UIvYrS 250 0 0 0 enabled up
-----
-
-There are the `out` links (from router to brokers) for the `my_queue` address (_id_ values `7` and `9`) which have each 5 deliveries. It shows messages distributed across brokers and related shards for the queue; it is confirmed by the different connections they are tied (_conn id_ values `1` and `2`).
-
-Starting the receiver connected to the "Router.A", it gets all the available messages from the queue.
-
-[options="nowrap"]
-----
-$ sudo python simple_recv.py -a localhost:6000/my_queue -m 10
-{u'sequence': 1L}
-{u'sequence': 2L}
-{u'sequence': 3L}
-{u'sequence': 4L}
-{u'sequence': 5L}
-{u'sequence': 6L}
-{u'sequence': 7L}
-{u'sequence': 8L}
-{u'sequence': 9L}
-{u'sequence': 10L}
-----
-
-As for the sender, they are received through both the brokers and related shards. it is confirmed using the `qdstat` tool.
-
-[options="nowrap"]
-----
-$ sudo qdstat -b localhost:6000 -l
-Router Links
- type dir conn id id peer class addr phs cap undel unsettled deliveries admin oper
- =======================================================================================================================
- endpoint in 1 6 mobile my_queue 1 250 0 0 5 enabled up
- endpoint out 1 7 mobile my_queue 0 250 0 0 5 enabled up
- endpoint in 2 8 mobile my_queue 1 250 0 0 5 enabled up
- endpoint out 2 9 mobile my_queue 0 250 0 0 5 enabled up
- endpoint in 10 22 mobile $management 0 250 0 0 1 enabled up
- endpoint out 10 23 local temp.HT+f3ZilGP5o3wo 250 0 0 0 enabled up
-----
-
-There are the `in` links (from brokers to router) for the `my_queue` address (_id_ values `6` and `8`) which have each 5 deliveries. It shows messages distributed across brokers and related shards for the queue; it is confirmed by the different connections they are tied (_conn id_ values `1` and `2`).
-
-One disadvantage of sharded queues is that the receiver might receive messages "out of order" even with very good performance.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/revision-info.adoc
----------------------------------------------------------------------
diff --git a/doc/new-book/revision-info.adoc b/doc/new-book/revision-info.adoc
deleted file mode 100644
index fb19158..0000000
--- a/doc/new-book/revision-info.adoc
+++ /dev/null
@@ -1,20 +0,0 @@
-////
-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
-////
-
-_Revised on {localdate} {localtime}_
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/routing.adoc
----------------------------------------------------------------------
diff --git a/doc/new-book/routing.adoc b/doc/new-book/routing.adoc
deleted file mode 100644
index dcb5d07..0000000
--- a/doc/new-book/routing.adoc
+++ /dev/null
@@ -1,721 +0,0 @@
-////
-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
-////
-
-[id='routing']
-= Routing
-
-Routing is the process by which messages are delivered to their destinations. To accomplish this, {RouterName} provides two routing mechanisms: _message routing_ and _link routing_.
-
-Message routing:: 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 _settlement_ based on the message's _address_ and _routing pattern_.
-+
---
-.Message Routing
-image::message-routing.png[Message Routing, align="center"]
-
-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.
---
-
-Link routing:: 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 is established, the transfer of message deliveries, flow frames, and dispositions is performed across the link route.
-+
---
-.Link Routing
-image::link-routing.png[Link Routing, align="center"]
-
-In this diagram, a router is connected to clients and to a broker, and it provides a link route to a queue on the broker (my_queue). The sender connects to the router, and the router propagates the link-attaches to the broker to form a direct link between the sender and the broker. The sender can begin sending messages to the queue, and the router passes the deliveries along the link route directly to the broker queue.
---
-
-== Comparison of Message Routing and Link Routing
-
-While you can use either message routing or link routing to deliver messages to a destination, they differ in several important ways. Understanding these differences will enable you to choose the proper routing approach for any particular use case.
-
-=== When to Use Message Routing
-
-Message routing is the default routing mechanism. You can use it to route messages on a per-message basis between clients directly (direct-routed messaging), or to and from broker queues (brokered messaging).
-
-Message routing is best suited to the following requirements:
-
-* Default, basic message routing.
-+
-{RouterName} automatically routes messages by default, so manual configuration is only required if you want routing behavior that is different than the default.
-
-* Message-based routing patterns.
-+
-Message routing supports both anycast and multicast routing patterns. You can load-balance individual messages across multiple consumers, and multicast (or fan-out) messages to multiple subscribers.
-
-* Sharding messages across multiple broker instances when message delivery order is not important.
-+
-Sharding messages from one producer might cause that producer's messages to be received in a different order than the order in which they were sent.
-
-Message routing is not suitable for any of the following requirements:
-
-* Dedicated path through the router network.
-+
-For inter-router transfers, all message deliveries are placed on the same inter-router link. This means that the traffic for one address might affect the delivery of the traffic for another address.
-
-* Granular, end-to-end flow control.
-+
-With message routing, end-to-end flow control is based on the settlement of deliveries and therefore might not be optimal in every case.
-
-* Transaction support.
-
-* Server-side selectors.
-
-=== When to Use Link Routing
-
-Link routing requires more detailed configuration than message routing as well as an AMQP container that can accept incoming link-attaches (typically a broker). However, link routing enables you to satisfy more advanced use cases than message routing.
-
-You can use link routing if you need to meet any of the following requirements:
-
-* Dedicated path through the router network.
-+
-With link routing, each link route has dedicated inter-router links through the network. Each link has its own dedicated message buffers, which means that the address will not have "head-of-line" blocking issues with other addresses.
-
-* Sharding messages across multiple broker instances with guaranteed delivery order.
-+
-Link routing to a sharded queue preserves the delivery order of the producer's messages by causing all messages on that link to go to the same broker instance.
-
-* End-to-end flow control.
-+
-Flow control is "real" in that credits flow across the link route from the receiver to the sender.
-
-* Transaction support.
-+
-Link routing supports local transactions to a broker.
-
-* Server-side selectors.
-+
-With a link route, consumers can provide server-side selectors for broker subscriptions.
-
-== Configuring Message Routing
-
-With message routing, 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 _settlement_ based on the message's _address_ and _routing pattern_.
-
-With message routing, you can do the following:
-
-* Route messages between clients (direct-routed, or brokerless messaging)
-+
-This involves configuring an address with a routing pattern. All messages sent to the address will be routed based on the routing pattern.
-* Route messages through a broker queue (brokered messaging)
-+
-This involves configuring a waypoint address to identify the broker queue and then connecting the router to the broker. All messages sent to the waypoint address will be routed to the broker queue.
-
-=== Addresses
-
-Addresses determine how messages flow through your router network. An address designates an endpoint in your messaging network, such as:
-
-* Endpoint processes that consume data or offer a service
-* Topics that match multiple consumers to multiple producers
-* Entities within a messaging broker:
-** Queues
-** Durable Topics
-** Exchanges
-
-When a router receives a message, it uses the message's address to determine where to send the message (either its destination or one step closer to its destination).
-
-// Do we need to specify that these are AMQP addresses? Should they be distinguished from generic message addresses?
-
-// Need to add something here about the difference between discovered vs. configured mobile addresses so that it's clear that with message routing, the router can either be proactive or reactive in the way it routes messages.
-
-[id='routing-patterns-overview']
-=== Routing Patterns
-
-Each address has one of the following routing patterns, which define the path that a message with the address can take across the messaging network:
-
-Balanced:: An anycast method that allows multiple consumers to use the same address. Each message is delivered to a single consumer only, and {RouterName} attempts to balance the traffic load across the router network.
-+
---
-If multiple consumers are attached to the same address, each router determines which outbound path should receive a message by considering each path's current number of unsettled deliveries. This means that more messages will be delivered along paths where deliveries are settled at higher rates.
-
-[NOTE]
-====
-{RouterName} neither measures nor uses message settlement time to determine which outbound path to use.
-====
-
-In this scenario, the messages are spread across both receivers regardless of path length:
-
-.Balanced Message Routing
-image::balanced-routing.png[Balanced Message Routing, align="center"]
---
-
-Closest:: An anycast method in which every message is sent along the shortest path to reach the destination, even if there are other consumers for the same address.
-+
-{RouterName} determines the shortest path based on the topology cost to reach each of the consumers. If there are multiple consumers with the same lowest cost, messages will be spread evenly among those consumers.
-+
-In this scenario, all messages sent by `Sender` will be delivered to `Receiver 1`:
-+
-.Closest Message Routing
-image::closest-routing.png[Closest Message Routing, align="center"]
-
-Multicast:: Messages are sent to all consumers attached to the address. Each consumer will receive one copy of the message.
-+
-In this scenario, all messages are sent to all receivers:
-+
-.Multicast Message Routing
-image::multicast-routing.png[Multicast Message Routing, align="center"]
-
-=== Message Settlement
-
-Message settlement is negotiated between the producer and the router when the producer establishes a link to the router. Depending on the settlement pattern, messages might be delivered with any of the following degrees of reliability:
-
-* At most once
-* At least once
-* Exactly once
-
-{RouterName} treats all messages as either _pre-settled_ or _unsettled_, and it is responsible for propagating the settlement of each message it routes.
-
-Pre-settled:: Sometimes called _fire and forget_, the router settles the incoming and outgoing deliveries and propagates the settlement to the message's destination. However, it does not guarantee delivery.
-
-Unsettled:: The router propagates the settlement between the sender and receiver, and guarantees one of the following outcomes:
-+
-* The message is delivered and settled, with the consumer's disposition indicated.
-* The delivery is settled with a disposition of `RELEASED`.
-+
-This means that the message did not reach its destination.
-* The delivery is settled with a disposition of `MODIFIED`.
-+
-This means that the message might or might not have reached its destination. The delivery is considered to be "in-doubt" and should be re-sent if "at least once" delivery is required.
-* The link, session, or connection to {RouterName} was dropped, and all deliveries are "in-doubt".
-
-[id='routing-messages-between-clients']
-=== Routing Messages Between Clients
-
-You can route messages between clients without using a broker. In a brokerless scenario (sometimes called _direct-routed messaging_), {RouterName} routes messages between clients directly.
-
-To route messages between clients, you configure an address with a routing distribution pattern. When a router receives a message with this address, the message is routed to its destination or destinations based on the address's routing distribution pattern.
-
-.Procedure
-
-. In the router's configuration file, add an `address` section:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-address {
- prefix: _ADDRESS_PREFIX_
- distribution: balanced|closest|multicast
- ...
-}
-----
-
-`prefix` | `pattern`:: The address or group of addresses to which the address settings should be applied. You can specify a prefix to match an exact address or beginning segment of an address. Alternatively, you can specify a pattern to match an address using wildcards.
-+
-//tag::prefix-matching[]
-A _prefix_ matches either an exact address or the beginning segment within an address that is delimited by either a `.` or `/` character. For example, the prefix `my_address` would match the address `my_address` as well as `my_address.1` and `my_address/1`. However, it would not match `my_address1`.
-//end::prefix-matching[]
-+
-//tag::pattern-matching[]
-A _pattern_ matches an address that corresponds to a pattern. A pattern is a sequence of words delimited by either a `.` or `/` character. You can use wildcard characters to represent a word. The `*` character matches exactly one word, and the `#` character matches any sequence of zero or more words.
-+
-The `*` and `#` characters are reserved as wildcards. Therefore, you should not use them in the message address.
-+
-The following table shows some examples of address patterns:
-+
-[cols="25,75"]
-|===
-| This pattern... | Matches...
-| `news` | `news`
-| `news/*/sports` | `news/europe/sports` and `news/usa/sports`, but not `news` or `news/europe/fr/sports`
-| `news/#` | `news`, `news/europe`, `news/usa`, `news/usa/sports`
-|===
-+
-[NOTE]
-====
-You can convert a `prefix` value to a `pattern` by appending `/\#` to it. For example, the prefix `a/b/c` is equivalent to the pattern `a/b/c/#`.
-====
-//end::pattern-matching[]
-
-`distribution`:: The message distribution pattern. The default is `balanced`, but you can specify any of the following options:
-+
-* `balanced` - Messages sent to the address will be routed to one of the receivers, and the routing network will attempt to balance the traffic load based on the rate of settlement.
-* `closest` - Messages sent to the address are sent on the shortest path to reach the destination. It means that if there are multiple receivers for the same address, only the closest one will receive the message.
-* `multicast` - Messages are sent to all receivers that are attached to the address in a _publish/subscribe_ model.
-+
-For more information about message distribution patterns, see xref:routing-patterns-overview[Routing Patterns].
-
-For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_address[address] in the `qdrouterd.conf` man page.
---
-
-. Add the same `address` section to any other routers that need to use the address.
-+
-The `address` that you added to this router configuration file only controls how this router distributes messages sent to the address. If you have additional routers in your router network that should distribute messages for this address, then you must add the same `address` section to each of their configuration files.
-
-[id='routing-messages-through-broker']
-=== Routing Messages Through a Broker Queue
-
-You can route messages to and from a broker queue to provide clients with access to the queue through a router. In this scenario, clients connect to a router to send and receive messages, and the router routes the messages to or from the broker queue.
-
-You can route messages to a queue hosted on a single broker, or route messages to a _sharded queue_ distributed across multiple brokers.
-
-.Brokered Messaging
-image::brokered-messaging.png[Brokered Messaging, align="center"]
-
-In this diagram, the sender connects to the router and sends messages to my_queue. The router attaches an outgoing link to the broker, and then sends the messages to my_queue. Later, the receiver connects to the router and requests messages from my_queue. The router attaches an incoming link to the broker to receive the messages from my_queue, and then delivers them to the receiver.
-
-You can also route messages to a _sharded queue_, which is a single, logical queue comprised of multiple, underlying physical queues. Using queue sharding, it is possible to distribute a single queue over multiple brokers. Clients can connect to any of the brokers that hold a shard to send and receive messages.
-
-.Brokered Messaging with Sharded Queue
-image::sharded-queue-02.png[Brokered Messaging with Sharded Queue, align="center"]
-
-In this diagram, a sharded queue (my_queue) is distributed across two brokers. The router is connected to the clients and to both brokers. The sender connects to the router and sends messages to my_queue. The router attaches an outgoing link to each broker, and then sends messages to each shard (by default, the routing distribution is `balanced`). Later, the receiver connects to the router and requests all of the messages from my_queue. The router attaches an incoming link to one of the brokers to receive the messages from my_queue, and then delivers them to the receiver.
-
-.Procedure
-
-. xref:configure-waypoint-address[Add a waypoint address].
-+
-This address identifies the queue to which you want to route messages.
-. xref:connect-router-to-broker[Add autolinks to connect the router to the broker].
-+
-Autolinks connect the router to the broker queue identified by the waypoint address.
-
-. xref:connect-router-to-broker[If the queue is sharded, add autolinks for each additional broker that hosts a shard].
-
-[id='configure-waypoint-address']
-==== Configuring Waypoint Addresses
-
-A waypoint address identifies a queue on a broker to which you want to route messages. You need to configure the waypoint address on each router that needs to use the address. For example, if a client is connected to _Router A_ to send messages to the broker queue, and another client is connected to _Router B_ to receive those messages, then you would need to configure the waypoint address on both _Router A_ and _Router B_.
-
-.Prerequisites
-
-An incoming connection (`listener`) to which the clients can connect should be configured. This connection defines how the producers and consumers connect to the router to send and receive messages. For more information, see xref:adding-incoming-connections[Adding Incoming Connections].
-
-// Does the broker queue have to exist before you create the waypoint address? If it doesn't exist, will you get an error?
-
-.Procedure
-
-* Create waypoint addresses on each router that needs to use the address:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-address {
- prefix: _ADDRESS_PREFIX_
- waypoint: yes
-}
-----
-
-`prefix` | `pattern`:: The address prefix or pattern that matches the broker queue to which you want to send messages. You can specify a prefix to match an exact address or beginning segment of an address. Alternatively, you can specify a pattern to match an address using wildcards.
-+
-include::routing.adoc[tags=prefix-matching]
-+
-include::routing.adoc[tags=pattern-matching]
-
-`waypoint`:: Set this attribute to `yes` so that the router handles messages sent to this address as a waypoint.
---
-
-[id='connect-router-to-broker']
-==== Connecting a Router to the Broker
-
-After you add waypoint addresses to identify the broker queue, you must connect a router to the broker using autolinks.
-
-With autolinks, client traffic is handled on the router, not the broker. Clients attach their links to the router, and then the router uses internal autolinks to connect to the queue on the broker. Therefore, the queue will always have a single producer and a single consumer regardless of how many clients are attached to the router.
-
-. If this router is different than the router that is connected to the clients, then add the waypoint address.
-
-. Add an outgoing connection to the broker:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-connector {
- name: _NAME_
- host: _HOST_NAME/ADDRESS_
- port: _PORT_NUMBER/NAME_
- role: route-container
- ...
-}
-----
-
-`name`:: The name of the `connector`. Specify a name that describes the broker.
-`host`:: Either an IP address (IPv4 or IPv6) or hostname on which the router should connect to the broker.
-`port`:: The port number or symbolic service name on which the router should connect to the broker.
-`role`:: Specify `route-container` to indicate that this connection is for an external container (broker).
-
-For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_connector[connector] in the `qdrouterd.conf` man page.
---
-
-. If you want to send messages to the broker queue, create an outgoing autolink to the broker queue:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-autoLink {
- addr: _ADDRESS_
- connection: _CONNECTOR_NAME_
- direction: out
- ...
-}
-----
-
-`addr`:: The address of the broker queue. When the autolink is created, it will be attached to this address.
-`externalAddr`:: An optional alternate address for the broker queue. You use an external address if the broker queue should have a different address than that which the sender uses. In this scenario, senders send messages to the `addr` address, and then the router routes them to the broker queue represented by the `externalAddr` address.
-`connection` | `containerID`:: How the router should connect to the broker. You can specify either an outgoing connection (`connection`) or the container ID of the broker (`containerID`).
-`direction`:: Set this attribute to `out` to specify that this autolink can send messages from the router to the broker.
-
-For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_autolink[autoLink] in the `qdrouterd.conf` man page.
---
-
-. If you want to receive messages from the broker queue, create an incoming autolink from the broker queue:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-autoLink {
- addr: _ADDRESS_
- connection: _CONNECTOR_NAME_
- direction: in
- ...
-}
-----
-
-`addr`:: The address of the broker queue. When the autolink is created, it will be attached to this address.
-`externalAddr`:: An optional alternate address for the broker queue. You use an external address if the broker queue should have a different address than that which the receiver uses. In this scenario, receivers receive messages from the `addr` address, and the router retrieves them from the broker queue represented by the `externalAddr` address.
-`connection` | `containerID`:: How the router should connect to the broker. You can specify either an outgoing connection (`connection`) or the container ID of the broker (`containerID`).
-`direction`:: Set this attribute to `in` to specify that this autolink can receive messages from the broker to the router.
-
-For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_autolink[autoLink] in the `qdrouterd.conf` man page.
---
-
-=== Example: Routing Messages Through Broker Queues
-
-This example shows how waypoints and autolinks can route messages through a pair of queues on a broker.
-
-==== Router Configuration
-
-[options="nowrap"]
-----
-connector { // <1>
- name: broker
- role: route-container
- host: 198.51.100.1
- port: 61617
- saslMechanisms: ANONYMOUS
-}
-
-address { // <2>
- prefix: queue
- waypoint: yes
-}
-
-autoLink { // <3>
- addr: queue.first
- direction: in
- connection: broker
-}
-
-autoLink { // <4>
- addr: queue.first
- direction: out
- connection: broker
-}
-
-autoLink { // <5>
- addr: queue.second
- direction: in
- connection: broker
-}
-
-autoLink { // <6>
- addr: queue.second
- direction: out
- connection: broker
-}
-----
-<1> The outgoing connection from the router to the broker. The `route-container` role enables the router to connect to an external AMQP container (in this case, a broker).
-<2> The namespace queue on the broker to which the router should route messages. All addresses that start with `queue` will be routed to a queue on the broker.
-<3> The incoming autolink from `queue.first` on the broker to the router.
-<4> The outgoing autolink from the router to `queue.first` on the broker.
-<5> The incoming autolink from `queue.second` on the broker to the router.
-<6> The outgoing autolink from the router to `queue.second` on the broker.
-
-==== How the Messages are Routed
-
-Initially, when the broker is offline, the autolinks are inactive.
-
-[options="nowrap"]
-----
-$ 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
-----
-
-Once the broker is online, the autolinks attempt to activate. In this case, the broker starts with the `queue.first` queue only, and the `queue.first` autolinks become active. The `queue.second` autolinks are in a failed state, because the `queue.second` queue does not exist on the broker.
-
-[options="nowrap"]
-----
-$ 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
-----
-
-The producer now connects to the router and sends three messages to `queue.first`.
-
-[options="nowrap"]
-----
-$ python simple_send.py -a 127.0.0.1/queue.first -m3
-all messages confirmed
-----
-
-The router's address statistics show that the messages were delivered to the queue.
-
-[options="nowrap"]
-----
-$ 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
-----
-
-The `queue.first` address appears twice in the output: once for each phase of the address. Phase 0 is for routing messages from producers to the outgoing autolink. Phase 1 is for routing messages from the incoming autolink to the subscribed consumers. In this case, Phase 0 of the address has counted three messages in the `in` column (the messages that arrived on the router from the producer), and three messages in the `out` column (the messages that were sent from the router to the broker queue).
-
-The consumer now connects to the router and receives the three messages from `queue.first`.
-
-[options="nowrap"]
-----
-$ 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)}
-----
-
-The router's address statistics now show that all three messages were received by the consumer from the broker queue.
-
-[options="nowrap"]
-----
-$ 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
-----
-
-The command output shows that Phase 1 of the address was used to deliver all three messages from the queue to the consumer.
-
-[NOTE]
-====
-Even in a multi-router network, and with multiple producers and consumers for `queue.first`, all deliveries are routed through the queue on the connected broker.
-====
-
-== Configuring Link Routing
-
-Link routing provides an alternative strategy for brokered messaging. A link route represents a private messaging path between a sender and a receiver in which the router passes the messages between end points. You can think of a link route as a "virtual connection" or "tunnel" that travels from a sender, through the router network, to a receiver.
-
-With link routing, 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 is established, the transfer of message deliveries, flow frames, and dispositions is performed across the link route.
-
-=== Link Route Addresses
-
-A link route address represents a broker queue, topic, or other service. When a client attaches a link route address to a router, the router propagates a link attachment to the broker resource identified by the address.
-
-=== Link Route Routing Patterns
-
-Routing patterns are not used with link routing, because there is a direct link between the sender and receiver. The router only makes a routing decision when it receives the initial link-attach request frame. Once the link is established, the router passes the messages along the link in a balanced distribution.
-
-=== Link Route Flow Control
-
-Unlike message routing, with link routing, the sender and receiver handle flow control directly: the receiver grants link credits, which is the number of messages it is able to receive. The router sends them directly to the sender, and then the sender sends the messages based on the credits that the receiver granted.
-
-// What additional information do we need to provide about AMQP link flow control options? Since this is handled on the client side for link routing, should we provide a simple example with a client program that implements link flow control?
-
-[id='creating-link-route']
-=== Creating a Link Route
-
-Link routes establish a link between a sender and a receiver that travels through a router. You can configure inward and outward link routes to enable the router to receive link-attaches from clients and to send them to a particular destination.
-
-With link routing, client traffic is handled on the broker, not the router. Clients have a direct link through the router to a broker's queue. Therefore, each client is a separate producer or consumer.
-
-.Procedure
-
-. In the router configuration file, add an outgoing connection to the broker:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-connector {
- name: _NAME_
- host: _HOST_NAME/ADDRESS_
- port: _PORT_NUMBER/NAME_
- role: route-container
- ...
-}
-----
-
-`name`:: The name of the `connector`. You should specify a name that describes the broker.
-`host`:: Either an IP address (IPv4 or IPv6) or hostname on which the router should connect to the broker.
-`port`:: The port number or symbolic service name on which the router should connect to the broker.
-`role`:: Specify `route-container` to indicate that this connection is for an external container (broker).
-
-For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_connector[connector] in the `qdrouterd.conf` man page.
---
-
-. If you want clients to send messages on this link route, create an incoming link route:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-linkRoute {
- prefix: __ADDRESS_PREFIX__
- connection: __CONNECTOR_NAME__
- direction: in
- ...
-}
-----
-
-`prefix` | `pattern`:: The address prefix or pattern that matches the broker queue that should be the destination for routed link-attaches. All messages that match this prefix or pattern will be distributed along the link route. You can specify a prefix to match an exact address or beginning segment of an address. Alternatively, you can specify a pattern to match an address using wildcards.
-+
-include::routing.adoc[tags=prefix-matching]
-+
-include::routing.adoc[tags=pattern-matching]
-
-`connection` | `containerID`:: How the router should connect to the broker. You can specify either an outgoing connection (`connection`) or the container ID of the broker (`containerID`).
-+
-If multiple brokers are connected to the router through this connection, requests for addresses matching the link route's prefix or pattern are balanced across the brokers. Alternatively, if you want to specify a particular broker, use `containerID` and add the broker's container ID.
-
-`direction`:: Set this attribute to `in` to specify that clients can send messages into the router network on this link route.
-
-For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_linkroute[linkRoute] in the `qdrouterd.conf` man page.
---
-
-. If you want clients to receive messages on this link route, create an outgoing link route:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-linkRoute {
- prefix: __ADDRESS_PREFIX__
- connection: __CONNECTOR_NAME__
- direction: out
- ...
-}
-----
-
-`prefix` | `pattern`:: The address prefix or pattern that matches the broker queue from which you want to receive routed link-attaches. All messages that match this prefix or pattern will be distributed along the link route. You can specify a prefix to match an exact address or beginning segment of an address. Alternatively, you can specify a pattern to match an address using wildcards.
-+
-include::routing.adoc[tags=prefix-matching]
-+
-include::routing.adoc[tags=pattern-matching]
-
-`connection` | `containerID`:: How the router should connect to the broker. You can specify either an outgoing connection (`connection`) or the container ID of the broker (`containerID`).
-+
-If multiple brokers are connected to the router through this connection, requests for addresses matching the link route's prefix or pattern are balanced across the brokers. Alternatively, if you want to specify a particular broker, use `containerID` and add the broker's container ID.
-`direction`:: Set this attribute to `out` to specify that this link route is for receivers.
-
-For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_linkroute[linkRoute] in the `qdrouterd.conf` man page.
---
-
-=== Example: Using a Link Route to Provide Client Isolation
-
-This example shows how a link route can connect a client to a message broker that is on a different private network.
-
-.Router Network with Isolated Clients
-----
-
- Public Network
- +-----------------+
- | +-----+ |
- | B1 | Rp | |
- | +/--\-+ |
- | / \ |
- | / \ |
- +----/--------\---+
- / \
- / \
- / \
- Private Net A / \ Private Net B
- +--------------/--+ +---\-------------+
- | +---/-+ | | +--\--+ |
- | B2 | Ra | | | | Rb | C1 |
- | +-----+ | | +-----+ |
- | | | |
- | | | |
- +-----------------+ +-----------------+
-----
-
-Client `C1` is constrained by firewall policy to connect to the router in its own network (`Rb`). However, it can use a link route to access queues, topics, and any other AMQP services that are provided on message brokers `B1` and `B2` -- even though they are on different networks.
-
-In this example, client `C1` needs to receive messages from `b2.event-queue`, which is hosted on broker `B2` in `Private Net A`. A link route connects the client and broker even though neither of them is aware that there is a router network between them.
-
-==== Router Configuration
-
-To enable client `C1` to receive messages from `b2.event-queue` on broker `B2`, router `Ra` must be able to do the following:
-
-* Connect to broker `B2`
-* Route links to and from broker `B2`
-* Advertise itself to the router network as a valid destination for links that have a `b2.event-queue` address.
-
-The relevant part of the configuration file for router `Ra` shows the following:
-
---
-[options="nowrap"]
-----
-connector { // <1>
- name: broker
- role: route-container
- host: 198.51.100.1
- port: 61617
- saslMechanisms: ANONYMOUS
-}
-
-linkRoute { // <2>
- prefix: b2
- direction: in
- connection: broker
-}
-
-linkRoute { // <3>
- prefix: b2
- direction: out
- connection: broker
-}
-----
-<1> The outgoing connection from the router to broker `B2`. The `route-container` role enables the router to connect to an external AMQP container (in this case, a broker).
-<2> The incoming link route for receiving links from client senders. Any sender with a target whose address begins with `b2` will be routed to broker `B2` using the `broker` connector.
-<3> The outgoing link route for sending links to client receivers. Any receivers whose source address begins with `b2` will be routed to broker `B2` using the `broker` connector.
---
-
-This configuration enables router `Ra` to advertise itself as a valid destination for targets and sources starting with `b2`. It also enables the router to connect to broker `B2`, and to route links to and from queues starting with the `b2` prefix.
-
-[NOTE]
-====
-While not required, routers `Rp` and `Rb` should also have the same configuration.
-====
-
-==== How the Client Receives Messages
-
-By using the configured link route, client `C1` can receive messages from broker `B2` even though they are on different networks.
-
-Router `Ra` establishes a connection to broker `B2`. 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 and receiver links attached to `Rb` or `Rp` will be routed along the shortest path to `Ra`, which then routes them to broker `B2`.
-
-To receive messages from the `b2.event-queue` on broker `B2`, client `C1` attaches a receiver link with a source address of `b2.event-queue` to its local router, `Rb`. Because the address matches the `b2` prefix, `Rb` routes the link to `Rp`, which is the next hop in the route to its destination. `Rp` routes the link to `Ra`, which routes it to broker `B2`. Client `C1` now has a receiver established, and it can begin receiving messages.
-
-[NOTE]
-====
-If broker `B2` is unavailable for any reason, router `Ra` will not advertise itself as a destination for `b2` addresses. In this case, routers `Rb` and `Rp` will reject link attaches that should be routed to broker `B2` with an error message indicating that there is no route available to the destination.
-====
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/technical-details-specifications.adoc
----------------------------------------------------------------------
diff --git a/doc/new-book/technical-details-specifications.adoc b/doc/new-book/technical-details-specifications.adoc
deleted file mode 100644
index 4a57d32..0000000
--- a/doc/new-book/technical-details-specifications.adoc
+++ /dev/null
@@ -1,190 +0,0 @@
-////
-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
-////
-
-[id='technical-details-specifications']
-= Technical Details and Specifications
-
-[id='client-compatibility']
-== Client Compatibility
-
-{RouterName} should, in theory, work with any client that is
-compatible with AMQP 1.0. The following clients have been tested:
-
-[width="100%",cols="22%,78%",options="header",]
-|=======================================================================
-|_Client_ |_Notes_
-|qpid::messaging |The Qpid messaging clients work with {RouterName}
-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.
-
-|Proton Reactor |The Proton Reactor API is compatible with {RouterName}.
-
-|Proton Messenger |Messenger works with {RouterName}.
-|=======================================================================
-
-[id='amqp-mapping']
-== AMQP Mapping
-
-{RouterName} is an AMQP router and as such, it provides extensions,
-code-points, and semantics for routing over AMQP. This page documents the
-details of {RouterName}'s use of AMQP.
-
-[id='message-annotations']
-=== Message Annotations
-
-The following Message Annotation fields are defined by {RouterName}:
-
-[width="100%",cols="23%,19%,58%",options="header",]
-|=======================================================================
-|_Field_ |_Type_ |_Description_
-|x-opt-qd.ingress |string |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.
-
-|x-opt-qd.trace |list of string |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.
-
-|x-opt-qd.to |string |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 _to_ 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.
-
-|x-opt-qd.phase |integer |The address-phase, if not zero, for messages
-flowing between routers.
-|=======================================================================
-
-[id='sourcetarget-capabilities']
-=== Source/Target Capabilities
-
-The following Capability values are used in Sources and Targets.
-
-[width="100%",cols="19%,81%",options="header",]
-|=======================================================================
-|_Capability_ |_Description_
-|qd.router |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.
-
-|qd.router-data |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.
-|=======================================================================
-
-[id='dynamic-node-properties']
-=== Dynamic-Node-Properties
-
-The following dynamic-node-properties are used by {RouterName} in Sources.
-
-[width="100%",cols="23%,77%",options="header",]
-|=======================================================================
-|_Property_ |_Description_
-|x-opt-qd.address |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.
-|=======================================================================
-
-[id='addresses-and-address-formats']
-=== Addresses and Address Formats
-
-The following AMQP addresses and address patterns are used within
-{RouterName}.
-
-[id='address-patterns']
-==== Address Patterns
-
-[width="100%",cols="38%,62%",options="header",]
-|=======================================================================
-|_Pattern_ |_Description_
-|`_local/<addr>` |An address that references a locally attached endpoint.
-Messages using this address pattern shall not be routed over more than
-one link.
-
-|`_topo/0/<router>/<addr>` |
-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.
-
-The `0` component immediately preceding the router-id is a placeholder
-for an _area_ which may be used in the future if area routing is
-implemented.
-
-|`<addr>` |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.
-|=======================================================================
-
-[id='supported-addresses']
-==== Supported Addresses
-
-[width="100%",cols="36%,64%",options="header",]
-|=======================================================================
-|_Address_ |_Description_
-|`$management` |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.
-
-|`_topo/0/Router.E/$management` |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.
-
-|`_local/qdhello` |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.
-
-|`_local/qdrouter` |The router entity in each of the connected routers.
-This address is used by a router to communicate with other routers in
-the network.
-
-|`_topo/0/Router.E/qdrouter` |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.
-|=======================================================================
-
-[id='implementation-of-the-amqp-management-specification']
-=== Implementation of the AMQP Management Specification
-
-{RouterName} is manageable remotely via AMQP. It is compliant with the
-emerging AMQP Management specification (draft 9).
-
-Differences from the specification:
-
-* The `name` 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.
-
-* The `REGISTER` and `DEREGISTER` operations are not implemented. The router
- automatically discovers peer routers via the router network and makes
- their management addresses available via the standard `GET-MGMT-NODES`
- operation.
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org
[05/11] qpid-dispatch git commit: DISPATCH-851: Move the new book
into primary position and reorg the docs
Posted by jr...@apache.org.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/old-user-guide/console_overview.png
----------------------------------------------------------------------
diff --git a/docs/books/old-user-guide/console_overview.png b/docs/books/old-user-guide/console_overview.png
new file mode 100644
index 0000000..af25f36
Binary files /dev/null and b/docs/books/old-user-guide/console_overview.png differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/old-user-guide/console_schema.png
----------------------------------------------------------------------
diff --git a/docs/books/old-user-guide/console_schema.png b/docs/books/old-user-guide/console_schema.png
new file mode 100644
index 0000000..ba56c7b
Binary files /dev/null and b/docs/books/old-user-guide/console_schema.png differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/old-user-guide/console_topology.png
----------------------------------------------------------------------
diff --git a/docs/books/old-user-guide/console_topology.png b/docs/books/old-user-guide/console_topology.png
new file mode 100644
index 0000000..ae4b22a
Binary files /dev/null and b/docs/books/old-user-guide/console_topology.png differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/old-user-guide/default_config.adoc
----------------------------------------------------------------------
diff --git a/docs/books/old-user-guide/default_config.adoc b/docs/books/old-user-guide/default_config.adoc
new file mode 100644
index 0000000..b0122be
--- /dev/null
+++ b/docs/books/old-user-guide/default_config.adoc
@@ -0,0 +1,35 @@
+////
+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
+////
+
+[[configuration]]
+Configuration
+-------------
+
+The default configuration file is installed in
+'{CMAKE_INSTALL_PREFIX}/etc/qpid-dispatch/qdrouterd.conf'. This configuration file will
+cause the router to run in standalone mode, listening on the standard
+AMQP port (5672). Dispatch Router looks for the configuration file in
+the installed location by default. If you wish to use a different path,
+the "-c" command line option will instruct Dispatch Router as to which
+configuration to load.
+
+To run the router, invoke the executable: `qdrouterd [-c my-config-file]`
+
+For more details of the configuration file see the 'qdrouterd.conf(5)' man
+page.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/old-user-guide/introduction.adoc
----------------------------------------------------------------------
diff --git a/docs/books/old-user-guide/introduction.adoc b/docs/books/old-user-guide/introduction.adoc
new file mode 100644
index 0000000..8a67bc9
--- /dev/null
+++ b/docs/books/old-user-guide/introduction.adoc
@@ -0,0 +1,128 @@
+////
+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
+////
+
+[[introduction]]
+Introduction
+------------
+
+[[overview]]
+Overview
+~~~~~~~~
+
+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.
+
+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.
+
+The router is an intermediary for messages but it is _not_ a broker. It
+does not _take responsibility for_ 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, _and_ it will route
+the acknowledgement of that message by the ultimate receiver back across
+the same path. This means that _responsibility_ for the message is
+transfered from the original sender to the ultimate receiver __as if
+they were directly connected__. However this is done via a flexible
+network that allows highly configurable routing of the message
+transparent to both sender and receiver.
+
+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.
+
+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.
+
+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,
+_all_ the receivers are connected to _all_ the brokers. If there is a
+message anywhere it can be delivered to any receiver.
+
+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.
+
+[[benefits]]
+Benefits
+~~~~~~~~
+
+Simplifies connectivity
+
+* An endpoint can do all of its messaging through a single transport
+connection
+* Avoid opening holes in firewalls for incoming connections
+
+Provides messaging connectivity where there is no TCP/IP connectivity
+
+* 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).
+
+Simplifies reliability
+
+* Reliability and availability are provided using redundant topology,
+not server clustering
+* Reliable end-to-end messaging without persistent stores
+* Use a message broker only when you need store-and-forward semantics
+
+[[features]]
+Features
+~~~~~~~~
+
+* Can be deployed stand-alone or in a network of routers
+** Supports arbitrary network topology - no restrictions on redundancy
++
+- Automatic route computation - adjusts quickly to changes in topology
+* Provides remote access to brokers or other AMQP servers
+* Security
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/old-user-guide/link_routing.adoc
----------------------------------------------------------------------
diff --git a/docs/books/old-user-guide/link_routing.adoc b/docs/books/old-user-guide/link_routing.adoc
new file mode 100644
index 0000000..bc52230
--- /dev/null
+++ b/docs/books/old-user-guide/link_routing.adoc
@@ -0,0 +1,166 @@
+////
+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
+////
+
+[[link-routing]]
+Link Routing
+------------
+
+This feature was introduced in Qpid Dispatch 0.4. This feature was
+significantly updated in Qpid Dispatch 0.6.
+
+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.
+
+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.
+
+Why would one want to do this? One reason is to provide client
+isolation. A network like the following can be deployed:
+
+----
+
+ Public Network
+ +-----------------+
+ | +-----+ |
+ | B1 | Rp | |
+ | +/--\-+ |
+ | / \ |
+ | / \ |
+ +----/--------\---+
+ / \
+ / \
+ / \
+ Private Net A / \ Private Net B
+ +--------------/--+ +---\-------------+
+ | +---/-+ | | +--\--+ |
+ | B2 | Ra | | | | Rb | C1 |
+ | +-----+ | | +-----+ |
+ | | | |
+ | | | |
+ +-----------------+ +-----------------+
+----
+
+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.
+
+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.
+
+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.
+
+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.
+
+[[link-routing-configuration]]
+Configuration
+~~~~~~~~~~~~~
+
+Starting with the configured topology shown above, how is link-routing
+configured to support the example described above?
+
+First, router Ra needs to be told how to make a connection to the broker
+B2:
+
+------------------------------
+connector {
+ name: broker
+ role: route-container
+ host: <B2-url>
+ port: <B2-port>
+ saslMechanisms: ANONYMOUS
+}
+------------------------------
+
+This _route-container_ 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.
+
+Now, the router must be configured to route certain addresses to B2:
+
+----------------------
+linkRoute {
+ prefix: b2
+ direction: in
+ connection: broker
+}
+
+linkRoute {
+ prefix: b2
+ direction: out
+ connection: broker
+}
+----------------------
+
+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).
+
+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.
+
+Examples of addresses that "begin with 'b2'" include:
+
+ * b2
+ * b2.queues
+ * b2.queues.app1
+
+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.
+
+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.
+
+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.
+
+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.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/old-user-guide/policy.adoc
----------------------------------------------------------------------
diff --git a/docs/books/old-user-guide/policy.adoc b/docs/books/old-user-guide/policy.adoc
new file mode 100644
index 0000000..a4eb99b
--- /dev/null
+++ b/docs/books/old-user-guide/policy.adoc
@@ -0,0 +1,456 @@
+////
+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
+////
+
+[id='policy']
+= Policy
+
+The Policy module is an optional authorization mechanism enforcing
+user connection restrictions and AMQP resource access control.
+
+Policy is assigned when a connection is created. The connection
+properties *AMQP virtual host*, *authenticated user name*, and *connection
+remote host* 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.
+
+[NOTE]
+====
+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.
+====
+
+== Definitions
+
+=== vhost
+
+A _vhost_ is typically the name of the host to which the client AMQP
+connection is directed. For example, suppose a client application opens
+connection URL:
+
+[options="nowrap"]
+----
+amqp://bigbroker.example.com:5672/favorite_subject
+----
+
+The client will signal virtual host name _bigbroker.example.com_ to
+the router during AMQP connection startup. Router Policy intercepts
+the virtual host _bigbroker.example.com_ and applies a vhost policy
+with that name to the connection.
+
+== Policy Features
+
+=== Total Connection Limit
+
+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.
+
+=== Vhost Policy
+
+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.
+
+Vhost policy also defines connection count limits to control the
+number of users that may be simultaneously connected to the vhost.
+
+[NOTE]
+====
+A vhost user may be assigned to one user group only.
+====
+
+=== Default Vhost
+
+A default vhost may be defined. The default vhost policy is used for
+connections whose vhost is otherwise not defined in the policy database.
+
+xref:example2[Example 2] illustrates how the default vhost feature can
+be used to apply a single vhost policy set of restrictions to any
+number of vhost connections.
+
+=== Vhost Patterns
+
+Policy vhost names may be interpreted as literal host names or
+as host name patterns. Vhost name patterns are a convenience
+for letting a single policy rule cover a wide range of vhosts.
+
+Host name patterns consist of a series of host and domain name
+labels and one or more tokens all concatenated with periods or dots.
+A token can be one of the following:
+
+[options="header"]
+|====
+| Token character | Match rule
+| asterisk * | matches a single hostname label
+| hash # | matches zero or more hostname labels
+|====
+
+Some simple examples show how given policy name patterns match
+incoming connection vhost names.
+
+[options="header"]
+|====
+| Policy pattern | Connection vhost | Policy match
+| *.example.com | example.com | no
+| *.example.com | www.example.com | yes
+| *.example.com | srv2.www.example.com | no
+| #.example.com | example.com | yes
+| #.example.com | www.example.com | yes
+| #.example.com | a.b.c.d.example.com | yes
+| #.example.com | bighost.com | no
+| www.*.test.example.com | www.test.example.com | no
+| www.*.test.example.com | www.a.test.example.com | yes
+| www.*.test.example.com | www.a.b.c.test.example.com | no
+| www.#.test.example.com | www.test.example.com | yes
+| www.#.test.example.com | www.a.test.example.com | yes
+| www.#.test.example.com | www.a.b.c.test.example.com | yes
+|====
+
+Pattern matching applies the following precedence rules.
+
+[options="header"]
+|====
+| Policy pattern | Precedence
+| exact match | high
+| asterisk * | medium
+| hash # | low
+|====
+
+Policy vhost name patterns are optimised before they are used
+in connection vhost name matching. As a result of this
+optimisation the names stored for pattern match lookups are
+not necessarily the same as the patterns specified in the
+vhost policy hostname. The policy agent disallows vhost
+name patterns that reduce to the same pattern as an existing name
+pattern. For instance, name pattern _pass:[#.#.#.#.com]_ is reduced to _pass:[#.com]_.
+Attempts to create a vhost name pattern whose optimised
+name conflicts with an existing optimised name will be denied.
+
+== Policy Schema
+
+Policy configuration is specified in two schema objects.
+
+[options="nowrap"]
+----
+policy = {
+ <global settings>
+}
+
+vhost = {
+ id: vhost-name
+ <connection limits>
+ groups: {
+ group-name: {
+ <user group settings>
+ }
+ }
+}
+----
+
+The _policy_ object is a singleton. Multiple _vhost_ objects may be
+created as needed.
+
+=== Global Policy
+
+[options="header", cols="35,15,50"]
+|====
+| attribute | default | description
+| maxConnections | 65535 | 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.
+| enableVhostPolicy | false | Enable vhost policy connection denial, and resource limit enforcement.
+| policyDir | "" | Absolute path to a directory that holds vhost definition .json files. All vhost definitions in all .json files in this directory are processed.
+| defaultVhost | "$default" | 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 _$default_.
+| enableVhostNamePatterns | false | Enable vhost name patterns. When false vhost hostnames are treated as literal strings. When true vhost hostnames are treated as match patterns.
+|====
+
+=== Vhost Policy
+
+[options="header", cols="35,15,50"]
+|====
+| attribute | default | description
+| id | | Vhost name must be unique.
+| maxConnections | 65535 | Maximum number of concurrent client connections allowed.
+| maxConnectionsPerUser | 65535 | Maximum number of concurrent client connections allowed for any user.
+| maxConnectionsPerRemoteHost | 65535 | Maximum number of concurrent client connections allowed for any remote host.
+| allowUnknownUser | false | Allow unknown users who are not members of a defined user group. Unknown users are assigned to the '$default' user group and receive '$default' settings.
+| groups | | A map where each key is a user group name and the value is a Vhost User Group Settings map.
+|====
+
+=== Vhost User Group Settings Map
+
+This object is the data value contained in entries in the policy/groups map.
+
+[options="header", cols="35,15,50"]
+|====
+| Section/Attribute | default | description
+| *Group Membership* | |
+| users | "" | Comma separated list of authenticated users in this group.
+| *Connection Restrictions* | |
+| remoteHosts | "" | 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 '*'. An empty list denies all access.
+| *AMQP Connection Open Limits* | |
+| maxFrameSize | 2^31-1 | Largest frame that may be sent on this connection. (AMQP Open, max-frame-size)
+| maxSessions | 65535 | Maximum number of sessions that may be created on this connection. (AMQP Open, channel-max)
+| *AMQP Session Begin Limits* | |
+| maxSessionWindow | 2^31-1 |Incoming capacity for new sessions measured in octets. AMQP Begin, incoming-window measured in AMQP frames is calculated by (maxSessionWindow / maxFrameSize). (AMQP Begin, incoming-window)
+| *AMQP Link Attach* | |
+| maxMessageSize | 0 | 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)
+| maxSenders | 2^31-1 | Maximum number of sending links that may be created on this connection.
+| maxReceivers | 2^31-1 | Maximum number of receiving links that may be created on this connection.
+| allowDynamicSource | false | This connection is allowed to create receiving links using the Dynamic Link Source feature.
+| allowAnonymousSender | false | This connection is allowed to create sending links using the Anonymous Sender feature.
+| allowUserIdProxy | false | This connection is allowed to send messages with a user_id property that differs from the connection's authenticated user id.
+| sources | "" | 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.
+| targets | "" | 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.
+| sourcePattern | "" | List of Source address patterns allowed when creating receiving links. This list must be expressed as a CSV string. An empty string denies all access.
+| targetPattern | "" | List of Target address patterns allowed when creating sending links. This list must be expressed as a CSV string. An empty string denies all access.
+|====
+
+== Policy Wildcard and User Name Substitution
+
+Policy provides several conventions to make writing rules easier.
+
+=== Remote Host Wildcard
+
+Remote host rules may consist of a single asterisk character to
+specify all hosts.
+
+[options="nowrap"]
+----
+ remoteHosts: *
+----
+
+The asterisk must stand alone and cannot be appended to a host name
+or to an IP address fragment.
+
+=== AMQP Source and Target User Name Substitution
+
+The rule definitions for `sources`, `targets`, `sourcePattern`, and
+`targetPattern` may include the username
+substitution token
+
+[options="nowrap"]
+----
+ ${user}
+----
+
+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.
+
+=== AMQP Source and Target Link Name Match Wildcard
+
+The rule definitions for `sources` and `targets` may contain a trailing
+asterisk character.
+The asterisk is recognized only if it is the last character in the
+link name.
+
+[options="nowrap"]
+----
+ sources: tmp_${user}, temp*, ${user}-home-*
+----
+
+The rule definitions for `sourcePattern` and `targetPattern` use the same
+patterns defined for router addresses and link routes. The patterns consist of one or more
+tokens separated by a forward slash /. 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.
+
+The user name substitution token may be used in a sourcePattern or in a
+targetPattern subject to the following restrictions:
+
+* The user name substitution token must be the first or last token in the rule clause.
+* The user name substitution token must stand alone within its delimited field.
+ It may not be concatenated with literal text prefixes or suffixes.
+
+For each rule definition multiple patterns may be specified in a comma
+separated list.
+
+[options="nowrap"]
+----
+ sourcePattern: tmp.${user}, temp/#, ${user}.home/*
+----
+
+[NOTE]
+====
+A rule definition may contain `sources` or `sourcePattern` but not both.
+A rule definition may contain `targets` or `targetPattern` but not both.
+====
+
+
+
+== Composing Policies
+
+This section shows policy examples designed to illustrate some common use cases.
+
+=== Example 1. User Policy Disabled
+
+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.
+
+[id='example2']
+=== Example 2. All Users Have Simple Connection Limits
+
+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.
+
+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.
+
+[options="nowrap"]
+----
+policy {
+ maxConnections: 100 <1>
+}
+
+vhost {
+ name: $default <2>
+ maxConnectionsPerUser: 10 <3>
+ allowUnknownUser: true <4>
+ groups: {
+ $default: {
+ remoteHosts: * <5>
+ sources: * <6>
+ targets: * <6>
+ }
+ }
+}
+----
+
+<1> The global maxConnections limit of 100 is enforced.
+<2> No normal vhost names are defined; user is assigned to default vhost '$default'.
+<3> The vhost maxConnectionsPerUser limit of 10 is enforced.
+<4> No groups are defined to have any users but allowUnknownUser is true so all users are assigned to group $default.
+<5> The user is allowed to connect from any remote host.
+<6> 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.
+
+=== Example 3. Admins Must Connect From Localhost
+
+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.
+
+In this example a user connects to vhost 'example.com'.
+
+[options="nowrap"]
+----
+vhost {
+ name: example.com <1>
+ allowUnknownUser: true <3>
+ groups: {
+ admin: {
+ users: alice, bob <2>
+ remoteHosts: 127.0.0.1, ::1 <4>
+ sources: * <5>
+ targets: * <5>
+ },
+ $default: {
+ remoteHosts: * <6>
+ sources: news*, sports*, chat* <7>
+ targets: chat* <7>
+ }
+ }
+}
+----
+
+<1> A connection to vhost 'example.com' locates this vhost rule set.
+<2> If one of users _alice_ or _bob_ is connecting then she or he is assigned to the 'admin' user group.
+<3> Any other user is not defined by a user group. However, since the _allowUnknownUser_ setting is true then this user is assigned to the '$default' user group.
+<4> Users in the 'admin' user group must connect from localhost. Connections for an 'admin' user from other hosts on the network are denied.
+<5> Users in the 'admin' user group are allowed to access any resource offered by the vhost service.
+<6> Other users are allowed to connect from any host.
+<7> Other users have source and target name lists that restrict the resources they are allowed to access.
+
+=== Example 4. Limiting Possible Memory Consumption
+
+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
+set directly by _maxSessionWindow_.
+
+By adjusting _maxSessions_, and _maxSessionWindow_ an
+administrator can prevent a user from consuming too much memory by
+buffering messages in flight.
+
+[NOTE]
+====
+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.
+====
+
+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.
+
+[options="nowrap"]
+----
+vhost {
+ name: traders.com <1>
+ groups: {
+ traders: {
+ users: trader-1, trader-2, ... <2>
+ maxFrameSize: 10000 <3>
+ maxSessionWindow: 5000000 <3>
+ maxSessions: 1 <4>
+ ...
+ },
+ feeds: {
+ users: nyse-feed, nasdaq-feed <5>
+ maxFrameSize: 60000 <6>
+ maxSessionWindow: 1200000000 <6>
+ maxSessions: 3 <7>
+ ...
+ }
+ }
+}
+----
+
+<1> These rules are for vhost traders.com.
+<2> The 'traders' group includes trader-1, trader-2, and any other user defined in the list.
+<3> _maxFrameSize_ and _maxSessionWindow_ allow for at most 5,000,000 bytes of data to be in flight on each session.
+<4> Only one session per connection is allowed.
+<5> In the 'feeds' group two users are defined.
+<6> _maxFrameSize_ and _maxSessionWindow_ allow for at most 1,200,000,000 bytes of data to be in flight on each session.
+<7> Up to three sessions per connection are allowed.
+
+////
+
+- Should we used signed ints for limits to allow for magic values?
+
+- In example 3, alice and bob cannot connect from an outside server and
+ get the $default settings.
+
+- Limits are enforced per router, so a vhost policy of maxConnections
+ 10 across 10 routers will allow 100 connections to that vhost.
+
+////
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/old-user-guide/schema_txt.py
----------------------------------------------------------------------
diff --git a/docs/books/old-user-guide/schema_txt.py b/docs/books/old-user-guide/schema_txt.py
new file mode 100644
index 0000000..9f340f3
--- /dev/null
+++ b/docs/books/old-user-guide/schema_txt.py
@@ -0,0 +1,109 @@
+##
+## 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
+##
+
+"""
+Generate the schema.md chapter for the dispatch book from the qdrouter.json schema.
+"""
+from __future__ import unicode_literals
+from __future__ import division
+from __future__ import absolute_import
+from __future__ import print_function
+
+import sys, re
+from qpid_dispatch_internal.management.qdrouter import QdSchema
+from qpid_dispatch_internal.management.schema_doc import SchemaWriter
+
+class BookSchemaWriter(SchemaWriter):
+
+ def run(self):
+ self.heading("Management Schema")
+ self.writeln("""
+This chapter documents the set of *management entity types* that define
+configuration and management of a Dispatch Router. A management entity type has
+a set of *attributes* that can be read, some attributes can also be
+updated. Some entity types also support *operations* that can be called.
+
+All management entity types have the following standard attributes:
+
+type::
+ The fully qualified type of the entity,
+ e.g. `org.apache.qpid.dispatch.router`. This document uses the short name
+ without the `org.apache.qpid.dispatch` prefix e.g. `router`. The dispatch
+ tools will accept the short or long name.
+
+name::
+ A user-generated identity for the entity. This can be used in other entities
+ that need to refer to the named entity.
+
+identity::
+ A system-generated identity of the entity. It includes
+ the short type name and some identifying information. E.g. `log/AGENT` or
+ `listener/localhost:amqp`
+
+There are two main categories of management entity type.
+
+Configuration Entities::
+ Parameters that can be set in the configuration file
+ (see `qdrouterd.conf(5)` man page) or set at run-time with the `qdmanage(8)`
+ tool.
+
+Operational Entities::
+ Run-time status values that can be queried using `qdstat(8)` or `qdmanage(8)` tools.
+""")
+
+ with self.section("Configuration Entities"):
+ self.writeln("""
+Configuration entities define the attributes allowed in the configuration file
+(see `qdrouterd.conf(5)`) but you can also create entities once the router is
+running using the `qdrouterd(8)` tool's `create` operation. Some entities can also
+be modified using the `update` operation, see the entity descriptions below.
+""")
+ self.entity_types_extending("configurationEntity")
+
+ with self.section("Operational Entities"):
+
+ self.writeln("""
+Operational entities provide statistics and other run-time attributes of the router.
+The `qdstat(8)` tool provides a convenient way to query run-time statistics.
+You can also use the general-purpose management tool `qdmanage(8)` to query
+operational attributes.
+""")
+ self.entity_types_extending("operationalEntity")
+
+ with self.section("Management Operations"):
+ self.writeln("""
+The 'qdstat(8)' and 'qdmanage(8)' tools allow you to view or modify management entity
+attributes. They work by invoking *management operations*. You can invoke these operations
+from any AMQP client by sending a message with the appropriate properties and body to the
+'$management' address. The message should have a 'reply-to' address indicating where the
+response should be sent.
+""")
+ def operation_section(title, entity_type):
+ with self.section(title):
+ self.operation_defs(entity_type)
+ operation_section("Operations for all entity types", self.schema.entity_type("entity"))
+ for e in self.schema.filter(lambda et: et.operation_defs and not et.name_is("entity")):
+ operation_section("Operations for '%s' entity type" % e.short_name, e)
+
+def main():
+ """Generate schema markdown documentation from L{QdSchema}"""
+ BookSchemaWriter(sys.stdout, QdSchema()).run()
+
+if __name__ == '__main__':
+ main()
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/old-user-guide/theory_of_operation.adoc
----------------------------------------------------------------------
diff --git a/docs/books/old-user-guide/theory_of_operation.adoc b/docs/books/old-user-guide/theory_of_operation.adoc
new file mode 100644
index 0000000..c2deab8
--- /dev/null
+++ b/docs/books/old-user-guide/theory_of_operation.adoc
@@ -0,0 +1,395 @@
+////
+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
+////
+
+== Theory of Operation
+
+This section introduces some key concepts about the router.
+
+=== Overview
+
+The router is an _application layer_ program running as a normal
+user program or as a daemon.
+
+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.
+
+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.
+
+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.
+
+=== Connections
+
+The router connects clients, servers, AMQP services, and other
+routers through network connections.
+
+==== Listener
+
+The router provides _listeners_ 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.
+
+Several types of listeners are defined by their role.
+
+[cols="20,80"]
+|===
+| Role | Description
+| normal | The connection is used for AMQP clients using normal message delivery.
+| inter-router | 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 | 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.
+|===
+
+==== Connector
+
+The router can also be configured to create outbound connections to
+messaging brokers or other AMQP entities using _connectors_. 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.
+
+Several types of connectors are defined by their role.
+
+[cols="20,80"]
+|===
+| Role | Description
+| normal | 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.
+| inter-router | 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 | 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.
+|===
+
+=== Addresses
+
+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 _to_ and _reply-to_ fields of a message's properties. They are also
+used during the creation of links in the _address_ field of a _source_ or
+a _target_.
+
+[NOTE]
+====
+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.
+====
+
+Addresses designate various kinds of entities in a messaging network:
+
+* Endpoint processes that consume data or offer a service
+* Topics that match multiple consumers to multiple producers
+* Entities within a messaging broker:
+** Queues
+** Durable Topics
+** Exchanges
+
+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.
+
+The router maintains several classes of address based on how the address is
+configured or discovered.
+
+[cols="25,75"]
+|===
+| Address Type | Description
+| mobile | The address is a rendezvous point between senders and receivers. The router aggregates and serializes messages from senders and distributes messages to receivers.
+| link route | The address defines a private messaging path between a sender and a receiver. The router simply passes messages between the end points.
+|===
+
+==== Mobile Addresses
+
+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.
+
+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.
+
+Mobile addresses may be discovered during normal router operation or
+configured through management settings.
+
+===== Discovered Mobile Addresses
+
+Mobile addresses are created when a client creates a link to a source
+or destination address that is unknown to the router network.
+
+Suppose a service provider wants to offer _my-service_ that clients
+may use. The service provider must open a receiver link with source
+address _my-service_. The router creates a mobile address
+_my-service_ and propagates the address so that it is known to every
+router in the network.
+
+Later a client wants to use the service and creates a sending link
+with target address _my-service_. The router matches the service
+provider's receiver having source address _my-service_ to the client's
+sender having target address _my-service_ and routes messages between
+the two.
+
+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.
+
+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 _my-service_ 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.
+
+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.
+
+===== Configured Mobile Addresses
+
+Mobile addresses may be configured using the router _autoLink_
+object. An address created via an _autoLink_ represents a queue,
+topic, or other service in an external broker. Logically the
+_autoLink_ addresses are treated by the router network as if the
+broker had connected to the router and offered the services itself.
+
+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.
+
+Multiple _autoLink_ 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.
+
+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.
+
+==== Link Route Addresses
+
+Link route addresses may be configured using the router _linkRoute_
+object. An link route address represents a queue, topic, or other
+service in an external broker similar to addresses configured by
+_autoLink_ 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.
+
+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.
+
+=== Message Routing
+
+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:
+
+* Routing pattern - balanced, closest, multicast
+* Routing mechanism - message routed, link routed
+
+// * TODO: describe these???
+// * Undeliverable action - drop, hold and retry, redirect
+// * Reliability - N destinations, etc.
+
+==== Routing Patterns
+
+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.
+
+Note that the routing patterns fall into two categories: Anycast
+(Balanced and Closest) and Multicast. There is no concept of
+"unicast" in which there is only one consumer for an address.
+
+Anycast distribution delivers each message to one consumer whereas
+multicast distribution delivers each message to all consumers.
+
+Anycast delivery is reliable when the message deliveries are
+unsettled. There is a reliability contract that the router network
+abides by when delivering unsettled messages to anycast addresses.
+For every such delivery sent by a producer, the router network
+guarantees that one of the following outcomes will occur:
+
+* The delivery shall be settled with ACCEPTED or REJECTED disposition
+ where the disposition is supplied by the consumer.
+* The delivery shall be settled with RELEASED disposition, meaning
+ that the message was not delivered to any consumer.
+* The delivery shall be settled with MODIFIED disposition, meaning
+ that the message may have been delivered to a consumer but should be
+ considered in-doubt and re-sent.
+* The connection to the producer shall be dropped, signifying that all
+ unsettled deliveries should now be considered in-doubt by the
+ producer and later re-sent.
+
+Multicast delivery is not reliable. If a producer sends an unsettled
+delivery, the ingress router shall settle the delivery with ACCEPTED
+disposition regardless of whether the message was delivered to any
+consumers.
+
+===== Balanced
+
+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.
+
+===== Closest
+
+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.
+
+===== Multicast
+
+Having multiple consumers on the same address at the same time,
+messages are routed such that each consumer receives one copy of the
+message.
+
+
+==== Routing Mechanisms
+
+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 _routing_:
+
+ 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.
+
+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.
+
+===== Message Routed
+
+Message routing occurs upon delivery of a message and is done based on
+the address in the message's _to_ field.
+
+When a delivery arrives on an incoming message-routing link, the
+router extracts the address from the delivered message's _to_ 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.
+
+Message routing can also occur without an address in the
+message's _to_ field if the incoming link has a target address. In
+fact, if the sender uses a link with a target address, the _to_ field
+shall be ignored even if used.
+
+===== Link Routed
+
+Link routing occurs when a new link is attached to the router across
+one of its AMQP connections. It is done based on the _target.address_
+field of an inbound link and the _source.address_ field of an outbound
+link.
+
+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.
+
+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.
+
+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.
+
+==== Message Settlement
+
+Messages may be delivered with varying degrees of reliability.
+
+* At most once
+* At least once
+* Exactly once
+
+The reliability is negotiated between the client and server during
+link establishment. The router handles all levels of reliability by treating
+messages as either _pre-settled_ or _unsettled_.
+
+[cols="20,80"]
+|===
+| Delivery | Handling
+| pre-settled | 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.
+| unsettled | 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.
+|===
+
+
+=== Security
+
+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.
+
+The router Policy module is an optional authorization mechanism
+enforcing user connection restrictions and AMQP resource access
+control.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/old-user-guide/tools.adoc
----------------------------------------------------------------------
diff --git a/docs/books/old-user-guide/tools.adoc b/docs/books/old-user-guide/tools.adoc
new file mode 100644
index 0000000..6f8298d
--- /dev/null
+++ b/docs/books/old-user-guide/tools.adoc
@@ -0,0 +1,92 @@
+////
+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
+////
+
+[[tools]]
+Tools
+-----
+
+[[qdstat]]
+qdstat
+~~~~~~
+
+_qdstat_ 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:
+
+[width="100%",cols="17%,83%",options="header",]
+|=======================================================================
+|_Option_ |_Description_
+|-l |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 _endpoint_ links
+and _router_ links. Endpoint links are attached to clients using the
+router. Router links are attached to other routers in a network of
+routbers.
+
+|-a |Print a list of addresses known to the router.
+
+|-n |Print a list of known routers in the network.
+
+|-c |Print a list of connections to the router.
+
+|--autolinks |Print a list of configured auto-links.
+
+|--linkroutes |Print a list of configures link-routes.
+|=======================================================================
+
+For complete details see the 'qdstat(8)' man page and the output of
+`qdstat --help`.
+
+[[qdmanage]]
+qdmanage
+~~~~~~~~
+
+_qdmanage_ is a general-purpose AMQP management client that allows you
+to not only view but modify the configuration of a running dispatch
+router.
+
+For example you can query all the connection entities in the router:
+
+----------------------------------
+$ qdmanage query --type connection
+----------------------------------
+
+To enable logging debug and higher level messages by default:
+
+-------------------------------------------
+$ qdmanage update log/DEFAULT enable=debug+
+-------------------------------------------
+
+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:
+
+-----------------------------------------
+$ qdmanage create type=listener port=5555
+-----------------------------------------
+
+Now you can connect to port 5555, for exampple:
+
+--------------------------------------------------
+$ qdmanage query -b localhost:5555 --type listener
+--------------------------------------------------
+
+For complete details see the 'qdmanage(8)' man page and the output of
+`qdmanage --help`. Also for details of what can be configured see the
+'qdrouterd.conf(5)' man page.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/attributes.adoc
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/attributes.adoc b/docs/books/user-guide/attributes.adoc
new file mode 100644
index 0000000..0162710
--- /dev/null
+++ b/docs/books/user-guide/attributes.adoc
@@ -0,0 +1,78 @@
+////
+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
+////
+
+// Standard document attributes
+
+:data-uri!:
+:doctype: article
+:experimental:
+:idprefix:
+:imagesdir: images
+:numbered:
+:sectanchors!:
+:sectnums:
+:source-highlighter: highlightjs
+:highlightjs-theme: solarized_dark
+:toc: left
+:linkattrs:
+:toclevels: 3
+
+// Component attributes
+
+:ProductName: Apache Qpid
+:RouterLongName: {ProductName} Dispatch Router
+:ClientAmqpPythonName: {ProductName} Proton Python
+:ConsoleName: {RouterLongName} Console
+:FragmentDir: common
+:RouterName: Dispatch Router
+:RouterSchemaDir: ../../build/doc/book
+:DispatchRouterVersion: 1.0.1
+
+// Book names
+
+:RouterBook: Using {RouterLongName}
+
+// Doc links
+
+:DispatchRouterUrlBase: https://qpid.apache.org/releases/qpid-dispatch-{DispatchRouterVersion}
+
+:ManagementEntitiesUrl: {DispatchRouterUrlBase}/man/managementschema.html
+:ManagementEntitiesLink: link:{ManagementEntitiesUrl}[{RouterName} Management Schema^]
+
+:RouterBookUrl: {DispatchRouterUrlBase}/book/book.html
+:RouterBookLink: link:{RouterBookUrl}[{RouterBook}]
+
+:qdmanageManPageUrl: {DispatchRouterUrlBase}/man/qdmanage.html
+:qdmanageManPageLink: link:{qdmanageManPageUrl}[qdmanage man page^]
+
+:qdrouterdManPageUrl: {DispatchRouterUrlBase}/man/qdrouterd.html
+:qdrouterdManPageLink: link:{qdrouterdManPageUrl}[qdrouterd man page^]
+
+:qdrouterdConfManPageUrl: {DispatchRouterUrlBase}/man/qdrouterd.conf.html
+:qdrouterdConfManPageLink: link:{qdrouterdConfManPageUrl}[qdrouterd.conf man page^]
+
+:qdstatManPageUrl: {DispatchRouterUrlBase}/man/qdstat.html
+:qdstatManPageLink: link:{qdstatManPageUrl}[qdstat man page^]
+
+:ClientAmqpPythonUrl: https://qpid.apache.org/proton/
+
+// Other links
+
+:AmqpSpecUrl: http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-overview-v1.0-os.html
+:AmqpSpecLink: link:{AmqpSpecUrl}[AMQP 1.0 specification^]
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/book.adoc
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/book.adoc b/docs/books/user-guide/book.adoc
new file mode 100644
index 0000000..4ed6bdf
--- /dev/null
+++ b/docs/books/user-guide/book.adoc
@@ -0,0 +1,61 @@
+////
+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
+////
+
+include::attributes.adoc[]
+
+= {RouterBook}
+
+// Introduction
+include::introduction.adoc[leveloffset=+1]
+
+// Theory of Operation
+include::theory_of_operation.adoc[leveloffset=+1]
+
+// Getting Started
+include::getting-started.adoc[leveloffset=+1]
+
+// Configuration
+include::understand-router-configuration.adoc[leveloffset=+1]
+
+// Network Connections
+include::configuration-connections.adoc[leveloffset=+1]
+
+// Security
+include::configuration-security.adoc[leveloffset=+1]
+
+// Routing
+include::routing.adoc[leveloffset=+1]
+
+// Logging
+include::logging.adoc[leveloffset=+1]
+
+// Management
+include::management.adoc[leveloffset=+1]
+
+// Reliability
+include::reliability.adoc[leveloffset=+1]
+
+// Technical Details and Specifications
+include::technical-details-specifications.adoc[leveloffset=+1]
+
+[appendix]
+include::cyrus-sasl.adoc[leveloffset=+1]
+
+// Revision information
+include::revision-info.adoc[]
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/common
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/common b/docs/books/user-guide/common
new file mode 120000
index 0000000..60d3b0a
--- /dev/null
+++ b/docs/books/user-guide/common
@@ -0,0 +1 @@
+../common
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/configuration-connections.adoc
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/configuration-connections.adoc b/docs/books/user-guide/configuration-connections.adoc
new file mode 100644
index 0000000..26e10a2
--- /dev/null
+++ b/docs/books/user-guide/configuration-connections.adoc
@@ -0,0 +1,90 @@
+////
+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
+////
+
+[id='router-network-connections']
+= Network Connections
+
+Connections define how the router communicates with clients, other routers, and brokers. You can configure _incoming connections_ to define how the router listens for data from clients and other routers, and you can configure _outgoing connections_ to define how the router sends data to other routers and brokers.
+
+[id='adding-incoming-connections']
+== Listening for Incoming Connections
+
+Listening for incoming connections involves setting the host and port on which the router should listen for traffic.
+
+.Procedure
+
+. In the router's configuration file, add a `listener`:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+listener {
+ host: _HOST_NAME/ADDRESS_
+ port: _PORT_NUMBER/NAME_
+ ...
+}
+----
+
+`host`:: Either an IP address (IPv4 or IPv6) or hostname on which the router should listen for incoming connections.
+`port`:: The port number or symbolic service name on which the router should listen for incoming connections.
+
+For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_listener[listener] in the `qdrouterd.conf` man page.
+--
+
+. If necessary, xref:securing-incoming-connections[secure the connection].
++
+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.
+
+. If you want the router to listen for incoming connections on additional hosts or ports, configure an additional `listener` entity for each host and port.
+
+[id='adding-outgoing-connections']
+== Adding Outgoing Connections
+
+Configuring outgoing connections involves setting the host and port on which the router connects to other routers and brokers.
+
+// Adding this here for now; in the future it might be better to have separate procedures for creating inter-router and route-container connections.
+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 xref:managing-connectors[].
+
+.Procedure
+
+. In the router's configuration file, add a `connector`:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+connector {
+ name: _NAME_
+ host: _HOST_NAME/ADDRESS_
+ port: _PORT_NUMBER/NAME_
+ ...
+}
+----
+
+`name`:: The name of the `connector`. You should specify a name that describes the entity to which the connector connects. This name is used by configured addresses (for example, a `linkRoute` entity) in order to specify which connection should be used for them.
+`host`:: Either an IP address (IPv4 or IPv6) or hostname on which the router should connect.
+`port`:: The port number or symbolic service name on which the router should connect.
+
+For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_connector[connector] in the `qdrouterd.conf` man page.
+--
+
+. If necessary, xref:securing-outgoing-connections[secure the connection].
++
+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.
+
+. For each remaining router or broker to which this router should connect, configure an additional `connector` entity.
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org
[02/11] qpid-dispatch git commit: DISPATCH-851: Move the new book
into primary position and reorg the docs
Posted by jr...@apache.org.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/reliability.adoc
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/reliability.adoc b/docs/books/user-guide/reliability.adoc
new file mode 100644
index 0000000..2826c55
--- /dev/null
+++ b/docs/books/user-guide/reliability.adoc
@@ -0,0 +1,701 @@
+////
+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
+////
+
+[id='reliability']
+= Reliability
+
+////
+There's a lot of really good information here, but most of it is best-suited at a level higher than this book. This book is really about configuring a router in an established topology, but most of the information in "Reliability" is about concepts and best practices to keep in mind as you design the topology. Alternatively, I could also see taking the examples presented here and turning them into a tutorial to teach some of the fundamental concepts inherent within router reliability.
+////
+
+In general, in a broker based architecture, the reliability feature is strictly related to the "store and forward" mechanism offered by each broker. Thanks to persistent journals, a broker can offer fault tolerance thus avoiding message loss; of course, it is not so true when messages are stored only in a volatile memory.
+
+This is completely different using {RouterName}, because each router neither takes ownership of messages nor stores them in a persistent storage. In this case, the reliability feature is offered by *path redundancy* which provides the possibility to reach the destination on different paths through the router network. In normal conditions, the best path is always chosen in terms of lowest cost but, when one or more routers go down, the topology is revisited by all remained routers and new paths are processed in order to reach always each destination. Of course, it means that the reliability is strictly related to the network topology the user chooses for his solution.
+
+Because a solution based on {RouterName} could be made not only by routers but by brokers too, the reliability is improved with persistent storage on them which add not only fault tolerance but temporal decoupling as well; without "store and forward" feature offered by brokers, the temporal decoupling is not possible only with routers and direct peers, both senders and receivers; the receiver must be online at same time of the sender in order to receive messages.
+
+== Path Redundancy
+
+Offering path redundancy means designing the network topology in a way that even when one or more routers go down or even connections between them, each destination is always reachable following alternate paths through the routers that are still part of the network.
+
+Consider the following simple scenario :
+
+* a network with three routers "Router.A", "Router.B" and "Router.C".
+* the "Router.A" is connected to both "Router.B" and "Router.C".
+* the "Router.C is connected to the "Router.B".
+* all three routers listen for client connections.
+* a sender client connects to the "Router.A" in order to send messages to a receiver client.
+* a receiver client connects to the "Router.B" initially in order to receive messages from the sender peer.
+
+.Path Redundancy Enabled Topology
+image::path-redundancy-01.png[Path Redundancy Enabled Topology, align="center"]
+
+The "Router.A" configuration is something like following.
+
+[options="nowrap"]
+----
+router {
+ mode: interior
+ id: Router.A
+}
+
+listener {
+ host: 0.0.0.0
+ port: 6000
+ authenticatePeer: no
+}
+
+connector {
+ name: INTER_ROUTER_B
+ addr: 127.0.0.1
+ port: 5001
+ role: inter-router
+}
+
+connector {
+ name: INTER_ROUTER_C
+ addr: 127.0.0.1
+ port: 5002
+ role: inter-router
+}
+----
+
+There is only one _listener_ in order to accept client connections and two _connector_ entities for connecting to the other two routers.
+
+The "Router.B" configuration is the following.
+
+[options="nowrap"]
+----
+router {
+ mode: interior
+ id: Router.B
+}
+
+listener {
+ addr: 0.0.0.0
+ port: 5001
+ authenticatePeer: no
+ role: inter-router
+}
+
+listener {
+ host: 0.0.0.0
+ port: 6001
+ authenticatePeer: no
+}
+----
+
+It has two _listener_ entities in order to listen for connections from clients and from other routers in the network (in this case from the "Router.A" and "Router.C").
+
+Finally, quite similar is the "Router.C" configuration.
+
+[options="nowrap"]
+----
+router {
+ mode: interior
+ id: Router.C
+}
+
+listener {
+ addr: 0.0.0.0
+ port: 5002
+ authenticatePeer: no
+ role: inter-router
+}
+
+listener {
+ host: 0.0.0.0
+ port: 6002
+ authenticatePeer: no
+}
+
+connector {
+ name: INTER_ROUTER_B
+ addr: 127.0.0.1
+ port: 5001
+ role: inter-router
+}
+----
+
+It has two _listener_ entities in order to listen for connections from clients and from other routers in the network (in this case from the "Router.A") and finally it has a _connector_ (for connecting to the "Router.B")
+
+Consider a sender client connected to "Router.A" and attached to `my_address` address which start to send messages (that is, 10 messages) and a receiver client connected to the "Router.B" and attached to the same address.
+
+Starting the receiver, it waits for messages with no output on the console.
+
+[options="nowrap"]
+----
+$ sudo python simple_recv.py -a localhost:6001/my_queue -m 10
+----
+
+Starting the sender, all the messages flow through "Router.A" and "Router.B" reaching the receiver; at this point the messages are all confirmed at sender side.
+
+[options="nowrap"]
+----
+$ sudo python simple_send.py -a localhost:6001/my_queue -m 10
+all messages confirmed
+----
+
+At same time, the receivers shows the messages received through the "Router.B".
+
+[options="nowrap"]
+----
+{u'sequence': 1L}
+{u'sequence': 2L}
+{u'sequence': 3L}
+{u'sequence': 4L}
+{u'sequence': 5L}
+{u'sequence': 6L}
+{u'sequence': 7L}
+{u'sequence': 8L}
+{u'sequence': 9L}
+{u'sequence': 10L}
+----
+
+The path redundancy is provided by the other available path through the "Router.A", "Router.C" and then "Router.B". It means that if the connection between "Router.A" and "Router.B" goes down, the alternative path is used to reach the receiver.
+
+Now, consider a fault on the "Router.B"; the receiver is not reachable anymore on that path but it can connect to the "Router.C" in order to continue to receive messages from the sender which does not know what's happened and it can continue to send messages to the "Router.A" in order to reach the receiver.
+
+.Path Redundancy after Router Failure
+image::path-redundancy-02.png[Path Redundancy after Router Failure, align="center"]
+
+The receiver is still reachable in order to get messages from the sender as displayed in the console output.
+
+[options="nowrap"]
+----
+$ sudo python simple_recv.py -a localhost:6002/my_queue -m 10
+{u'sequence': 1L}
+{u'sequence': 2L}
+{u'sequence': 3L}
+{u'sequence': 4L}
+{u'sequence': 5L}
+{u'sequence': 6L}
+{u'sequence': 7L}
+{u'sequence': 8L}
+{u'sequence': 9L}
+{u'sequence': 10L}
+----
+
+== Path Redundancy and Temporal Decoupling
+
+In order to have temporal decoupling in a solution based on {RouterName}, adding one or more brokers is a must for its "store and forward" feature. Choosing the right topology, it is possible to have a solution which offers reliability with both path redundancy and permanent storing for messages.
+
+Consider the following simple scenario :
+
+* a network with three routers "Router.A", "Router.B" and "Router.C" and finally a broker.
+* the "Router.A" is connected to both "Router.B" and "Router.C".
+* initially only the "Router.B" is connected to the broker.
+* all three routers listen for client connections.
+* a sender client connects to the "Router.A" in order to send messages to a queue in the broker.
+* a receiver client connects to the "Router.A" in order to get messages from the queue in the broker.
+
+.Path Redundancy and Temporal Decoupling Enabled Topology
+image::path-redundancy-temp-decoupling-01.png[Path Redundancy and Temporal Decoupling Enabled Topology, align="center"]
+
+The receiver client can be offline when the sender starts to send messages because they'll be stored into the queue permanently; coming back online, the receiver can get messages from the queue itself without message loss.
+
+The "Router.A" configuration is something like following.
+
+[options="nowrap"]
+----
+router {
+ mode: interior
+ id: Router.A
+}
+
+listener {
+ host: 0.0.0.0
+ port: 6000
+ authenticatePeer: no
+}
+
+connector {
+ name: INTER_ROUTER_B
+ addr: 127.0.0.1
+ port: 5001
+ role: inter-router
+}
+
+connector {
+ name: INTER_ROUTER_C
+ addr: 127.0.0.1
+ port: 5002
+ role: inter-router
+}
+
+address {
+ prefix: my_queue
+ waypoint: yes
+}
+----
+
+It has a _listener_ for accepting incoming connections from clients and two _connector_ entities in order to connect to the other routers. The queue named `my_queue` on the broker is exposed by a waypoint.
+
+The "Router.B" configuration is the following.
+
+[options="nowrap"]
+----
+router {
+ mode: interior
+ id: Router.B
+}
+
+listener {
+ addr: 0.0.0.0
+ port: 5001
+ authenticatePeer: no
+ role: inter-router
+}
+
+listener {
+ host: 0.0.0.0
+ port: 6001
+ authenticatePeer: no
+}
+
+connector {
+ name: BROKER
+ addr: 127.0.0.1
+ port: 5672
+ role: route-container
+}
+
+address {
+ prefix: my_queue
+ waypoint: yes
+}
+
+autoLink {
+ addr: my_queue
+ connection: BROKER
+ direction: in
+}
+
+autoLink {
+ addr: my_queue
+ connection: BROKER
+ direction: out
+}
+----
+
+It can accept incoming connections from clients and from other routers (in this case the "Router.A") and connects to the broker. The queue named `my_queue` on the broker is exposed by a waypoint with the related auto-links in both directions in order to send and receive messages to/from the queue itself.
+
+Finally, the simple "Router.C" configuration.
+
+[options="nowrap"]
+----
+router {
+ mode: interior
+ id: Router.C
+}
+
+listener {
+ addr: 0.0.0.0
+ port: 5002
+ authenticatePeer: no
+ role: inter-router
+}
+
+listener {
+ host: 0.0.0.0
+ port: 6002
+ authenticatePeer: no
+}
+----
+
+It can accept incoming connections from clients and from other routers (in this case the "Router.A"). Initially there is no connection between this router and the broker.
+
+First of all, thanks to the broker and its "store and forward" feature, the sender can connect to the "Router.A" and start to send messages even if the receiver is not online in that moment. Using the Python sample from the Qpid Proton library, the console output is like following.
+
+[options="nowrap"]
+----
+$ sudo python simple_send.py -a localhost:6000/my_queue -m 10
+all messages confirmed
+----
+
+All messages are confirmed because they reached the queue inside the broker through "Router.A" and "Router.B"; it is confirmed using the `qdstat` tool.
+
+[options="nowrap"]
+----
+$ sudo qdstat -b localhost:6001 -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
+ router Router.A closest 0 0 1 0 0 0 6 0 6
+ router Router.C closest 0 0 1 0 0 0 4 0 4
+ mobile my_queue 1 balanced 0 0 0 0 0 0 0 0 0
+ mobile my_queue 0 balanced 0 1 0 0 0 10 0 0 0
+ local qdhello flood 1 1 0 0 0 0 0 97 117
+ local qdrouter flood 1 0 0 0 0 0 0 7 0
+ topo qdrouter flood 1 0 2 0 0 0 8 13 9
+ local qdrouter.ma multicast 1 0 0 0 0 0 0 2 0
+ topo qdrouter.ma multicast 1 0 2 0 0 0 0 0 1
+ local temp.7f2u0zv9_U6QC5e closest 0 1 0 0 0 0 0 0 0
+----
+
+For the "Router.B", there are 10 messages as output (from the router to the broker) on the `my_queue` address.
+
+Starting the receiver connected to the "Router.A", it gets all the available messages from the queue.
+
+[options="nowrap"]
+----
+$ sudo python simple_recv.py -a localhost:6000/my_queue -m 10
+{u'sequence': 1L}
+{u'sequence': 2L}
+{u'sequence': 3L}
+{u'sequence': 4L}
+{u'sequence': 5L}
+{u'sequence': 6L}
+{u'sequence': 7L}
+{u'sequence': 8L}
+{u'sequence': 9L}
+{u'sequence': 10L}
+----
+
+Using the `qdstat` tool on the "Router.B" another time, the output is like following.
+
+[options="nowrap"]
+----
+$ sudo qdstat -b localhost:6001 -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
+ router Router.A closest 0 0 1 0 0 0 6 0 6
+ router Router.C closest 0 0 1 0 0 0 4 0 4
+ mobile my_queue 1 balanced 0 0 0 0 10 0 10 0 0
+ mobile my_queue 0 balanced 0 1 0 0 0 10 0 0 0
+ local qdhello flood 1 1 0 0 0 0 0 156 182
+ local qdrouter flood 1 0 0 0 0 0 0 7 0
+ topo qdrouter flood 1 0 2 0 0 0 10 18 11
+ local qdrouter.ma multicast 1 0 0 0 0 0 0 2 0
+ topo qdrouter.ma multicast 1 0 2 0 0 0 0 2 1
+ local temp.Xov_ZUcyti3jjXY closest 0 1 0 0 0 0 0 0 0
+----
+
+For the "Router.B", there are 10 messages as input (from the broker to the router) on the `my_queue` address.
+
+Now, consider a fault on the "Router.B"; in this case the broker is not reachable but it is possible to set up path redundancy through the "Router.C".
+
+.Path Redundancy and Temporal Decoupling after Router Failure
+image::path-redundancy-temp-decoupling-02.png[Path Redundancy and Temporal Decoupling after Router Failure, align="center"]
+
+Using the `qdmanage` tool, it is possible to configure the waypoint on `my_queue` address, the related auto-links in both directions and finally the _connector_ instance in order to enable the connection to the broker.
+
+[options="nowrap"]
+----
+$ sudo qdmanage -b localhost:6002 create --stdin
+[
+{ "type":"connector", "name":"BROKER", "port":5672, "role":"route-container" },
+{ "type":"address", "prefix":"my_queue", "waypoint":"yes" },
+{ "type":"autoLink", "addr":"my_queue", "connection":"BROKER", "direction":"in" },
+{ "type":"autoLink", "addr":"my_queue", "connection":"BROKER", "direction":"out" }
+]
+[
+ {
+ "verifyHostname": true,
+ "stripAnnotations": "both",
+ "name": "BROKER",
+ "allowRedirect": true,
+ "idleTimeoutSeconds": 16,
+ "maxFrameSize": 65536,
+ "host": "127.0.0.1",
+ "cost": 1,
+ "role": "route-container",
+ "maxSessions": 32768,
+ "type": "org.apache.qpid.dispatch.connector",
+ "port": "5672",
+ "identity": "connector/127.0.0.1:5672:BROKER",
+ "addr": "127.0.0.1"
+ },
+ {
+ "name": null,
+ "prefix": "my_queue",
+ "ingressPhase": 0,
+ "waypoint": false,
+ "distribution": "balanced",
+ "type": "org.apache.qpid.dispatch.router.config.address",
+ "identity": "7",
+ "egressPhase": 0
+ },
+ {
+ "addr": "my_queue",
+ "name": null,
+ "linkRef": null,
+ "type": "org.apache.qpid.dispatch.router.config.autoLink",
+ "operStatus": "inactive",
+ "connection": "BROKER",
+ "direction": "in",
+ "phase": 1,
+ "lastError": null,
+ "externalAddr": null,
+ "identity": "8",
+ "containerId": null
+ },
+ {
+ "addr": "my_queue",
+ "name": null,
+ "linkRef": null,
+ "type": "org.apache.qpid.dispatch.router.config.autoLink",
+ "operStatus": "inactive",
+ "connection": "BROKER",
+ "direction": "out",
+ "phase": 0,
+ "lastError": null,
+ "externalAddr": null,
+ "identity": "9",
+ "containerId": null
+ }
+]
+----
+
+The "Router.C" configuration changes in the same way as "Router.B". It can accept incoming connections from clients and from other routers (in this case the "Router.A") and connects to the broker. The queue named `my_queue` on the broker is exposed by a waypoint with the related auto-links in both directions in order to send and receive messages to/from the queue itself.
+
+At this point, the sender can connect to the "Router.A" for sending messages to the queue in the broker thanks to the "Router.C".
+
+[options="nowrap"]
+----
+$ sudo python simple_send.py -a localhost:6000/my_queue -m 10
+all messages confirmed
+----
+
+All messages are confirmed because they reached the queue inside the broker through "Router.A" and "Router.C"; it is confirmed using the `qdstat` tool.
+
+[options="nowrap"]
+----
+$ sudo qdstat -b localhost:6002 -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 1 1
+ local $displayname closest 1 0 0 0 0 0 0 0 0
+ mobile $management 0 closest 1 0 0 0 5 0 0 5 0
+ local $management closest 1 0 0 0 0 0 0 0 0
+ router Router.A closest 0 0 1 0 0 0 5 0 5
+ mobile my_queue 0 balanced 0 1 0 0 0 10 0 0 0
+ mobile my_queue 1 balanced 0 0 0 0 0 0 0 0 0
+ local qdhello flood 1 1 0 0 0 0 0 665 647
+ local qdrouter flood 1 0 0 0 0 0 0 8 0
+ topo qdrouter flood 1 0 1 0 0 0 31 52 32
+ local qdrouter.ma multicast 1 0 0 0 0 0 0 1 0
+ topo qdrouter.ma multicast 1 0 1 0 0 0 1 2 1
+ local temp.k6UMaS4P0JmtSlL closest 0 1 0 0 0 0 0 0 0
+
+----
+
+For the "Router.C", there are 10 messages as output (from the router to the broker) on the `my_queue` address.
+
+Starting the receiver connected to the "Router.A", it gets all the available messages from the queue.
+
+[options="nowrap"]
+----
+$ sudo python simple_recv.py -a localhost:6000/my_queue -m 10
+{u'sequence': 1L}
+{u'sequence': 2L}
+{u'sequence': 3L}
+{u'sequence': 4L}
+{u'sequence': 5L}
+{u'sequence': 6L}
+{u'sequence': 7L}
+{u'sequence': 8L}
+{u'sequence': 9L}
+{u'sequence': 10L}
+----
+
+Using the `qdstat` tool on the "Router.C" another time, the output is like following.
+
+[options="nowrap"]
+----
+$ sudo qdstat -b localhost:6002 -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 1 1
+ local $displayname closest 1 0 0 0 0 0 0 0 0
+ mobile $management 0 closest 1 0 0 0 6 0 0 6 0
+ local $management closest 1 0 0 0 0 0 0 0 0
+ router Router.A closest 0 0 1 0 0 0 5 0 5
+ mobile my_queue 0 balanced 0 1 0 0 0 10 0 0 0
+ mobile my_queue 1 balanced 0 0 0 0 10 0 10 0 0
+ local qdhello flood 1 1 0 0 0 0 0 746 726
+ local qdrouter flood 1 0 0 0 0 0 0 8 0
+ topo qdrouter flood 1 0 1 0 0 0 34 55 35
+ local qdrouter.ma multicast 1 0 0 0 0 0 0 1 0
+ topo qdrouter.ma multicast 1 0 1 0 0 0 1 4 1
+ local temp.Hso3moy3l+Sn+Fy closest 0 1 0 0 0 0 0 0 0
+----
+
+For the "Router.C", there are 10 messages as input (from the broker to the router) on the `my_queue` address.
+
+== Sharded Queue
+
+Every broker has limits in terms of queue size but in order to overcome this problem, one possible solution is "sharding" queues : in that way a single queue is divided in more "shards" (chunks) each on a different broker. It means that such solution needs more than one broker instance in order to host a shard on each of them. Of course, a sender connected to one of these brokers can send messages to the shard hosted only on that broker. At same time, a receiver connected to a broker can get messages from the shard that is hosted on that broker and can not see available messages in the shards hosted on the other brokers, even if they are all parts of the same queue.
+
+[NOTE]
+====
+Even if speaking about shards it is obvious that they are real queues all with same name but on different brokers. The "shard" concept is an abstract one because finally a shard is a real queue stored on a broker.
+====
+
+The big problem in this scenario, designed only with brokers, is that a receiver can be stucked on an empty shard without reading any messages while the shards on the other brokers have messages to deliver. it is a real problem because the receiver is interested in receiving messages from the whole queue and it does not take care if it is shared or not. Because of this problem, the receiver sees the queue as empty even if it is not so true due to the sharding and the messages available on the other shards.
+
+The above problem can be solved adding a {RouterName} instance in the network in front of the brokers and leverage on its waypoint feature with related auto-links.
+
+Consider the following simple scenario :
+
+* a network with one router "Router.A" and two brokers.
+* the "Router.A" listens for clients connections and it is connected to both brokers.
+* the brokers host shards for a queue; each broker has one shard.
+* a sender client connects to the "Router.A" in order to send messages to the queue.
+* a receiver client connects to the "Router.A" in order to get messages from the queue.
+
+.Sharded Queue Enabled Topology
+image::sharded-queue-01.png[Sharded Queue Enabled Topology, align="center"]
+
+With such solution and connecting to the "Router.A", sender and receiver do not know anything about sharding; they want send and receive messages to/from the whole queue that is the only thing they are aware of. They are both connected to the router and see only one address (related to the queue).
+
+The "Router.A" configuration is something like following.
+
+[options="nowrap"]
+----
+router {
+ mode: standalone
+ id: Router.A
+}
+
+listener {
+ host: 0.0.0.0
+ port: 6000
+ authenticatePeer: no
+}
+
+connector {
+ name: BROKER1
+ addr: 127.0.0.1
+ port: 5672
+ role: route-container
+}
+
+connector {
+ name: BROKER2
+ addr: 127.0.0.1
+ port: 5673
+ role: route-container
+}
+
+address {
+ prefix: my_queue
+ waypoint: yes
+}
+
+autoLink {
+ addr: my_queue
+ connection: BROKER1
+ direction: in
+}
+
+autoLink {
+ addr: my_queue
+ connection: BROKER1
+ direction: out
+}
+
+autoLink {
+ addr: my_queue
+ connection: BROKER2
+ direction: in
+}
+
+autoLink {
+ addr: my_queue
+ connection: BROKER2
+ direction: out
+}
+----
+
+The router has a _listener_ for incoming connection from clients and two _connector_ instances in order to connect to both brokers. The whole queue is named `my_queue` hosted in terms of shards on both brokers and the router is configured with a waypoint for that address. Finally, there are two auto-links in both directions for that queue on both brokers.
+
+Using the Python sample from the Qpid Proton library, the sender can connect to the "Router.A" and start to send messages to the queue; the console output is like following.
+
+[options="nowrap"]
+----
+$ sudo python simple_send.py -a localhost:6000/my_queue -m 10
+all messages confirmed
+----
+
+All messages are confirmed because they reached the queue and, thanks to the default `balanced` distribution on the address, the messages are delivered to both shards on the brokers (5 messages per shard). Using the `qdstat` tool on the router, the distribution is clear.
+
+[options="nowrap"]
+----
+$ sudo qdstat -b localhost:6000 -l
+Router Links
+ type dir conn id id peer class addr phs cap undel unsettled deliveries admin oper
+ =======================================================================================================================
+ endpoint in 1 6 mobile my_queue 1 250 0 0 0 enabled up
+ endpoint out 1 7 mobile my_queue 0 250 0 0 5 enabled up
+ endpoint in 2 8 mobile my_queue 1 250 0 0 0 enabled up
+ endpoint out 2 9 mobile my_queue 0 250 0 0 5 enabled up
+ endpoint in 8 19 mobile $management 0 250 0 0 1 enabled up
+ endpoint out 8 20 local temp.qCGHruCa4UIvYrS 250 0 0 0 enabled up
+----
+
+There are the `out` links (from router to brokers) for the `my_queue` address (_id_ values `7` and `9`) which have each 5 deliveries. It shows messages distributed across brokers and related shards for the queue; it is confirmed by the different connections they are tied (_conn id_ values `1` and `2`).
+
+Starting the receiver connected to the "Router.A", it gets all the available messages from the queue.
+
+[options="nowrap"]
+----
+$ sudo python simple_recv.py -a localhost:6000/my_queue -m 10
+{u'sequence': 1L}
+{u'sequence': 2L}
+{u'sequence': 3L}
+{u'sequence': 4L}
+{u'sequence': 5L}
+{u'sequence': 6L}
+{u'sequence': 7L}
+{u'sequence': 8L}
+{u'sequence': 9L}
+{u'sequence': 10L}
+----
+
+As for the sender, they are received through both the brokers and related shards. it is confirmed using the `qdstat` tool.
+
+[options="nowrap"]
+----
+$ sudo qdstat -b localhost:6000 -l
+Router Links
+ type dir conn id id peer class addr phs cap undel unsettled deliveries admin oper
+ =======================================================================================================================
+ endpoint in 1 6 mobile my_queue 1 250 0 0 5 enabled up
+ endpoint out 1 7 mobile my_queue 0 250 0 0 5 enabled up
+ endpoint in 2 8 mobile my_queue 1 250 0 0 5 enabled up
+ endpoint out 2 9 mobile my_queue 0 250 0 0 5 enabled up
+ endpoint in 10 22 mobile $management 0 250 0 0 1 enabled up
+ endpoint out 10 23 local temp.HT+f3ZilGP5o3wo 250 0 0 0 enabled up
+----
+
+There are the `in` links (from brokers to router) for the `my_queue` address (_id_ values `6` and `8`) which have each 5 deliveries. It shows messages distributed across brokers and related shards for the queue; it is confirmed by the different connections they are tied (_conn id_ values `1` and `2`).
+
+One disadvantage of sharded queues is that the receiver might receive messages "out of order" even with very good performance.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/revision-info.adoc
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/revision-info.adoc b/docs/books/user-guide/revision-info.adoc
new file mode 100644
index 0000000..fb19158
--- /dev/null
+++ b/docs/books/user-guide/revision-info.adoc
@@ -0,0 +1,20 @@
+////
+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
+////
+
+_Revised on {localdate} {localtime}_
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/routing.adoc
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/routing.adoc b/docs/books/user-guide/routing.adoc
new file mode 100644
index 0000000..dcb5d07
--- /dev/null
+++ b/docs/books/user-guide/routing.adoc
@@ -0,0 +1,721 @@
+////
+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
+////
+
+[id='routing']
+= Routing
+
+Routing is the process by which messages are delivered to their destinations. To accomplish this, {RouterName} provides two routing mechanisms: _message routing_ and _link routing_.
+
+Message routing:: 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 _settlement_ based on the message's _address_ and _routing pattern_.
++
+--
+.Message Routing
+image::message-routing.png[Message Routing, align="center"]
+
+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.
+--
+
+Link routing:: 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 is established, the transfer of message deliveries, flow frames, and dispositions is performed across the link route.
++
+--
+.Link Routing
+image::link-routing.png[Link Routing, align="center"]
+
+In this diagram, a router is connected to clients and to a broker, and it provides a link route to a queue on the broker (my_queue). The sender connects to the router, and the router propagates the link-attaches to the broker to form a direct link between the sender and the broker. The sender can begin sending messages to the queue, and the router passes the deliveries along the link route directly to the broker queue.
+--
+
+== Comparison of Message Routing and Link Routing
+
+While you can use either message routing or link routing to deliver messages to a destination, they differ in several important ways. Understanding these differences will enable you to choose the proper routing approach for any particular use case.
+
+=== When to Use Message Routing
+
+Message routing is the default routing mechanism. You can use it to route messages on a per-message basis between clients directly (direct-routed messaging), or to and from broker queues (brokered messaging).
+
+Message routing is best suited to the following requirements:
+
+* Default, basic message routing.
++
+{RouterName} automatically routes messages by default, so manual configuration is only required if you want routing behavior that is different than the default.
+
+* Message-based routing patterns.
++
+Message routing supports both anycast and multicast routing patterns. You can load-balance individual messages across multiple consumers, and multicast (or fan-out) messages to multiple subscribers.
+
+* Sharding messages across multiple broker instances when message delivery order is not important.
++
+Sharding messages from one producer might cause that producer's messages to be received in a different order than the order in which they were sent.
+
+Message routing is not suitable for any of the following requirements:
+
+* Dedicated path through the router network.
++
+For inter-router transfers, all message deliveries are placed on the same inter-router link. This means that the traffic for one address might affect the delivery of the traffic for another address.
+
+* Granular, end-to-end flow control.
++
+With message routing, end-to-end flow control is based on the settlement of deliveries and therefore might not be optimal in every case.
+
+* Transaction support.
+
+* Server-side selectors.
+
+=== When to Use Link Routing
+
+Link routing requires more detailed configuration than message routing as well as an AMQP container that can accept incoming link-attaches (typically a broker). However, link routing enables you to satisfy more advanced use cases than message routing.
+
+You can use link routing if you need to meet any of the following requirements:
+
+* Dedicated path through the router network.
++
+With link routing, each link route has dedicated inter-router links through the network. Each link has its own dedicated message buffers, which means that the address will not have "head-of-line" blocking issues with other addresses.
+
+* Sharding messages across multiple broker instances with guaranteed delivery order.
++
+Link routing to a sharded queue preserves the delivery order of the producer's messages by causing all messages on that link to go to the same broker instance.
+
+* End-to-end flow control.
++
+Flow control is "real" in that credits flow across the link route from the receiver to the sender.
+
+* Transaction support.
++
+Link routing supports local transactions to a broker.
+
+* Server-side selectors.
++
+With a link route, consumers can provide server-side selectors for broker subscriptions.
+
+== Configuring Message Routing
+
+With message routing, 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 _settlement_ based on the message's _address_ and _routing pattern_.
+
+With message routing, you can do the following:
+
+* Route messages between clients (direct-routed, or brokerless messaging)
++
+This involves configuring an address with a routing pattern. All messages sent to the address will be routed based on the routing pattern.
+* Route messages through a broker queue (brokered messaging)
++
+This involves configuring a waypoint address to identify the broker queue and then connecting the router to the broker. All messages sent to the waypoint address will be routed to the broker queue.
+
+=== Addresses
+
+Addresses determine how messages flow through your router network. An address designates an endpoint in your messaging network, such as:
+
+* Endpoint processes that consume data or offer a service
+* Topics that match multiple consumers to multiple producers
+* Entities within a messaging broker:
+** Queues
+** Durable Topics
+** Exchanges
+
+When a router receives a message, it uses the message's address to determine where to send the message (either its destination or one step closer to its destination).
+
+// Do we need to specify that these are AMQP addresses? Should they be distinguished from generic message addresses?
+
+// Need to add something here about the difference between discovered vs. configured mobile addresses so that it's clear that with message routing, the router can either be proactive or reactive in the way it routes messages.
+
+[id='routing-patterns-overview']
+=== Routing Patterns
+
+Each address has one of the following routing patterns, which define the path that a message with the address can take across the messaging network:
+
+Balanced:: An anycast method that allows multiple consumers to use the same address. Each message is delivered to a single consumer only, and {RouterName} attempts to balance the traffic load across the router network.
++
+--
+If multiple consumers are attached to the same address, each router determines which outbound path should receive a message by considering each path's current number of unsettled deliveries. This means that more messages will be delivered along paths where deliveries are settled at higher rates.
+
+[NOTE]
+====
+{RouterName} neither measures nor uses message settlement time to determine which outbound path to use.
+====
+
+In this scenario, the messages are spread across both receivers regardless of path length:
+
+.Balanced Message Routing
+image::balanced-routing.png[Balanced Message Routing, align="center"]
+--
+
+Closest:: An anycast method in which every message is sent along the shortest path to reach the destination, even if there are other consumers for the same address.
++
+{RouterName} determines the shortest path based on the topology cost to reach each of the consumers. If there are multiple consumers with the same lowest cost, messages will be spread evenly among those consumers.
++
+In this scenario, all messages sent by `Sender` will be delivered to `Receiver 1`:
++
+.Closest Message Routing
+image::closest-routing.png[Closest Message Routing, align="center"]
+
+Multicast:: Messages are sent to all consumers attached to the address. Each consumer will receive one copy of the message.
++
+In this scenario, all messages are sent to all receivers:
++
+.Multicast Message Routing
+image::multicast-routing.png[Multicast Message Routing, align="center"]
+
+=== Message Settlement
+
+Message settlement is negotiated between the producer and the router when the producer establishes a link to the router. Depending on the settlement pattern, messages might be delivered with any of the following degrees of reliability:
+
+* At most once
+* At least once
+* Exactly once
+
+{RouterName} treats all messages as either _pre-settled_ or _unsettled_, and it is responsible for propagating the settlement of each message it routes.
+
+Pre-settled:: Sometimes called _fire and forget_, the router settles the incoming and outgoing deliveries and propagates the settlement to the message's destination. However, it does not guarantee delivery.
+
+Unsettled:: The router propagates the settlement between the sender and receiver, and guarantees one of the following outcomes:
++
+* The message is delivered and settled, with the consumer's disposition indicated.
+* The delivery is settled with a disposition of `RELEASED`.
++
+This means that the message did not reach its destination.
+* The delivery is settled with a disposition of `MODIFIED`.
++
+This means that the message might or might not have reached its destination. The delivery is considered to be "in-doubt" and should be re-sent if "at least once" delivery is required.
+* The link, session, or connection to {RouterName} was dropped, and all deliveries are "in-doubt".
+
+[id='routing-messages-between-clients']
+=== Routing Messages Between Clients
+
+You can route messages between clients without using a broker. In a brokerless scenario (sometimes called _direct-routed messaging_), {RouterName} routes messages between clients directly.
+
+To route messages between clients, you configure an address with a routing distribution pattern. When a router receives a message with this address, the message is routed to its destination or destinations based on the address's routing distribution pattern.
+
+.Procedure
+
+. In the router's configuration file, add an `address` section:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+address {
+ prefix: _ADDRESS_PREFIX_
+ distribution: balanced|closest|multicast
+ ...
+}
+----
+
+`prefix` | `pattern`:: The address or group of addresses to which the address settings should be applied. You can specify a prefix to match an exact address or beginning segment of an address. Alternatively, you can specify a pattern to match an address using wildcards.
++
+//tag::prefix-matching[]
+A _prefix_ matches either an exact address or the beginning segment within an address that is delimited by either a `.` or `/` character. For example, the prefix `my_address` would match the address `my_address` as well as `my_address.1` and `my_address/1`. However, it would not match `my_address1`.
+//end::prefix-matching[]
++
+//tag::pattern-matching[]
+A _pattern_ matches an address that corresponds to a pattern. A pattern is a sequence of words delimited by either a `.` or `/` character. You can use wildcard characters to represent a word. The `*` character matches exactly one word, and the `#` character matches any sequence of zero or more words.
++
+The `*` and `#` characters are reserved as wildcards. Therefore, you should not use them in the message address.
++
+The following table shows some examples of address patterns:
++
+[cols="25,75"]
+|===
+| This pattern... | Matches...
+| `news` | `news`
+| `news/*/sports` | `news/europe/sports` and `news/usa/sports`, but not `news` or `news/europe/fr/sports`
+| `news/#` | `news`, `news/europe`, `news/usa`, `news/usa/sports`
+|===
++
+[NOTE]
+====
+You can convert a `prefix` value to a `pattern` by appending `/\#` to it. For example, the prefix `a/b/c` is equivalent to the pattern `a/b/c/#`.
+====
+//end::pattern-matching[]
+
+`distribution`:: The message distribution pattern. The default is `balanced`, but you can specify any of the following options:
++
+* `balanced` - Messages sent to the address will be routed to one of the receivers, and the routing network will attempt to balance the traffic load based on the rate of settlement.
+* `closest` - Messages sent to the address are sent on the shortest path to reach the destination. It means that if there are multiple receivers for the same address, only the closest one will receive the message.
+* `multicast` - Messages are sent to all receivers that are attached to the address in a _publish/subscribe_ model.
++
+For more information about message distribution patterns, see xref:routing-patterns-overview[Routing Patterns].
+
+For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_address[address] in the `qdrouterd.conf` man page.
+--
+
+. Add the same `address` section to any other routers that need to use the address.
++
+The `address` that you added to this router configuration file only controls how this router distributes messages sent to the address. If you have additional routers in your router network that should distribute messages for this address, then you must add the same `address` section to each of their configuration files.
+
+[id='routing-messages-through-broker']
+=== Routing Messages Through a Broker Queue
+
+You can route messages to and from a broker queue to provide clients with access to the queue through a router. In this scenario, clients connect to a router to send and receive messages, and the router routes the messages to or from the broker queue.
+
+You can route messages to a queue hosted on a single broker, or route messages to a _sharded queue_ distributed across multiple brokers.
+
+.Brokered Messaging
+image::brokered-messaging.png[Brokered Messaging, align="center"]
+
+In this diagram, the sender connects to the router and sends messages to my_queue. The router attaches an outgoing link to the broker, and then sends the messages to my_queue. Later, the receiver connects to the router and requests messages from my_queue. The router attaches an incoming link to the broker to receive the messages from my_queue, and then delivers them to the receiver.
+
+You can also route messages to a _sharded queue_, which is a single, logical queue comprised of multiple, underlying physical queues. Using queue sharding, it is possible to distribute a single queue over multiple brokers. Clients can connect to any of the brokers that hold a shard to send and receive messages.
+
+.Brokered Messaging with Sharded Queue
+image::sharded-queue-02.png[Brokered Messaging with Sharded Queue, align="center"]
+
+In this diagram, a sharded queue (my_queue) is distributed across two brokers. The router is connected to the clients and to both brokers. The sender connects to the router and sends messages to my_queue. The router attaches an outgoing link to each broker, and then sends messages to each shard (by default, the routing distribution is `balanced`). Later, the receiver connects to the router and requests all of the messages from my_queue. The router attaches an incoming link to one of the brokers to receive the messages from my_queue, and then delivers them to the receiver.
+
+.Procedure
+
+. xref:configure-waypoint-address[Add a waypoint address].
++
+This address identifies the queue to which you want to route messages.
+. xref:connect-router-to-broker[Add autolinks to connect the router to the broker].
++
+Autolinks connect the router to the broker queue identified by the waypoint address.
+
+. xref:connect-router-to-broker[If the queue is sharded, add autolinks for each additional broker that hosts a shard].
+
+[id='configure-waypoint-address']
+==== Configuring Waypoint Addresses
+
+A waypoint address identifies a queue on a broker to which you want to route messages. You need to configure the waypoint address on each router that needs to use the address. For example, if a client is connected to _Router A_ to send messages to the broker queue, and another client is connected to _Router B_ to receive those messages, then you would need to configure the waypoint address on both _Router A_ and _Router B_.
+
+.Prerequisites
+
+An incoming connection (`listener`) to which the clients can connect should be configured. This connection defines how the producers and consumers connect to the router to send and receive messages. For more information, see xref:adding-incoming-connections[Adding Incoming Connections].
+
+// Does the broker queue have to exist before you create the waypoint address? If it doesn't exist, will you get an error?
+
+.Procedure
+
+* Create waypoint addresses on each router that needs to use the address:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+address {
+ prefix: _ADDRESS_PREFIX_
+ waypoint: yes
+}
+----
+
+`prefix` | `pattern`:: The address prefix or pattern that matches the broker queue to which you want to send messages. You can specify a prefix to match an exact address or beginning segment of an address. Alternatively, you can specify a pattern to match an address using wildcards.
++
+include::routing.adoc[tags=prefix-matching]
++
+include::routing.adoc[tags=pattern-matching]
+
+`waypoint`:: Set this attribute to `yes` so that the router handles messages sent to this address as a waypoint.
+--
+
+[id='connect-router-to-broker']
+==== Connecting a Router to the Broker
+
+After you add waypoint addresses to identify the broker queue, you must connect a router to the broker using autolinks.
+
+With autolinks, client traffic is handled on the router, not the broker. Clients attach their links to the router, and then the router uses internal autolinks to connect to the queue on the broker. Therefore, the queue will always have a single producer and a single consumer regardless of how many clients are attached to the router.
+
+. If this router is different than the router that is connected to the clients, then add the waypoint address.
+
+. Add an outgoing connection to the broker:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+connector {
+ name: _NAME_
+ host: _HOST_NAME/ADDRESS_
+ port: _PORT_NUMBER/NAME_
+ role: route-container
+ ...
+}
+----
+
+`name`:: The name of the `connector`. Specify a name that describes the broker.
+`host`:: Either an IP address (IPv4 or IPv6) or hostname on which the router should connect to the broker.
+`port`:: The port number or symbolic service name on which the router should connect to the broker.
+`role`:: Specify `route-container` to indicate that this connection is for an external container (broker).
+
+For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_connector[connector] in the `qdrouterd.conf` man page.
+--
+
+. If you want to send messages to the broker queue, create an outgoing autolink to the broker queue:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+autoLink {
+ addr: _ADDRESS_
+ connection: _CONNECTOR_NAME_
+ direction: out
+ ...
+}
+----
+
+`addr`:: The address of the broker queue. When the autolink is created, it will be attached to this address.
+`externalAddr`:: An optional alternate address for the broker queue. You use an external address if the broker queue should have a different address than that which the sender uses. In this scenario, senders send messages to the `addr` address, and then the router routes them to the broker queue represented by the `externalAddr` address.
+`connection` | `containerID`:: How the router should connect to the broker. You can specify either an outgoing connection (`connection`) or the container ID of the broker (`containerID`).
+`direction`:: Set this attribute to `out` to specify that this autolink can send messages from the router to the broker.
+
+For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_autolink[autoLink] in the `qdrouterd.conf` man page.
+--
+
+. If you want to receive messages from the broker queue, create an incoming autolink from the broker queue:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+autoLink {
+ addr: _ADDRESS_
+ connection: _CONNECTOR_NAME_
+ direction: in
+ ...
+}
+----
+
+`addr`:: The address of the broker queue. When the autolink is created, it will be attached to this address.
+`externalAddr`:: An optional alternate address for the broker queue. You use an external address if the broker queue should have a different address than that which the receiver uses. In this scenario, receivers receive messages from the `addr` address, and the router retrieves them from the broker queue represented by the `externalAddr` address.
+`connection` | `containerID`:: How the router should connect to the broker. You can specify either an outgoing connection (`connection`) or the container ID of the broker (`containerID`).
+`direction`:: Set this attribute to `in` to specify that this autolink can receive messages from the broker to the router.
+
+For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_autolink[autoLink] in the `qdrouterd.conf` man page.
+--
+
+=== Example: Routing Messages Through Broker Queues
+
+This example shows how waypoints and autolinks can route messages through a pair of queues on a broker.
+
+==== Router Configuration
+
+[options="nowrap"]
+----
+connector { // <1>
+ name: broker
+ role: route-container
+ host: 198.51.100.1
+ port: 61617
+ saslMechanisms: ANONYMOUS
+}
+
+address { // <2>
+ prefix: queue
+ waypoint: yes
+}
+
+autoLink { // <3>
+ addr: queue.first
+ direction: in
+ connection: broker
+}
+
+autoLink { // <4>
+ addr: queue.first
+ direction: out
+ connection: broker
+}
+
+autoLink { // <5>
+ addr: queue.second
+ direction: in
+ connection: broker
+}
+
+autoLink { // <6>
+ addr: queue.second
+ direction: out
+ connection: broker
+}
+----
+<1> The outgoing connection from the router to the broker. The `route-container` role enables the router to connect to an external AMQP container (in this case, a broker).
+<2> The namespace queue on the broker to which the router should route messages. All addresses that start with `queue` will be routed to a queue on the broker.
+<3> The incoming autolink from `queue.first` on the broker to the router.
+<4> The outgoing autolink from the router to `queue.first` on the broker.
+<5> The incoming autolink from `queue.second` on the broker to the router.
+<6> The outgoing autolink from the router to `queue.second` on the broker.
+
+==== How the Messages are Routed
+
+Initially, when the broker is offline, the autolinks are inactive.
+
+[options="nowrap"]
+----
+$ 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
+----
+
+Once the broker is online, the autolinks attempt to activate. In this case, the broker starts with the `queue.first` queue only, and the `queue.first` autolinks become active. The `queue.second` autolinks are in a failed state, because the `queue.second` queue does not exist on the broker.
+
+[options="nowrap"]
+----
+$ 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
+----
+
+The producer now connects to the router and sends three messages to `queue.first`.
+
+[options="nowrap"]
+----
+$ python simple_send.py -a 127.0.0.1/queue.first -m3
+all messages confirmed
+----
+
+The router's address statistics show that the messages were delivered to the queue.
+
+[options="nowrap"]
+----
+$ 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
+----
+
+The `queue.first` address appears twice in the output: once for each phase of the address. Phase 0 is for routing messages from producers to the outgoing autolink. Phase 1 is for routing messages from the incoming autolink to the subscribed consumers. In this case, Phase 0 of the address has counted three messages in the `in` column (the messages that arrived on the router from the producer), and three messages in the `out` column (the messages that were sent from the router to the broker queue).
+
+The consumer now connects to the router and receives the three messages from `queue.first`.
+
+[options="nowrap"]
+----
+$ 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)}
+----
+
+The router's address statistics now show that all three messages were received by the consumer from the broker queue.
+
+[options="nowrap"]
+----
+$ 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
+----
+
+The command output shows that Phase 1 of the address was used to deliver all three messages from the queue to the consumer.
+
+[NOTE]
+====
+Even in a multi-router network, and with multiple producers and consumers for `queue.first`, all deliveries are routed through the queue on the connected broker.
+====
+
+== Configuring Link Routing
+
+Link routing provides an alternative strategy for brokered messaging. A link route represents a private messaging path between a sender and a receiver in which the router passes the messages between end points. You can think of a link route as a "virtual connection" or "tunnel" that travels from a sender, through the router network, to a receiver.
+
+With link routing, 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 is established, the transfer of message deliveries, flow frames, and dispositions is performed across the link route.
+
+=== Link Route Addresses
+
+A link route address represents a broker queue, topic, or other service. When a client attaches a link route address to a router, the router propagates a link attachment to the broker resource identified by the address.
+
+=== Link Route Routing Patterns
+
+Routing patterns are not used with link routing, because there is a direct link between the sender and receiver. The router only makes a routing decision when it receives the initial link-attach request frame. Once the link is established, the router passes the messages along the link in a balanced distribution.
+
+=== Link Route Flow Control
+
+Unlike message routing, with link routing, the sender and receiver handle flow control directly: the receiver grants link credits, which is the number of messages it is able to receive. The router sends them directly to the sender, and then the sender sends the messages based on the credits that the receiver granted.
+
+// What additional information do we need to provide about AMQP link flow control options? Since this is handled on the client side for link routing, should we provide a simple example with a client program that implements link flow control?
+
+[id='creating-link-route']
+=== Creating a Link Route
+
+Link routes establish a link between a sender and a receiver that travels through a router. You can configure inward and outward link routes to enable the router to receive link-attaches from clients and to send them to a particular destination.
+
+With link routing, client traffic is handled on the broker, not the router. Clients have a direct link through the router to a broker's queue. Therefore, each client is a separate producer or consumer.
+
+.Procedure
+
+. In the router configuration file, add an outgoing connection to the broker:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+connector {
+ name: _NAME_
+ host: _HOST_NAME/ADDRESS_
+ port: _PORT_NUMBER/NAME_
+ role: route-container
+ ...
+}
+----
+
+`name`:: The name of the `connector`. You should specify a name that describes the broker.
+`host`:: Either an IP address (IPv4 or IPv6) or hostname on which the router should connect to the broker.
+`port`:: The port number or symbolic service name on which the router should connect to the broker.
+`role`:: Specify `route-container` to indicate that this connection is for an external container (broker).
+
+For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_connector[connector] in the `qdrouterd.conf` man page.
+--
+
+. If you want clients to send messages on this link route, create an incoming link route:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+linkRoute {
+ prefix: __ADDRESS_PREFIX__
+ connection: __CONNECTOR_NAME__
+ direction: in
+ ...
+}
+----
+
+`prefix` | `pattern`:: The address prefix or pattern that matches the broker queue that should be the destination for routed link-attaches. All messages that match this prefix or pattern will be distributed along the link route. You can specify a prefix to match an exact address or beginning segment of an address. Alternatively, you can specify a pattern to match an address using wildcards.
++
+include::routing.adoc[tags=prefix-matching]
++
+include::routing.adoc[tags=pattern-matching]
+
+`connection` | `containerID`:: How the router should connect to the broker. You can specify either an outgoing connection (`connection`) or the container ID of the broker (`containerID`).
++
+If multiple brokers are connected to the router through this connection, requests for addresses matching the link route's prefix or pattern are balanced across the brokers. Alternatively, if you want to specify a particular broker, use `containerID` and add the broker's container ID.
+
+`direction`:: Set this attribute to `in` to specify that clients can send messages into the router network on this link route.
+
+For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_linkroute[linkRoute] in the `qdrouterd.conf` man page.
+--
+
+. If you want clients to receive messages on this link route, create an outgoing link route:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+linkRoute {
+ prefix: __ADDRESS_PREFIX__
+ connection: __CONNECTOR_NAME__
+ direction: out
+ ...
+}
+----
+
+`prefix` | `pattern`:: The address prefix or pattern that matches the broker queue from which you want to receive routed link-attaches. All messages that match this prefix or pattern will be distributed along the link route. You can specify a prefix to match an exact address or beginning segment of an address. Alternatively, you can specify a pattern to match an address using wildcards.
++
+include::routing.adoc[tags=prefix-matching]
++
+include::routing.adoc[tags=pattern-matching]
+
+`connection` | `containerID`:: How the router should connect to the broker. You can specify either an outgoing connection (`connection`) or the container ID of the broker (`containerID`).
++
+If multiple brokers are connected to the router through this connection, requests for addresses matching the link route's prefix or pattern are balanced across the brokers. Alternatively, if you want to specify a particular broker, use `containerID` and add the broker's container ID.
+`direction`:: Set this attribute to `out` to specify that this link route is for receivers.
+
+For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_linkroute[linkRoute] in the `qdrouterd.conf` man page.
+--
+
+=== Example: Using a Link Route to Provide Client Isolation
+
+This example shows how a link route can connect a client to a message broker that is on a different private network.
+
+.Router Network with Isolated Clients
+----
+
+ Public Network
+ +-----------------+
+ | +-----+ |
+ | B1 | Rp | |
+ | +/--\-+ |
+ | / \ |
+ | / \ |
+ +----/--------\---+
+ / \
+ / \
+ / \
+ Private Net A / \ Private Net B
+ +--------------/--+ +---\-------------+
+ | +---/-+ | | +--\--+ |
+ | B2 | Ra | | | | Rb | C1 |
+ | +-----+ | | +-----+ |
+ | | | |
+ | | | |
+ +-----------------+ +-----------------+
+----
+
+Client `C1` is constrained by firewall policy to connect to the router in its own network (`Rb`). However, it can use a link route to access queues, topics, and any other AMQP services that are provided on message brokers `B1` and `B2` -- even though they are on different networks.
+
+In this example, client `C1` needs to receive messages from `b2.event-queue`, which is hosted on broker `B2` in `Private Net A`. A link route connects the client and broker even though neither of them is aware that there is a router network between them.
+
+==== Router Configuration
+
+To enable client `C1` to receive messages from `b2.event-queue` on broker `B2`, router `Ra` must be able to do the following:
+
+* Connect to broker `B2`
+* Route links to and from broker `B2`
+* Advertise itself to the router network as a valid destination for links that have a `b2.event-queue` address.
+
+The relevant part of the configuration file for router `Ra` shows the following:
+
+--
+[options="nowrap"]
+----
+connector { // <1>
+ name: broker
+ role: route-container
+ host: 198.51.100.1
+ port: 61617
+ saslMechanisms: ANONYMOUS
+}
+
+linkRoute { // <2>
+ prefix: b2
+ direction: in
+ connection: broker
+}
+
+linkRoute { // <3>
+ prefix: b2
+ direction: out
+ connection: broker
+}
+----
+<1> The outgoing connection from the router to broker `B2`. The `route-container` role enables the router to connect to an external AMQP container (in this case, a broker).
+<2> The incoming link route for receiving links from client senders. Any sender with a target whose address begins with `b2` will be routed to broker `B2` using the `broker` connector.
+<3> The outgoing link route for sending links to client receivers. Any receivers whose source address begins with `b2` will be routed to broker `B2` using the `broker` connector.
+--
+
+This configuration enables router `Ra` to advertise itself as a valid destination for targets and sources starting with `b2`. It also enables the router to connect to broker `B2`, and to route links to and from queues starting with the `b2` prefix.
+
+[NOTE]
+====
+While not required, routers `Rp` and `Rb` should also have the same configuration.
+====
+
+==== How the Client Receives Messages
+
+By using the configured link route, client `C1` can receive messages from broker `B2` even though they are on different networks.
+
+Router `Ra` establishes a connection to broker `B2`. 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 and receiver links attached to `Rb` or `Rp` will be routed along the shortest path to `Ra`, which then routes them to broker `B2`.
+
+To receive messages from the `b2.event-queue` on broker `B2`, client `C1` attaches a receiver link with a source address of `b2.event-queue` to its local router, `Rb`. Because the address matches the `b2` prefix, `Rb` routes the link to `Rp`, which is the next hop in the route to its destination. `Rp` routes the link to `Ra`, which routes it to broker `B2`. Client `C1` now has a receiver established, and it can begin receiving messages.
+
+[NOTE]
+====
+If broker `B2` is unavailable for any reason, router `Ra` will not advertise itself as a destination for `b2` addresses. In this case, routers `Rb` and `Rp` will reject link attaches that should be routed to broker `B2` with an error message indicating that there is no route available to the destination.
+====
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/technical-details-specifications.adoc
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/technical-details-specifications.adoc b/docs/books/user-guide/technical-details-specifications.adoc
new file mode 100644
index 0000000..4a57d32
--- /dev/null
+++ b/docs/books/user-guide/technical-details-specifications.adoc
@@ -0,0 +1,190 @@
+////
+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
+////
+
+[id='technical-details-specifications']
+= Technical Details and Specifications
+
+[id='client-compatibility']
+== Client Compatibility
+
+{RouterName} should, in theory, work with any client that is
+compatible with AMQP 1.0. The following clients have been tested:
+
+[width="100%",cols="22%,78%",options="header",]
+|=======================================================================
+|_Client_ |_Notes_
+|qpid::messaging |The Qpid messaging clients work with {RouterName}
+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.
+
+|Proton Reactor |The Proton Reactor API is compatible with {RouterName}.
+
+|Proton Messenger |Messenger works with {RouterName}.
+|=======================================================================
+
+[id='amqp-mapping']
+== AMQP Mapping
+
+{RouterName} is an AMQP router and as such, it provides extensions,
+code-points, and semantics for routing over AMQP. This page documents the
+details of {RouterName}'s use of AMQP.
+
+[id='message-annotations']
+=== Message Annotations
+
+The following Message Annotation fields are defined by {RouterName}:
+
+[width="100%",cols="23%,19%,58%",options="header",]
+|=======================================================================
+|_Field_ |_Type_ |_Description_
+|x-opt-qd.ingress |string |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.
+
+|x-opt-qd.trace |list of string |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.
+
+|x-opt-qd.to |string |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 _to_ 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.
+
+|x-opt-qd.phase |integer |The address-phase, if not zero, for messages
+flowing between routers.
+|=======================================================================
+
+[id='sourcetarget-capabilities']
+=== Source/Target Capabilities
+
+The following Capability values are used in Sources and Targets.
+
+[width="100%",cols="19%,81%",options="header",]
+|=======================================================================
+|_Capability_ |_Description_
+|qd.router |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.
+
+|qd.router-data |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.
+|=======================================================================
+
+[id='dynamic-node-properties']
+=== Dynamic-Node-Properties
+
+The following dynamic-node-properties are used by {RouterName} in Sources.
+
+[width="100%",cols="23%,77%",options="header",]
+|=======================================================================
+|_Property_ |_Description_
+|x-opt-qd.address |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.
+|=======================================================================
+
+[id='addresses-and-address-formats']
+=== Addresses and Address Formats
+
+The following AMQP addresses and address patterns are used within
+{RouterName}.
+
+[id='address-patterns']
+==== Address Patterns
+
+[width="100%",cols="38%,62%",options="header",]
+|=======================================================================
+|_Pattern_ |_Description_
+|`_local/<addr>` |An address that references a locally attached endpoint.
+Messages using this address pattern shall not be routed over more than
+one link.
+
+|`_topo/0/<router>/<addr>` |
+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.
+
+The `0` component immediately preceding the router-id is a placeholder
+for an _area_ which may be used in the future if area routing is
+implemented.
+
+|`<addr>` |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.
+|=======================================================================
+
+[id='supported-addresses']
+==== Supported Addresses
+
+[width="100%",cols="36%,64%",options="header",]
+|=======================================================================
+|_Address_ |_Description_
+|`$management` |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.
+
+|`_topo/0/Router.E/$management` |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.
+
+|`_local/qdhello` |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.
+
+|`_local/qdrouter` |The router entity in each of the connected routers.
+This address is used by a router to communicate with other routers in
+the network.
+
+|`_topo/0/Router.E/qdrouter` |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.
+|=======================================================================
+
+[id='implementation-of-the-amqp-management-specification']
+=== Implementation of the AMQP Management Specification
+
+{RouterName} is manageable remotely via AMQP. It is compliant with the
+emerging AMQP Management specification (draft 9).
+
+Differences from the specification:
+
+* The `name` 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.
+
+* The `REGISTER` and `DEREGISTER` operations are not implemented. The router
+ automatically discovers peer routers via the router network and makes
+ their management addresses available via the standard `GET-MGMT-NODES`
+ operation.
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org
[10/11] qpid-dispatch git commit: DISPATCH-851: Move the new book
into primary position and reorg the docs
Posted by jr...@apache.org.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/book/policy.adoc
----------------------------------------------------------------------
diff --git a/doc/book/policy.adoc b/doc/book/policy.adoc
deleted file mode 100644
index a4eb99b..0000000
--- a/doc/book/policy.adoc
+++ /dev/null
@@ -1,456 +0,0 @@
-////
-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
-////
-
-[id='policy']
-= Policy
-
-The Policy module is an optional authorization mechanism enforcing
-user connection restrictions and AMQP resource access control.
-
-Policy is assigned when a connection is created. The connection
-properties *AMQP virtual host*, *authenticated user name*, and *connection
-remote host* 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.
-
-[NOTE]
-====
-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.
-====
-
-== Definitions
-
-=== vhost
-
-A _vhost_ is typically the name of the host to which the client AMQP
-connection is directed. For example, suppose a client application opens
-connection URL:
-
-[options="nowrap"]
-----
-amqp://bigbroker.example.com:5672/favorite_subject
-----
-
-The client will signal virtual host name _bigbroker.example.com_ to
-the router during AMQP connection startup. Router Policy intercepts
-the virtual host _bigbroker.example.com_ and applies a vhost policy
-with that name to the connection.
-
-== Policy Features
-
-=== Total Connection Limit
-
-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.
-
-=== Vhost Policy
-
-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.
-
-Vhost policy also defines connection count limits to control the
-number of users that may be simultaneously connected to the vhost.
-
-[NOTE]
-====
-A vhost user may be assigned to one user group only.
-====
-
-=== Default Vhost
-
-A default vhost may be defined. The default vhost policy is used for
-connections whose vhost is otherwise not defined in the policy database.
-
-xref:example2[Example 2] illustrates how the default vhost feature can
-be used to apply a single vhost policy set of restrictions to any
-number of vhost connections.
-
-=== Vhost Patterns
-
-Policy vhost names may be interpreted as literal host names or
-as host name patterns. Vhost name patterns are a convenience
-for letting a single policy rule cover a wide range of vhosts.
-
-Host name patterns consist of a series of host and domain name
-labels and one or more tokens all concatenated with periods or dots.
-A token can be one of the following:
-
-[options="header"]
-|====
-| Token character | Match rule
-| asterisk * | matches a single hostname label
-| hash # | matches zero or more hostname labels
-|====
-
-Some simple examples show how given policy name patterns match
-incoming connection vhost names.
-
-[options="header"]
-|====
-| Policy pattern | Connection vhost | Policy match
-| *.example.com | example.com | no
-| *.example.com | www.example.com | yes
-| *.example.com | srv2.www.example.com | no
-| #.example.com | example.com | yes
-| #.example.com | www.example.com | yes
-| #.example.com | a.b.c.d.example.com | yes
-| #.example.com | bighost.com | no
-| www.*.test.example.com | www.test.example.com | no
-| www.*.test.example.com | www.a.test.example.com | yes
-| www.*.test.example.com | www.a.b.c.test.example.com | no
-| www.#.test.example.com | www.test.example.com | yes
-| www.#.test.example.com | www.a.test.example.com | yes
-| www.#.test.example.com | www.a.b.c.test.example.com | yes
-|====
-
-Pattern matching applies the following precedence rules.
-
-[options="header"]
-|====
-| Policy pattern | Precedence
-| exact match | high
-| asterisk * | medium
-| hash # | low
-|====
-
-Policy vhost name patterns are optimised before they are used
-in connection vhost name matching. As a result of this
-optimisation the names stored for pattern match lookups are
-not necessarily the same as the patterns specified in the
-vhost policy hostname. The policy agent disallows vhost
-name patterns that reduce to the same pattern as an existing name
-pattern. For instance, name pattern _pass:[#.#.#.#.com]_ is reduced to _pass:[#.com]_.
-Attempts to create a vhost name pattern whose optimised
-name conflicts with an existing optimised name will be denied.
-
-== Policy Schema
-
-Policy configuration is specified in two schema objects.
-
-[options="nowrap"]
-----
-policy = {
- <global settings>
-}
-
-vhost = {
- id: vhost-name
- <connection limits>
- groups: {
- group-name: {
- <user group settings>
- }
- }
-}
-----
-
-The _policy_ object is a singleton. Multiple _vhost_ objects may be
-created as needed.
-
-=== Global Policy
-
-[options="header", cols="35,15,50"]
-|====
-| attribute | default | description
-| maxConnections | 65535 | 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.
-| enableVhostPolicy | false | Enable vhost policy connection denial, and resource limit enforcement.
-| policyDir | "" | Absolute path to a directory that holds vhost definition .json files. All vhost definitions in all .json files in this directory are processed.
-| defaultVhost | "$default" | 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 _$default_.
-| enableVhostNamePatterns | false | Enable vhost name patterns. When false vhost hostnames are treated as literal strings. When true vhost hostnames are treated as match patterns.
-|====
-
-=== Vhost Policy
-
-[options="header", cols="35,15,50"]
-|====
-| attribute | default | description
-| id | | Vhost name must be unique.
-| maxConnections | 65535 | Maximum number of concurrent client connections allowed.
-| maxConnectionsPerUser | 65535 | Maximum number of concurrent client connections allowed for any user.
-| maxConnectionsPerRemoteHost | 65535 | Maximum number of concurrent client connections allowed for any remote host.
-| allowUnknownUser | false | Allow unknown users who are not members of a defined user group. Unknown users are assigned to the '$default' user group and receive '$default' settings.
-| groups | | A map where each key is a user group name and the value is a Vhost User Group Settings map.
-|====
-
-=== Vhost User Group Settings Map
-
-This object is the data value contained in entries in the policy/groups map.
-
-[options="header", cols="35,15,50"]
-|====
-| Section/Attribute | default | description
-| *Group Membership* | |
-| users | "" | Comma separated list of authenticated users in this group.
-| *Connection Restrictions* | |
-| remoteHosts | "" | 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 '*'. An empty list denies all access.
-| *AMQP Connection Open Limits* | |
-| maxFrameSize | 2^31-1 | Largest frame that may be sent on this connection. (AMQP Open, max-frame-size)
-| maxSessions | 65535 | Maximum number of sessions that may be created on this connection. (AMQP Open, channel-max)
-| *AMQP Session Begin Limits* | |
-| maxSessionWindow | 2^31-1 |Incoming capacity for new sessions measured in octets. AMQP Begin, incoming-window measured in AMQP frames is calculated by (maxSessionWindow / maxFrameSize). (AMQP Begin, incoming-window)
-| *AMQP Link Attach* | |
-| maxMessageSize | 0 | 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)
-| maxSenders | 2^31-1 | Maximum number of sending links that may be created on this connection.
-| maxReceivers | 2^31-1 | Maximum number of receiving links that may be created on this connection.
-| allowDynamicSource | false | This connection is allowed to create receiving links using the Dynamic Link Source feature.
-| allowAnonymousSender | false | This connection is allowed to create sending links using the Anonymous Sender feature.
-| allowUserIdProxy | false | This connection is allowed to send messages with a user_id property that differs from the connection's authenticated user id.
-| sources | "" | 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.
-| targets | "" | 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.
-| sourcePattern | "" | List of Source address patterns allowed when creating receiving links. This list must be expressed as a CSV string. An empty string denies all access.
-| targetPattern | "" | List of Target address patterns allowed when creating sending links. This list must be expressed as a CSV string. An empty string denies all access.
-|====
-
-== Policy Wildcard and User Name Substitution
-
-Policy provides several conventions to make writing rules easier.
-
-=== Remote Host Wildcard
-
-Remote host rules may consist of a single asterisk character to
-specify all hosts.
-
-[options="nowrap"]
-----
- remoteHosts: *
-----
-
-The asterisk must stand alone and cannot be appended to a host name
-or to an IP address fragment.
-
-=== AMQP Source and Target User Name Substitution
-
-The rule definitions for `sources`, `targets`, `sourcePattern`, and
-`targetPattern` may include the username
-substitution token
-
-[options="nowrap"]
-----
- ${user}
-----
-
-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.
-
-=== AMQP Source and Target Link Name Match Wildcard
-
-The rule definitions for `sources` and `targets` may contain a trailing
-asterisk character.
-The asterisk is recognized only if it is the last character in the
-link name.
-
-[options="nowrap"]
-----
- sources: tmp_${user}, temp*, ${user}-home-*
-----
-
-The rule definitions for `sourcePattern` and `targetPattern` use the same
-patterns defined for router addresses and link routes. The patterns consist of one or more
-tokens separated by a forward slash /. 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.
-
-The user name substitution token may be used in a sourcePattern or in a
-targetPattern subject to the following restrictions:
-
-* The user name substitution token must be the first or last token in the rule clause.
-* The user name substitution token must stand alone within its delimited field.
- It may not be concatenated with literal text prefixes or suffixes.
-
-For each rule definition multiple patterns may be specified in a comma
-separated list.
-
-[options="nowrap"]
-----
- sourcePattern: tmp.${user}, temp/#, ${user}.home/*
-----
-
-[NOTE]
-====
-A rule definition may contain `sources` or `sourcePattern` but not both.
-A rule definition may contain `targets` or `targetPattern` but not both.
-====
-
-
-
-== Composing Policies
-
-This section shows policy examples designed to illustrate some common use cases.
-
-=== Example 1. User Policy Disabled
-
-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.
-
-[id='example2']
-=== Example 2. All Users Have Simple Connection Limits
-
-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.
-
-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.
-
-[options="nowrap"]
-----
-policy {
- maxConnections: 100 <1>
-}
-
-vhost {
- name: $default <2>
- maxConnectionsPerUser: 10 <3>
- allowUnknownUser: true <4>
- groups: {
- $default: {
- remoteHosts: * <5>
- sources: * <6>
- targets: * <6>
- }
- }
-}
-----
-
-<1> The global maxConnections limit of 100 is enforced.
-<2> No normal vhost names are defined; user is assigned to default vhost '$default'.
-<3> The vhost maxConnectionsPerUser limit of 10 is enforced.
-<4> No groups are defined to have any users but allowUnknownUser is true so all users are assigned to group $default.
-<5> The user is allowed to connect from any remote host.
-<6> 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.
-
-=== Example 3. Admins Must Connect From Localhost
-
-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.
-
-In this example a user connects to vhost 'example.com'.
-
-[options="nowrap"]
-----
-vhost {
- name: example.com <1>
- allowUnknownUser: true <3>
- groups: {
- admin: {
- users: alice, bob <2>
- remoteHosts: 127.0.0.1, ::1 <4>
- sources: * <5>
- targets: * <5>
- },
- $default: {
- remoteHosts: * <6>
- sources: news*, sports*, chat* <7>
- targets: chat* <7>
- }
- }
-}
-----
-
-<1> A connection to vhost 'example.com' locates this vhost rule set.
-<2> If one of users _alice_ or _bob_ is connecting then she or he is assigned to the 'admin' user group.
-<3> Any other user is not defined by a user group. However, since the _allowUnknownUser_ setting is true then this user is assigned to the '$default' user group.
-<4> Users in the 'admin' user group must connect from localhost. Connections for an 'admin' user from other hosts on the network are denied.
-<5> Users in the 'admin' user group are allowed to access any resource offered by the vhost service.
-<6> Other users are allowed to connect from any host.
-<7> Other users have source and target name lists that restrict the resources they are allowed to access.
-
-=== Example 4. Limiting Possible Memory Consumption
-
-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
-set directly by _maxSessionWindow_.
-
-By adjusting _maxSessions_, and _maxSessionWindow_ an
-administrator can prevent a user from consuming too much memory by
-buffering messages in flight.
-
-[NOTE]
-====
-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.
-====
-
-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.
-
-[options="nowrap"]
-----
-vhost {
- name: traders.com <1>
- groups: {
- traders: {
- users: trader-1, trader-2, ... <2>
- maxFrameSize: 10000 <3>
- maxSessionWindow: 5000000 <3>
- maxSessions: 1 <4>
- ...
- },
- feeds: {
- users: nyse-feed, nasdaq-feed <5>
- maxFrameSize: 60000 <6>
- maxSessionWindow: 1200000000 <6>
- maxSessions: 3 <7>
- ...
- }
- }
-}
-----
-
-<1> These rules are for vhost traders.com.
-<2> The 'traders' group includes trader-1, trader-2, and any other user defined in the list.
-<3> _maxFrameSize_ and _maxSessionWindow_ allow for at most 5,000,000 bytes of data to be in flight on each session.
-<4> Only one session per connection is allowed.
-<5> In the 'feeds' group two users are defined.
-<6> _maxFrameSize_ and _maxSessionWindow_ allow for at most 1,200,000,000 bytes of data to be in flight on each session.
-<7> Up to three sessions per connection are allowed.
-
-////
-
-- Should we used signed ints for limits to allow for magic values?
-
-- In example 3, alice and bob cannot connect from an outside server and
- get the $default settings.
-
-- Limits are enforced per router, so a vhost policy of maxConnections
- 10 across 10 routers will allow 100 connections to that vhost.
-
-////
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/book/schema_txt.py
----------------------------------------------------------------------
diff --git a/doc/book/schema_txt.py b/doc/book/schema_txt.py
deleted file mode 100644
index 9f340f3..0000000
--- a/doc/book/schema_txt.py
+++ /dev/null
@@ -1,109 +0,0 @@
-##
-## 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
-##
-
-"""
-Generate the schema.md chapter for the dispatch book from the qdrouter.json schema.
-"""
-from __future__ import unicode_literals
-from __future__ import division
-from __future__ import absolute_import
-from __future__ import print_function
-
-import sys, re
-from qpid_dispatch_internal.management.qdrouter import QdSchema
-from qpid_dispatch_internal.management.schema_doc import SchemaWriter
-
-class BookSchemaWriter(SchemaWriter):
-
- def run(self):
- self.heading("Management Schema")
- self.writeln("""
-This chapter documents the set of *management entity types* that define
-configuration and management of a Dispatch Router. A management entity type has
-a set of *attributes* that can be read, some attributes can also be
-updated. Some entity types also support *operations* that can be called.
-
-All management entity types have the following standard attributes:
-
-type::
- The fully qualified type of the entity,
- e.g. `org.apache.qpid.dispatch.router`. This document uses the short name
- without the `org.apache.qpid.dispatch` prefix e.g. `router`. The dispatch
- tools will accept the short or long name.
-
-name::
- A user-generated identity for the entity. This can be used in other entities
- that need to refer to the named entity.
-
-identity::
- A system-generated identity of the entity. It includes
- the short type name and some identifying information. E.g. `log/AGENT` or
- `listener/localhost:amqp`
-
-There are two main categories of management entity type.
-
-Configuration Entities::
- Parameters that can be set in the configuration file
- (see `qdrouterd.conf(5)` man page) or set at run-time with the `qdmanage(8)`
- tool.
-
-Operational Entities::
- Run-time status values that can be queried using `qdstat(8)` or `qdmanage(8)` tools.
-""")
-
- with self.section("Configuration Entities"):
- self.writeln("""
-Configuration entities define the attributes allowed in the configuration file
-(see `qdrouterd.conf(5)`) but you can also create entities once the router is
-running using the `qdrouterd(8)` tool's `create` operation. Some entities can also
-be modified using the `update` operation, see the entity descriptions below.
-""")
- self.entity_types_extending("configurationEntity")
-
- with self.section("Operational Entities"):
-
- self.writeln("""
-Operational entities provide statistics and other run-time attributes of the router.
-The `qdstat(8)` tool provides a convenient way to query run-time statistics.
-You can also use the general-purpose management tool `qdmanage(8)` to query
-operational attributes.
-""")
- self.entity_types_extending("operationalEntity")
-
- with self.section("Management Operations"):
- self.writeln("""
-The 'qdstat(8)' and 'qdmanage(8)' tools allow you to view or modify management entity
-attributes. They work by invoking *management operations*. You can invoke these operations
-from any AMQP client by sending a message with the appropriate properties and body to the
-'$management' address. The message should have a 'reply-to' address indicating where the
-response should be sent.
-""")
- def operation_section(title, entity_type):
- with self.section(title):
- self.operation_defs(entity_type)
- operation_section("Operations for all entity types", self.schema.entity_type("entity"))
- for e in self.schema.filter(lambda et: et.operation_defs and not et.name_is("entity")):
- operation_section("Operations for '%s' entity type" % e.short_name, e)
-
-def main():
- """Generate schema markdown documentation from L{QdSchema}"""
- BookSchemaWriter(sys.stdout, QdSchema()).run()
-
-if __name__ == '__main__':
- main()
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/book/theory_of_operation.adoc
----------------------------------------------------------------------
diff --git a/doc/book/theory_of_operation.adoc b/doc/book/theory_of_operation.adoc
deleted file mode 100644
index c2deab8..0000000
--- a/doc/book/theory_of_operation.adoc
+++ /dev/null
@@ -1,395 +0,0 @@
-////
-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
-////
-
-== Theory of Operation
-
-This section introduces some key concepts about the router.
-
-=== Overview
-
-The router is an _application layer_ program running as a normal
-user program or as a daemon.
-
-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.
-
-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.
-
-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.
-
-=== Connections
-
-The router connects clients, servers, AMQP services, and other
-routers through network connections.
-
-==== Listener
-
-The router provides _listeners_ 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.
-
-Several types of listeners are defined by their role.
-
-[cols="20,80"]
-|===
-| Role | Description
-| normal | The connection is used for AMQP clients using normal message delivery.
-| inter-router | 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 | 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.
-|===
-
-==== Connector
-
-The router can also be configured to create outbound connections to
-messaging brokers or other AMQP entities using _connectors_. 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.
-
-Several types of connectors are defined by their role.
-
-[cols="20,80"]
-|===
-| Role | Description
-| normal | 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.
-| inter-router | 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 | 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.
-|===
-
-=== Addresses
-
-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 _to_ and _reply-to_ fields of a message's properties. They are also
-used during the creation of links in the _address_ field of a _source_ or
-a _target_.
-
-[NOTE]
-====
-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.
-====
-
-Addresses designate various kinds of entities in a messaging network:
-
-* Endpoint processes that consume data or offer a service
-* Topics that match multiple consumers to multiple producers
-* Entities within a messaging broker:
-** Queues
-** Durable Topics
-** Exchanges
-
-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.
-
-The router maintains several classes of address based on how the address is
-configured or discovered.
-
-[cols="25,75"]
-|===
-| Address Type | Description
-| mobile | The address is a rendezvous point between senders and receivers. The router aggregates and serializes messages from senders and distributes messages to receivers.
-| link route | The address defines a private messaging path between a sender and a receiver. The router simply passes messages between the end points.
-|===
-
-==== Mobile Addresses
-
-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.
-
-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.
-
-Mobile addresses may be discovered during normal router operation or
-configured through management settings.
-
-===== Discovered Mobile Addresses
-
-Mobile addresses are created when a client creates a link to a source
-or destination address that is unknown to the router network.
-
-Suppose a service provider wants to offer _my-service_ that clients
-may use. The service provider must open a receiver link with source
-address _my-service_. The router creates a mobile address
-_my-service_ and propagates the address so that it is known to every
-router in the network.
-
-Later a client wants to use the service and creates a sending link
-with target address _my-service_. The router matches the service
-provider's receiver having source address _my-service_ to the client's
-sender having target address _my-service_ and routes messages between
-the two.
-
-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.
-
-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 _my-service_ 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.
-
-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.
-
-===== Configured Mobile Addresses
-
-Mobile addresses may be configured using the router _autoLink_
-object. An address created via an _autoLink_ represents a queue,
-topic, or other service in an external broker. Logically the
-_autoLink_ addresses are treated by the router network as if the
-broker had connected to the router and offered the services itself.
-
-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.
-
-Multiple _autoLink_ 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.
-
-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.
-
-==== Link Route Addresses
-
-Link route addresses may be configured using the router _linkRoute_
-object. An link route address represents a queue, topic, or other
-service in an external broker similar to addresses configured by
-_autoLink_ 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.
-
-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.
-
-=== Message Routing
-
-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:
-
-* Routing pattern - balanced, closest, multicast
-* Routing mechanism - message routed, link routed
-
-// * TODO: describe these???
-// * Undeliverable action - drop, hold and retry, redirect
-// * Reliability - N destinations, etc.
-
-==== Routing Patterns
-
-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.
-
-Note that the routing patterns fall into two categories: Anycast
-(Balanced and Closest) and Multicast. There is no concept of
-"unicast" in which there is only one consumer for an address.
-
-Anycast distribution delivers each message to one consumer whereas
-multicast distribution delivers each message to all consumers.
-
-Anycast delivery is reliable when the message deliveries are
-unsettled. There is a reliability contract that the router network
-abides by when delivering unsettled messages to anycast addresses.
-For every such delivery sent by a producer, the router network
-guarantees that one of the following outcomes will occur:
-
-* The delivery shall be settled with ACCEPTED or REJECTED disposition
- where the disposition is supplied by the consumer.
-* The delivery shall be settled with RELEASED disposition, meaning
- that the message was not delivered to any consumer.
-* The delivery shall be settled with MODIFIED disposition, meaning
- that the message may have been delivered to a consumer but should be
- considered in-doubt and re-sent.
-* The connection to the producer shall be dropped, signifying that all
- unsettled deliveries should now be considered in-doubt by the
- producer and later re-sent.
-
-Multicast delivery is not reliable. If a producer sends an unsettled
-delivery, the ingress router shall settle the delivery with ACCEPTED
-disposition regardless of whether the message was delivered to any
-consumers.
-
-===== Balanced
-
-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.
-
-===== Closest
-
-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.
-
-===== Multicast
-
-Having multiple consumers on the same address at the same time,
-messages are routed such that each consumer receives one copy of the
-message.
-
-
-==== Routing Mechanisms
-
-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 _routing_:
-
- 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.
-
-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.
-
-===== Message Routed
-
-Message routing occurs upon delivery of a message and is done based on
-the address in the message's _to_ field.
-
-When a delivery arrives on an incoming message-routing link, the
-router extracts the address from the delivered message's _to_ 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.
-
-Message routing can also occur without an address in the
-message's _to_ field if the incoming link has a target address. In
-fact, if the sender uses a link with a target address, the _to_ field
-shall be ignored even if used.
-
-===== Link Routed
-
-Link routing occurs when a new link is attached to the router across
-one of its AMQP connections. It is done based on the _target.address_
-field of an inbound link and the _source.address_ field of an outbound
-link.
-
-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.
-
-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.
-
-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.
-
-==== Message Settlement
-
-Messages may be delivered with varying degrees of reliability.
-
-* At most once
-* At least once
-* Exactly once
-
-The reliability is negotiated between the client and server during
-link establishment. The router handles all levels of reliability by treating
-messages as either _pre-settled_ or _unsettled_.
-
-[cols="20,80"]
-|===
-| Delivery | Handling
-| pre-settled | 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.
-| unsettled | 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.
-|===
-
-
-=== Security
-
-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.
-
-The router Policy module is an optional authorization mechanism
-enforcing user connection restrictions and AMQP resource access
-control.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/book/tools.adoc
----------------------------------------------------------------------
diff --git a/doc/book/tools.adoc b/doc/book/tools.adoc
deleted file mode 100644
index 6f8298d..0000000
--- a/doc/book/tools.adoc
+++ /dev/null
@@ -1,92 +0,0 @@
-////
-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
-////
-
-[[tools]]
-Tools
------
-
-[[qdstat]]
-qdstat
-~~~~~~
-
-_qdstat_ 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:
-
-[width="100%",cols="17%,83%",options="header",]
-|=======================================================================
-|_Option_ |_Description_
-|-l |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 _endpoint_ links
-and _router_ links. Endpoint links are attached to clients using the
-router. Router links are attached to other routers in a network of
-routbers.
-
-|-a |Print a list of addresses known to the router.
-
-|-n |Print a list of known routers in the network.
-
-|-c |Print a list of connections to the router.
-
-|--autolinks |Print a list of configured auto-links.
-
-|--linkroutes |Print a list of configures link-routes.
-|=======================================================================
-
-For complete details see the 'qdstat(8)' man page and the output of
-`qdstat --help`.
-
-[[qdmanage]]
-qdmanage
-~~~~~~~~
-
-_qdmanage_ is a general-purpose AMQP management client that allows you
-to not only view but modify the configuration of a running dispatch
-router.
-
-For example you can query all the connection entities in the router:
-
-----------------------------------
-$ qdmanage query --type connection
-----------------------------------
-
-To enable logging debug and higher level messages by default:
-
--------------------------------------------
-$ qdmanage update log/DEFAULT enable=debug+
--------------------------------------------
-
-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:
-
------------------------------------------
-$ qdmanage create type=listener port=5555
------------------------------------------
-
-Now you can connect to port 5555, for exampple:
-
---------------------------------------------------
-$ qdmanage query -b localhost:5555 --type listener
---------------------------------------------------
-
-For complete details see the 'qdmanage(8)' man page and the output of
-`qdmanage --help`. Also for details of what can be configured see the
-'qdrouterd.conf(5)' man page.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/common/fragment-router-sasl-para.adoc
----------------------------------------------------------------------
diff --git a/doc/common/fragment-router-sasl-para.adoc b/doc/common/fragment-router-sasl-para.adoc
deleted file mode 100644
index c6264e4..0000000
--- a/doc/common/fragment-router-sasl-para.adoc
+++ /dev/null
@@ -1,20 +0,0 @@
-////
-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
-////
-
-To see a list of Cyrus SASL plugins in a `dnf`-based Linux system, use the `dnf search cyrus-sasl` command. To install a Cyrus SASL plugin, use the `dnf install _PLUGIN_` command.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/common/fragment-starting-router-step.adoc
----------------------------------------------------------------------
diff --git a/doc/common/fragment-starting-router-step.adoc b/doc/common/fragment-starting-router-step.adoc
deleted file mode 100644
index 4e9117b..0000000
--- a/doc/common/fragment-starting-router-step.adoc
+++ /dev/null
@@ -1,29 +0,0 @@
-////
-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
-////
-
-. To start the router, use the *`qdrouterd`* command.
-+
---
-This example uses the default configuration to start the router as a daemon:
-
-[options="nowrap"]
-----
-$ qdrouterd -d
-----
---
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/index.adoc
----------------------------------------------------------------------
diff --git a/doc/index.adoc b/doc/index.adoc
deleted file mode 100644
index 1095701..0000000
--- a/doc/index.adoc
+++ /dev/null
@@ -1,35 +0,0 @@
-////
-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
-////
-
-[[documentation-for-dispatch]]
-Documentation for dispatch
---------------------------
-
-:index-only:
-
-link:book.html[Dispatch Router User Guide] (link:book.pdf[PDF Format])
-
-Manual pages
-
-- link:qdrouterd.8.html[qdrouterd]
-- link:qdrouterd.conf.5.html[qdrouterd.conf]
-- link:qdstat.8.html[qdstat]
-- link:qdmanage.8.html[qdmanage]
-
-Also check the link:http://qpid.apache.org/components/dispatch-router[Dispatch Router Website]
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/man/help2txt.py
----------------------------------------------------------------------
diff --git a/doc/man/help2txt.py b/doc/man/help2txt.py
deleted file mode 100644
index 24aeb53..0000000
--- a/doc/man/help2txt.py
+++ /dev/null
@@ -1,69 +0,0 @@
-#
-# 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
-#
-
-"""
-Convert --help output of a program into asciidoc text format.
-"""
-from __future__ import print_function
-from __future__ import unicode_literals
-from __future__ import division
-from __future__ import absolute_import
-
-
-import re, sys
-from qpid_dispatch_internal.compat import PY_STRING_TYPE
-from qpid_dispatch_internal.compat.subproc import check_output
-
-
-def help2txt(help_out):
- VALUE = r"(?:[\w-]+|<[^>]+>)"
- DEFAULT = r"(?: +\([^)]+\))?"
- OPTION = r"-[\w-]+(?:[ =]%s)?%s" % (VALUE, DEFAULT) # -opt[(=| )value][(default)]
- OPTIONS = r"%s(?:, *%s)*" % (OPTION, OPTION) # opt[,opt...]
- HELP = r"(?:[ \t]+\w.*$)|(?:(?:\n[ \t]+[^-\s].*$)+)" # same line or following lines indented.
- OPT_HELP = r"^\s+(%s)(%s)" % (OPTIONS, HELP)
- SUBHEAD = r"^((?: +\w+)*):$"
-
- # check_output returns binary in py3
- if not isinstance(help_out, PY_STRING_TYPE):
- help_out = help_out.decode()
-
- options = re.search("^Options:$", help_out, re.IGNORECASE | re.MULTILINE)
- if (options): help_out = help_out[options.end():]
- result = ""
-
- def heading(text, depth):
- return "%s %s\n\n" % ("="*depth, text)
-
- for item in re.finditer(r"%s|%s" % (OPT_HELP, SUBHEAD), help_out, re.IGNORECASE | re.MULTILINE):
- if item.group(3):
- result += heading(item.group(3).strip(), 3)
- else:
- result += "%s\n: %s\n\n" % (item.group(1), re.sub("\s+", " ", item.group(2)).strip())
- return result
-
-def main(argv):
- if len(argv) < 2: raise ValueError("Wrong number of arguments\nUsage %s"
- " <program> [args,...]" % argv[0])
- program = argv[1:]
- print(help2txt(check_output(program)))
-
-if __name__ == "__main__":
- main(sys.argv)
-
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/man/qdmanage.8.adoc
----------------------------------------------------------------------
diff --git a/doc/man/qdmanage.8.adoc b/doc/man/qdmanage.8.adoc
deleted file mode 100644
index 9f668b5..0000000
--- a/doc/man/qdmanage.8.adoc
+++ /dev/null
@@ -1,139 +0,0 @@
-////
-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
-////
-
-qdmanage(8)
-==========
-:doctype: manpage
-
-NAME
-----
-qdmanage - management client to control or query qdrouterd(8)
-
-SYNOPSIS
---------
-*qdmanage* ['OPTIONS'] 'OPERATION' ['ARGUMENTS']
-
-DESCRIPTION
------------
-An AMQP management client for use with the Dispatch router daemon
-('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 'qdrouterd'.
-
-OPTIONS
--------
-
-include::{generated_man}/qdmanage_help.adoc[]
-
-OPERATIONS
-----------
-
-`query` ['ATTR'...]::
- 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.
-
-`create` ['ATTR=VALUE'...]::
- 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.
-
-`read`::
- Print all of the attributes of a single entity, specified by the --name or
- --identity options.
-
-`update` ['ATTR=VALUE'...]::
- 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.
-
-`delete`::
- Delete an entity specified by the --name or --identity options.
-
-`get-types` ['TYPE']::
- List entity types with their base types. With no arguments, list all
- types.
-
-`get-operations` ['TYPE']::
- List entity types with their operations. With no arguments, list all
- types.
-
-`get-attributes` ['TYPE']::
- List entity types with their attributes. With no arguments, list all
- types.
-
-`get-annotations` ['TYPE']::
- List entity types with their annotations. With no arguments, list all
- types.
-
-`get-mgmt-nodes`::
- List all other known management nodes connected to this one.
-
-`get-json-schema` ['INDENT']::
- Get the router schema in JSON format. Optional integer indent for
- formatted output.
-
-`get-log` ['INDENT']::
- Get recent log entries from the router.
-
-FILES
------
-
-{CMAKE_INSTALL_PREFIX}/{QD_DOC_INSTALL_DIR}/qdrouter.json::
- Management schema for 'qdrouterd'.
-{CMAKE_INSTALL_PREFIX}/{QD_DOC_INSTALL_DIR}/qdrouter.json.readme.txt::
- Explanation of the management schema.
-
-EXAMPLES
---------
-
-.Show the logging configuration:
---------------------------------------------------------------
-qdmanage query --type=log
---------------------------------------------------------------
-
-.Enable debug and higher log messages by default:
---------------------------------------------------------------
-qdmanage update name=log/DEFAULT enable=debug+
---------------------------------------------------------------
-
-.Enable trace log messages only for the MESSAGE module, and direct MESSAGE logs to the file _test.log_:
---------------------------------------------------------------
-qdmanage update name=log/MESSAGE enable=trace output=test.log
---------------------------------------------------------------
-
-.Set MESSAGE logging back to the default:
-------------------------------------------------
-qdmanage update name=log/MESSAGE enable=default
-------------------------------------------------
-
-.Disable MESSAGE logging:
----------------------------------------------
-qdmanage update name=log/MESSAGE enable=none
----------------------------------------------
-
-SEE ALSO
-----------
-'qdrouterd(8)', 'qdstat(8)', 'qdrouterd.conf(5)'
-
-http://qpid.apache.org/components/dispatch-router
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/man/qdrouterd.8.adoc
----------------------------------------------------------------------
diff --git a/doc/man/qdrouterd.8.adoc b/doc/man/qdrouterd.8.adoc
deleted file mode 100644
index ae2c2a2..0000000
--- a/doc/man/qdrouterd.8.adoc
+++ /dev/null
@@ -1,54 +0,0 @@
-////
-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
-////
-
-qdrouterd(8)
-===========
-:doctype: manpage
-
-NAME
-----
-qdrouterd - routes AMQP messages.
-
-SYNOPSIS
---------
-*qdrouterd* ['OPTIONS']
-
-
-DESCRIPTION
------------
-The Qpid Dispatch router ('qdrouterd') is a network daemon that directs
-AMQP 1.0 messages between endpoints, such as messaging clients and
-servers.
-
-OPTIONS
--------
-
-include::{generated_man}/qdrouterd_help.adoc[]
-
-FILES
------
-
-{SYSCONF_INSTALL_DIR}/qdrouterd.conf::
- Configuration file.
-
-SEE ALSO
---------
-'qdrouterd.conf(5)', 'qdstat(8)', 'qdmanage(8)'
-
-http://qpid.apache.org/components/dispatch-router
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/man/qdrouterd.conf.5.py
----------------------------------------------------------------------
diff --git a/doc/man/qdrouterd.conf.5.py b/doc/man/qdrouterd.conf.5.py
deleted file mode 100644
index e2bdd8e..0000000
--- a/doc/man/qdrouterd.conf.5.py
+++ /dev/null
@@ -1,155 +0,0 @@
-#
-# 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
-#
-
-"""
-Generate the qdrouterd.conf. man page from the qdrouterd management schema.
-"""
-
-from __future__ import unicode_literals
-from __future__ import division
-from __future__ import absolute_import
-from __future__ import print_function
-
-import sys
-from qpid_dispatch_internal.management.qdrouter import QdSchema
-from qpid_dispatch_internal.management.schema_doc import SchemaWriter
-from qpid_dispatch_internal.compat import dict_itervalues
-
-CONNECTOR = 'org.apache.qpid.dispatch.connector'
-LISTENER = 'org.apache.qpid.dispatch.listener'
-
-class ManPageWriter(SchemaWriter):
-
- def __init__(self):
- super(ManPageWriter, self).__init__(sys.stdout, QdSchema())
-
- def attribute_type(self, attr, holder):
- # Don't show read-only attributes
- if not attr.create and not attr.update:
- # It is ok to show the console attributes
- if not holder.short_name == "console":
- return
- super(ManPageWriter, self).attribute_type(attr, holder, show_create=False, show_update=False)
-
-
-
- def man_page(self):
- self.writeln(r"""
-qdrouterd.conf(5)
-=================
-:doctype: manpage
-
-NAME
-----
-qdrouterd.conf - configuration file for the dispatch router.
-
-SYNOPSIS
---------
-Provides the initial configuration when 'qdrouterd(8)' starts. The configuration
-of a running router can be modified using 'qdmanage(8)'.
-
-
-DESCRIPTION
------------
-
-The configuration file is made up of sections with this syntax:
-
-----
-sectionName {
- attributeName: attributeValue
- attributeName: attributeValue
- ...
-}
-----
-
-For example you can define a router using the 'router' section
-
-----
-router {
- mode: standalone
- id: Router.A
- ...
-}
-----
-
-or define a listener using the 'listener' section
-
-----
-listener {
- host: 0.0.0.0
- port: 20102
- saslMechanisms: ANONYMOUS
- ...
-}
-----
-
-or define a connector using the 'connector' section
-
-----
-connector {
- role: inter-router
- host: 0.0.0.0
- port: 20003
- saslMechanisms: ANONYMOUS
- ...
-}
-----
-
-An 'sslProfile' section with SSL credentials can be included in multiple 'listener' or 'connector' entities. Here's an example, note
-how the 'sslProfile' attribute of 'listener' sections references the 'name'
-attribute of 'sslProfile' sections.
-
-----
-sslProfile {
- name: my-ssl
- caCertFile: ca-certificate-1.pem
- certFile: server-certificate-1.pem
- privateKeyFile: server-private-key.pem
-}
-
-listener {
- sslProfile: my-ssl
- host: 0.0.0.0
- port: 20102
- saslMechanisms: ANONYMOUS
-}
-----
-""")
-
- with self.section("Configuration Sections"):
-
- config = self.schema.entity_type("configurationEntity")
- for entity_type in dict_itervalues(self.schema.entity_types):
- if config in entity_type.all_bases:
- with self.section(entity_type.short_name):
- if entity_type.description:
- self.para(entity_type.description)
- self.attribute_types(entity_type)
-
- self.writeln("""
-SEE ALSO
---------
-
-*qdrouterd(8)*, *qdmanage(8)*
-
-http://qpid.apache.org/components/dispatch-router
-""")
-
-if __name__ == '__main__':
- ManPageWriter().man_page()
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/man/qdstat.8.adoc
----------------------------------------------------------------------
diff --git a/doc/man/qdstat.8.adoc b/doc/man/qdstat.8.adoc
deleted file mode 100644
index bd62be4..0000000
--- a/doc/man/qdstat.8.adoc
+++ /dev/null
@@ -1,277 +0,0 @@
-////
-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
-////
-
-qdstat(8)
-=========
-:doctype: manpage
-
-NAME
-----
-qdstat - show status and statistics for a running 'qdrouterd'
-
-SYNOPSIS
---------
-*qdstat* ['OPTIONS']
-
-DESCRIPTION
------------
-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.
-
-OPTIONS
--------
-
-include::{generated_man}/qdstat_help.adoc[]
-
-OUTPUT COLUMNS
---------------
-
-qdstat -c
-~~~~~~~~~
-id::
-The connection's unique identifier.
-
-host::
-The hostname or internet address of the remotely-connected AMQP container.
-
-container::
-The container name of the remotely-connected AMQP container.
-
-role::
-The connection's role:
- - 'normal' - The normal connection from a client to a router.
- - 'inter-router' - The connection between routers to form a network.
- - 'route-container' - The connection to or from a broker or other host to receive link routes and waypoints.
-
-dir::
-The direction in which the connection was established:
- - 'in' - The connection was initiated by the remote container.
- - 'out' - The connection was initiated by this router.
-
-security::
-The security or encryption method, if any, used for this connection.
-
-authentication::
-The authentication method and user ID of the connection's authenticated user.
-
-qdstat -l
-~~~~~~~~~
-type::
-The type of link:
- - 'router-control' - An inter-router link that is reserved for control messages exchanged between routers.
- - 'inter-router' - An inter-router link that is used for normal message-routed deliveries.
- - 'endpoint' - A normal link to an external endpoint container.
-
-dir::
-The direction that messages flow on the link:
- - 'in' - Deliveries flow inbound to the router.
- - 'out' - Deliveries flow outbound from the router.
-
-conn id::
-The unique identifier of the connection over which this link is
-attached.
-
-id::
-The unique identifier of this link.
-
-peer::
-For link-routed links, the unique identifier of the peer link. In
-link routing, an inbound link is paired with an outbound link.
-
-class::
-The class of the address bound to the link:
- - 'local' - The address that is local to this router (temporary).
- - 'topo' - A topological address used for router control messages.
- - 'router' - A summary router address used to route messages to a remote router’s local addresses.
- - 'mobile' - A mobile address for an attached consumer or producer.
- - 'link-in' - The address match for incoming routed links.
- - 'link-out' - The address match for outgoing routed links.
-
-addr::
-The address bound to the link.
-
-phs::
-The phase of the address bound to the link.
-
-cap::
-The capacity, in deliveries, of the link.
-
-undel::
-The number of undelivered messages stored on the link's FIFO.
-
-unsett::
-The number of unsettled deliveries being tracked by the link.
-
-del::
-The total number of deliveries that have transited this link.
-
-presett::
-The number of pre-settled deliveries that transited this link.
-
-psdrop::
-The number of pre-settled deliveries that were dropped due to congestion.
-
-acc::
-The number of deliveries on this link that were accepted.
-
-rej::
-The number of deliveries on this link that were rejected.
-
-rel::
-The number of deliveries on this link that were released.
-
-mod::
-The number of deliveries on this link that were modified.
-
-admin::
-The administrative status of the link:
- - 'enabled' - The link is enabled for normal operation.
- - 'disabled' - The link is disabled and should be quiescing or stopped (not yet supported).
-
-oper::
-The operational status of the link:
- - 'up' - The link is operational.
- - 'down' - The link is not attached.
- - 'quiescing' - The link is in the process of quiescing (not yet supported).
- - 'idle' - The link has completed quiescing and is idle (not yet supported).
-
-name::
-The link name (only shown if the -v option is provided).
-
-qdstat -n
-^^^^^^^^^
-
-router-id::
-The router's ID.
-
-next-hop::
-If this router is not a neighbor, this field identifies the next-hop neighbor used to reach this router.
-
-link::
-The ID of the link to the neighbor router.
-
-cost::
-The topology cost to this remote router (with -v option only).
-
-neighbors::
-The list of neighbor routers (the router's link-state). This field is available only if you specify the -v option.
-
-valid-origins::
-The list of origin routers for which the best path to the listed router passes through this router (available only with the -v option).
-
-qdstat -a
-~~~~~~~~~
-
-class::
-The class of the address:
- - 'local' - The address that is local to this router.
- - 'topo' - The topological address used for router control messages.
- - 'router' - A summary router address used to route messages to a remote router's local addresses.
- - 'mobile' - A mobile address for an attached consumer or producer.
-
-addr::
-The address text.
-
-phs::
-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.
-
-distrib::
-One of the following distribution methods used for this address:
- - 'multicast' - A copy of each message is delivered once to each consumer for the address.
- - '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.
- - '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 (that is, higher cost consumers will only receive deliveries if closer consumers are backed up).
- - 'flood' - Used only for router-control traffic. This is multicast without the prevention of duplicate deliveries.
-
-in-proc::
-The number of in-process consumers for this address.
-
-local::
-For this router, the number of local consumers for this address.
-
-remote::
-The number of remote routers that have at least one consumer for this address.
-
-cntnr::
-The number of locally-attached containers that are destinations for link routes on this address.
-
-in::
-The number of deliveries for this address that entered the network on this router.
-
-out::
-The number of deliveries for this address that exited the network on this router.
-
-thru::
-The number of deliveries for this address that were forwarded to other routers.
-
-to-proc::
-The number of deliveries for this address that were delivered to an in-process consumer.
-
-from-proc::
-The number of deliveries for this address that were received from an in-process producer.
-
-qdstat --linkroutes
-~~~~~~~~~~~~~~~~~~~
-
-prefix::
-The address prefix of the link route.
-
-dir::
-The direction of matching links (from this router's perspective).
-
-distrib::
-The distribution method used for routed links. This value should always be 'linkBalanced', which is the only supported distribution for routed links.
-
-status::
-The operational status of the link route:
- - 'active' - The route is actively routing attaches (it is ready for use).
- - 'inactive' - The route is inactive, because no local destination is connected.
-
-qstat --autolinks
-~~~~~~~~~~~~~~~~~
-addr::
-The auto link's address.
-
-dir::
-The direction that messages flow over the auto link:
- - 'in' - Messages flow in from the route-container to the router network.
- - 'out' - Messages flow out to the route-container from the router network.
-
-phs::
-The address phase for this auto link.
-
-link::
-The ID of the link managed by this auto link.
-
-status::
-The operational status of this auto link:
- - 'inactive' - There is no connected container for this auto link.
- - 'attaching' - The link is attaching to the container.
- - 'failed' - The link-attach failed.
- - 'active' - The link is operational.
- - 'quiescing' - The link is quiescing (not yet supported).
- - 'idle' - The link is idle (not yet supported).
-
-lastErr::
-The description of the last attach failure that occurred on this auto link.
-
-SEE ALSO
---------
-
-'qdrouterd(8)', 'qdmanage(8)', 'qdrouterd.conf(5)'
-
-http://qpid.apache.org/components/dispatch-router
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/attributes.adoc
----------------------------------------------------------------------
diff --git a/doc/new-book/attributes.adoc b/doc/new-book/attributes.adoc
deleted file mode 100644
index 0162710..0000000
--- a/doc/new-book/attributes.adoc
+++ /dev/null
@@ -1,78 +0,0 @@
-////
-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
-////
-
-// Standard document attributes
-
-:data-uri!:
-:doctype: article
-:experimental:
-:idprefix:
-:imagesdir: images
-:numbered:
-:sectanchors!:
-:sectnums:
-:source-highlighter: highlightjs
-:highlightjs-theme: solarized_dark
-:toc: left
-:linkattrs:
-:toclevels: 3
-
-// Component attributes
-
-:ProductName: Apache Qpid
-:RouterLongName: {ProductName} Dispatch Router
-:ClientAmqpPythonName: {ProductName} Proton Python
-:ConsoleName: {RouterLongName} Console
-:FragmentDir: common
-:RouterName: Dispatch Router
-:RouterSchemaDir: ../../build/doc/book
-:DispatchRouterVersion: 1.0.1
-
-// Book names
-
-:RouterBook: Using {RouterLongName}
-
-// Doc links
-
-:DispatchRouterUrlBase: https://qpid.apache.org/releases/qpid-dispatch-{DispatchRouterVersion}
-
-:ManagementEntitiesUrl: {DispatchRouterUrlBase}/man/managementschema.html
-:ManagementEntitiesLink: link:{ManagementEntitiesUrl}[{RouterName} Management Schema^]
-
-:RouterBookUrl: {DispatchRouterUrlBase}/book/book.html
-:RouterBookLink: link:{RouterBookUrl}[{RouterBook}]
-
-:qdmanageManPageUrl: {DispatchRouterUrlBase}/man/qdmanage.html
-:qdmanageManPageLink: link:{qdmanageManPageUrl}[qdmanage man page^]
-
-:qdrouterdManPageUrl: {DispatchRouterUrlBase}/man/qdrouterd.html
-:qdrouterdManPageLink: link:{qdrouterdManPageUrl}[qdrouterd man page^]
-
-:qdrouterdConfManPageUrl: {DispatchRouterUrlBase}/man/qdrouterd.conf.html
-:qdrouterdConfManPageLink: link:{qdrouterdConfManPageUrl}[qdrouterd.conf man page^]
-
-:qdstatManPageUrl: {DispatchRouterUrlBase}/man/qdstat.html
-:qdstatManPageLink: link:{qdstatManPageUrl}[qdstat man page^]
-
-:ClientAmqpPythonUrl: https://qpid.apache.org/proton/
-
-// Other links
-
-:AmqpSpecUrl: http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-overview-v1.0-os.html
-:AmqpSpecLink: link:{AmqpSpecUrl}[AMQP 1.0 specification^]
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/book.adoc
----------------------------------------------------------------------
diff --git a/doc/new-book/book.adoc b/doc/new-book/book.adoc
deleted file mode 100644
index 4ed6bdf..0000000
--- a/doc/new-book/book.adoc
+++ /dev/null
@@ -1,61 +0,0 @@
-////
-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
-////
-
-include::attributes.adoc[]
-
-= {RouterBook}
-
-// Introduction
-include::introduction.adoc[leveloffset=+1]
-
-// Theory of Operation
-include::theory_of_operation.adoc[leveloffset=+1]
-
-// Getting Started
-include::getting-started.adoc[leveloffset=+1]
-
-// Configuration
-include::understand-router-configuration.adoc[leveloffset=+1]
-
-// Network Connections
-include::configuration-connections.adoc[leveloffset=+1]
-
-// Security
-include::configuration-security.adoc[leveloffset=+1]
-
-// Routing
-include::routing.adoc[leveloffset=+1]
-
-// Logging
-include::logging.adoc[leveloffset=+1]
-
-// Management
-include::management.adoc[leveloffset=+1]
-
-// Reliability
-include::reliability.adoc[leveloffset=+1]
-
-// Technical Details and Specifications
-include::technical-details-specifications.adoc[leveloffset=+1]
-
-[appendix]
-include::cyrus-sasl.adoc[leveloffset=+1]
-
-// Revision information
-include::revision-info.adoc[]
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/common
----------------------------------------------------------------------
diff --git a/doc/new-book/common b/doc/new-book/common
deleted file mode 120000
index 8332399..0000000
--- a/doc/new-book/common
+++ /dev/null
@@ -1 +0,0 @@
-../common/
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/configuration-connections.adoc
----------------------------------------------------------------------
diff --git a/doc/new-book/configuration-connections.adoc b/doc/new-book/configuration-connections.adoc
deleted file mode 100644
index 26e10a2..0000000
--- a/doc/new-book/configuration-connections.adoc
+++ /dev/null
@@ -1,90 +0,0 @@
-////
-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
-////
-
-[id='router-network-connections']
-= Network Connections
-
-Connections define how the router communicates with clients, other routers, and brokers. You can configure _incoming connections_ to define how the router listens for data from clients and other routers, and you can configure _outgoing connections_ to define how the router sends data to other routers and brokers.
-
-[id='adding-incoming-connections']
-== Listening for Incoming Connections
-
-Listening for incoming connections involves setting the host and port on which the router should listen for traffic.
-
-.Procedure
-
-. In the router's configuration file, add a `listener`:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-listener {
- host: _HOST_NAME/ADDRESS_
- port: _PORT_NUMBER/NAME_
- ...
-}
-----
-
-`host`:: Either an IP address (IPv4 or IPv6) or hostname on which the router should listen for incoming connections.
-`port`:: The port number or symbolic service name on which the router should listen for incoming connections.
-
-For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_listener[listener] in the `qdrouterd.conf` man page.
---
-
-. If necessary, xref:securing-incoming-connections[secure the connection].
-+
-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.
-
-. If you want the router to listen for incoming connections on additional hosts or ports, configure an additional `listener` entity for each host and port.
-
-[id='adding-outgoing-connections']
-== Adding Outgoing Connections
-
-Configuring outgoing connections involves setting the host and port on which the router connects to other routers and brokers.
-
-// Adding this here for now; in the future it might be better to have separate procedures for creating inter-router and route-container connections.
-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 xref:managing-connectors[].
-
-.Procedure
-
-. In the router's configuration file, add a `connector`:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-connector {
- name: _NAME_
- host: _HOST_NAME/ADDRESS_
- port: _PORT_NUMBER/NAME_
- ...
-}
-----
-
-`name`:: The name of the `connector`. You should specify a name that describes the entity to which the connector connects. This name is used by configured addresses (for example, a `linkRoute` entity) in order to specify which connection should be used for them.
-`host`:: Either an IP address (IPv4 or IPv6) or hostname on which the router should connect.
-`port`:: The port number or symbolic service name on which the router should connect.
-
-For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_connector[connector] in the `qdrouterd.conf` man page.
---
-
-. If necessary, xref:securing-outgoing-connections[secure the connection].
-+
-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.
-
-. For each remaining router or broker to which this router should connect, configure an additional `connector` entity.
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org
[03/11] qpid-dispatch git commit: DISPATCH-851: Move the new book
into primary position and reorg the docs
Posted by jr...@apache.org.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/logging.adoc
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/logging.adoc b/docs/books/user-guide/logging.adoc
new file mode 100644
index 0000000..32b7e93
--- /dev/null
+++ b/docs/books/user-guide/logging.adoc
@@ -0,0 +1,346 @@
+////
+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
+////
+
+[id='logging']
+= Logging
+
+Logging enables you to diagnose error and performance issues with {RouterName}.
+
+{RouterName} consists of internal modules that provide important information about the router. For each module, you can specify logging levels, the format of the log file, and the location to which the logs should be written.
+
+[id='logging-modules-you-can-configure']
+== Logging Modules
+
+{RouterName} logs are broken into different categories called _logging modules_. Each module provides important information about a particular aspect of {RouterName}.
+
+=== The `DEFAULT` Logging Module
+
+The default module. This module applies defaults to all of the other logging modules.
+
+=== The `ROUTER` Logging Module
+
+This module provides information and statistics about the local router. This includes how the router connects to other routers in the network, and information about the remote destinations that are directly reachable from the router (link routes, waypoints, autolinks, and so on).
+
+In this example, on `Router.A`, the `ROUTER` log shows that `Router.B` is the next hop. It also shows the cost for `Router.A` to reach the other routers on the network:
+
+[options="nowrap"]
+----
+Tue Jun 7 13:28:27 2016 ROUTER (trace) Node Router.C next hop set: Router.B
+Tue Jun 7 13:28:27 2016 ROUTER (trace) Node Router.C valid origins: []
+Tue Jun 7 13:28:27 2016 ROUTER (trace) Node Router.C cost: 2
+Tue Jun 7 13:28:27 2016 ROUTER (trace) Node Router.B valid origins: []
+Tue Jun 7 13:28:27 2016 ROUTER (trace) Node Router.B cost: 1
+----
+
+On `Router.B`, the `ROUTER` log provides more information about valid origins:
+
+[options="nowrap"]
+----
+Tue Jun 7 13:28:25 2016 ROUTER (trace) Node Router.C cost: 1
+Tue Jun 7 13:28:26 2016 ROUTER (trace) Node Router.A created: maskbit=2
+Tue Jun 7 13:28:26 2016 ROUTER (trace) Node Router.A link set: link_id=1
+Tue Jun 7 13:28:26 2016 ROUTER (trace) Node Router.A valid origins: ['Router.C']
+Tue Jun 7 13:28:26 2016 ROUTER (trace) Node Router.A cost: 1
+Tue Jun 7 13:28:27 2016 ROUTER (trace) Node Router.C valid origins: ['Router.A']
+----
+
+=== The `ROUTER_CORE` Logging Module
+
+This module provides information about the local router's operations on active connections and links. This includes operations related to opened and closed connections, messages sent, deliveries, and flow control.
+
+[options="nowrap"]
+----
+Tue Jun 7 13:42:07 2016 ROUTER_CORE (trace) Core action 'link_flow'
+Tue Jun 7 13:42:08 2016 ROUTER_CORE (trace) Core action 'link_deliver'
+Tue Jun 7 13:42:08 2016 ROUTER_CORE (trace) Core action 'send_to'
+Tue Jun 7 13:42:08 2016 ROUTER_CORE (trace) Core action 'link_flow'
+----
+
+=== The `ROUTER_HELLO` Logging Module
+
+This module provides information about the _Hello_ protocol used by interior routers to exchange Hello messages, which include information about the router's ID and a list of its reachable neighbors (the other routers with which this router has bidirectional connectivity).
+
+The logs for this module are helpful for monitoring or resolving issues in the network topology, and for determining to which other routers a router is connected, and the hop-cost for each of those connections.
+
+In this example, on `Router.A`, the `ROUTER_HELLO` log shows that it is connected to `Router.B`, and that `Router.B` is connected to `Router.A` and `Router.C`:
+
+[options="nowrap"]
+----
+Tue Jun 7 13:50:21 2016 ROUTER_HELLO (trace) RCVD: HELLO(id=Router.B area=0 inst=1465307413 seen=['Router.A', 'Router.C']) // <1>
+Tue Jun 7 13:50:21 2016 ROUTER_HELLO (trace) SENT: HELLO(id=Router.A area=0 inst=1465307416 seen=['Router.B']) // <2>
+Tue Jun 7 13:50:22 2016 ROUTER_HELLO (trace) RCVD: HELLO(id=Router.B area=0 inst=1465307413 seen=['Router.A', 'Router.C'])
+Tue Jun 7 13:50:22 2016 ROUTER_HELLO (trace) SENT: HELLO(id=Router.A area=0 inst=1465307416 seen=['Router.B'])
+----
+<1> `Router.A` received a Hello message from `Router.B`, which can see `Router.A` and `Router.C`.
+<2> `Router.A` sent a Hello message to `Router.B`, which is the only router it can see.
+
+On `Router.B`, the `ROUTER_HELLO` log shows the same router topology from a different perspective:
+
+[options="nowrap"]
+----
+Tue Jun 7 13:50:18 2016 ROUTER_HELLO (trace) SENT: HELLO(id=Router.B area=0 inst=1465307413 seen=['Router.A', 'Router.C']) // <1>
+Tue Jun 7 13:50:18 2016 ROUTER_HELLO (trace) RCVD: HELLO(id=Router.A area=0 inst=1465307416 seen=['Router.B']) // <2>
+Tue Jun 7 13:50:19 2016 ROUTER_HELLO (trace) RCVD: HELLO(id=Router.C area=0 inst=1465307411 seen=['Router.B']) // <3>
+----
+<1> `Router.B` sent a Hello message to `Router.A` and `Router.C`.
+<2> `Router.B` received a Hello message from `Router.A`, which can only see `Router.B`.
+<3> `Router.B` received a Hello message from `Router.C`, which can only see `Router.B`.
+
+=== The `ROUTER_LS` Logging Module
+
+This module provides information about link-state data between routers, including Router Advertisement (RA), Link State Request (LSR), and Link State Update (LSU) messages.
+
+Periodically, each router sends an LSR to the other routers and receives an LSU with the requested information. Exchanging the above information, each router can compute the next hops in the topology, and the related costs.
+
+This example shows the RA, LSR, and LSU messages sent between three routers:
+
+[options="nowrap"]
+----
+Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) SENT: LSR(id=Router.A area=0) to: Router.C //
+Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) SENT: LSR(id=Router.A area=0) to: Router.B //
+Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) SENT: RA(id=Router.A area=0 inst=1465308600 ls_seq=1 mobile_seq=1) // <1>
+Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) RCVD: LSU(id=Router.B area=0 inst=1465308595 ls_seq=2 ls=LS(id=Router.B area=0 ls_seq=2 peers={'Router.A': 1L, 'Router.C': 1L})) // <2>
+Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) RCVD: LSR(id=Router.B area=0)
+Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) SENT: LSU(id=Router.A area=0 inst=1465308600 ls_seq=1 ls=LS(id=Router.A area=0 ls_seq=1 peers={'Router.B': 1}))
+Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) RCVD: RA(id=Router.C area=0 inst=1465308592 ls_seq=1 mobile_seq=0)
+Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) SENT: LSR(id=Router.A area=0) to: Router.C
+Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) RCVD: LSR(id=Router.C area=0) // <3>
+Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) SENT: LSU(id=Router.A area=0 // inst=1465308600 ls_seq=1 ls=LS(id=Router.A area=0 ls_seq=1 peers={'Router.B': 1}))
+Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) RCVD: LSU(id=Router.C area=0 inst=1465308592 ls_seq=1 ls=LS(id=Router.C area=0 ls_seq=1 peers={'Router.B': 1L})) // <4>
+Tue Jun 7 14:10:03 2016 ROUTER_LS (trace) Computed next hops: {'Router.C': 'Router.B', 'Router.B': 'Router.B'} // <5>
+Tue Jun 7 14:10:03 2016 ROUTER_LS (trace) Computed costs: {'Router.C': 2L, 'Router.B': 1}
+Tue Jun 7 14:10:03 2016 ROUTER_LS (trace) Computed valid origins: {'Router.C': [], 'Router.B': []}
+----
+<1> `Router.A` sent LSR requests and an RA advertisement to the other routers on the network.
+<2> `Router.A` received an LSU from `Router.B`, which has two peers: `Router.A`, and `Router.C` (with a cost of `1`).
+<3> `Router.A` received an LSR from both `Router.B` and `Router.C`, and replied with an LSU.
+<4> `Router.A` received an LSU from `Router.C`, which only has one peer: `Router.B` (with a cost of `1`).
+<5> After the LSR and LSU messages are exchanged, `Router.A` computed the router topology with the related costs.
+
+=== The `ROUTER_MA` Logging Module
+
+This module provides information about the exchange of mobile address information between routers, including Mobile Address Request (MAR) and Mobile Address Update (MAU) messages exchanged between routers. You can use this log to monitor the state of mobile addresses attached to each router.
+
+This example shows the MAR and MAU messages sent between three routers:
+
+[options="nowrap"]
+----
+Tue Jun 7 14:27:20 2016 ROUTER_MA (trace) SENT: MAU(id=Router.A area=0 mobile_seq=1 add=['Cmy_queue', 'Dmy_queue', 'M0my_queue_wp'] del=[]) // <1>
+Tue Jun 7 14:27:21 2016 ROUTER_MA (trace) RCVD: MAR(id=Router.C area=0 have_seq=0) // <2>
+Tue Jun 7 14:27:21 2016 ROUTER_MA (trace) SENT: MAU(id=Router.A area=0 mobile_seq=1 add=['Cmy_queue', 'Dmy_queue', 'M0my_queue_wp'] del=[])
+Tue Jun 7 14:27:22 2016 ROUTER_MA (trace) RCVD: MAR(id=Router.B area=0 have_seq=0) // <3>
+Tue Jun 7 14:27:22 2016 ROUTER_MA (trace) SENT: MAU(id=Router.A area=0 mobile_seq=1 add=['Cmy_queue', 'Dmy_queue', 'M0my_queue_wp'] del=[])
+Tue Jun 7 14:27:39 2016 ROUTER_MA (trace) RCVD: MAU(id=Router.C area=0 mobile_seq=1 add=['M0my_test'] del=[]) // <4>
+Tue Jun 7 14:27:51 2016 ROUTER_MA (trace) RCVD: MAU(id=Router.C area=0 mobile_seq=2 add=[] del=['M0my_test']) // <5>
+----
+<1> `Router.A` sent MAU messages to the other routers in the network to notify them about the addresses added for `my_queue` and `my_queue_wp`.
+<2> `Router.A` received a MAR message in response from `Router.C`.
+<3> `Router.A` received another MAR message in response from `Router.B`.
+<4> `Router.C` sent a MAU message to notify the other routers that it added and address for `my_test`.
+<5> `Router.C` sent another MAU message to notify the other routers that it deleted the address for `my_test` (because the receiver is detached).
+
+=== The `MESSAGE` Logging Module
+
+This module provides information about AMQP messages sent and received by the router, including information about the address, body, and link. You can use this log to find high-level information about messages on a particular router.
+
+In this example, `Router.A` has sent and received some messages related to the Hello protocol, and sent and received some other messages on a link for a mobile address:
+
+[options="nowrap"]
+----
+Tue Jun 7 14:36:54 2016 MESSAGE (trace) Sending Message{to='amqp:/_topo/0/Router.B/qdrouter' body='\d1\00\00\00\1b\00\00\00\04\a1\02id\a1\08R'} on link qdlink.p9XmBm19uDqx50R
+Tue Jun 7 14:36:54 2016 MESSAGE (trace) Received Message{to='amqp:/_topo/0/Router.A/qdrouter' body='\d1\00\00\00\8e\00\00\00
+\a1\06ls_se'} on link qdlink.phMsJOq7YaFsGAG
+Tue Jun 7 14:36:54 2016 MESSAGE (trace) Received Message{ body='\d1\00\00\00\10\00\00\00\02\a1\08seque'} on link qdlink.FYHqBX+TtwXZHfV
+Tue Jun 7 14:36:54 2016 MESSAGE (trace) Sending Message{ body='\d1\00\00\00\10\00\00\00\02\a1\08seque'} on link qdlink.yU1tnPs5KbMlieM
+Tue Jun 7 14:36:54 2016 MESSAGE (trace) Sending Message{to='amqp:/_local/qdhello' body='\d1\00\00\00G\00\00\00\08\a1\04seen\d0'} on link qdlink.p9XmBm19uDqx50R
+Tue Jun 7 14:36:54 2016 MESSAGE (trace) Sending Message{to='amqp:/_topo/0/Router.C/qdrouter' body='\d1\00\00\00\1b\00\00\00\04\a1\02id\a1\08R'} on link qdlink.p9XmBm19uDqx50R
+----
+
+=== The `SERVER` Logging Module
+
+This module provides information about how the router is listening for and connecting to other containers in the network (such as clients, routers, and brokers). This includes the state of AMQP messages sent and received by the broker (open, begin, attach, transfer, flow, and so on), and the related content of those messages.
+
+For example, this log shows details about how the router handled a link attachment:
+
+[options="nowrap"]
+----
+Tue Jun 7 14:39:52 2016 SERVER (trace) [2]: <- AMQP
+Tue Jun 7 14:39:52 2016 SERVER (trace) [1]: <- AMQP
+Tue Jun 7 14:39:52 2016 SERVER (trace) [1]:0 <- @open(16) [container-id="Router.B", max-frame-size=16384, channel-max=32767, idle-time-out=8000, offered-capabilities=:"ANONYMOUS-RELAY", properties={:product="qpid-dispatch-router", :version="0.6.0"}]
+Tue Jun 7 14:39:52 2016 SERVER (trace) [1]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=15, outgoing-window=2147483647]
+Tue Jun 7 14:39:52 2016 SERVER (trace) [1]:RAW: "\x00\x00\x00\x1e\x02\x00\x00\x00\x00S\x11\xd0\x00\x00\x00\x0e\x00\x00\x00\x04@R\x00R\x0fp\x7f\xff\xff\xff"
+Tue Jun 7 14:39:52 2016 SERVER (trace) [1]:1 -> @begin(17) [next-outgoing-id=0, incoming-window=15, outgoing-window=2147483647]
+Tue Jun 7 14:39:52 2016 SERVER (trace) [1]:RAW: "\x00\x00\x00\x1e\x02\x00\x00\x01\x00S\x11\xd0\x00\x00\x00\x0e\x00\x00\x00\x04@R\x00R\x0fp\x7f\xff\xff\xff"
+Tue Jun 7 14:39:52 2016 SERVER (trace) [1]:0 -> @attach(18) [name="qdlink.uSSeXPSfTHhxo8d", handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=false, capabilities=:"qd.router"], target=@target(41) [durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=false, capabilities=:"qd.router"], initial-delivery-count=0]
+Tue Jun 7 14:39:52 2016 SERVER (trace) [1]:RAW: "\x00\x00\x00\x91\x02\x00\x00\x00\x00S\x12\xd0\x00\x00\x00\x81\x00\x00\x00\x0a\xa1\x16qdlink.uSSeXPSfTHhxo8dR\x00AP\x02P\x00\x00S(\xd0\x00\x00\x00'\x00\x00\x00\x0b@R\x00\xa3\x0blink-detachR\x00B@@@@@\xa3\x09qd.router\x00S)\xd0\x00\x00\x00#\x00\x00\x00\x07@R\x00\xa3\x0blink-detachR\x00B@\xa3\x09qd.router@@R\x00"
+----
+
+=== The `AGENT` Logging Module
+
+This module provides information about configuration changes made to the router from either editing the router's configuration file or using `qdmanage`.
+
+In this example, on `Router.A`, `address`, `linkRoute`, and `autoLink` entities were added to the router's configuration file. When the router was started, the `AGENT` module applied these changes, and they are now viewable in the log:
+
+[options="nowrap"]
+----
+Tue Jun 7 15:07:32 2016 AGENT (debug) Add entity: ConnectorEntity(addr=127.0.0.1, allowRedirect=True, cost=1, host=127.0.0.1, identity=connector/127.0.0.1:5672:BROKER, idleTimeoutSeconds=16, maxFrameSize=65536, name=BROKER, port=5672, role=route-container, stripAnnotations=both, type=org.apache.qpid.dispatch.connector, verifyHostname=True)
+Tue Jun 7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigAddressEntity(distribution=closest, identity=router.config.address/0, name=router.config.address/0, prefix=my_address, type=org.apache.qpid.dispatch.router.config.address, waypoint=False)
+Tue Jun 7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigAddressEntity(distribution=balanced, identity=router.config.address/1, name=router.config.address/1, prefix=my_queue_wp, type=org.apache.qpid.dispatch.router.config.address, waypoint=True)
+Tue Jun 7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigLinkrouteEntity(connection=BROKER, direction=in, distribution=linkBalanced, identity=router.config.linkRoute/0, name=router.config.linkRoute/0, prefix=my_queue, type=org.apache.qpid.dispatch.router.config.linkRoute)
+Tue Jun 7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigLinkrouteEntity(connection=BROKER, direction=out, distribution=linkBalanced, identity=router.config.linkRoute/1, name=router.config.linkRoute/1, prefix=my_queue, type=org.apache.qpid.dispatch.router.config.linkRoute)
+Tue Jun 7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigAutolinkEntity(addr=my_queue_wp, connection=BROKER, direction=in, identity=router.config.autoLink/0, name=router.config.autoLink/0, type=org.apache.qpid.dispatch.router.config.autoLink)
+Tue Jun 7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigAutolinkEntity(addr=my_queue_wp, connection=BROKER, direction=out, identity=router.config.autoLink/1, name=router.config.autoLink/1, type=org.apache.qpid.dispatch.router.config.autoLink)
+----
+
+=== The `CONTAINER` Logging Module
+
+This module provides information about the nodes related to the router. This includes only the AMQP relay node.
+
+[options="nowrap"]
+----
+Tue Jun 7 14:46:18 2016 CONTAINER (trace) Container Initialized
+Tue Jun 7 14:46:18 2016 CONTAINER (trace) Node Type Registered - router
+Tue Jun 7 14:46:18 2016 CONTAINER (trace) Node of type 'router' installed as default node
+----
+
+=== The `ERROR` Logging Module
+
+This module provides detailed information about error conditions encountered during execution.
+
+In this example, `Router.A` failed to start when an incorrect path was specified for the router's configuration file:
+
+[options="nowrap"]
+----
+$ sudo qdrouterd --conf xxx
+Wed Jun 15 09:53:28 2016 ERROR (error) Python: Exception: Cannot load configuration file xxx: [Errno 2] No such file or directory: 'xxx'
+Wed Jun 15 09:53:28 2016 ERROR (error) Traceback (most recent call last):
+ File "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py", line 155, in configure_dispatch
+ config = Config(filename)
+ File "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py", line 41, in __init__
+ self.load(filename, raw_json)
+ File "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py", line 123, in load
+ with open(source) as f:
+Exception: Cannot load configuration file xxx: [Errno 2] No such file or directory: 'xxx'
+
+Wed Jun 15 09:53:28 2016 MAIN (critical) Router start-up failed: Python: Exception: Cannot load configuration file xxx: [Errno 2] No such file or directory: 'xxx'
+qdrouterd: Python: Exception: Cannot load configuration file xxx: [Errno 2] No such file or directory: 'xxx'
+----
+
+=== The `POLICY` Logging Module
+
+This module provides information about policies that have been configured for the router.
+
+In this example, `Router.A` has no limits on maximum connections, and the default application policy is disabled:
+
+[options="nowrap"]
+----
+Tue Jun 7 15:07:32 2016 POLICY (info) Policy configured maximumConnections: 0, policyFolder: '', access rules enabled: 'false'
+Tue Jun 7 15:07:32 2016 POLICY (info) Policy fallback defaultApplication is disabled
+----
+
+[id='configure-default-logging']
+== Configuring Logging
+
+You can specify the types of events that should be logged, the format of the log entries, and where those entries should be sent.
+
+.Procedure
+
+. In the router's configuration file, add a `log` section to set the default logging properties:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+log {
+ module: DEFAULT
+ enable: _LOGGING_LEVEL_
+ includeTimestamp: yes
+ ...
+}
+----
+
+`module`:: Specify `DEFAULT`.
+`enable`:: The logging level. You can specify any of the following levels (from lowest to highest):
++
+//tag::logging-levels[]
+* `trace` - provides the most information, but significantly affects system performance
+* `debug` - useful for debugging, but affects system performance
+* `info` - provides general information without affecting system performance
+* `notice` - provides general information, but is less verbose than `info`
+* `warning` - provides information about issues you should be aware of, but which are not errors
+* `error` - error conditions that you should address
+* `critical` - critical system issues that you must address immediately
+
++
+To specify multiple levels, use a comma-separated list. You can also use `+` to specify a level and all levels above it. For example, `trace,debug,warning+` enables trace, debug, warning, error, and critical levels. For default logging, you should typically use the `info+` or `notice+` level. These levels will provide general information, warnings, and errors for all modules without affecting the performance of {RouterName}.
+//end::logging-levels[]
+`includeTimestamp`:: Set this to `yes` to include the timestamp in all logs.
+
+For information about additional log attributes, see link:{qdrouterdConfManPageUrl}#_log[log] in the `qdrouterd.conf` man page.
+--
+
+. Add an additional `log` section for each logging module that should not follow the default logging configuration:
++
+--
+
+[options="nowrap",subs="+quotes"]
+----
+log {
+ module: _MODULE_NAME_
+ enable: _LOGGING_LEVEL_
+ ...
+}
+----
+
+`module`:: The name of the module for which you are configuring logging. For a list of valid modules, see xref:logging-modules-you-can-configure[].
+`enable`:: The logging level. You can specify any of the following levels (from lowest to highest):
++
+include::logging.adoc[tags=logging-levels]
+
+For information about additional log attributes, see link:{qdrouterdConfManPageUrl}#_log[log] in the `qdrouterd.conf` man page.
+--
+
+== Viewing Log Entries
+
+You may need to view log entries to diagnose errors, performance problems, and other important issues. A log entry consists of an optional timestamp, the logging module, the logging level, and the log message.
+
+=== Viewing Log Entries on the Console
+
+By default, log entries are logged to the console, and you can view them there. However, if the `output` attribute is set for a particular logging module, then you can find those log entries in the specified location (`stderr`, `syslog`, or a file).
+
+=== Viewing Log Entries on the CLI
+
+You can use the `qdstat` tool to view a list of recent log entries.
+
+.Procedure
+
+* Use the *`qdstat --log`* command to view recent log entries.
++
+--
+You can use the `--limit` parameter to limit the number of log entries that are displayed. For more information about `qdstat`, see {qdstatManPageLink}.
+
+This example displays the last three log entries for `Router.A`:
+
+[options="nowrap",subs="+quotes"]
+----
+$ qdstat --log --limit=3 -r ROUTER.A
+Wed Jun 7 17:49:32 2017 ROUTER_CORE (none) Core action 'link_deliver'
+Wed Jun 7 17:49:32 2017 ROUTER_CORE (none) Core action 'send_to'
+Wed Jun 7 17:49:32 2017 SERVER (none) [2]:0 -> @flow(19) [next-incoming-id=1, incoming-window=61, next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=1, link-credit=250, drain=false]
+----
+--
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/management-entities.adoc
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/management-entities.adoc b/docs/books/user-guide/management-entities.adoc
new file mode 100644
index 0000000..3f677e3
--- /dev/null
+++ b/docs/books/user-guide/management-entities.adoc
@@ -0,0 +1,24 @@
+////
+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
+////
+
+= Management Entities
+
+The {RouterName} management schema provides a set of management entities that you can use to configure and operate a router.
+
+For details about the management entities, see {ManagementEntitiesLink}.
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/management.adoc
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/management.adoc b/docs/books/user-guide/management.adoc
new file mode 100644
index 0000000..fa933de
--- /dev/null
+++ b/docs/books/user-guide/management.adoc
@@ -0,0 +1,38 @@
+////
+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
+////
+
+= Management
+
+You can manage {RouterName} using both graphical and command-line tools.
+
+{ConsoleName}:: A graphical tool for monitoring and managing {RouterName} routers.
+`qdstat`:: A command-line tool for monitoring the status of {RouterName} routers.
+`qdmanage`:: A command-line tool for viewing and updating the configuration of {RouterName} routers.
+
+// Using the Console
+include::using-console.adoc[leveloffset=+1]
+
+// Monitoring Using qdstat
+include::monitoring-using-qdstat.adoc[leveloffset=+1]
+
+// Managing Using qdmanage
+include::managing-using-qdmanage.adoc[leveloffset=+1]
+
+// Management Entities
+include::management-entities.adoc[leveloffset=+1]
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/managing-using-qdmanage.adoc
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/managing-using-qdmanage.adoc b/docs/books/user-guide/managing-using-qdmanage.adoc
new file mode 100644
index 0000000..b22bd6d
--- /dev/null
+++ b/docs/books/user-guide/managing-using-qdmanage.adoc
@@ -0,0 +1,679 @@
+////
+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
+////
+
+[id='managing-router']
+= Managing {RouterName} Using `qdmanage`
+
+You can use `qdmanage` to view and modify the configuration of a running router at runtime. Specifically, `qdmanage` enables you to create, read, update, and delete the sections and attributes in the router's configuration file without having to restart the router.
+
+[NOTE]
+====
+The `qdmanage` tool implements the AMQP management specification, which means that you can use it with any standard AMQP-managed endpoint, not just with {RouterName}.
+====
+
+== Syntax for Using `qdmanage`
+
+You can use `qdmanage` with the following syntax:
+
+[options="nowrap",subs="+quotes"]
+----
+$ qdmanage [__CONNECTION_OPTIONS__] __OPERATION__ [__OPTIONS__]
+----
+
+This specifies:
+
+* One or more optional `connection_options` to specify the router on which to perform the operation, or to supply security credentials if the router only accepts secure connections.
++
+If you do not specify any connection options, `qdmanage` connects to the router listening on localhost and the default AMQP port (5672).
+* The `operation` to perform on the router.
+* One or more optional `options` to specify a configuration entity on which to perform the operation or how to format the command output.
+
+When you enter a `qdmanage` command, it is executed as an AMQP management operation request, and then the response is returned as command output in JSON format.
+
+For example, the following command executes a query operation on a router, and then returns the response in JSON format:
+
+[options="nowrap"]
+----
+$ qdmanage query --type listener
+[
+ {
+ "stripAnnotations": "both",
+ "addr": "127.0.0.1",
+ "multiTenant": false,
+ "requireSsl": false,
+ "idleTimeoutSeconds": 16,
+ "saslMechanisms": "ANONYMOUS",
+ "maxFrameSize": 16384,
+ "requireEncryption": false,
+ "host": "0.0.0.0",
+ "cost": 1,
+ "role": "normal",
+ "http": false,
+ "maxSessions": 32768,
+ "authenticatePeer": false,
+ "type": "org.apache.qpid.dispatch.listener",
+ "port": "amqp",
+ "identity": "listener/0.0.0.0:amqp",
+ "name": "listener/0.0.0.0:amqp"
+ }
+]
+----
+
+For more information about `qdmanage`, see the {qdmanageManPageLink}.
+
+== Managing Network Connections
+
+You can use `qdmanage` to view, create, update, and delete listeners and connectors for any router in your router network.
+
+=== Managing Listeners
+
+Listeners define how clients can connect to a router. The following table lists the `qdmanage` commands you can use to perform common operations on listeners.
+
+For more information about the attributes you can use with these commands, see link:{qdrouterdConfManPageUrl}#_listener[listener] in the `qdrouterd.conf` man page.
+
+//tag::qdmanage-connection-options-note[]
+[NOTE]
+====
+The commands in this table demonstrate operations on the local router listening on localhost and the default AMQP port (5672). If you want to perform an operation on a different router in the router network, you must specify the necessary connection options. For more information, see link:{qdmanageManPageUrl}#_connection_options[Connection Options] in the qdmanage man page.
+====
+//end::qdmanage-connection-options-note[]
+
+[cols="30,70"]
+|===
+| To... | Use this command...
+
+|View the router’s listeners
+a|
+[options="nowrap"]
+----
+qdmanage query --type=listener
+----
+
+|View the roles and ports on which the router is listening
+a|
+[options="nowrap"]
+----
+qdmanage query role port --type=listener
+----
+
+|View the attributes configured for a listener
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage read --name=_LISTENER_NAME_
+----
+
+|Create a listener
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage create --type=listener --_ATTRIBUTE_=_VALUE_ ...
+----
+
+|Create multiple listeners
+a|
+. Enter this command:
++
+[options="nowrap"]
+----
+qdmanage create --stdin
+----
+. Configure the listeners using a JSON map:
++
+[options="nowrap",subs="+quotes"]
+----
+[{"type"="listener", "_ATTRIBUTE_":"_VALUE_"...}, {"type"="listener", "_ATTRIBUTE_":"_VALUE_"...}...]
+----
+
+These commands use a JSON map to create two listeners.
+
+|Update a listener
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage update --type=listener --_ATTRIBUTE_=_VALUE_ ...
+----
+
+|Update multiple listeners
+a|
+. Enter this command:
++
+[options="nowrap"]
+----
+qdmanage update --stdin
+----
+. Configure the listeners using a JSON map:
++
+[options="nowrap",subs="+quotes"]
+----
+[{"type"="listener", "_ATTRIBUTE_":"_VALUE_"...}, {"type"="listener", "_ATTRIBUTE_":"_VALUE_"...}...]
+----
+
+These commands use a JSON map to update two listeners.
+
+|Delete an attribute from a listener
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage update --type=listener --_ATTRIBUTE_
+----
+
+|Delete a listener
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage delete --name=_LISTENER_NAME_
+----
+
+|===
+
+[id='managing-connectors']
+=== Managing Connectors
+
+Connectors define how the router can connect to other endpoints in your messaging network, such as brokers and other routers. The following table lists the `qdmanage` commands you can use to perform common operations on connectors.
+
+For more information about the attributes you can use with these commands, see link:{qdrouterdConfManPageUrl}#_connector[connector] in the `qdrouterd.conf` man page.
+
+// Note about qdmanage connection options.
+include::managing-using-qdmanage.adoc[tags=qdmanage-connection-options-note]
+
+[cols="30,70"]
+|===
+| To... | Use this command...
+
+|View the router’s connectors
+a|
+[options="nowrap"]
+----
+qdmanage query --type=connector
+----
+
+|View the roles and ports on which the router can connect to other endpoints
+a|
+[options="nowrap"]
+----
+qdmanage query role port --type=connector
+----
+
+|If the router is connected to a broker, view the alternate URLs on which the router can connect to the broker if the primary connection fails
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage query failoverUrls --type=connector --name=CONNECTOR_NAME
+----
+
+|View the attributes configured for a connector
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage read --name=_CONNECTOR_NAME_
+----
+
+|Create a connector
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage create --type=connector --_ATTRIBUTE_=_VALUE_ ...
+----
+
+|Create multiple connectors
+a|
+. Enter this command:
++
+[options="nowrap"]
+----
+qdmanage create --stdin
+----
+. Configure the connectors using a JSON map:
++
+[options="nowrap",subs="+quotes"]
+----
+[{"type"="connector", "_ATTRIBUTE_":"_VALUE_"...}, {"type"="connector", "_ATTRIBUTE_":"_VALUE_"...}...]
+----
+
+These commands use a JSON map to create two connectors.
+
+|Update a connector
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage update --type=connector --_ATTRIBUTE_=_VALUE_ ...
+----
+
+|Update multiple connectors
+a|
+. Enter this command:
++
+[options="nowrap"]
+----
+qdmanage update --stdin
+----
+. Configure the connectors using a JSON map:
++
+[options="nowrap",subs="+quotes"]
+----
+[{"type"="connector", "_ATTRIBUTE_":"_VALUE_"...}, {"type"="connector", "_ATTRIBUTE_":"_VALUE_"...}...]
+----
+
+These commands use a JSON map to update two connectors.
+
+|Delete an attribute from a connector
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage update --type=connector --_ATTRIBUTE_
+----
+
+|Delete a connector
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage delete --name=_CONNECTOR_NAME_
+----
+
+|===
+
+== Managing Security
+
+{RouterName} supports both SSL/TLS and SASL security protocols for encrypting and authenticating incoming and outgoing connections for your routers. You can use `qdmanage` to view, create, update, and delete security policies for any router in your router network.
+
+=== Managing SSL/TLS Encryption and Authentication
+
+{RouterName} supports SSL/TLS for certificate-level encryption and mutual authentication. The following table lists the common `qdmanage` commands you can use to secure incoming and outgoing connections for a router in your router network.
+
+For more information about the attributes you can use with these commands, see link:{qdrouterdConfManPageUrl}#_sslprofile[sslProfile] and link:{qdrouterdConfManPageUrl}#_listener[listener] in the `qdrouterd.conf` man page.
+
+// Note about qdmanage connection options.
+include::managing-using-qdmanage.adoc[tags=qdmanage-connection-options-note]
+
+[cols="30,70"]
+|===
+| To... | Use this command...
+
+|View the router’s SSL configuration
+a|
+[options="nowrap"]
+----
+qdmanage query --type=sslProfile
+----
+
+|Set up SSL for the router
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage create --type=sslProfile --name=_NAME_ --certDB=_PATH_ --certFile=_PATH_ --privateKeyFile=_PATH_ --_ATTRIBUTE_=_VALUE_ ...
+----
+
+|Add SSL/TLS encryption to an incoming connection
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage update --name=_LISTENER_NAME_ --sslProfile=_NAME_ --requireSsl=yes
+----
+
+|Change SSL/TLS encryption on an incoming connection
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage update --name=_LISTENER_NAME_ --_ATTRIBUTE_=_VALUE_ ...
+----
+
+|Add SSL/TLS client authentication to an incoming connection
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage update --name=_LISTENER_NAME_ --authenticatePeer=yes
+----
+
+|Remove SSL/TLS client authentication from an incoming connection
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage update --name=_LISTENER_NAME_ --authenticatePeer=no
+----
+
+|Add SSL/TLS client authentication to an outgoing connection
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage update --name=_CONNECTOR_NAME_ --sslProfile=_NAME_
+----
+
+|Remove SSL/TLS client authentication from an outgoing connection
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage update --name=_CONNECTOR_NAME_ --sslProfile
+----
+
+|Delete an SSL profile
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage delete --name=_SSL_PROFILE_NAME_
+----
+
+|===
+
+=== Managing SASL Encryption and Authentication
+
+{RouterName} supports SASL for authentication and payload encryption. The following table lists the common `qdmanage` commands you can use to secure incoming and outgoing connections for a router in your router network.
+
+For more information about the attributes you can use with these commands, see link:{qdrouterdConfManPageUrl}#_router[router] and link:{qdrouterdConfManPageUrl}#_listener[listener] in the `qdrouterd.conf` man page.
+
+// Note about qdmanage connection options.
+include::managing-using-qdmanage.adoc[tags=qdmanage-connection-options-note]
+
+[cols="30,70"]
+|===
+| To... | Use this command...
+
+|Set up SASL for the router
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage update --type=router --saslConfigDir=_PATH_ --saslConfigName=_NAME_
+----
+
+|Add SASL authentication to an incoming connection
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage update --name=_LISTENER_NAME_ --authenticatePeer=yes --saslMechanisms=_MECHANISMS_
+----
+
+|Change SASL mechanisms for an incoming connection
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage update --name=_LISTENER_NAME_ --saslMechanisms=_MECHANISMS_
+----
+
+|Add SASL authentication to an outgoing connection
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage update --name=_CONNECTOR_NAME_ --saslMechanisms=_MECHANISMS_ --saslUsername=_USERNAME_ --saslPassword=_PASSWORD_
+----
+
+|Change SASL mechanisms for an outgoing connection
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage update --name=_CONNECTOR_NAME_ --saslMechanisms=_MECHANISMS_
+----
+
+|Add SASL payload encryption to an incoming connection
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage update --name=_LISTENER_NAME_ --requireEncryption=yes --saslMechanisms=_MECHANISMS_
+----
+
+|Change SASL mechanisms for an incoming connection
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage update --name=_LISTENER_NAME_ --saslMechanisms=_MECHANISMS_
+----
+
+|Remove SASL payload encryption from an incoming connection
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage update --name=_LISTENER_NAME_ --requireEncryption=no --saslMechanisms
+----
+
+|Delete a SASL configuration
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage update --type=router --saslConfigDir --saslConfigName
+----
+
+|===
+
+== Managing Routing
+
+{RouterName} supports both message routing and link routing for distributing messages between senders and receivers. You can use `qdmanage` to view how addresses and link routes are configured in your environment, and define how a router should distribute messages.
+
+=== Managing Message Routing
+
+Message routing involves configuring addresses to define how {RouterName} should distribute messages. The following table lists the common `qdmanage` commands you can use to configure addresses for a router in your router network.
+
+For more information about the attributes you can use with these commands, see link:{qdrouterdConfManPageUrl}#_address[address] and link:{qdrouterdConfManPageUrl}#_autolink[autolink] in the `qdrouterd.conf` man page.
+
+// Note about qdmanage connection options.
+include::managing-using-qdmanage.adoc[tags=qdmanage-connection-options-note]
+
+[cols="30,70"]
+|===
+| To... | Use this command...
+
+|View addresses
+a|
+[options="nowrap"]
+----
+qdmanage query --type=address
+----
+
+[options="nowrap",subs="+quotes"]
+----
+qdmanage read --name=_ADDRESS_NAME_
+----
+
+|View address distribution patterns
+a|
+[options="nowrap"]
+----
+qdmanage query prefix distribution --type=address
+----
+
+|View waypoints to broker queues
+a|
+[options="nowrap"]
+----
+qdmanage query prefix --type=address --waypoint=yes
+----
+
+|View autolinks
+a|
+[options="nowrap"]
+----
+qdmanage query --type=autolink
+----
+
+|Set a distribution pattern for an address
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage create --type=address --prefix=_ADDRESS_PREFIX_ --distribution=_DISTRIBUTION_PATTERN_ ...
+----
+
+|Set distribution patterns for multiple addresses
+a|
+. Enter this command:
++
+[options="nowrap",subs="+quotes"]
+----
+qdmanage create --stdin
+----
+
+. Configure the addresses using a JSON map:
++
+[options="nowrap",subs="+quotes"]
+----
+[{"type":"address", "prefix":"_ADDRESS_PREFIX_", "distribution":"_DISTRIBUTION_PATTERN_", "_ATTRIBUTE_":"_VALUE_", ...}, {"type":"address", "prefix":"_ADDRESS_PREFIX_", "distribution":"_DISTRIBUTION_PATTERN_", "_ATTRIBUTE_":"_VALUE_", ...} ...]
+----
+
+These commands configure two addresses.
+
+|Connect an address to a broker queue
+a|
+. Enter this command:
++
+[options="nowrap"]
+----
+qdmanage create --stdin
+----
+
+. Create an address waypoint, an incoming autolink, and an outgoing autolink:
++
+[options="nowrap",subs="+quotes"]
+----
+[{"type":"address", "prefix":"_ADDRESS_PREFIX_", "waypoint":"yes"}, {"type":"autolink", "addr":"_ADDRESS_NAME_", "connection":"_CONNECTOR/LISTENER_NAME_", "direction":"in"}, {"type":"autolink", "addr":"_ADDRESS_NAME_", "connection":"_CONNECTOR/LISTENER_NAME_", "direction":"out"}]
+----
+
+|Update an address configuration
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage update --name=_ADDRESS_NAME_ --_ATTRIBUTE_=_VALUE_ ...
+----
+
+|Update an autolink
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage update --name=_AUTOLINK_NAME_ --_ATTRIBUTE_=_VALUE_ ...
+----
+
+|Delete an address configuration
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage delete --name=_ADDRESS_NAME_
+----
+
+|Delete an autolink
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage delete --name=_AUTOLINK_NAME_
+----
+
+|===
+
+=== Managing Link Routing
+
+A link route is a chain of links between a sender and receiver that provides a private messaging path. The following table lists the common `qdmanage` commands you can use to view, create, update, and delete link routes.
+
+For more information about the attributes you can use with these commands, see the link:{qdrouterdConfManPageUrl}#_linkroute[linkRoute] in the `qdrouterd.conf` man page.
+
+// Note about qdmanage connection options.
+include::managing-using-qdmanage.adoc[tags=qdmanage-connection-options-note]
+
+[cols="30,70"]
+|===
+| To... | Use this command...
+
+|View link routes
+a|
+[options="nowrap"]
+----
+qdmanage query --type=linkRoute
+----
+
+[options="nowrap",subs="+quotes"]
+----
+qdmanage read --name=_LINK_ROUTE_NAME_
+----
+
+|Create a link route
+a|
+. Enter this command:
++
+[options="nowrap"]
+----
+qdmanage create --stdin
+----
+
+. Create an incoming and outgoing link route:
++
+[options="nowrap",subs="+quotes"]
+----
+[{"type":"linkRoute", "prefix":"_ADDRESS_PREFIX_", "connection":"_CONNECTOR/LISTENER_NAME_", "direction":"in", ...}, {"type":"linkRoute", "prefix":"_ADDRESS_PREFIX_", "connection":"_CONNECTOR/LISTENER_NAME_", "direction":"out", ...}]
+----
+
+|Update a link route
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage update --name=_LINK_ROUTE_NAME_ --_ATTRIBUTE_=_VALUE_ ...
+----
+
+|Delete a link route
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage delete --name=_INCOMING_LINK_ROUTE_NAME_
+qdmanage delete --name=_OUTGOING_LINK_ROUTE_NAME_
+----
+
+|===
+
+== Managing Logging
+
+{RouterName} logs are broken into different categories called logging modules. Each module provides important information about a particular aspect of a router. The following table lists the common `qdmanage` commands you can use to view and change the configuration of a logging module.
+
+For more information about the attributes you can use with these commands, see link:{qdrouterdConfManPageUrl}#_log[log] in the `qdrouterd.conf` man page.
+
+// Note about qdmanage connection options.
+include::managing-using-qdmanage.adoc[tags=qdmanage-connection-options-note]
+
+[cols="30,70"]
+|===
+| To... | Use this command...
+
+|View the logging configuration
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage query --type=log
+----
+
+|View the logging configuration for a logging module
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage read --type=log --module=_LOGGING_MODULE_NAME_
+----
+
+|Set the default logging configuration
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage create --type=log --module=DEFAULT --enable=_LOGGING_LEVEL_ --includeTimestamp=yes --_ATTRIBUTE_=_VALUE_
+----
+
+|Enable logging for a logging module
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage create --type=log --module=_LOGGING_MODULE_NAME_ --enable=_LOGGING_LEVEL_ --_ATTRIBUTE_=_VALUE_ ...
+----
+
+|Change the logging configuration for a logging module
+a|
+[options="nowrap",subs="+quotes"]
+----
+qdmanage update --type=log --module=_LOGGING_MODULE_NAME_ --_ATTRIBUTE_=_VALUE_ ...
+----
+
+|===
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/monitoring-using-qdstat.adoc
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/monitoring-using-qdstat.adoc b/docs/books/user-guide/monitoring-using-qdstat.adoc
new file mode 100644
index 0000000..c0b1c64
--- /dev/null
+++ b/docs/books/user-guide/monitoring-using-qdstat.adoc
@@ -0,0 +1,392 @@
+////
+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
+////
+
+[id='monitoring-using-qdstat']
+= Monitoring {RouterName} Using `qdstat`
+
+You can use `qdstat` to view the status of routers on your router network. For example, you can view information about the attached links and configured addresses, available connections, and nodes in the router network.
+
+== Syntax for Using `qdstat`
+
+You can use `qdstat` with the following syntax:
+
+[options="nowrap",subs="+quotes"]
+----
+$ qdstat __OPTION__ [__CONNECTION_OPTIONS__] [__SECURE_CONNECTION_OPTIONS__]
+----
+
+This specifies:
+
+* An `option` for the type of information to view.
+* One or more optional `connection_options` to specify a router for which to view the information.
++
+If you do not specify a connection option, `qdstat` connects to the router listening on localhost and the default AMQP port (5672).
+* The `secure_connection_options` if the router for which you want to view information only accepts secure connections.
+
+For more information about `qdstat`, see the {qdstatManPageLink}.
+
+== Viewing General Statistics for a Router
+
+You can view information about a router in the router network, such as its working mode and ID.
+
+.Procedure
+
+* Use the following command:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+$ qdstat -g [__CONNECTION_OPTIONS__]
+----
+
+This example shows general statistics for the local router:
+
+[options="nowrap"]
+----
+$ qdstat -g
+Router Statistics
+ attr value
+ =========================
+ Version 0.8.0
+ Mode standalone
+ Area 0
+ Router Id Router.A
+ Link Routes 0
+ Auto Links 0
+ Links 2
+ Nodes 0
+ Addresses 4
+ Connections 1
+----
+--
+
+== Viewing a List of Connections to a Router
+
+You can view:
+
+* Connections from clients (sender/receiver)
+* Connections from and to other routers in the network
+* Connections to other containers (such as brokers)
+* Connections from the tool itself
+
+.Procedure
+
+* Use this command:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+$ qdstat -c [__CONNECTION_OPTIONS__]
+----
+
+For more information about the fields displayed by this command, see link:{qdstatManPageUrl}#_qdstat_c[the qdstat -c output columns^].
+
+In this example, two clients are connected to `Router.A`. `Router.A` is connected to `Router.B` and a broker.
+
+Viewing the connections on Router.A displays the following:
+
+[options="nowrap"]
+----
+$ qdstat -c -r Router.A
+Connections
+id host container role dir security authentication tenant
+==================================================================================================================================
+ 2 127.0.0.1:5672 route-container out no-security anonymous-user // <1>
+ 10 127.0.0.1:5001 Router.B inter-router out no-security anonymous-user // <2>
+ 12 localhost.localdomain:42972 161211fe-ba9e-4726-9996-52d6962d1276 normal in no-security anonymous-user // <3>
+ 14 localhost.localdomain:42980 a35fcc78-63d9-4bed-b57c-053969c38fda normal in no-security anonymous-user // <3>
+ 15 localhost.localdomain:42982 0a03aa5b-7c45-4500-8b38-db81d01ce651 normal in no-security anonymous-user // <4>
+----
+<1> This connection shows that `Router.A` is connected to a broker, because the `role` is `route-container`, and the `dir` is `out`.
+<2> `Router.A` is also connected to another router on the network (the `role` is `inter-router`), establishing an output connection (the `dir` is `out`).
+<3> These connections show that two clients are connected to `Router.A`, because the `role` is `normal`, and the `dir` is `in`.
+<4> The connection from `qdstat` to `Router.A`. This is the connection that `qdstat` uses to query `Router.A` and display the command output.
+
+`Router.A` is connected to `Router.B`. Viewing the connections on `Router.B` displays the following:
+
+[options="nowrap"]
+----
+$ qdstat -c -r Router.B
+Connections
+id host container role dir security authentication tenant
+====================================================================================================
+ 1 localhost.localdomain:51848 Router.A inter-router in no-security anonymous-user // <1>
+----
+<1> This connection shows that `Router.B` is connected to `Router.A` through an incoming connection (the `role` is `inter-router` and the `dir` is `in`). There is not a connection from `qdstat` to `Router.B`, because the command was run from `Router.A` and forwarded to `Router.B`.
+--
+
+== Viewing AMQP Links Attached to a Router
+
+You can view a list of AMQP links attached to the router from clients (sender/receiver), from or to other routers into the network, to other containers (for example, brokers), and from the tool itself.
+
+.Procedure
+* Use this command:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+$ qdstat -l [__CONNECTION_OPTIONS__]
+----
+
+For more information about the fields displayed by this command, see link:{qdstatManPageUrl}#_qdstat_l[the qdstat -l output columns^].
+
+In this example, `Router.A` is connected to both `Router.B` and a broker. A link route is configured for the `my_queue` queue and waypoint (with autolinks), and for the `my_queue_wp` queue on the broker. In addition, there is a receiver connected to `my_address` (message routing based), another to `my_queue`, and the a third one to `my_queue_wp`.
+
+In this configuration, the router uses only one connection to the broker for both the waypoints (related to `my_queue_wp`) and the link route (related to `my_queue`).
+
+Viewing the links displays the following:
+
+[options="nowrap"]
+----
+$ qdstat -l
+Router Links
+ type dir conn id id peer class addr phs cap undel unsett del presett acc rej rel mod admin oper
+ ==============================================================================================================================================
+ router-control in 2 7 250 0 0 2876 0 0 0 0 0 enabled up // <1>
+ router-control out 2 8 local qdhello 250 0 0 2716 0 0 0 0 0 enabled up
+ inter-router in 2 9 250 0 0 1 0 0 0 0 0 enabled up
+ inter-router out 2 10 250 0 0 1 0 0 0 0 0 enabled up
+ endpoint in 1 11 mobile my_queue_wp 1 250 0 0 3 0 0 0 0 0 enabled up // <2>
+ endpoint out 1 12 mobile my_queue_wp 0 250 0 0 3 0 0 0 0 0 enabled up
+ endpoint out 4 15 mobile my_address 0 250 0 0 0 0 0 0 0 0 enabled up // <3>
+ endpoint out 6 18 19 250 0 0 1 0 0 0 0 0 enabled up // <4>
+ endpoint in 1 19 18 0 0 0 1 0 0 0 0 0 enabled up // <5>
+ endpoint out 19 40 mobile my_queue_wp 1 250 0 0 1 0 0 0 0 0 enabled up // <6>
+ endpoint in 24 48 mobile $management 0 250 0 0 1 0 0 0 0 0 enabled up
+ endpoint out 24 49 local temp.mx5HxzUe2Eddw_s 250 0 0 0 0 0 0 0 0 enabled up
+----
+<1> The `conn id` 2 connection has four links (in both directions) for inter-router communications with `Router.B`, such as control messages and normal message-routed deliveries.
+<2> There are two autolinks (`conn id 1`) for the waypoint for `my_queue_wp`. There is an incoming (`id 11`) and outgoing (`id 12`) link to the broker, and another `out` link (`id 40`) to the receiver.
+<3> A `mobile` link for `my_address`. The `dir` is `out` related to the receiver attached to it.
+<4> The `out` link from the router to the receiver for `my_queue`. This enables the router to deliver messages to the receiver.
+<5> The `in` link to the router for `my_queue`. This enables the router to get messages from `my_queue` so that they can be sent to the receiver on the `out` link.
+<6> The remaining links are related to the `$management` address and are used by `qdstat` to receive the information that is displayed by this command.
+--
+
+== Viewing Known Routers on a Network
+
+To see the topology of the router network, you can view known routers on the network.
+
+.Procedure
+
+* Use this command:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+$ qdstat -n [__CONNECTION_OPTIONS__]
+----
+
+For more information about the fields displayed by this command, see link:{qdstatManPageUrl}#_qdstat_n[the qdstat -n output columns^].
+
+In this example, `Router.A` is connected to `Router.B`, which is connected to `Router.C`. Viewing the router topology on `Router.A` shows the following:
+
+[options="nowrap"]
+----
+$ qdstat -n -r Router.A
+Routers in the Network
+ router-id next-hop link cost neighbors valid-origins
+ ==========================================================================
+ Router.A (self) - ['Router.B'] [] // <1>
+ Router.B - 0 1 ['Router.A', 'Router.C'] [] // <2>
+ Router.C Router.B - 2 ['Router.B'] [] // <3>
+----
+<1> `Router.A` has one neighbor: `Router.B`.
+<2> `Router.B` is connected to `Router.A` and `Router.C` over `link` 0. The `cost` for `Router.A` to reach `Router.B` is 1, because the two routers are connected directly.
+<3> `Router.C` is connected to `Router.B`, but not to `Router.A`. The `cost` for `Router.A` to reach `Router.C` is 2, because messages would have to pass through `Router.B` as the `next-hop`.
+
+`Router.B` shows a different view of the router topology:
+
+[options="nowrap"]
+----
+$ qdstat -n -v -r Router.B
+Routers in the Network
+ router-id next-hop link cost neighbors valid-origins
+ ==========================================================================
+ Router.A - 0 1 ['Router.B'] ['Router.C']
+ Router.B (self) - ['Router.A', 'Router.C'] []
+ Router.C - 1 1 ['Router.B'] ['Router.A']
+----
+
+The `neighbors` list is the same when viewed on `Router.B`. However, from the perspective of `Router.B`, the destinations on `Router.A` and `Router.C` both have a `cost` of `1`. This is because `Router.B` is connected to `Router.A` and `Router.C` through links.
+
+The `valid-origins` column shows that starting from `Router.C`, `Router.B` has the best path to reach `Router.A`. Likewise, starting from `Router.A`, `Router.B` has the best path to reach `Router.C`.
+
+Finally, `Router.C` shows the following details about the router topology:
+
+[options="nowrap"]
+----
+$ qdstat -n -v -r Router.C
+Routers in the Network
+ router-id next-hop link cost neighbors valid-origins
+ ==========================================================================
+ Router.A Router.B - 2 ['Router.B'] []
+ Router.B - 0 1 ['Router.A', 'Router.C'] []
+ Router.C (self) - ['Router.B'] []
+----
+
+Due to a symmetric topology, the `Router.C` perspective of the topology is very similar to the `Router.A` perspective. The primary difference is the `cost`: the cost to reach `Router.B` is `1`, because the two routers are connected. However, the cost to reach `Router.A` is `2`, because the messages would have to pass through `Router.B` as the `next-hop`.
+--
+
+== Viewing Addresses Known to a Router
+
+You can view message-routed and link-routed addresses known to a router.
+
+.Procedure
+
+* Use the following command:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+$ qdstat -a [__CONNECTION_OPTIONS__]
+----
+
+For more information about the fields displayed by this command, see link:{qdstatManPageUrl}#_qdstat_a[the qdstat -a output columns^].
+
+In this example, `Router.A` is connected to both `Router.B` and a broker. The broker has two queues:
+
+* `my_queue` (with a link route on `Router.A`)
+* `my_queue_wp` (with a waypoint and autolinks configured on `Router.A`)
+
+In addition, there are three receivers: one connected to `my_address` for message routing, another connected to `my_queue`, and the last one connected to `my_queue_wp`.
+
+Viewing the addresses displays the following information:
+
+[options="nowrap"]
+----
+$ 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 8 0 0 8 0
+ local $management closest 1 0 0 0 0 0 0 0 0
+ router Router.B closest 0 0 1 0 0 0 5 0 5 // <1>
+ mobile my_address 0 closest 0 1 0 0 1 1 0 0 0 // <2>
+ link-in my_queue linkBalanced 0 0 0 1 0 0 0 0 0 // <3>
+ link-out my_queue linkBalanced 0 0 0 1 0 0 0 0 0
+ mobile my_queue_wp 1 balanced 0 1 0 0 1 1 0 0 0 // <4>
+ mobile my_queue_wp 0 balanced 0 1 0 0 1 1 0 0 0
+ local qdhello flood 1 1 0 0 0 0 0 741 706 // <5>
+ local qdrouter flood 1 0 0 0 0 0 0 4 0
+ topo qdrouter flood 1 0 1 0 0 0 27 28 28
+ local qdrouter.ma multicast 1 0 0 0 0 0 0 1 0
+ topo qdrouter.ma multicast 1 0 1 0 0 0 2 0 3
+ local temp.IJSoXoY_lX0TiDE closest 0 1 0 0 0 0 0 0 0
+----
+<1> An address related to `Router.B` with a `remote` at 1. This is the consumer from `Router.B`.
+<2> The `my_address` address has one local consumer, which is related to the single receiver attached on that address. The `in` and `out` fields are both 1, which means that one message has traveled through this address using the `closest` distribution method.
+<3> The incoming link route for the `my_queue` address. This address has one locally-attached container (`cntnr`) as a destination (in this case, the broker). The following entry is the outgoing link for the same address.
+<4> The incoming autolink for the `my_queue_wp` address and configured waypoint. There is one local consumer (`local`) for the attached receiver. The following entry is the outgoing autolink for the same address. A single message has traveled through the autolinks.
+<5> The `qdhello`, `qdrouter`, and `qdrouter.ma` addresses are used to periodically update the network topology and deliver router control messages. These updates are made automatically through the inter-router protocol, and are based on all of the messages the routers have exchanged. In this case, the distribution method (`distrib`) for each address is either flood or multicast to ensure the control messages reach all of the routers in the network.
+--
+
+== Viewing a Router's Autolinks
+
+You can view a list of the autolinks that are associated with waypoint addresses for a node on another container (such as a broker).
+
+.Procedure
+
+* Use the following command:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+$ qdstat --autolinks [__CONNECTION_OPTIONS__]
+----
+
+For more information about the fields displayed by this command, see link:{qdstatManPageUrl}#_qdstat_autolinks[the qdstat --autolinks output columns^].
+
+In this example, a router is connected to a broker. The broker has a queue called `my_queue_wp`, to which the router is configured with a waypoint and autolinks. Viewing the autolinks displays the following:
+
+[options="nowrap"]
+----
+$ qdstat --autolinks
+AutoLinks
+ addr dir phs link status lastErr
+ ==============================================
+ my_queue_wp in 1 4 active // <1>
+ my_queue_wp out 0 5 active // <2>
+----
+<1> The incoming autolink from `my_queue_wp`. As indicated by the `status` field, the link is active, because the broker is running and the connection for the link is already established (as indicated by the `link` field).
+<2> The outgoing autlink to `my_queue_wp`. Like the incoming link, it is active and has an established connection.
+--
+
+== Viewing the Status of a Router's Link Routes
+
+You can view the status of each incoming and outgoing link route.
+
+.Procedure
+
+* Use the following command:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+$ qdstat --linkroutes [__CONNECTION_OPTIONS__]
+----
+
+For more information about the fields displayed by this command, see link:{qdstatManPageUrl}#_qdstat_linkroutes[the qdstat --linkroutes output columns^].
+
+In this example, a router is connected to a broker. The router is configured with a link route to the `my_queue` queue on the broker. Viewing the link routes displays the following:
+
+[options="nowrap"]
+----
+$ qdstat --linkroutes
+Link Routes
+ prefix dir distrib status
+ =====================================
+ my_queue in linkBalanced active // <1>
+ my_queue out linkBalanced active // <2>
+----
+<1> The incoming link route from `my_queue` to the router. This route is currently active, because the broker is running.
+<2> The outgoing link from the router to `my_queue`. This route is also currently active.
+--
+
+== Viewing Memory Consumption Information
+
+If you need to perform debugging or tracing for a router, you can view information about its memory consumption.
+
+.Procedure
+
+* Use the following command:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+$ qdstat -m [__CONNECTION_OPTIONS__]
+----
+
+This command displays information about allocated objects, their size, and their usage by application threads:
+
+[options="nowrap"]
+----
+$ qdstat -m
+Types
+ type size batch thread-max total in-threads rebal-in rebal-out
+ ===========================================================================================
+ qd_bitmask_t 24 64 128 64 64 0 0
+ qd_buffer_t 536 16 32 80 80 0 0
+ qd_composed_field_t 64 64 128 256 256 0 0
+ qd_composite_t 112 64 128 320 320 0 0
+ ...
+----
+--
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org
[04/11] qpid-dispatch git commit: DISPATCH-851: Move the new book
into primary position and reorg the docs
Posted by jr...@apache.org.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/configuration-reference.adoc
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/configuration-reference.adoc b/docs/books/user-guide/configuration-reference.adoc
new file mode 100644
index 0000000..9ea6a12
--- /dev/null
+++ b/docs/books/user-guide/configuration-reference.adoc
@@ -0,0 +1,225 @@
+////
+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
+////
+
+[id='router-configuration-reference']
+
+// This config reference could stand to be cleaned up. Also, some of the introductory content is no longer necessary since it's covered in the introductory chapter about configuration. We should just link to it instead of repeating it here.
+
+= Configuration Reference
+
+The {RouterName} component behavior is totally configurable using a configuration file which can be passed as parameter (with the `--conf` option) on the command line when running it. After installation, a default configuration file is placed at the following path :
+
+[options="nowrap"]
+----
+[install-prefix]/etc/qpid-dispatch/qdrouterd.conf
+----
+
+This file is used when the router is started without specify configuration file path on the command line and when it is started as a service. In case of starting router on the command line the configuration file can be placed anywhere on the file system.
+
+== Configuration File
+
+The configuration file is made up of sections with following syntax :
+
+[options="nowrap"]
+----
+sectionName {
+ attributeName: attributeValue
+ attributeName: attributeValue
+ ...
+}
+----
+
+A section could be referenced by another section using its `name` attribute. An example is the _sslProfile_ section which describes attributes for setting SSL/TLS configuration and can be applied to one or more _listener_ and _connector_ sections.
+
+[options="nowrap"]
+----
+sslProfile {
+ name: ssl-profile-one
+ caCertFile: ca-certificate-1.pem
+ certFile: server-certificate-1.pem
+ privateKeyFile: server-private-key.pem
+}
+
+listener {
+ sslProfile: ssl-profile-one
+ host: 0.0.0.0
+ port: amqp
+ saslMechanisms: ANONYMOUS
+}
+----
+
+In the above example, the _sslProfile_ section named _ssl-profile-one_ is used to define the _sslProfile_ attribute for the _listener_ section.
+
+=== Configuration Sections
+
+[id='router-configuration-file-sslprofile']
+==== sslProfile
+
+Attributes for setting SSL/TLS configuration for connections.
+
+* *_caCertFile_* (path) : The absolute path to the database that contains the public certificates of trusted certificate authorities (CA).
+* *_certFile_* (path) : 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.
+* *_privateKeyFile_* (path) : The absolute path to the file containing the PEM-formatted private key for the above certificate.
+* *_passwordFile_* (path) : If the above private key is password protected, this is the absolute path to a file containing the password that unlocks the certificate key.
+* *_password_* (string) : 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 ‘password’ option. Don’t use both password and passwordFile in the same profile.
+* *_uidFormat_* (string) : A list of x509 client certificate fields that will be used to build a string that will uniquely identify the client certificate owner. For example, a value of ‘cou’ 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 ‘oF’ indicates that the uid will consist of o (organization name) concatenated with F (the sha256 fingerprint of the entire certificate) . Allowed values can be any combination of comma separated ‘c’( ISO3166 two character country code), ‘s’(state or province), ‘l’(Locality; generally - city), ‘o’(Organization - Company Name), ‘u’(Organization Unit - typically certificate type or brand), ‘n’(CommonName - typically a username for client certificates) and ‘1’(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).
+* *_uidNameMappingFile_* (string) : The absolute path to the file containing the unique id to display name mapping.
+* *_name_* (string) : The name of the profile used for referencing it from _listener_ and _connector_ sections.
+
+*Used by* : _listener_, _connector_.
+
+[id='router-configuration-file-router']
+==== router
+
+Describe main information about the router related to identity, internal processes and inter routers communication.
+
+
+* *_id_* (string) : Router’s unique identity. It is required and the router will fail to start without it.
+* *_mode_* (One of [`standalone`, `interior`], default=`standalone`) : 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.
+* *_helloIntervalSeconds_* (integer, default=`1`) : Interval in seconds between HELLO messages sent to neighbor routers in order to announce its presence (as a keep alive).
+* *_helloMaxAgeSeconds_* (integer, default=`3`) : Time in seconds after which a neighbor router is declared lost if no HELLO is received.
+* *_raIntervalSeconds_* (integer, default=`30`) : Interval in seconds between Router-Advertisements sent to all routers in a stable network.
+* *_raIntervalFluxSeconds_* (integer, default=`4`) : Interval in seconds between Router-Advertisements sent to all routers during topology fluctuations.
+* *_remoteLsMaxAgeSeconds_* (integer, default=`60`) : Time in seconds after which link state is declared stale if no RA is received.
+* *_workerThreads_* (integer, default=`4`) : The number of threads that will be created to process message traffic and other application work (timers, non-amqp file descriptors, and so on).
+* *_debugDump_* (path) : The absolute path for a file to dump debugging information that can’t be logged normally.
+* *_saslConfigDir_* (path) : The absolute path to the SASL configuration file.
+* *_saslConfigName_* (string, default=`qdrouterd`) : Name of the SASL configuration. This string + ‘.conf’ is the name of the configuration file.
+
+[id='router-configuration-file-listener']
+==== listener
+
+Listens for incoming connections to the router.
+
+* *_host_* (string, default=`127.0.0.1`) : IP address: ipv4 or ipv6 literal or a hostname.
+* *_port_* (string, default=`amqp`) : Port number or symbolic service name.
+* *_protocolFamily_* (One of [`IPv4`, `IPv6`]) : IPv4: Internet Protocol version 4; IPv6: Internet Protocol version 6. If not specified, the protocol family will be automatically determined from the address.
+* *_role_* (One of [`normal`, `inter-router`, `route-container`], default=`normal`) : 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. The route-container role can be used for router-container connections, for example, a router-broker connection.
+* *_cost_* (integer, default=`1`) : For the `inter-route` 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.
+* *_saslMechanisms_* (string) : Space separated list of accepted SASL authentication mechanisms.
+* *_authenticatePeer_* (boolean) : yes: Require the peer’s identity to be authenticated; no: Do not require any authentication.
+* *_requireEncryption_* (boolean) : yes: Require the connection to the peer to be encrypted; no: Permit non-encrypted communication with the peer. It is related to SASL mechanisms which support encryption.
+* *_requireSsl_* (boolean) : yes: Require the use of SSL/TLS on the connection; no: Allow clients to connect without SSL/TLS.
+* *_trustedCertsFile_* (path) : This optional setting can be used to reduce the set of available CAs for client authentication. If used, this setting must provide an absolute path to a PEM file that contains the trusted certificates.
+* *_maxFrameSize_* (integer, default=`16384`) : 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.
+* *_idleTimeoutSeconds_* : (integer, default=`16`) : 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.
+* *_initialHandshakeTimeoutSeconds_* (integer, default=`0`): The number of seconds after a connection transport is established that the router waits for the connecting client to complete the initial handshake and send the `AMQP OPEN` frame. If this timeout is exceeded, the connection is dropped. The default value is `0`, which means that no timeout is applied.
+* *_stripAnnotations_* (One of [`in`, `out`, `both`, `no`], default=`both`) : 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.
+* *_linkCapacity_* (integer) : 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.
+* *_sslProfile_* (string) : The name of the _sslProfile_ entity to use in order to have SSL/TLS configuration.
+* *_http_* (boolean): If set to `yes`, the listener will accept HTTP connections using AMQP over WebSockets.
+
+[id='router-configuration-file-connector']
+==== connector
+
+Establishes an outgoing connection from the router.
+
+* *_name_* (string) : Name using to reference the connector in the configuration file for example for a link routing to queue on a broker.
+* *_host_* (string, default=`127.0.0.1`) : IP address: ipv4 or ipv6 literal or a hostname.
+* *_port_* (string, default=`amqp`) : Port number or symbolic service name.
+* *_protocolFamily_* (One of [`IPv4`, `IPv6`]) : IPv4: Internet Protocol version 4; IPv6: Internet Protocol version 6. If not specified, the protocol family will be automatically determined from the address.
+* *_role_* (One of [`normal`, `inter-router`, `route-container`], default=`normal`) : 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.
+* *_cost_* (integer, default=`1`) : For the ‘inter-router’ 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.
+* *_saslMechanisms_* (string) : Space separated list of accepted SASL authentication mechanisms.
+* *_allowRedirect_* (boolean, default=True) : Allow the peer to redirect this connection to another address.
+* *_maxFrameSize_* (integer, default=`65536`) : 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.
+* *_idleTimeoutSeconds_* (integer, default=`16`) : 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.
+* *_stripAnnotations_* (One of [`in`, `out`, `both`, `no`], default=`both`) : 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.
+* *_linkCapacity_* (integer) : 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.
+* *_verifyHostname_* (boolean, default=True) : yes: Ensures that when initiating a connection (as a client) the hostname in the URL to which this connector connects to matches the hostname in the digital certificate that the peer sends back as part of the SSL/TLS connection; no: Does not perform hostname verification
+* *_saslUsername_* (string) : The username that the connector is using to connect to a peer.
+* *_saslPassword_* (string) : The password that the connector is using to connect to a peer.
+* *_sslProfile_* (string) : The name of the _sslProfile_ entity to use in order to have SSL/TLS configuration.
+
+[id='router-configuration-file-log']
+==== log
+
+Configure logging for a particular module which is part of the router. You can use the UPDATE operation to change log settings while the router is running.
+
+* *_module_* (One of [`ROUTER`, `ROUTER_CORE`, `ROUTER_HELLO`, `ROUTER_LS`, `ROUTER_MA`, `MESSAGE`, `SERVER`, `AGENT`, `CONTAINER`, `ERROR`, `POLICY`, `DEFAULT`], required) : Module to configure. The special module `DEFAULT` specifies defaults for all modules.
+* *_enable_* (string, default=`default`, required) 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 `+` to enable that level and above. For example `trace,debug,warning+` means enable trace, debug, warning, error and critical. The value ‘none’ means disable logging for the module. The value `default` means use the value from the `DEFAULT` module.
+* *_includeTimestamp_* (boolean) : Include timestamp in log messages.
+* *_includeSource_* (boolean) : Include source file and line number in log messages.
+* *_outputFile_* (string) : Where to send log messages. Can be `stderr`, `syslog` or a file name.
+
+[id='router-configuration-file-address']
+==== address
+
+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.
+
+* *_prefix_* (string, required) : The address prefix for the configured settings.
+* *_distribution_* (One of [`multicast`, `closest`, `balanced`], default=`balanced`) : Treatment of traffic associated with the address.
+* *_waypoint_* (boolean) : Designates this address space as being used for waypoints. This will cause the proper address-phasing to be used.
+* *_ingressPhase_* (integer) : Advanced - Override the ingress phase for this address.
+* *_egressPhase_* (integer) : Advanced - Override the egress phase for this address.
+
+[id='router-configuration-file-linkroute']
+==== linkRoute
+
+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.
+
+* *_prefix_* (string, required) : The address prefix for the configured settings.
+* *_containerId_* (string) : it specifies that the link route will be activated if a remote container will provide a container-id matching with this value.
+* *_connection_* (string) : The name from a connector or listener.
+* *_distribution_* (One of [`linkBalanced`], default=`linkBalanced`) : Treatment of traffic associated with the address.
+* *_direction_* (One of [`in`, `out`], required) : The permitted direction of links. It is defined from a router point of view so ‘in’ means client senders (router ingress) and ‘out’ means client receivers (router egress).
+
+[id='router-configuration-file-autolink']
+==== autoLink
+
+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, and so on.).
+
+* *_addr_* (string, required) : The address of the provisioned object.
+* *_direction_* (One of [`in`, `out`], required) : The direction of the link to be created. In means into the router, out means out of the router.
+* *_phase_* (integer) : The address phase for this link. Defaults to `0` for `out` links and `1` for `in` links.
+* *_containerId_* (string) : ContainerID for the target container.
+* *_connection_* (string) : The name from a connector or listener.
+
+==== console
+
+Start a websocket/tcp proxy and http file server to serve the web console.
+
+* *_listener_* (string) : The name of the listener to send the proxied tcp traffic to.
+* *_wsport_* (integer, default=`5673`) : The port on which to listen for websocket traffic.
+* *_proxy_* (string) : The full path to the proxy program to run.
+* *_home_* (string) : The full path to the html/css/js files for the console.
+* *_args_* (string) : Optional args to pass to the proxy program for logging, authentication, and so on.
+
+==== policy
+
+Defines global connection limit
+
+* *_maximumConnections_* (integer) : Global maximum number of concurrent client connections allowed. Zero implies no limit. This limit is always enforced even if no other policy settings have been defined.
+* *_enableAccessRules_* (boolean) : Enable user rule set processing and connection denial.
+* *_policyFolder_* (path) : The absolute path to a folder that holds policyRuleset definition .json files. For a small system the rulesets may all be defined in this file. At a larger scale it is better to have the policy files in their own folder and to have none of the rulesets defined here. All rulesets in all .json files in this folder are processed.
+* *_defaultApplication_* (string) : Application policyRuleset to use for connections with no open.hostname or a hostname that does not match any existing policy. For users that don’t wish to use open.hostname or any multi-tennancy feature, this default policy can be the only policy in effect for the network.
+* *_defaultApplicationEnabled_* (boolean) : Enable defaultApplication policy fallback logic.
+
+==== policyRuleset
+
+Per application definition of the locations from which users may connect and the groups to which users belong.
+
+* *_maxConnections_* (integer) : Maximum number of concurrent client connections allowed. Zero implies no limit.
+* *_maxConnPerUser_* (integer) : Maximum number of concurrent client connections allowed for any single user. Zero implies no limit.
+* *_maxConnPerHost_* (integer) : Maximum number of concurrent client connections allowed for any remote host. Zero implies no limit.
+* *_userGroups_* (map) : A map where each key is a user group name and the corresponding value is a CSV string naming the users in that group. Users who are assigned to one or more groups are deemed ‘restricted’. Restricted users are subject to connection ingress policy and are assigned policy settings based on the assigned user groups. Unrestricted users may be allowed or denied. If unrestricted users are allowed to connect then they are assigned to user group default.
+* *_ingressHostGroups_* (map) : A map where each key is an ingress host group name and the corresponding value is a CSV string naming the IP addresses or address ranges in that group. IP addresses may be FQDN strings or numeric IPv4 or IPv6 host addresses. A host range is two host addresses of the same address family separated with a hyphen. The wildcard host address ‘*’ represents any host address.
+* *_ingressPolicies_* (map) : A map where each key is a user group name and the corresponding value is a CSV string naming the ingress host group names that restrict the ingress host for the user group. Users who are members of the user group are allowed to connect only from a host in one of the named ingress host groups.
+* *_connectionAllowDefault_* (boolean) : 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 ‘default’ user group and receive ‘default’ settings.
+* *_settings_* (map) : A map where each key is a user group name and the value is a map of the corresponding settings for that group.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/configuration-security.adoc
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/configuration-security.adoc b/docs/books/user-guide/configuration-security.adoc
new file mode 100644
index 0000000..993cecf
--- /dev/null
+++ b/docs/books/user-guide/configuration-security.adoc
@@ -0,0 +1,773 @@
+////
+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
+////
+
+[id='security-config']
+= Security
+
+Securing your router network involves configuring authentication and authorization. You can authenticate and encrypt the router's connections using SSL/TLS or SASL. Additionally, you can authorize access to messaging resources by setting user connection restrictions and defining AMQP resource access control.
+
+== Authenticating Remote Peers
+
+You can configure {RouterName} to communicate with clients, routers, and brokers in a secure way by authenticating and encrypting the router's connections. {RouterName} supports the following security protocols:
+
+* _SSL/TLS_ for certificate-based encryption and mutual authentication
+* _SASL_ for authentication and payload encryption
+
+[id='setting-up-ssl-for-encryption-and-authentication']
+=== Setting Up SSL/TLS for Encryption and Authentication
+
+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.
+
+.Prerequisites
+
+You must have the following files in PEM format:
+
+* An X.509 CA certificate (used for signing the router certificate for the SSL/TLS server authentication feature).
+* A private key (with or without password protection) for the router.
+* An X.509 router certificate signed by the X.509 CA certificate.
+
+.Procedure
+
+* In the router's configuration file, add an `sslProfile` section:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+sslProfile {
+ name: _NAME_
+ ciphers: _CIPHERS_
+ caCertFile: _PATH_.pem
+ certFile: _PATH_.pem
+ privateKeyFile: _PATH_.pem
+ password: _PASSWORD/PATH_TO_PASSWORD_FILE_
+ ...
+}
+----
+
+`name`:: A name for the SSL/TLS profile. You can use this name to refer to the profile from the incoming and outgoing connections.
++
+For example:
++
+[options="nowrap"]
+----
+name: router-ssl-profile
+----
+
+`ciphers`:: 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.
++
+To enable a cipher list, enter one or more cipher strings separated by colons (`:`). For example:
++
+[options="nowrap"]
+----
+ciphers: ALL:!aNULL:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
+----
++
+To see the full list of available ciphers, use the `openssl ciphers` command. For more information about each cipher, see the link:https://www.openssl.org/docs/manmaster/man1/ciphers.html[ciphers man page^].
+
+`caCertFile`:: The absolute path to the file that contains the public certificates of trusted certificate authorities (CA).
++
+For example:
++
+[options="nowrap"]
+----
+caCertFile: /qdrouterd/ssl_certs/ca-cert.pem
+----
+
+`certFile`:: 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.
++
+For example:
++
+[options="nowrap"]
+----
+certFile: /qdrouterd/ssl_certs/router-cert-pwd.pem
+----
+
+`privateKeyFile`:: The absolute path to the file containing the PEM-formatted private key for the above certificate.
++
+For example:
++
+[options="nowrap"]
+----
+privateKeyFile: /qdrouterd/ssl_certs/router-key-pwd.pem
+----
+
+`passwordFile` or `password`:: 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.
++
+For example:
++
+[options="nowrap"]
+----
+password: routerKeyPassword
+----
+
+For information about additional `sslProfile` attributes, see link:{qdrouterdConfManPageUrl}#_sslprofile[sslProfile] in the `qdrouterd.conf` man page.
+--
+
+[id='setting-up-sasl-for-authentication-and-payload-encryption']
+=== Setting Up SASL for Authentication and Payload Encryption
+
+If you plan to use SASL to authenticate connections, you must first add the SASL attributes to the `router` 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.
+
+.Prerequisites
+
+Before you can set up SASL, you must have the following:
+
+* xref:generating-sasl-database[The SASL database is generated.]
+* xref:configuring-sasl-database[The SASL configuration file is configured.]
+* The Cyrus SASL plugin is installed for each SASL mechanism you plan to use.
++
+Cyrus SASL uses plugins to support specific SASL mechanisms. Before you can use a particular SASL mechanism, the relevant plugin must be installed. For example, you need the `cyrus-sasl-plain` plugin to use SASL PLAIN authentication.
++
+--
+// Note about searching for an installing SASL plugins.
+include::{FragmentDir}/fragment-router-sasl-para.adoc[]
+--
+
+.Procedure
+
+* In the router's configuration file, add the following attributes to the `router` section:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+router {
+ ...
+ saslConfigDir: _PATH_
+ saslConfigName: _FILE_NAME_
+}
+----
+
+`saslConfigDir`:: The absolute path to the SASL configuration file.
++
+For example:
++
+[options="nowrap"]
+----
+saslConfigDir: /qdrouterd/security
+----
+
+`saslConfigName`:: The name of the SASL configuration file. This name should _not_ include the `.conf` file extension.
++
+For example:
++
+[options="nowrap"]
+----
+saslConfigName: qdrouterd_sasl
+----
+--
+
+[id='securing-incoming-connections']
+=== Securing Incoming Connections
+
+You can secure incoming connections by configuring each connection's `listener` entity for encryption, authentication, or both.
+
+.Prerequisites
+
+Before securing incoming connections, the security protocols you plan to use should be set up.
+
+.Choices
+
+* xref:adding-ssl-encryption-to-incoming-connection[Add SSL/TLS encryption]
+* xref:adding-sasl-authentication-to-incoming-connection[Add SASL authentication]
+* xref:adding-ssl-client-authentication-to-incoming-connection[Add SSL/TLS client authentication]
+* xref:adding-sasl-payload-encryption-to-incoming-connection[Add SASL payload encryption]
+
+[id='adding-ssl-encryption-to-incoming-connection']
+==== Adding SSL/TLS Encryption to an Incoming Connection
+
+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.
+
+.Procedure
+
+* In the router's configuration file, add the following attributes to the connection's `listener` entity:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+listener {
+ ...
+ sslProfile: _SSL_PROFILE_NAME_
+ requireSsl: yes
+}
+----
+
+`sslProfile`:: The name of the SSL/TLS profile you set up.
+
+`requireSsl`:: Enter `yes` to require all clients connecting to the router on this connection to use encryption.
+--
+
+[id='adding-sasl-authentication-to-incoming-connection']
+==== Adding SASL Authentication to an Incoming Connection
+
+You can configure an incoming connection to authenticate the client using SASL. You can use SASL authentication with or without SSL/TLS encryption.
+
+.Procedure
+
+* In the router's configuration file, add the following attributes to the connection's `listener` section:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+listener {
+ ...
+ authenticatePeer: yes
+ saslMechanisms: _MECHANISMS_
+}
+----
+
+`authenticatePeer`:: Set this attribute to `yes` to require the router to authenticate the identity of a remote peer before it can use this incoming connection.
+
+`saslMechanisms`:: The SASL authentication mechanism (or mechanisms) to use for peer authentication. You can choose any of the Cyrus SASL authentication mechanisms _except_ for `ANONYMOUS`. To specify multiple authentication mechanisms, separate each mechanism with a space.
++
+For a full list of supported Cyrus SASL authentication mechanisms, see link:https://www.cyrusimap.org/sasl/sasl/authentication_mechanisms.html[Authentication Mechanisms^].
+--
+
+[id='adding-ssl-client-authentication-to-incoming-connection']
+==== Adding SSL/TLS Client Authentication to an Incoming Connection
+
+You can configure an incoming connection to authenticate the client using SSL/TLS.
+
+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.
+
+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.
+
+You can use SSL/TLS client authentication with or without SASL authentication.
+
+.Procedure
+
+* In the router's configuration, file, add the following attribute to the connection's `listener` entity:
++
+--
+[options="nowrap"]
+----
+listener {
+ ...
+ authenticatePeer: yes
+}
+----
+
+`authenticatePeer`:: Set this attribute to `yes` to require the router to authenticate the identity of a remote peer before it can use this incoming connection.
+--
+
+[id='adding-sasl-payload-encryption-to-incoming-connection']
+==== Adding SASL Payload Encryption to an Incoming Connection
+
+If you do not use SSL/TLS, you can still encrypt the incoming connection by using SASL payload encryption.
+
+.Procedure
+
+* In the router's configuration file, add the following attributes to the connection's `listener` section:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+listener {
+ ...
+ requireEncryption: yes
+ saslMechanisms: _MECHANISMS_
+}
+----
+
+`requireEncryption`:: Set this attribute to `yes` to require the router to use SASL payload encryption for the connection.
+
+`saslMechanisms`:: 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.
++
+For a full list of supported Cyrus SASL authentication mechanisms, see link:https://www.cyrusimap.org/sasl/sasl/authentication_mechanisms.html[Authentication Mechanisms^].
+--
+
+[id='securing-outgoing-connections']
+=== Securing Outgoing Connections
+
+You can secure outgoing connections by configuring each connection's `connector` entity for encryption, authentication, or both.
+
+.Prerequisites
+
+Before securing outgoing connections, the security protocols you plan to use should be set up.
+
+.Choices
+
+* xref:adding-ssl-authentication-to-outgoing-connection[Add SSL/TLS authentication]
+* xref:adding-sasl-authentication-to-outgoing-connection[Add SASL authentication]
+
+[id='adding-ssl-authentication-to-outgoing-connection']
+==== Adding SSL/TLS Client Authentication to an Outgoing Connection
+
+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.
+
+You can use SSL/TLS client authentication with or without SASL authentication.
+
+.Procedure
+
+* In the router's configuration file, add the `sslProfile` attribute to the connection's `connector` entity:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+connector {
+ ...
+ sslProfile: _SSL_PROFILE_NAME_
+}
+----
+
+`sslProfile`:: The name of the SSL/TLS profile you set up.
+--
+
+[id='adding-sasl-authentication-to-outgoing-connection']
+==== Adding SASL Authentication to an Outgoing Connection
+
+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.
+
+.Procedure
+
+* In the router's configuration file, add the `saslMechanisms` attribute to the connection's `connector` entity:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+connector {
+ ...
+ saslMechanisms: _MECHANISMS_
+ saslUsername: _USERNAME_
+ saslPassword: _PASSWORD_
+}
+----
+
+`saslMechanisms`:: 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.
++
+For a full list of supported Cyrus SASL authentication mechanisms, see link:https://www.cyrusimap.org/sasl/sasl/authentication_mechanisms.html[Authentication Mechanisms^].
+`saslUsername`:: If any of the SASL mechanisms uses username/password authentication, then provide the username to connect to the external container.
+`saslPassword`:: If any of the SASL mechanisms uses username/password authentication, then provide the password to connect to the external container.
+--
+
+[id='integrating-with-kerberos']
+=== Integrating with Kerberos
+
+By using the `GSSAPI` SASL mechanism, you can configure {RouterName} to authenticate incoming connections using Kerberos.
+
+.Prerequisites
+
+* A Kerberos infrastructure must be deployed in your environment.
+
+* In the Kerberos environment, a service principal of `amqp/_HOSTNAME_@_REALM_` must be configured.
++
+This is the service principal that {RouterName} uses.
+
+* The `cyrus-sasl-gssapi` package must be installed on each client and router host machine.
+
+* xref:setting-up-sasl-for-authentication-and-payload-encryption[SASL must be set up for {RouterName}].
+
+.Procedure
+
+. On the router's host machine, open the `/etc/sasl2/qdrouterd.conf` configuration file.
++
+--
+.An `/etc/sasl2/qdrouterd.conf` Configuration File
+====
+[options="nowrap"]
+----
+pwcheck_method: auxprop
+auxprop_plugin: sasldb
+sasldb_path: qdrouterd.sasldb
+keytab: /etc/krb5.keytab
+mech_list: ANONYMOUS DIGEST-MD5 EXTERNAL PLAIN GSSAPI
+----
+====
+--
+
+. Verify the following:
+** The `mech_list` attribute contains the `GSSAPI` mechanism.
+** The `keytab` attribute points to the location of the keytab file.
+
+
+. Open the router's configuration file.
+
+. For each incoming connection that should use Kerberos for authentication, set the router's `listener` to use the `GSSAPI` mechanism.
++
+--
+.A `listener` in the Router Configuration File
+====
+[options="nowrap"]
+----
+listener {
+ ...
+ authenticatePeer: yes
+ saslMechanisms: GSSAPI
+}
+----
+====
+
+For more information about these attributes, see xref:adding-sasl-authentication-to-incoming-connection[].
+--
+
+== Authorizing Access to Messaging Resources
+
+You can restrict the number of user connections, and control access to AMQP messaging resources by configuring _policies_.
+
+=== Types of Policies
+
+You can configure two different types of policies: _global policies_ and _vhost policies_.
+
+Global policies::
+Settings for the router. A global policy defines the maximum number of incoming user connections for the router (across all vhost policies), and defines how the router should use vhost policies.
+
+Vhost policies::
+Connection and AMQP resource limits for a messaging endpoint (called an AMQP virtual host, or _vhost_). A vhost policy defines what a client can access on a messaging endpoint over a particular connection.
++
+[NOTE]
+====
+A vhost is typically the name of the host to which the client connection is directed. For example, if a client application opens a connection to the `amqp://mybroker.example.com:5672/queue01` URL, the vhost would be `mybroker.example.com`.
+====
+
+The resource limits defined in global and vhost policies are applied to user connections only. The limits do not affect inter-router connections or router connections that are outbound to waypoints.
+
+=== How {RouterName} Applies Policies
+
+{RouterName} uses both global and vhost policies to determine whether to permit a connection, and if it is permitted, to apply the appropriate resource limits.
+
+When a client creates a connection to the router, the router first determines whether to allow or deny the connection. This decision is based on the following criteria:
+
+* Whether the connection will exceed the router's global connection limit (defined in the global policy)
+* Whether the connection will exceed the vhost's connection limits (defined in the vhost policy that matches the host to which the connection is directed)
+
+If the connection is allowed, the router assigns the user (the authenticated user name from the connection) to a user group, and enforces the user group's resource limits for the lifetime of the connection.
+
+=== Configuring Global Policies
+
+You can set the incoming connection limit for the router and define how it should use vhost policies by configuring a global policy.
+
+.Procedure
+
+* In the router configuration file, add a `policy` section.
++
+--
+[options="nowrap",subs="+quotes"]
+----
+policy = {
+ maxConnections: 10000 // <1>
+ enableVhostPolicy: true // <2>
+ policyDir: /etc/qpid-dispatch/policies/ // <3>
+ defaultVhost: $default // <4>
+}
+----
+<1> The maximum number of concurrent client connections allowed for this router. This limit is always enforced, even if no other policy settings have been defined. The limit is applied to all incoming connections regardless of remote host, authenticated user, or targeted vhost. The default (and the maximum) value is `65535`.
+
+<2> Enables the router to enforce the connection denials and resource limits defined in the configured vhost policies. The default is `false`, which means that the router will not enforce any vhost policies.
++
+[NOTE]
+====
+Setting `enableVhostPolicy` to `false` improves the router's performance.
+====
+
+<3> The absolute path to a directory that holds vhost policy definition files in JSON format (`*.json`). The router processes all of the vhost policies in each JSON file that is in this directory. For more information, see xref:configuring-vhost-policies-json[].
+
+<4> The name of the default vhost policy. This policy rule set is applied to a connection for which a vhost policy has not otherwise been configured. Processing for the default vhost is enabled by default and set to select vhost '$default'. To disable default vhost processing set defaultVhost to blank or do not define a vhost named '$default'.
+--
+
+=== Configuring Vhost Policies
+
+You configure vhost policies to define the connection limits and AMQP resource limits for a messaging endpoint.
+
+A vhost policy consists of the following:
+
+* Connection limits
++
+These limits control the number of users that can be connected to the vhost simultaneously.
+
+* User groups
++
+A user group defines the messaging resources that the group members are permitted to access. Each user group defines the following:
+
+** A set of users that can connect to the vhost (the group members)
+** The remote hosts from which the group members may connect to the router network
+** The AMQP resources that the group members are permitted to access on the vhost
+
+You can use the following methods to configure vhost policies:
+
+* xref:configuring-vhost-policies-router[Configure vhost policies directly in the router configuration file]
+* xref:configuring-vhost-policies-json[Configure vhost policies as JSON files]
+
+[id='configuring-vhost-policies-router']
+==== Configuring Vhost Policies in the Router Configuration File
+
+You can configure vhost policies in the router configuration file by configuring `vhost` entities. However, if multiple routers in your router network should be configured with the same vhost configuration, you will need to add the `vhost` configuration to each router's configuration file.
+
+.Procedure
+
+. In the router configuration file, add a `vhost` section and define the connection limits for it.
++
+--
+The connection limits apply to all users that are connected to the vhost. These limits control the number of users that can be connected simultaneously to the vhost.
+
+[options="nowrap",subs="+quotes"]
+----
+vhost = {
+ hostname: example.com // <1>
+ maxConnections: 10000 // <2>
+ maxConnectionsPerUser: 1000 // <3>
+ maxConnectionsPerHost: 1000 // <4>
+ allowUnknownUser: false // <5>
+ ...
+}
+----
+
+<1> The host name of the vhost. This vhost policy will be applied to any client connection that is directed to the hostname that you specify.
+
+<2> The global maximum number of concurrent client connections allowed for this vhost. The default is `65535`.
+
+<3> The maximum number of concurrent client connections allowed for any user. The default is `65535`.
+
+<4> The maximum number of concurrent client connections allowed for any remote host (the host from which the client is connecting). The default is `65535`.
+
+<5> Whether unknown users (users who are not members of a defined user group) are allowed to connect to the vhost. Unknown users are assigned to the `$default` user group and receive `$default` settings. The default is `false`, which means that unknown users are not allowed.
+--
+
+. In the `vhost` section, beneath the connection settings that you added, add the necessary user groups.
++
+--
+A user group defines what messaging resources the members of the group are allowed to access.
+
+[options="nowrap",subs="+quotes"]
+----
+vhost {
+ ...
+ groups: {
+ admin: { // <1>
+ users: admin1, admin2 // <2>
+ remoteHosts: 127.0.0.1, ::1 // <3>
+ sources: * // <4>
+ targets: * // <5>
+ },
+ ...
+ }
+}
+----
+
+<1> The name of the user group.
+
+<2> A list of authenticated users for this user group. Use commas to separate multiple users. A user may belong to only one vhost user group.
+
+<3> A list of remote hosts from which the users may connect. A host can be a hostname, IP address, or IP address range. Use commas to separate multiple hosts. To allow access from all remote hosts, specify a wildcard `*`. To deny access from all remote hosts, leave this attribute blank.
+
+<4> A list of AMQP source addresses from which users in this group may receive messages. To specify multiple AMQP addresses, separate the addresses with either a comma or a space. If you do not specify any addresses, users in this group are not allowed to receive messages from any addresses.
++
+You can use the substitution token `${user}` to specify an AMQP address that contains a user's authenticated user name. This enables you to allow access to resources specific to each user in the user group without having to name each user individually. You can only specify the `${user}` token once in an AMQP address name. If there are multiple tokens in an address, only the leftmost token will be substituted.
++
+You can use an asterisk (`*`) wildcard to match one or more characters in an AMQP address. However, this wildcard is only recognized if it is the last character in the address name.
++
+.Allowing Access to All Addresses
+====
+[options="nowrap"]
+----
+sources: *
+----
+====
++
+.Restricting Access to All Addresses
+====
+[options="nowrap"]
+----
+sources:
+----
+====
++
+.Allowing Access to Specific Addresses
+====
+[options="nowrap"]
+----
+sources: myaddress01, myaddress02, myaddress03
+----
+====
++
+.Allowing Access to User-Specific Addresses
+====
+This definition allows access to any address that meets any of the following rules:
+
+* Starts with the prefix `tmp_` and ends with the user name
+* Starts with the prefix `temp` followed by any additional characters
+* Starts with the user name, is followed by `-home-`, and ends with any additional characters
+
+[options="nowrap"]
+----
+sources: tmp_${user}, temp*, ${user}-home-*
+----
+====
+
+<5> A list of AMQP target addresses from which users in this group may send messages. You can specify multiple AMQP addresses and use user name substitution and wildcards the same way as with source addresses.
+--
+
+. If necessary, add any advanced user group settings to the vhost user group.
++
+The advanced user group settings enable you to define resource limits based on the AMQP connection open, session begin, and link attach phases of the connection. For more information, see link:{qdrouterdConfManPageUrl}#_vhostUserGroupSettings[Vhost User Group Settings^].
+
+[id='configuring-vhost-policies-json']
+==== Configuring Vhost Policies as JSON Files
+
+As an alternative to using the router configuration file, you can configure vhost policies in JSON files. If you have multiple routers that need to share the same vhost configuration, you can put the vhost configuration JSON files in a location accessible to each router, and then configure the routers to apply the vhost policies defined in these JSON files.
+
+.Procedure
+
+. Determine where to store the vhost policy JSON files.
++
+The directory should be accessible by each router that needs to apply these vhost policies.
+
+. In the directory you determined, create a JSON file for each vhost policy.
++
+The vhost policy is configured the same way as a `vhost` entity in the router configuration file, only using JSON syntax. For more information about vhost policy attributes, see xref:configuring-vhost-policies-router[].
++
+.Sample Vhost Policy JSON File
+====
+[source,json,options="nowrap"]
+----
+{
+ "vhost": {
+ "name": "example.com",
+ "maxConnectionsPerUser": 100,
+ "allowUnknownUser": true,
+ "groups": {
+ "admin": {
+ "users": ["admin1", "admin2"],
+ "sources": "*",
+ "targets": "*"
+ },
+ "developers": {
+ "users": ["dev1", "dev2", "dev3"],
+ "remoteHosts": "*",
+ "sources": ["myqueue1", "myqueue2"],
+ "targets": ["myqueue1", "myqueue2"]
+ }
+ }
+ }
+}
+----
+====
+
+. In the router configuration file, locate the `policy` entity and set the `policyDir` attribute to point to the directory where the vhost policy JSON files are stored.
++
+.A `policy` Entity
+====
+[options="nowrap"]
+----
+policy = {
+ maxConnections: 1000
+ enableVhostPolicy: true
+ policyDir: /etc/vhost-policies/ // <1>
+ defaultVhost: $default
+}
+----
+<1> The absolute path to a directory that holds vhost policy definition files in JSON format (*.json). The router processes all of the vhost policies in each JSON file that is in this directory.
+====
+
+. Repeat the previous step for each additional router that should use the vhost policies located in the vhost policy directory.
+
+=== Example: Configuring a Vhost Policy
+
+In this example, a vhost policy defines resource limits for clients connecting to the `example.com` host.
+
+.A Vhost Policy in the Router Configuration File
+====
+[options="nowrap"]
+----
+vhost {
+ name: example.com // <1>
+ maxConnectionsPerUser: 10 // <2>
+ allowUnknownUser: true // <3>
+ groups: {
+ admin: {
+ users: admin-01, admin-02 // <4>
+ remoteHosts: 127.0.0.1, ::1 // <5>
+ sources: * // <6>
+ targets: * // <6>
+ },
+ $default: {
+ remoteHosts: * // <7>
+ sources: news*, sports*, chat* // <8>
+ targets: chat* // <9>
+ }
+ }
+}
+----
+
+<1> The rules defined in this vhost policy will be applied to any user connecting to `example.com`.
+
+<2> Each user can open up to 10 connections to the vhost.
+
+<3> Any user can connect to this vhost. Users that are not part of the `admin` group are assigned to the `$default` group.
+
+<4> If the `admin-01` or `admin-02` user connects to the vhost, they are assigned to the `admin` user group.
+
+<5> Users in the `admin` user group must connect from localhost. If the admin user attempts to connect from any other host, the connection will be denied.
+
+<6> Users in the admin user group can send and receive from any address offered by the vhost.
+
+<7> Any non-admin user is permitted to connect from any host.
+
+<8> Non-admin users are permitted to receive messages from any addresses that start with the `news`, `sports`, or `chat` prefixes.
+
+<9> Non-admin users are permitted to send messages to any address that start with the `chat` prefix.
+====
+
+=== Example: Using a Vhost Policy to Limit Memory Consumption (Advanced)
+
+By using the advanced vhost policy attributes, you can control how much system buffer memory a user connection can potentially consume.
+
+In this example, a stock trading site provides services for stock traders. However, the site must also accept high-capacity, automated data feeds from stock exchanges. To prevent trading activity from consuming memory needed for the feeds, a larger amount of system buffer memory is allotted to the feeds than to the traders.
+
+This examples uses the `maxSessions` and `maxSessionWindow` attributes to set the buffer memory consumption limits for each AMQP session. These settings are passed directly to the AMQP connection and session negotiations, and do not require any processing cycles on the router.
+
+This example does not show the vhost policy settings that are unrelated to buffer allocation.
+
+.A Vhost Policy to Limit Memory Consumption
+====
+[options="nowrap"]
+----
+vhost {
+ name: traders.com // <1>
+ groups: {
+ traders: {
+ users: trader-1, trader-2, ... // <2>
+ maxFrameSize: 10000 // <3>
+ maxSessionWindow: 5000000 // <3>
+ maxSessions: 1 // <4>
+ ...
+ },
+ feeds: {
+ users: nyse-feed, nasdaq-feed // <5>
+ maxFrameSize: 60000 // <6>
+ maxSessionWindow: 1200000000 // <6>
+ maxSessions: 3 // <7>
+ ...
+ }
+ }
+}
+----
+
+<1> The rules defined in this vhost policy will be applied to any user connecting to `traders.com`.
+
+<2> The `traders` group includes `trader-01`, `trader-02`, and any other user defined in the list.
+
+<3> At most, 5,000,000 bytes of data can be in flight on each session.
+
+<4> Only one session per connection is allowed.
+
+<5> The `feeds` group includes two users.
+
+<6> At most, 1,200,000,000 bytes of data can be in flight on each session.
+
+<7> Up to three sessions per connection are allowed.
+====
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/cyrus-sasl.adoc
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/cyrus-sasl.adoc b/docs/books/user-guide/cyrus-sasl.adoc
new file mode 100644
index 0000000..3618ffc
--- /dev/null
+++ b/docs/books/user-guide/cyrus-sasl.adoc
@@ -0,0 +1,90 @@
+////
+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
+////
+
+[id='cyrus-sasl']
+= Using Cyrus SASL to Provide Authentication
+
+// Just doing some basic editing for now; for future releases, this content will need some more work. Also need to determine if it should be moved from an appendix to the section that deals with setting up SASL.
+
+{RouterName} uses the Cyrus SASL library for SASL authentication. Therefore, if you want to use SASL, you must set up the Cyrus SASL database and configure it.
+
+[id='generating-sasl-database']
+== Generating a SASL Database
+
+To generate a SASL database to store credentials, enter the following command:
+
+[options="nowrap",subs="+quotes"]
+----
+$ sudo saslpasswd2 -c -f _SASL_DATABASE_NAME_.sasldb -u _DOMAIN_NAME_ _USER_NAME_
+----
+
+This command creates or updates the specified SASL database, and adds the specified user name to it. The command also prompts you for the user name's password.
+
+// What is the goal here - to add user credentials to the database? If so, do you need to run this command for every user that you want to add? When it says that the command prompts for the password, does that mean you use the prompt to set the user's password?
+
+The full user name is the user name you entered plus the domain name (`__USER_NAME__`@`__DOMAIN_NAME__`). Providing a domain name is not required when you add a user to the database, but if you do not provide one, a default domain will be added automatically (the hostname of the machine on which the tool is running). For example, in the command above, the full user name would be `user1@domain.com`.
+
+== Viewing Users in a SASL Database
+
+To view the user names stored in the SASL database:
+
+[options="nowrap",subs="+quotes"]
+----
+$ sudo sasldblistusers2 -f qdrouterd.sasldb
+user2@domain.com: __PASSWORD__
+user1@domain.com: __PASSWORD__
+----
+
+[id='configuring-sasl-database']
+== Configuring a SASL Database
+
+To use the SASL database to provide authentication in {RouterName}:
+
+. Open the `/etc/sasl2/qdrouterd.conf` configuration file.
+
+. Set the following attributes:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+pwcheck_method: auxprop
+auxprop_plugin: sasldb
+sasldb_path: __SASL_DATABASE_NAME__
+mech_list: __MECHANISM1 ...__
+----
+
+`sasldb_path`:: The name of the SASL database to use.
++
+For example:
++
+[options="nowrap"]
+----
+sasldb_path: qdrouterd.sasldb
+----
+
+`mech_list`:: The SASL mechanisms to enable for authentication. To add multiple mechanisms, separate each entry with a space.
++
+For example:
++
+[options="nowrap"]
+----
+mech_list: ANONYMOUS DIGEST-MD5 EXTERNAL PLAIN
+----
+// Where can users find a list of supported mechanisms?
+--
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/getting-started.adoc
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/getting-started.adoc b/docs/books/user-guide/getting-started.adoc
new file mode 100644
index 0000000..021dcba
--- /dev/null
+++ b/docs/books/user-guide/getting-started.adoc
@@ -0,0 +1,156 @@
+////
+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
+////
+
+[id='getting-started']
+= Getting Started
+
+Before configuring {RouterName}, 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.
+
+[id='starting-the-router']
+== Starting the Router
+
+.Procedure
+
+// Step 1 for starting the router.
+include::{FragmentDir}/fragment-starting-router-step.adoc[]
++
+[NOTE]
+====
+You can specify a different configuration file with which to start the router. For more information, see xref:methods-for-changing-router-configuration[_Changing a Router's Configuration_].
+====
++
+The router starts, using the default configuration file stored at `/etc/qpid-dispatch/qdrouterd.conf`.
+
+. View the log to verify the router status:
++
+[options="nowrap"]
+----
+$ qdstat --log
+----
++
+This example shows that the router was correctly installed, is running, and is ready to route traffic between clients:
++
+[options="nowrap"]
+----
+$ qdstat --log
+Fri May 20 09:38:03 2017 SERVER (info) Container Name: Router.A // <1>
+Fri May 20 09:38:03 2017 ROUTER (info) Router started in Standalone mode // <2>
+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 // <3>
+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 // <4>
+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 // <5>
+----
+<1> The name of this router instance.
+<2> By default, the router starts in _standalone_ mode, which means that it cannot connect to other routers or be used in a router network.
+<3> The management agent. It provides the `$management` address, through which management tools such as `qdmanage` and `qdstat` 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 link:https://www.oasis-open.org/committees/download.php/54441/AMQP%20Management%20v1.0%20WD09[AMQP management specification (Draft 9)].
+<4> A listener is started on all available network interfaces and listens for connections on the standard AMQP port (5672, which is not encrypted).
+<5> Threads for handling message traffic and all other internal operations.
+
+== Routing Messages in a Peer-to-Peer Configuration
+
+// XXX Calling this peer-to-peer poses some problems. It's also
+// technically client-server in this instance, and most people think
+// those two things are exclusive.
+
+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.
+
+.Peer-to-peer Communication
+image::01-peer-to-peer.png[Peer-to-peer Communication, align="center"]
+
+As the diagram indicates, the configuration consists of an {RouterName} 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.
+
+A broker is not used in this example, so there is no _"store and forward"_ 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.
+
+This example uses a {ClientAmqpPythonName} client to start a receiver client, and then send five messages from the sender client.
+
+.Prerequisites
+
+{ClientAmqpPythonName} must be installed before you can complete the peer-to-peer routing example. For more information, see {ClientAmqpPythonUrl}.
+
+.Procedure
+
+. xref:starting-the-receiver-client[Start the receiver client].
+. xref:sending-messages[Send messages].
+
+[id='starting-the-receiver-client']
+=== Starting the Receiver Client
+
+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.
+
+[NOTE]
+====
+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.
+====
+
+.Procedure
+
+* To start the receiver by using the Python receiver client, navigate to the Python examples directory and run the `simple_recv.py` example:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+$ cd __INSTALL_DIR__/examples/python/
+$ python simple_recv.py -a 127.0.0.1:5672/examples -m 5
+----
+
+This command starts the receiver and listens on the default address (`127.0.0.1:5672/examples`). The receiver is also set to receive a maximum of five messages.
+--
+
+[id='sending-messages']
+=== Sending Messages
+
+After starting the receiver client, you can send messages from the sender. These messages will travel through the router to the receiver.
+
+.Procedure
+
+* In a new terminal window, navigate to the Python examples directory and run the `simple_send.py` example:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+$ cd __INSTALL_DIR__/examples/python/
+$ python simple_send.py -a 127.0.0.1:5672/examples -m 5
+----
+
+This command sends five auto-generated messages to the default address (`127.0.0.1:5672/examples`) and then confirms that they were delivered and acknowledged by the receiver:
+
+[options="nowrap"]
+----
+all messages confirmed
+----
+
+The receiver client receives the messages and displays their content:
+
+[options="nowrap"]
+----
+{u'sequence': 1L}
+{u'sequence': 2L}
+{u'sequence': 3L}
+{u'sequence': 4L}
+{u'sequence': 5L}
+----
+--
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/images/01-peer-to-peer.png
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/images/01-peer-to-peer.png b/docs/books/user-guide/images/01-peer-to-peer.png
new file mode 100644
index 0000000..5c834aa
Binary files /dev/null and b/docs/books/user-guide/images/01-peer-to-peer.png differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/images/balanced-routing.png
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/images/balanced-routing.png b/docs/books/user-guide/images/balanced-routing.png
new file mode 100644
index 0000000..fedcdbf
Binary files /dev/null and b/docs/books/user-guide/images/balanced-routing.png differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/images/brokered-messaging.png
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/images/brokered-messaging.png b/docs/books/user-guide/images/brokered-messaging.png
new file mode 100644
index 0000000..ae129d4
Binary files /dev/null and b/docs/books/user-guide/images/brokered-messaging.png differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/images/closest-routing.png
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/images/closest-routing.png b/docs/books/user-guide/images/closest-routing.png
new file mode 100644
index 0000000..ba3f0a5
Binary files /dev/null and b/docs/books/user-guide/images/closest-routing.png differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/images/console1.png
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/images/console1.png b/docs/books/user-guide/images/console1.png
new file mode 100644
index 0000000..f131884
Binary files /dev/null and b/docs/books/user-guide/images/console1.png differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/images/console_charts.png
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/images/console_charts.png b/docs/books/user-guide/images/console_charts.png
new file mode 100644
index 0000000..169c2ca
Binary files /dev/null and b/docs/books/user-guide/images/console_charts.png differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/images/console_entity.png
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/images/console_entity.png b/docs/books/user-guide/images/console_entity.png
new file mode 100644
index 0000000..130c7e7
Binary files /dev/null and b/docs/books/user-guide/images/console_entity.png differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/images/console_login.png
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/images/console_login.png b/docs/books/user-guide/images/console_login.png
new file mode 100644
index 0000000..63e22c6
Binary files /dev/null and b/docs/books/user-guide/images/console_login.png differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/images/console_overview.png
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/images/console_overview.png b/docs/books/user-guide/images/console_overview.png
new file mode 100644
index 0000000..af25f36
Binary files /dev/null and b/docs/books/user-guide/images/console_overview.png differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/images/console_schema.png
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/images/console_schema.png b/docs/books/user-guide/images/console_schema.png
new file mode 100644
index 0000000..ba56c7b
Binary files /dev/null and b/docs/books/user-guide/images/console_schema.png differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/images/console_topology.png
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/images/console_topology.png b/docs/books/user-guide/images/console_topology.png
new file mode 100644
index 0000000..ae4b22a
Binary files /dev/null and b/docs/books/user-guide/images/console_topology.png differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/images/link-routing.png
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/images/link-routing.png b/docs/books/user-guide/images/link-routing.png
new file mode 100644
index 0000000..0c1b9e4
Binary files /dev/null and b/docs/books/user-guide/images/link-routing.png differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/images/message-routing.png
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/images/message-routing.png b/docs/books/user-guide/images/message-routing.png
new file mode 100644
index 0000000..42f4638
Binary files /dev/null and b/docs/books/user-guide/images/message-routing.png differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/images/multicast-routing.png
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/images/multicast-routing.png b/docs/books/user-guide/images/multicast-routing.png
new file mode 100644
index 0000000..d4548a6
Binary files /dev/null and b/docs/books/user-guide/images/multicast-routing.png differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/images/path-redundancy-01.png
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/images/path-redundancy-01.png b/docs/books/user-guide/images/path-redundancy-01.png
new file mode 100644
index 0000000..ba8f10d
Binary files /dev/null and b/docs/books/user-guide/images/path-redundancy-01.png differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/images/path-redundancy-02.png
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/images/path-redundancy-02.png b/docs/books/user-guide/images/path-redundancy-02.png
new file mode 100644
index 0000000..6d4a1f5
Binary files /dev/null and b/docs/books/user-guide/images/path-redundancy-02.png differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/images/path-redundancy-temp-decoupling-01.png
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/images/path-redundancy-temp-decoupling-01.png b/docs/books/user-guide/images/path-redundancy-temp-decoupling-01.png
new file mode 100644
index 0000000..c3c6631
Binary files /dev/null and b/docs/books/user-guide/images/path-redundancy-temp-decoupling-01.png differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/images/path-redundancy-temp-decoupling-02.png
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/images/path-redundancy-temp-decoupling-02.png b/docs/books/user-guide/images/path-redundancy-temp-decoupling-02.png
new file mode 100644
index 0000000..ecab8b1
Binary files /dev/null and b/docs/books/user-guide/images/path-redundancy-temp-decoupling-02.png differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/images/sharded-queue-01.png
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/images/sharded-queue-01.png b/docs/books/user-guide/images/sharded-queue-01.png
new file mode 100644
index 0000000..ab25be0
Binary files /dev/null and b/docs/books/user-guide/images/sharded-queue-01.png differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/images/sharded-queue-02.png
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/images/sharded-queue-02.png b/docs/books/user-guide/images/sharded-queue-02.png
new file mode 100644
index 0000000..7e73e6d
Binary files /dev/null and b/docs/books/user-guide/images/sharded-queue-02.png differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/user-guide/introduction.adoc
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/introduction.adoc b/docs/books/user-guide/introduction.adoc
new file mode 100644
index 0000000..37eb37c
--- /dev/null
+++ b/docs/books/user-guide/introduction.adoc
@@ -0,0 +1,124 @@
+////
+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
+////
+
+[id='introduction']
+= Introduction
+
+[id='overview']
+== Overview
+
+The {RouterName} 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.
+
+A messaging client can make a single AMQP connection into a messaging
+bus built of {RouterName} 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.
+
+The router is an intermediary for messages but it is _not_ a broker. It
+does not _take responsibility for_ 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, _and_ it will route
+the acknowledgement of that message by the ultimate receiver back across
+the same path. This means that _responsibility_ for the message is
+transfered from the original sender to the ultimate receiver __as if
+they were directly connected__. However this is done via a flexible
+network that allows highly configurable routing of the message
+transparent to both sender and receiver.
+
+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.
+
+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 {RouterName} 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.
+
+For an exampe of using {RouterName} 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 {RouterName} network,
+_all_ the receivers are connected to _all_ the brokers. If there is a
+message anywhere it can be delivered to any receiver.
+
+{RouterName} 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.
+
+[id='benefits']
+== Benefits
+
+Simplifies connectivity
+
+* An endpoint can do all of its messaging through a single transport
+connection
+* Avoid opening holes in firewalls for incoming connections
+
+Provides messaging connectivity where there is no TCP/IP connectivity
+
+* 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).
+
+Simplifies reliability
+
+* Reliability and availability are provided using redundant topology,
+not server clustering
+* Reliable end-to-end messaging without persistent stores
+* Use a message broker only when you need store-and-forward semantics
+
+[id='features']
+== Features
+
+* Can be deployed stand-alone or in a network of routers
+** Supports arbitrary network topology - no restrictions on redundancy
++
+- Automatic route computation - adjusts quickly to changes in topology
+* Provides remote access to brokers or other AMQP servers
+* Security
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org
[11/11] qpid-dispatch git commit: DISPATCH-851: Move the new book
into primary position and reorg the docs
Posted by jr...@apache.org.
DISPATCH-851: Move the new book into primary position and reorg the docs
Project: http://git-wip-us.apache.org/repos/asf/qpid-dispatch/repo
Commit: http://git-wip-us.apache.org/repos/asf/qpid-dispatch/commit/f77f92cb
Tree: http://git-wip-us.apache.org/repos/asf/qpid-dispatch/tree/f77f92cb
Diff: http://git-wip-us.apache.org/repos/asf/qpid-dispatch/diff/f77f92cb
Branch: refs/heads/master
Commit: f77f92cbeb5cf88c9ddcd577ab4b2deadb3dedf5
Parents: 7c8f311
Author: Justin Ross <jr...@apache.org>
Authored: Tue Jun 26 14:32:56 2018 -0700
Committer: Justin Ross <jr...@apache.org>
Committed: Tue Jun 26 14:32:56 2018 -0700
----------------------------------------------------------------------
CMakeLists.txt | 2 +-
doc/CMakeLists.txt | 170 ----
doc/README | 48 --
doc/asciidoc.conf.in | 31 -
doc/book/addressing.adoc | 133 ----
doc/book/amqp-mapping.adoc | 175 -----
doc/book/auto_links.adoc | 323 --------
doc/book/basic_usage.adoc | 203 -----
doc/book/book.adoc | 71 --
doc/book/client_compatibility.adoc | 39 -
doc/book/console1.png | Bin 40412 -> 0 bytes
doc/book/console_charts.png | Bin 70070 -> 0 bytes
doc/book/console_entity.png | Bin 69319 -> 0 bytes
doc/book/console_installation.adoc | 68 --
doc/book/console_login.png | Bin 39915 -> 0 bytes
doc/book/console_operation.adoc | 71 --
doc/book/console_overview.adoc | 27 -
doc/book/console_overview.png | Bin 87960 -> 0 bytes
doc/book/console_schema.png | Bin 68025 -> 0 bytes
doc/book/console_topology.png | Bin 67338 -> 0 bytes
doc/book/default_config.adoc | 35 -
doc/book/introduction.adoc | 128 ---
doc/book/link_routing.adoc | 166 ----
doc/book/policy.adoc | 456 -----------
doc/book/schema_txt.py | 109 ---
doc/book/theory_of_operation.adoc | 395 ----------
doc/book/tools.adoc | 92 ---
doc/common/fragment-router-sasl-para.adoc | 20 -
doc/common/fragment-starting-router-step.adoc | 29 -
doc/index.adoc | 35 -
doc/man/help2txt.py | 69 --
doc/man/qdmanage.8.adoc | 139 ----
doc/man/qdrouterd.8.adoc | 54 --
doc/man/qdrouterd.conf.5.py | 155 ----
doc/man/qdstat.8.adoc | 277 -------
doc/new-book/attributes.adoc | 78 --
doc/new-book/book.adoc | 61 --
doc/new-book/common | 1 -
doc/new-book/configuration-connections.adoc | 90 ---
doc/new-book/configuration-reference.adoc | 225 ------
doc/new-book/configuration-security.adoc | 773 -------------------
doc/new-book/cyrus-sasl.adoc | 90 ---
doc/new-book/getting-started.adoc | 156 ----
doc/new-book/images/01-peer-to-peer.png | Bin 20101 -> 0 bytes
doc/new-book/images/balanced-routing.png | Bin 43261 -> 0 bytes
doc/new-book/images/brokered-messaging.png | Bin 50206 -> 0 bytes
doc/new-book/images/closest-routing.png | Bin 39803 -> 0 bytes
doc/new-book/images/console1.png | Bin 40412 -> 0 bytes
doc/new-book/images/console_charts.png | Bin 70070 -> 0 bytes
doc/new-book/images/console_entity.png | Bin 69319 -> 0 bytes
doc/new-book/images/console_login.png | Bin 39915 -> 0 bytes
doc/new-book/images/console_overview.png | Bin 87960 -> 0 bytes
doc/new-book/images/console_schema.png | Bin 68025 -> 0 bytes
doc/new-book/images/console_topology.png | Bin 67338 -> 0 bytes
doc/new-book/images/link-routing.png | Bin 46968 -> 0 bytes
doc/new-book/images/message-routing.png | Bin 35861 -> 0 bytes
doc/new-book/images/multicast-routing.png | Bin 44923 -> 0 bytes
doc/new-book/images/path-redundancy-01.png | Bin 47995 -> 0 bytes
doc/new-book/images/path-redundancy-02.png | Bin 42131 -> 0 bytes
.../path-redundancy-temp-decoupling-01.png | Bin 47766 -> 0 bytes
.../path-redundancy-temp-decoupling-02.png | Bin 49105 -> 0 bytes
doc/new-book/images/sharded-queue-01.png | Bin 28383 -> 0 bytes
doc/new-book/images/sharded-queue-02.png | Bin 62233 -> 0 bytes
doc/new-book/introduction.adoc | 124 ---
doc/new-book/logging.adoc | 346 ---------
doc/new-book/management-entities.adoc | 24 -
doc/new-book/management.adoc | 38 -
doc/new-book/managing-using-qdmanage.adoc | 679 ----------------
doc/new-book/monitoring-using-qdstat.adoc | 392 ----------
doc/new-book/reliability.adoc | 701 -----------------
doc/new-book/revision-info.adoc | 20 -
doc/new-book/routing.adoc | 721 -----------------
.../technical-details-specifications.adoc | 190 -----
doc/new-book/theory_of_operation.adoc | 394 ----------
.../understand-router-configuration.adoc | 206 -----
doc/new-book/using-console.adoc | 126 ---
doc/notes/code-conventions.txt | 32 -
docs/CMakeLists.txt | 27 +
docs/README.md | 40 +
docs/books/CMakeLists.txt | 54 ++
.../books/common/fragment-router-sasl-para.adoc | 20 +
.../common/fragment-starting-router-step.adoc | 29 +
docs/books/old-user-guide/addressing.adoc | 133 ++++
docs/books/old-user-guide/amqp-mapping.adoc | 175 +++++
docs/books/old-user-guide/auto_links.adoc | 323 ++++++++
docs/books/old-user-guide/basic_usage.adoc | 203 +++++
docs/books/old-user-guide/book.adoc | 71 ++
.../old-user-guide/client_compatibility.adoc | 39 +
docs/books/old-user-guide/console1.png | Bin 0 -> 40412 bytes
docs/books/old-user-guide/console_charts.png | Bin 0 -> 70070 bytes
docs/books/old-user-guide/console_entity.png | Bin 0 -> 69319 bytes
.../old-user-guide/console_installation.adoc | 68 ++
docs/books/old-user-guide/console_login.png | Bin 0 -> 39915 bytes
.../books/old-user-guide/console_operation.adoc | 71 ++
docs/books/old-user-guide/console_overview.adoc | 27 +
docs/books/old-user-guide/console_overview.png | Bin 0 -> 87960 bytes
docs/books/old-user-guide/console_schema.png | Bin 0 -> 68025 bytes
docs/books/old-user-guide/console_topology.png | Bin 0 -> 67338 bytes
docs/books/old-user-guide/default_config.adoc | 35 +
docs/books/old-user-guide/introduction.adoc | 128 +++
docs/books/old-user-guide/link_routing.adoc | 166 ++++
docs/books/old-user-guide/policy.adoc | 456 +++++++++++
docs/books/old-user-guide/schema_txt.py | 109 +++
.../old-user-guide/theory_of_operation.adoc | 395 ++++++++++
docs/books/old-user-guide/tools.adoc | 92 +++
docs/books/user-guide/attributes.adoc | 78 ++
docs/books/user-guide/book.adoc | 61 ++
docs/books/user-guide/common | 1 +
.../user-guide/configuration-connections.adoc | 90 +++
.../user-guide/configuration-reference.adoc | 225 ++++++
.../user-guide/configuration-security.adoc | 773 +++++++++++++++++++
docs/books/user-guide/cyrus-sasl.adoc | 90 +++
docs/books/user-guide/getting-started.adoc | 156 ++++
.../books/user-guide/images/01-peer-to-peer.png | Bin 0 -> 20101 bytes
.../user-guide/images/balanced-routing.png | Bin 0 -> 43261 bytes
.../user-guide/images/brokered-messaging.png | Bin 0 -> 50206 bytes
.../books/user-guide/images/closest-routing.png | Bin 0 -> 39803 bytes
docs/books/user-guide/images/console1.png | Bin 0 -> 40412 bytes
docs/books/user-guide/images/console_charts.png | Bin 0 -> 70070 bytes
docs/books/user-guide/images/console_entity.png | Bin 0 -> 69319 bytes
docs/books/user-guide/images/console_login.png | Bin 0 -> 39915 bytes
.../user-guide/images/console_overview.png | Bin 0 -> 87960 bytes
docs/books/user-guide/images/console_schema.png | Bin 0 -> 68025 bytes
.../user-guide/images/console_topology.png | Bin 0 -> 67338 bytes
docs/books/user-guide/images/link-routing.png | Bin 0 -> 46968 bytes
.../books/user-guide/images/message-routing.png | Bin 0 -> 35861 bytes
.../user-guide/images/multicast-routing.png | Bin 0 -> 44923 bytes
.../user-guide/images/path-redundancy-01.png | Bin 0 -> 47995 bytes
.../user-guide/images/path-redundancy-02.png | Bin 0 -> 42131 bytes
.../path-redundancy-temp-decoupling-01.png | Bin 0 -> 47766 bytes
.../path-redundancy-temp-decoupling-02.png | Bin 0 -> 49105 bytes
.../user-guide/images/sharded-queue-01.png | Bin 0 -> 28383 bytes
.../user-guide/images/sharded-queue-02.png | Bin 0 -> 62233 bytes
docs/books/user-guide/introduction.adoc | 124 +++
docs/books/user-guide/logging.adoc | 346 +++++++++
docs/books/user-guide/management-entities.adoc | 24 +
docs/books/user-guide/management.adoc | 38 +
.../user-guide/managing-using-qdmanage.adoc | 679 ++++++++++++++++
.../user-guide/monitoring-using-qdstat.adoc | 392 ++++++++++
docs/books/user-guide/reliability.adoc | 701 +++++++++++++++++
docs/books/user-guide/revision-info.adoc | 20 +
docs/books/user-guide/routing.adoc | 721 +++++++++++++++++
.../technical-details-specifications.adoc | 190 +++++
docs/books/user-guide/theory_of_operation.adoc | 394 ++++++++++
.../understand-router-configuration.adoc | 206 +++++
docs/books/user-guide/using-console.adoc | 126 +++
docs/man/CMakeLists.txt | 125 +++
docs/man/asciidoc.conf.in | 31 +
docs/man/help2txt.py | 69 ++
docs/man/qdmanage.8.adoc | 139 ++++
docs/man/qdrouterd.8.adoc | 54 ++
docs/man/qdrouterd.conf.5.py | 155 ++++
docs/man/qdstat.8.adoc | 277 +++++++
docs/notes/code-conventions.txt | 32 +
154 files changed, 8979 insertions(+), 8986 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/CMakeLists.txt
----------------------------------------------------------------------
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 62b65a8..af2e004 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -237,7 +237,7 @@ if (NOT UNITTEST2_MISSING)
endif(NOT UNITTEST2_MISSING)
add_subdirectory(python)
add_subdirectory(router)
-add_subdirectory(doc)
+add_subdirectory(docs)
add_subdirectory(console)
# reconfigure.in is a workaround to force cmake re-configuration. For example,
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/CMakeLists.txt
----------------------------------------------------------------------
diff --git a/doc/CMakeLists.txt b/doc/CMakeLists.txt
deleted file mode 100644
index 0fc7435..0000000
--- a/doc/CMakeLists.txt
+++ /dev/null
@@ -1,170 +0,0 @@
-##
-## 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.
-##
-
-# In old cmake (< 2.8) documentation is built by "make all" so set BUILD_DOC OFF
-# if you don't want that. For new cmake it is only built by "make doc"
-option(BUILD_DOCS "Generate documentation with 'make doc'" ON)
-option(DOC_VERBOSE "Verbose output from doc tools for debugging" OFF)
-option(DOC_XMLLINT "Use xmllint to verify XML output" OFF)
-
-if(BUILD_DOCS)
- if ("${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}" VERSION_LESS "2.8")
- # OPTIONAL does not exist in install before 2.8 so always make and install docs
- set(DOC_TARGET ALL)
- macro(install_doc)
- install(${ARGN})
- endmacro()
- else()
- macro(install_doc)
- install(${ARGN} OPTIONAL)
- endmacro()
- endif()
-
- # Popular locations
- set(src ${CMAKE_CURRENT_SOURCE_DIR})
- set(bin ${CMAKE_CURRENT_BINARY_DIR})
- set(tools ${CMAKE_SOURCE_DIR}/tools)
- set(schema ../python/qpid_dispatch/management/qdrouter.json)
- set(py_management ../python/qpid_dispatch_internal/management)
- set(schema_depends ${schema} ${py_management}/schema_doc.py ${py_management}/schema.py)
-
- # Flags for doc tools, based on cmake options
- set(ADOC_FLAGS "--conf-file=${bin}/asciidoc.conf")
- set(A2X_FLAGS "--asciidoc-opts=--conf-file=${bin}/asciidoc.conf" -D${bin})
- if (DOC_VERBOSE)
- set(ADOC_FLAGS ${ADOC_FLAGS} -v)
- set(A2X_FLAGS ${A2X_FLAGS} -v)
- endif()
- if (NOT DOC_XMLLINT)
- set(A2X_FLAGS ${A2X_FLAGS} --no-xmllint)
- endif()
-
- # Generate asciidoc fragments from management schema to incorporate in text
- macro(schema_gen script output)
- add_custom_command(
- OUTPUT ${output}
- COMMAND ${RUN} -s ${script} 1> ${output}
- DEPENDS ${script} ${schema_depends})
- list(APPEND GENERATED_TXT "${output}")
- endmacro()
-
- schema_gen(${src}/book/schema_txt.py ${bin}/book/schema.adoc)
- schema_gen(${src}/man/qdrouterd.conf.5.py ${bin}/man/qdrouterd.conf.5.adoc)
-
- # Generate asciidoc .adoc from --help output for man pages
- macro(help2txt program)
- get_filename_component(name ${program} NAME)
- set(output ${bin}/man/${name}_help.adoc)
- add_custom_command(
- OUTPUT ${output}
- COMMAND ${RUN} -s ${src}/man/help2txt.py ${program} --help 1> ${output}
- DEPENDS ${program} ${schema_depends} ${src}/man/help2txt.py)
- list(APPEND GENERATED_TXT "${output}")
- endmacro()
-
- help2txt(${CMAKE_BINARY_DIR}/router/qdrouterd)
- help2txt(${tools}/qdmanage)
- help2txt(${tools}/qdstat)
-
- add_custom_target(doc_gen ALL DEPENDS ${GENERATED_TXT})
- install(DIRECTORY ${src}/book/ DESTINATION ${QD_DOC_INSTALL_DIR})
-
- install(FILES ${bin}/book/schema.adoc DESTINATION ${QD_DOC_INSTALL_DIR})
- install(FILES ${bin}/man/qdrouterd.conf.5.adoc DESTINATION ${QD_DOC_INSTALL_DIR})
-
- EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E copy_directory ${src}/book/ ${bin}/book)
- EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E copy_directory ${src}/man/ ${bin}/man)
-
- find_program(ASCIIDOC_EXE asciidoc DOC "Generate HTML documentation")
- if (ASCIIDOC_EXE)
- configure_file(${src}/asciidoc.conf.in ${bin}/asciidoc.conf)
- configure_file(${src}/index.adoc ${bin}/index.adoc)
-
- # Copy the book dir images for HTML viewing in the build directory.
- # Don't use configure_file since it truncates .png files at 1st ^Z character
-
- # Copy the images. Don't use configure_file since it truncates .png files at 1st ^Z character
- file(GLOB_RECURSE PNG_SRC RELATIVE ${src} *.png)
- foreach(file ${PNG_SRC})
- get_filename_component(name ${file} NAME)
- EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E copy_if_different ${src}/${file} ${bin}/_images/${name})
- endforeach()
-
- # Generate HTML
- file(GLOB_RECURSE ADOC_SRC *.adoc)
- foreach(source index book/book man/qdmanage.8 man/qdrouterd.8 man/qdstat.8 man/qdrouterd.conf.5)
- get_filename_component(name ${source} NAME)
- get_filename_component(dir ${source} PATH)
- string(FIND ${name} "." dot)
- if(dot GREATER 0)
- string(LENGTH ${name} length)
- MATH(EXPR desired_length "${length}-2")
- string(SUBSTRING ${name} "0" ${desired_length} name)
- endif(dot GREATER 0)
- set(output ${bin}/${dir}/${name}.html)
- add_custom_command(
- OUTPUT ${output} ${output}.in
- # Pretty .html for direct viewing.
- COMMAND ${ASCIIDOC_EXE} ${ADOC_FLAGS} -o ${output} ${source}.adoc
- # Raw .html.in body for inclusion in Qpid website.
- COMMAND ${ASCIIDOC_EXE} ${ADOC_FLAGS} -s -o ${output}.in ${source}.adoc
- DEPENDS ${source}.adoc ${GENERATED_TXT} ${ADOC_SRC} ${bin}/asciidoc.conf
- WORKING_DIRECTORY ${bin}
- )
- list(APPEND DOC_DEPENDS ${output})
- install_doc(FILES ${output} DESTINATION ${QD_DOC_INSTALL_DIR})
- endforeach()
-
- find_program(A2X_EXE a2x DOC DOC "Generate Unix man pages")
- if (A2X_EXE)
- # Generate man pages.
- foreach(source ${bin}/man/qdmanage.8 ${bin}/man/qdrouterd.8 ${bin}/man/qdstat.8 ${bin}/man/qdrouterd.conf.5)
- get_filename_component(name ${source} NAME)
- get_filename_component(dir ${source} PATH)
- string(REGEX REPLACE ".*\\.([0-9])$" "\\1" section ${source}) # Man section number
- set(output ${bin}/${name})
- add_custom_command(
- OUTPUT ${output}
- COMMAND ${A2X_EXE} ${A2X_FLAGS} -f manpage -D ${bin} ${source}.adoc
- DEPENDS ${source}.adoc ${GENERATED_TXT})
- list(APPEND DOC_DEPENDS ${output})
- install_doc(FILES ${output} DESTINATION ${CMAKE_INSTALL_PREFIX}/${MAN_INSTALL_DIR}/man${section})
- endforeach()
-
- # Generate PDF if we have the latex tool
- find_program(DBLATEX_EXE dblatex "Generate PDF documentation")
- if (DBLATEX_EXE)
- add_custom_command(
- OUTPUT ${bin}/book.pdf
- COMMAND ${A2X_EXE} ${A2X_FLAGS} -f pdf ${src}/book/book.adoc
- DEPENDS ${src}/book/book.adoc ${GENERATED_TXT})
- list(APPEND DOC_DEPENDS ${bin}/book.pdf)
- install_doc(FILES ${bin}/book.pdf DESTINATION ${QD_DOC_INSTALL_DIR})
- else(DBLATEX_EXE)
- message(STATUS "dblatex not found: not generating PDF")
- endif(DBLATEX_EXE)
- else(A2X_EXE)
- message(STATUS "a2x not found: not generating man pages or PDF")
- endif(A2X_EXE)
- else(ASCIIDOC_EXE)
- message(STATUS "asciidoc not found: not generating HTML, man pages or PDF")
- endif(ASCIIDOC_EXE)
-
- add_custom_target(doc ${DOC_TARGET} DEPENDS ${DOC_DEPENDS})
-endif(BUILD_DOCS)
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/README
----------------------------------------------------------------------
diff --git a/doc/README b/doc/README
deleted file mode 100644
index 52c12e4..0000000
--- a/doc/README
+++ /dev/null
@@ -1,48 +0,0 @@
-////
-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
-////
-
-Building documentation
-----------------------
-
-Documentation is built when you run `make doc`.
-
-(On old versions of cmake it is always built, use `cmake -DBUILD_DOCS=OFF` to
-prevent it being built.)
-
-You need the following tools to build the documentation:
-
-* asciidoc (8.6.8) for HTML book and man pages
-* dblatex (0.3.6) for PDF book.
-
-The versions above are known to work, earlier versions may or may not.
-
-Writing documentation
----------------------
-
-Documentation is written in asciidoc markup. Sub-directories:
-
-* 'book/': Asciidoc source for the user guide.
-* 'man/': Asciidoc source for Unix man pages.
-* 'notes': Developer notes: project information, design notes, or::
- anything else that's primarily of developer interest. These are not
- installed.
-
-Some book chapters are generated by python scripts rather than being text
-files. For example `schema.adoc` is generated by `schema_txt.py` from the
-documentation strings in the management schema `qdrouterd.json`.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/asciidoc.conf.in
----------------------------------------------------------------------
diff --git a/doc/asciidoc.conf.in b/doc/asciidoc.conf.in
deleted file mode 100644
index b122cc4..0000000
--- a/doc/asciidoc.conf.in
+++ /dev/null
@@ -1,31 +0,0 @@
-#
-# 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.
-#
-
-[attributes]
-SYSCONF_INSTALL_DIR=${SYSCONF_INSTALL_DIR}
-CMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}
-QD_DOC_INSTALL_DIR=${QD_DOC_INSTALL_DIR}
-QPID_DISPATCH_VERSION=${QPID_DISPATCH_VERSION}
-
-generated=${CMAKE_CURRENT_BINARY_DIR}
-generated_book=${CMAKE_CURRENT_BINARY_DIR}/book
-generated_man=${CMAKE_CURRENT_BINARY_DIR}/man
-
-[footer-text]
-Qpid Dispatch ${QPID_DISPATCH_VERSION} - generated {localdate} {localtime}
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/book/addressing.adoc
----------------------------------------------------------------------
diff --git a/doc/book/addressing.adoc b/doc/book/addressing.adoc
deleted file mode 100644
index d138425..0000000
--- a/doc/book/addressing.adoc
+++ /dev/null
@@ -1,133 +0,0 @@
-////
-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
-////
-
-[[addressing]]
-Addressing
-----------
-
-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 `to`
-and `reply-to` fields of a message's properties. They are also used
-during the creation of links in the `address` field of a `source` or
-a `target`.
-
-Addresses designate various kinds of entities in a messaging network:
-
-* Endpoint processes that consume data or offer a service
-* Topics that match multiple consumers to multiple producers
-* Entities within a messaging broker:
-** Queues
-** Durable Topics
-** Exchanges
-
-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.
-
-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.
-
-Address semantics include the following considerations:
-
-* _Routing pattern_ - direct, multicast, balanced
-* _Undeliverable action_ - drop, hold and retry, redirect
-* _Reliability_ - N destinations, etc.
-
-[[routing-patterns]]
-Routing patterns
-~~~~~~~~~~~~~~~~
-
-Routing patterns constrain the paths that a message can take across a
-network.
-
-[width="100%",cols="18%,82%",options="header",]
-|=======================================================================
-|_Pattern_ |_Description_
-|_Direct_ |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.
-
-|_Multicast_ |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.
-
-|_Balanced_ |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.
-|=======================================================================
-
-[[routing-mechanisms]]
-Routing mechanisms
-~~~~~~~~~~~~~~~~~~
-
-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 __routing__:
-
-_____________________________________________________________________________________________________________________________________________________________________________________________________________________________________
-In a network built of multiple routers connected by connections (i.e.,
-nodes and edges in a graph), _routing_ determines which connection to
-use to send a message directly to its destination or one step closer to
-its destination.
-_____________________________________________________________________________________________________________________________________________________________________________________________________________________________________
-
-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.
-
-[[message-routing]]
-Message routing
-^^^^^^^^^^^^^^^
-
-Message routing occurs upon delivery of a message and is done based on
-the address in the message's `to` field.
-
-When a delivery arrives on an incoming link, the router extracts the
-address from the delivered message's `to` 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.
-
-[width="100%",cols="20%,80%",options="header",]
-|=======================================================================
-|_Delivery_ |_Handling_
-|_pre-settled_ |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.
-
-|_unsettled_ |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.
-|=======================================================================
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/book/amqp-mapping.adoc
----------------------------------------------------------------------
diff --git a/doc/book/amqp-mapping.adoc b/doc/book/amqp-mapping.adoc
deleted file mode 100644
index 4f540c5..0000000
--- a/doc/book/amqp-mapping.adoc
+++ /dev/null
@@ -1,175 +0,0 @@
-////
-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
-////
-
-[[amqp-mapping]]
-AMQP Mapping
-------------
-
-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.
-
-[[message-annotations]]
-Message Annotations
-~~~~~~~~~~~~~~~~~~~
-
-The following Message Annotation fields are defined by Dispatch Router:
-
-[width="100%",cols="23%,19%,58%",options="header",]
-|=======================================================================
-|_Field_ |_Type_ |_Description_
-|x-opt-qd.ingress |string |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.
-
-|x-opt-qd.trace |list of string |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.
-
-|x-opt-qd.to |string |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 _to_ 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.
-
-|x-opt-qd.phase |integer |The address-phase, if not zero, for messages
-flowing between routers.
-|=======================================================================
-
-[[sourcetarget-capabilities]]
-Source/Target Capabilities
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The following Capability values are used in Sources and Targets.
-
-[width="100%",cols="19%,81%",options="header",]
-|=======================================================================
-|_Capability_ |_Description_
-|qd.router |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.
-
-|qd.router-data |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.
-|=======================================================================
-
-[[dynamic-node-properties]]
-Dynamic-Node-Properties
-~~~~~~~~~~~~~~~~~~~~~~~
-
-The following dynamic-node-properties are used by Dispatch in Sources.
-
-[width="100%",cols="23%,77%",options="header",]
-|=======================================================================
-|_Property_ |_Description_
-|x-opt-qd.address |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.
-|=======================================================================
-
-[[addresses-and-address-formats]]
-Addresses and Address Formats
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The following AMQP addresses and address patterns are used within
-Dispatch Router.
-
-[[address-patterns]]
-Address Patterns
-^^^^^^^^^^^^^^^^
-
-[width="100%",cols="38%,62%",options="header",]
-|=======================================================================
-|_Pattern_ |_Description_
-|`_local/<addr>` |An address that references a locally attached endpoint.
-Messages using this address pattern shall not be routed over more than
-one link.
-
-|`_topo/0/<router>/<addr>` |
-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.
-
-The '0' component immediately preceding the router-id is a placeholder
-for an _area_ which may be used in the future if area routing is
-implemented.
-
-|`<addr>` |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.
-|=======================================================================
-
-[[supported-addresses]]
-Supported Addresses
-^^^^^^^^^^^^^^^^^^^
-
-[width="100%",cols="36%,64%",options="header",]
-|=======================================================================
-|_Address_ |_Description_
-|`$management` |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.
-
-|`_topo/0/Router.E/$management` |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.
-
-|`_local/qdhello` |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.
-
-|`_local/qdrouter` |The router entity in each of the connected routers.
-This address is used by a router to communicate with other routers in
-the network.
-
-|`_topo/0/Router.E/qdrouter` |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.
-|=======================================================================
-
-[[implementation-of-the-amqp-management-specification]]
-Implementation of the AMQP Management Specification
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Qpid Dispatch is manageable remotely via AMQP. It is compliant with the
-emerging AMQP Management specification (draft 9).
-
-Differences from the specification:
-
-- The `name` 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.
-- The `REGISTER` and `DEREGISTER` operations are not implemented. The router
- automatically discovers peer routers via the router network and makes
- their management addresses available via the standard `GET-MGMT-NODES`
- operation.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/book/auto_links.adoc
----------------------------------------------------------------------
diff --git a/doc/book/auto_links.adoc b/doc/book/auto_links.adoc
deleted file mode 100644
index 5ef8bc7..0000000
--- a/doc/book/auto_links.adoc
+++ /dev/null
@@ -1,323 +0,0 @@
-////
-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
-////
-
-[[indirect-waypoints-and-auto-links]]
-Indirect Waypoints and Auto-Links
----------------------------------
-
-This feature was introduced in Qpid Dispatch 0.6. It is a significant
-improvement on an earlier somewhat experimental feature called
-Waypoints.
-
-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.
-
-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:
-
-_________________________________________________________________________________________
-* The name of the connector/listener that resulted in the connection of
-the container, or
-* The AMQP container-id of the remote container.
-_________________________________________________________________________________________
-
-[[queue-waypoint-example]]
-Queue Waypoint Example
-~~~~~~~~~~~~~~~~~~~~~~
-
-Here is an example configuration for routing messages deliveries through
-a pair of queues on a broker:
-
-----
-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
-}
-----
-
-The +address+ entity identifies a namespace 'queue.' that will be used
-for routing messages through queues via autolinks. The four +autoLink+ entities
-identify the head and tail of two queues on the broker that will be connected
-via auto-links.
-
-If there is no broker connected, the auto-links shall remain
-_inactive_. This can be observed by using the `qdstat` tool:
-
----------------------------
-$ 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
----------------------------
-
-If a broker comes online with a queue called 'queue.first', the
-auto-links will attempt to activate:
-
---------------------
-$ 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
---------------------
-
-Note that two of the auto-links are in _failed_ state because the queue
-does not exist on the broker.
-
-If we now use the Qpid Proton example application `simple_send.py` to send
-three messages to 'queue.first' via the router:
-
---------------------------
-$ python simple_send.py -a 127.0.0.1/queue.first -m3
-all messages confirmed
---------------------------
-
-and then look at the address statistics on the router:
-
-----------------------------
-$ 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
-----------------------------
-
-we see that 'queue.first' appears twice in the list of addresses. The
-+phs+, or phase column shows that there are two phases for the
-address. Phase '0' is for routing message deliveries from producers to
-the tail of the queue (the +out+ auto-link associated with the queue).
-Phase 1 is for routing deliveries from the head of the queue to
-subscribed consumers.
-
-Note that three deliveries have been counted in the "in" and "out"
-columns for phase '0'. The "in" column represents the three messages
-that arrived from `simple_send.py` and the +out+ column represents the three
-deliveries to the queue on the broker.
-
-If we now use `simple_recv.py` to receive three messages from this address:
-
---------------
-$ 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)}
---------------
-
-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.
-
-----------------------------
-$ 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
-----------------------------
-
-Note that even in a multi-router network, and with multiple producers
-and consumers for 'queue.first', all deliveries will be routed through
-the queue on the connected broker.
-
-[[sharded-queue-example]]
-Sharded Queue Example
-~~~~~~~~~~~~~~~~~~~~~
-
-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.
-
-----
-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
-}
-----
-
-In the above configuration, there are two instances of _queue.first_ on
-brokers 1 and 2. Message traffic from producers to address _queue.first_
-shall be balanced between the two instance and messages from the queues
-shall be balanced across the collection of subscribers to the same
-address.
-
-[[dynamically-adding-shards]]
-Dynamically Adding Shards
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-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 `qdmanage`:
-
-----
-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
-----
-
-[[address-renaming]]
-Using a Different External Address on an Auto-Link
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-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 +externalAddr+ that
-allows the waypoint to have a different address than that which is
-used by the senders and receivers.
-
-Here's an example:
-
-----
-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
-}
-
-----
-
-In the above configuration, the router network provides waypoint
-routing for the address _queue.first_, 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.
-
-In this example, the endpoints (senders and receivers) are unaware of
-the _broker_queue_ address and simply interact with _queue.first_.
-Likewise, the broker is unaware of the _queue.first_ address and
-behaves as though a sender and a receiver is attached each using the
-address _broker_queue_.
-
-The +qdstat+ tool shows the external address for auto-links.
-
---------------------
-$ 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
---------------------
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/book/basic_usage.adoc
----------------------------------------------------------------------
diff --git a/doc/book/basic_usage.adoc b/doc/book/basic_usage.adoc
deleted file mode 100644
index 2eb030a..0000000
--- a/doc/book/basic_usage.adoc
+++ /dev/null
@@ -1,203 +0,0 @@
-////
-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
-////
-
-[[basic-usage-and-examples]]
-Basic Usage and Examples
-------------------------
-
-[[standalone-and-interior-modes]]
-Standalone and Interior Modes
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The router can operate stand-alone or as a node in a network of routers.
-The mode is configured in the _router_ 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.
-
-If your router is running in stand-alone mode, _qdstat -a_ will look
-like the following:
-
------------------------------------------------------------------------------------------------------------------
-$ 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
------------------------------------------------------------------------------------------------------------------
-
-Note that there are a number of known addresses. _$management_ is the
-address of the router's embedded management agent.
-_temp.1GThUllfR7N+BDP_ is the temporary reply-to address of the _qdstat_
-client making requests to the agent.
-
-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:
-
--------------------------------------------------------------------------------------------------------------------
-$ 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
--------------------------------------------------------------------------------------------------------------------
-
-[[mobile-subscribers]]
-Mobile Subscribers
-~~~~~~~~~~~~~~~~~~
-
-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.
-
-To illustrate a subscription on a stand-alone router, you can use the
-examples that are provided with Qpid Proton. Using the _simple_recv.py_
-example receiver:
-
--------------------------------------------------
-$ python ./simple_recv.py -a 127.0.0.1/my-address
--------------------------------------------------
-
-This command creates a receiving link subscribed to the specified
-address. To verify the subscription:
-
------------------------------------------------------------------------------------------------------------------
-$ 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
------------------------------------------------------------------------------------------------------------------
-
-You can then, in a separate command window, run a sender to produce
-messages to that address:
-
--------------------------------------------------
-$ python ./simple_send.py -a 127.0.0.1/my-address
--------------------------------------------------
-
-[[dynamic-reply-to]]
-Dynamic Reply-To
-~~~~~~~~~~~~~~~~
-
-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.
-
--------------------------------------------------------------------
-#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();
-}
--------------------------------------------------------------------
-
-The equivalent program written in Python against the Proton Messenger
-API:
-
-----------------------------------------------------------------
-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()
-----------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/book/book.adoc
----------------------------------------------------------------------
diff --git a/doc/book/book.adoc b/doc/book/book.adoc
deleted file mode 100644
index a51419a..0000000
--- a/doc/book/book.adoc
+++ /dev/null
@@ -1,71 +0,0 @@
-////
-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
-////
-
-Qpid Dispatch Router Book
-=========================
-:toc:
-:numbered:
-:doctype: book
-
-include::introduction.adoc[]
-include::theory_of_operation.adoc[]
-
-[[using-qpid-dispatch]]
-Using Qpid Dispatch
--------------------
-
-:leveloffset: 1
-
-include::default_config.adoc[]
-include::tools.adoc[]
-include::basic_usage.adoc[]
-include::link_routing.adoc[]
-include::auto_links.adoc[]
-
-:leveloffset: 0
-
-:leveloffset: 2
-
-include::policy.adoc[]
-
-:leveloffset: 0
-
-[[technical-details-and-specifications]]
-Technical Details and Specifications
-------------------------------------
-
-:leveloffset: 1
-
-include::client_compatibility.adoc[]
-include::addressing.adoc[]
-include::amqp-mapping.adoc[]
-include::{generated_book}/schema.adoc[]
-
-:leveloffset: 0
-
-[[console]]
-Console
--------
-:leveloffset: 1
-
-include::console_overview.adoc[]
-include::console_installation.adoc[]
-include::console_operation.adoc[]
-
-:leveloffset: 0
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/book/client_compatibility.adoc
----------------------------------------------------------------------
diff --git a/doc/book/client_compatibility.adoc b/doc/book/client_compatibility.adoc
deleted file mode 100644
index 7930240..0000000
--- a/doc/book/client_compatibility.adoc
+++ /dev/null
@@ -1,39 +0,0 @@
-////
-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
-////
-
-[[client-compatibility]]
-Client Compatibility
---------------------
-
-Dispatch Router should, in theory, work with any client that is
-compatible with AMQP 1.0. The following clients have been tested:
-
-[width="100%",cols="22%,78%",options="header",]
-|=======================================================================
-|_Client_ |_Notes_
-|qpid::messaging |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.
-
-|Proton Reactor |The Proton Reactor API is compatible with Dispatch
-Router.
-
-|Proton Messenger |Messenger works with Dispatch Router.
-|=======================================================================
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/book/console1.png
----------------------------------------------------------------------
diff --git a/doc/book/console1.png b/doc/book/console1.png
deleted file mode 100644
index f131884..0000000
Binary files a/doc/book/console1.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/book/console_charts.png
----------------------------------------------------------------------
diff --git a/doc/book/console_charts.png b/doc/book/console_charts.png
deleted file mode 100644
index 169c2ca..0000000
Binary files a/doc/book/console_charts.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/book/console_entity.png
----------------------------------------------------------------------
diff --git a/doc/book/console_entity.png b/doc/book/console_entity.png
deleted file mode 100644
index 130c7e7..0000000
Binary files a/doc/book/console_entity.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/book/console_installation.adoc
----------------------------------------------------------------------
diff --git a/doc/book/console_installation.adoc b/doc/book/console_installation.adoc
deleted file mode 100644
index cda9f18..0000000
--- a/doc/book/console_installation.adoc
+++ /dev/null
@@ -1,68 +0,0 @@
-////
-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
-////
-
-[[console-installation]]
-Console installation
---------------------
-
-[[prerequisites]]
-Prerequisites
-~~~~~~~~~~~~~
-
-The following need to be installed before running a console:
-
-* One or more dispatch routers. See the documentation for the dispatch
-router for help in starting a router network.
-* A websockets to tcp proxy.
-* A web server. This can be any server capable of serving static
-html/js/css/image files.
-
-To install a websockets to tcp proxy:
-
-----
-sudo dnf install python-websockify
-websockify localhost:5673 localhost:5672
-----
-
-This will start the proxy listening to ws traffic on port 5673 and
-translating it to tcp on port 5672. One of the routers in the network
-needs to have a listener configured on port 5672. That listener's role
-should be 'normal'. For example:
-
-----
-listener {
- host: 0.0.0.0
- role: normal
- port: amqp
- saslMechanisms: ANONYMOUS
-}
-----
-
-[[the-console-files]]
-The console files
-~~~~~~~~~~~~~~~~~
-
-The files for the console are located under the console/stand-alone
-directory in the source tree
-* 'index.html'
-* 'plugin/'
-
-Copy these files to a directory under the the html or webapps directory
-of your web server. For example, for apache tomcat the files should be
-under webapps/dispatch. Then the console is available as 'http://localhost:8080/dispatch'
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/book/console_login.png
----------------------------------------------------------------------
diff --git a/doc/book/console_login.png b/doc/book/console_login.png
deleted file mode 100644
index 63e22c6..0000000
Binary files a/doc/book/console_login.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/book/console_operation.adoc
----------------------------------------------------------------------
diff --git a/doc/book/console_operation.adoc b/doc/book/console_operation.adoc
deleted file mode 100644
index 233ffc8..0000000
--- a/doc/book/console_operation.adoc
+++ /dev/null
@@ -1,71 +0,0 @@
-////
-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
-////
-[[console-operation]]
-Console operation
------------------
-
-[[logging-in-to-a-router-network]]
-Logging in to a router network
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-image:console_login.png[image]
-
-Enter the address of the websockets to tcp proxy that is connected to a router in the network.
-
-The Autostart checkbox, when checked, will automatically log in with the previous host:port the next time you start the console.
-
-[[overview-page]]
-Overview page
-~~~~~~~~~~~~~
-
-image:book/console_overview.png[image]
-
-On the overview page, aggregate information about routers, addresses, and connections is displayed.
-
-[[topology-page]]
-Topology page
-~~~~~~~~~~~~~
-
-image:console_topology.png[image]
-
-This page displays the router network in a graphical form showing how the routers are connected and information about the individual routers and links.
-
-[[list-page]]
-List page
-~~~~~~~~~
-
-image:console_entity.png[image]
-
-Displays detailed information about entities such as routers, links, addresses, memory.
-
-[[charts-page]]
-Charts page
-~~~~~~~~~~~
-
-image:console_charts.png[image]
-
-This page displays graphs of numeric values that are on the list page.
-
-[[schema-page]]
-Schema page
-~~~~~~~~~~~
-
-image:console_schema.png[image]
-
-This page displays the json schema that is used to manage the router network.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/book/console_overview.adoc
----------------------------------------------------------------------
diff --git a/doc/book/console_overview.adoc b/doc/book/console_overview.adoc
deleted file mode 100644
index 10cf023..0000000
--- a/doc/book/console_overview.adoc
+++ /dev/null
@@ -1,27 +0,0 @@
-////
-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
-////
-[[console-overview]]
-Console overview
-----------------
-
-The console is an HTML based web site that displays information about a qpid dispatch router network.
-
-The console requires an HTML web server that can serve static html, javascript, style sheets, and images.
-
-The console only provides limited information about the clients that are attached to the router network and is therfore more appropriate for administrators needing to know the layout and health of the router network.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/book/console_overview.png
----------------------------------------------------------------------
diff --git a/doc/book/console_overview.png b/doc/book/console_overview.png
deleted file mode 100644
index af25f36..0000000
Binary files a/doc/book/console_overview.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/book/console_schema.png
----------------------------------------------------------------------
diff --git a/doc/book/console_schema.png b/doc/book/console_schema.png
deleted file mode 100644
index ba56c7b..0000000
Binary files a/doc/book/console_schema.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/book/console_topology.png
----------------------------------------------------------------------
diff --git a/doc/book/console_topology.png b/doc/book/console_topology.png
deleted file mode 100644
index ae4b22a..0000000
Binary files a/doc/book/console_topology.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/book/default_config.adoc
----------------------------------------------------------------------
diff --git a/doc/book/default_config.adoc b/doc/book/default_config.adoc
deleted file mode 100644
index b0122be..0000000
--- a/doc/book/default_config.adoc
+++ /dev/null
@@ -1,35 +0,0 @@
-////
-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
-////
-
-[[configuration]]
-Configuration
--------------
-
-The default configuration file is installed in
-'{CMAKE_INSTALL_PREFIX}/etc/qpid-dispatch/qdrouterd.conf'. This configuration file will
-cause the router to run in standalone mode, listening on the standard
-AMQP port (5672). Dispatch Router looks for the configuration file in
-the installed location by default. If you wish to use a different path,
-the "-c" command line option will instruct Dispatch Router as to which
-configuration to load.
-
-To run the router, invoke the executable: `qdrouterd [-c my-config-file]`
-
-For more details of the configuration file see the 'qdrouterd.conf(5)' man
-page.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/book/introduction.adoc
----------------------------------------------------------------------
diff --git a/doc/book/introduction.adoc b/doc/book/introduction.adoc
deleted file mode 100644
index 8a67bc9..0000000
--- a/doc/book/introduction.adoc
+++ /dev/null
@@ -1,128 +0,0 @@
-////
-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
-////
-
-[[introduction]]
-Introduction
-------------
-
-[[overview]]
-Overview
-~~~~~~~~
-
-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.
-
-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.
-
-The router is an intermediary for messages but it is _not_ a broker. It
-does not _take responsibility for_ 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, _and_ it will route
-the acknowledgement of that message by the ultimate receiver back across
-the same path. This means that _responsibility_ for the message is
-transfered from the original sender to the ultimate receiver __as if
-they were directly connected__. However this is done via a flexible
-network that allows highly configurable routing of the message
-transparent to both sender and receiver.
-
-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.
-
-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.
-
-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,
-_all_ the receivers are connected to _all_ the brokers. If there is a
-message anywhere it can be delivered to any receiver.
-
-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.
-
-[[benefits]]
-Benefits
-~~~~~~~~
-
-Simplifies connectivity
-
-* An endpoint can do all of its messaging through a single transport
-connection
-* Avoid opening holes in firewalls for incoming connections
-
-Provides messaging connectivity where there is no TCP/IP connectivity
-
-* 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).
-
-Simplifies reliability
-
-* Reliability and availability are provided using redundant topology,
-not server clustering
-* Reliable end-to-end messaging without persistent stores
-* Use a message broker only when you need store-and-forward semantics
-
-[[features]]
-Features
-~~~~~~~~
-
-* Can be deployed stand-alone or in a network of routers
-** Supports arbitrary network topology - no restrictions on redundancy
-+
-- Automatic route computation - adjusts quickly to changes in topology
-* Provides remote access to brokers or other AMQP servers
-* Security
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/book/link_routing.adoc
----------------------------------------------------------------------
diff --git a/doc/book/link_routing.adoc b/doc/book/link_routing.adoc
deleted file mode 100644
index bc52230..0000000
--- a/doc/book/link_routing.adoc
+++ /dev/null
@@ -1,166 +0,0 @@
-////
-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
-////
-
-[[link-routing]]
-Link Routing
-------------
-
-This feature was introduced in Qpid Dispatch 0.4. This feature was
-significantly updated in Qpid Dispatch 0.6.
-
-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.
-
-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.
-
-Why would one want to do this? One reason is to provide client
-isolation. A network like the following can be deployed:
-
-----
-
- Public Network
- +-----------------+
- | +-----+ |
- | B1 | Rp | |
- | +/--\-+ |
- | / \ |
- | / \ |
- +----/--------\---+
- / \
- / \
- / \
- Private Net A / \ Private Net B
- +--------------/--+ +---\-------------+
- | +---/-+ | | +--\--+ |
- | B2 | Ra | | | | Rb | C1 |
- | +-----+ | | +-----+ |
- | | | |
- | | | |
- +-----------------+ +-----------------+
-----
-
-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.
-
-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.
-
-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.
-
-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.
-
-[[link-routing-configuration]]
-Configuration
-~~~~~~~~~~~~~
-
-Starting with the configured topology shown above, how is link-routing
-configured to support the example described above?
-
-First, router Ra needs to be told how to make a connection to the broker
-B2:
-
-------------------------------
-connector {
- name: broker
- role: route-container
- host: <B2-url>
- port: <B2-port>
- saslMechanisms: ANONYMOUS
-}
-------------------------------
-
-This _route-container_ 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.
-
-Now, the router must be configured to route certain addresses to B2:
-
-----------------------
-linkRoute {
- prefix: b2
- direction: in
- connection: broker
-}
-
-linkRoute {
- prefix: b2
- direction: out
- connection: broker
-}
-----------------------
-
-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).
-
-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.
-
-Examples of addresses that "begin with 'b2'" include:
-
- * b2
- * b2.queues
- * b2.queues.app1
-
-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.
-
-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.
-
-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.
-
-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.
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org
[09/11] qpid-dispatch git commit: DISPATCH-851: Move the new book
into primary position and reorg the docs
Posted by jr...@apache.org.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/configuration-reference.adoc
----------------------------------------------------------------------
diff --git a/doc/new-book/configuration-reference.adoc b/doc/new-book/configuration-reference.adoc
deleted file mode 100644
index 9ea6a12..0000000
--- a/doc/new-book/configuration-reference.adoc
+++ /dev/null
@@ -1,225 +0,0 @@
-////
-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
-////
-
-[id='router-configuration-reference']
-
-// This config reference could stand to be cleaned up. Also, some of the introductory content is no longer necessary since it's covered in the introductory chapter about configuration. We should just link to it instead of repeating it here.
-
-= Configuration Reference
-
-The {RouterName} component behavior is totally configurable using a configuration file which can be passed as parameter (with the `--conf` option) on the command line when running it. After installation, a default configuration file is placed at the following path :
-
-[options="nowrap"]
-----
-[install-prefix]/etc/qpid-dispatch/qdrouterd.conf
-----
-
-This file is used when the router is started without specify configuration file path on the command line and when it is started as a service. In case of starting router on the command line the configuration file can be placed anywhere on the file system.
-
-== Configuration File
-
-The configuration file is made up of sections with following syntax :
-
-[options="nowrap"]
-----
-sectionName {
- attributeName: attributeValue
- attributeName: attributeValue
- ...
-}
-----
-
-A section could be referenced by another section using its `name` attribute. An example is the _sslProfile_ section which describes attributes for setting SSL/TLS configuration and can be applied to one or more _listener_ and _connector_ sections.
-
-[options="nowrap"]
-----
-sslProfile {
- name: ssl-profile-one
- caCertFile: ca-certificate-1.pem
- certFile: server-certificate-1.pem
- privateKeyFile: server-private-key.pem
-}
-
-listener {
- sslProfile: ssl-profile-one
- host: 0.0.0.0
- port: amqp
- saslMechanisms: ANONYMOUS
-}
-----
-
-In the above example, the _sslProfile_ section named _ssl-profile-one_ is used to define the _sslProfile_ attribute for the _listener_ section.
-
-=== Configuration Sections
-
-[id='router-configuration-file-sslprofile']
-==== sslProfile
-
-Attributes for setting SSL/TLS configuration for connections.
-
-* *_caCertFile_* (path) : The absolute path to the database that contains the public certificates of trusted certificate authorities (CA).
-* *_certFile_* (path) : 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.
-* *_privateKeyFile_* (path) : The absolute path to the file containing the PEM-formatted private key for the above certificate.
-* *_passwordFile_* (path) : If the above private key is password protected, this is the absolute path to a file containing the password that unlocks the certificate key.
-* *_password_* (string) : 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 ‘password’ option. Don’t use both password and passwordFile in the same profile.
-* *_uidFormat_* (string) : A list of x509 client certificate fields that will be used to build a string that will uniquely identify the client certificate owner. For example, a value of ‘cou’ 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 ‘oF’ indicates that the uid will consist of o (organization name) concatenated with F (the sha256 fingerprint of the entire certificate) . Allowed values can be any combination of comma separated ‘c’( ISO3166 two character country code), ‘s’(state or province), ‘l’(Locality; generally - city), ‘o’(Organization - Company Name), ‘u’(Organization Unit - typically certificate type or brand), ‘n’(CommonName - typically a username for client certificates) and ‘1’(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).
-* *_uidNameMappingFile_* (string) : The absolute path to the file containing the unique id to display name mapping.
-* *_name_* (string) : The name of the profile used for referencing it from _listener_ and _connector_ sections.
-
-*Used by* : _listener_, _connector_.
-
-[id='router-configuration-file-router']
-==== router
-
-Describe main information about the router related to identity, internal processes and inter routers communication.
-
-
-* *_id_* (string) : Router’s unique identity. It is required and the router will fail to start without it.
-* *_mode_* (One of [`standalone`, `interior`], default=`standalone`) : 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.
-* *_helloIntervalSeconds_* (integer, default=`1`) : Interval in seconds between HELLO messages sent to neighbor routers in order to announce its presence (as a keep alive).
-* *_helloMaxAgeSeconds_* (integer, default=`3`) : Time in seconds after which a neighbor router is declared lost if no HELLO is received.
-* *_raIntervalSeconds_* (integer, default=`30`) : Interval in seconds between Router-Advertisements sent to all routers in a stable network.
-* *_raIntervalFluxSeconds_* (integer, default=`4`) : Interval in seconds between Router-Advertisements sent to all routers during topology fluctuations.
-* *_remoteLsMaxAgeSeconds_* (integer, default=`60`) : Time in seconds after which link state is declared stale if no RA is received.
-* *_workerThreads_* (integer, default=`4`) : The number of threads that will be created to process message traffic and other application work (timers, non-amqp file descriptors, and so on).
-* *_debugDump_* (path) : The absolute path for a file to dump debugging information that can’t be logged normally.
-* *_saslConfigDir_* (path) : The absolute path to the SASL configuration file.
-* *_saslConfigName_* (string, default=`qdrouterd`) : Name of the SASL configuration. This string + ‘.conf’ is the name of the configuration file.
-
-[id='router-configuration-file-listener']
-==== listener
-
-Listens for incoming connections to the router.
-
-* *_host_* (string, default=`127.0.0.1`) : IP address: ipv4 or ipv6 literal or a hostname.
-* *_port_* (string, default=`amqp`) : Port number or symbolic service name.
-* *_protocolFamily_* (One of [`IPv4`, `IPv6`]) : IPv4: Internet Protocol version 4; IPv6: Internet Protocol version 6. If not specified, the protocol family will be automatically determined from the address.
-* *_role_* (One of [`normal`, `inter-router`, `route-container`], default=`normal`) : 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. The route-container role can be used for router-container connections, for example, a router-broker connection.
-* *_cost_* (integer, default=`1`) : For the `inter-route` 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.
-* *_saslMechanisms_* (string) : Space separated list of accepted SASL authentication mechanisms.
-* *_authenticatePeer_* (boolean) : yes: Require the peer’s identity to be authenticated; no: Do not require any authentication.
-* *_requireEncryption_* (boolean) : yes: Require the connection to the peer to be encrypted; no: Permit non-encrypted communication with the peer. It is related to SASL mechanisms which support encryption.
-* *_requireSsl_* (boolean) : yes: Require the use of SSL/TLS on the connection; no: Allow clients to connect without SSL/TLS.
-* *_trustedCertsFile_* (path) : This optional setting can be used to reduce the set of available CAs for client authentication. If used, this setting must provide an absolute path to a PEM file that contains the trusted certificates.
-* *_maxFrameSize_* (integer, default=`16384`) : 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.
-* *_idleTimeoutSeconds_* : (integer, default=`16`) : 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.
-* *_initialHandshakeTimeoutSeconds_* (integer, default=`0`): The number of seconds after a connection transport is established that the router waits for the connecting client to complete the initial handshake and send the `AMQP OPEN` frame. If this timeout is exceeded, the connection is dropped. The default value is `0`, which means that no timeout is applied.
-* *_stripAnnotations_* (One of [`in`, `out`, `both`, `no`], default=`both`) : 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.
-* *_linkCapacity_* (integer) : 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.
-* *_sslProfile_* (string) : The name of the _sslProfile_ entity to use in order to have SSL/TLS configuration.
-* *_http_* (boolean): If set to `yes`, the listener will accept HTTP connections using AMQP over WebSockets.
-
-[id='router-configuration-file-connector']
-==== connector
-
-Establishes an outgoing connection from the router.
-
-* *_name_* (string) : Name using to reference the connector in the configuration file for example for a link routing to queue on a broker.
-* *_host_* (string, default=`127.0.0.1`) : IP address: ipv4 or ipv6 literal or a hostname.
-* *_port_* (string, default=`amqp`) : Port number or symbolic service name.
-* *_protocolFamily_* (One of [`IPv4`, `IPv6`]) : IPv4: Internet Protocol version 4; IPv6: Internet Protocol version 6. If not specified, the protocol family will be automatically determined from the address.
-* *_role_* (One of [`normal`, `inter-router`, `route-container`], default=`normal`) : 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.
-* *_cost_* (integer, default=`1`) : For the ‘inter-router’ 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.
-* *_saslMechanisms_* (string) : Space separated list of accepted SASL authentication mechanisms.
-* *_allowRedirect_* (boolean, default=True) : Allow the peer to redirect this connection to another address.
-* *_maxFrameSize_* (integer, default=`65536`) : 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.
-* *_idleTimeoutSeconds_* (integer, default=`16`) : 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.
-* *_stripAnnotations_* (One of [`in`, `out`, `both`, `no`], default=`both`) : 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.
-* *_linkCapacity_* (integer) : 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.
-* *_verifyHostname_* (boolean, default=True) : yes: Ensures that when initiating a connection (as a client) the hostname in the URL to which this connector connects to matches the hostname in the digital certificate that the peer sends back as part of the SSL/TLS connection; no: Does not perform hostname verification
-* *_saslUsername_* (string) : The username that the connector is using to connect to a peer.
-* *_saslPassword_* (string) : The password that the connector is using to connect to a peer.
-* *_sslProfile_* (string) : The name of the _sslProfile_ entity to use in order to have SSL/TLS configuration.
-
-[id='router-configuration-file-log']
-==== log
-
-Configure logging for a particular module which is part of the router. You can use the UPDATE operation to change log settings while the router is running.
-
-* *_module_* (One of [`ROUTER`, `ROUTER_CORE`, `ROUTER_HELLO`, `ROUTER_LS`, `ROUTER_MA`, `MESSAGE`, `SERVER`, `AGENT`, `CONTAINER`, `ERROR`, `POLICY`, `DEFAULT`], required) : Module to configure. The special module `DEFAULT` specifies defaults for all modules.
-* *_enable_* (string, default=`default`, required) 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 `+` to enable that level and above. For example `trace,debug,warning+` means enable trace, debug, warning, error and critical. The value ‘none’ means disable logging for the module. The value `default` means use the value from the `DEFAULT` module.
-* *_includeTimestamp_* (boolean) : Include timestamp in log messages.
-* *_includeSource_* (boolean) : Include source file and line number in log messages.
-* *_outputFile_* (string) : Where to send log messages. Can be `stderr`, `syslog` or a file name.
-
-[id='router-configuration-file-address']
-==== address
-
-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.
-
-* *_prefix_* (string, required) : The address prefix for the configured settings.
-* *_distribution_* (One of [`multicast`, `closest`, `balanced`], default=`balanced`) : Treatment of traffic associated with the address.
-* *_waypoint_* (boolean) : Designates this address space as being used for waypoints. This will cause the proper address-phasing to be used.
-* *_ingressPhase_* (integer) : Advanced - Override the ingress phase for this address.
-* *_egressPhase_* (integer) : Advanced - Override the egress phase for this address.
-
-[id='router-configuration-file-linkroute']
-==== linkRoute
-
-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.
-
-* *_prefix_* (string, required) : The address prefix for the configured settings.
-* *_containerId_* (string) : it specifies that the link route will be activated if a remote container will provide a container-id matching with this value.
-* *_connection_* (string) : The name from a connector or listener.
-* *_distribution_* (One of [`linkBalanced`], default=`linkBalanced`) : Treatment of traffic associated with the address.
-* *_direction_* (One of [`in`, `out`], required) : The permitted direction of links. It is defined from a router point of view so ‘in’ means client senders (router ingress) and ‘out’ means client receivers (router egress).
-
-[id='router-configuration-file-autolink']
-==== autoLink
-
-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, and so on.).
-
-* *_addr_* (string, required) : The address of the provisioned object.
-* *_direction_* (One of [`in`, `out`], required) : The direction of the link to be created. In means into the router, out means out of the router.
-* *_phase_* (integer) : The address phase for this link. Defaults to `0` for `out` links and `1` for `in` links.
-* *_containerId_* (string) : ContainerID for the target container.
-* *_connection_* (string) : The name from a connector or listener.
-
-==== console
-
-Start a websocket/tcp proxy and http file server to serve the web console.
-
-* *_listener_* (string) : The name of the listener to send the proxied tcp traffic to.
-* *_wsport_* (integer, default=`5673`) : The port on which to listen for websocket traffic.
-* *_proxy_* (string) : The full path to the proxy program to run.
-* *_home_* (string) : The full path to the html/css/js files for the console.
-* *_args_* (string) : Optional args to pass to the proxy program for logging, authentication, and so on.
-
-==== policy
-
-Defines global connection limit
-
-* *_maximumConnections_* (integer) : Global maximum number of concurrent client connections allowed. Zero implies no limit. This limit is always enforced even if no other policy settings have been defined.
-* *_enableAccessRules_* (boolean) : Enable user rule set processing and connection denial.
-* *_policyFolder_* (path) : The absolute path to a folder that holds policyRuleset definition .json files. For a small system the rulesets may all be defined in this file. At a larger scale it is better to have the policy files in their own folder and to have none of the rulesets defined here. All rulesets in all .json files in this folder are processed.
-* *_defaultApplication_* (string) : Application policyRuleset to use for connections with no open.hostname or a hostname that does not match any existing policy. For users that don’t wish to use open.hostname or any multi-tennancy feature, this default policy can be the only policy in effect for the network.
-* *_defaultApplicationEnabled_* (boolean) : Enable defaultApplication policy fallback logic.
-
-==== policyRuleset
-
-Per application definition of the locations from which users may connect and the groups to which users belong.
-
-* *_maxConnections_* (integer) : Maximum number of concurrent client connections allowed. Zero implies no limit.
-* *_maxConnPerUser_* (integer) : Maximum number of concurrent client connections allowed for any single user. Zero implies no limit.
-* *_maxConnPerHost_* (integer) : Maximum number of concurrent client connections allowed for any remote host. Zero implies no limit.
-* *_userGroups_* (map) : A map where each key is a user group name and the corresponding value is a CSV string naming the users in that group. Users who are assigned to one or more groups are deemed ‘restricted’. Restricted users are subject to connection ingress policy and are assigned policy settings based on the assigned user groups. Unrestricted users may be allowed or denied. If unrestricted users are allowed to connect then they are assigned to user group default.
-* *_ingressHostGroups_* (map) : A map where each key is an ingress host group name and the corresponding value is a CSV string naming the IP addresses or address ranges in that group. IP addresses may be FQDN strings or numeric IPv4 or IPv6 host addresses. A host range is two host addresses of the same address family separated with a hyphen. The wildcard host address ‘*’ represents any host address.
-* *_ingressPolicies_* (map) : A map where each key is a user group name and the corresponding value is a CSV string naming the ingress host group names that restrict the ingress host for the user group. Users who are members of the user group are allowed to connect only from a host in one of the named ingress host groups.
-* *_connectionAllowDefault_* (boolean) : 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 ‘default’ user group and receive ‘default’ settings.
-* *_settings_* (map) : A map where each key is a user group name and the value is a map of the corresponding settings for that group.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/configuration-security.adoc
----------------------------------------------------------------------
diff --git a/doc/new-book/configuration-security.adoc b/doc/new-book/configuration-security.adoc
deleted file mode 100644
index 993cecf..0000000
--- a/doc/new-book/configuration-security.adoc
+++ /dev/null
@@ -1,773 +0,0 @@
-////
-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
-////
-
-[id='security-config']
-= Security
-
-Securing your router network involves configuring authentication and authorization. You can authenticate and encrypt the router's connections using SSL/TLS or SASL. Additionally, you can authorize access to messaging resources by setting user connection restrictions and defining AMQP resource access control.
-
-== Authenticating Remote Peers
-
-You can configure {RouterName} to communicate with clients, routers, and brokers in a secure way by authenticating and encrypting the router's connections. {RouterName} supports the following security protocols:
-
-* _SSL/TLS_ for certificate-based encryption and mutual authentication
-* _SASL_ for authentication and payload encryption
-
-[id='setting-up-ssl-for-encryption-and-authentication']
-=== Setting Up SSL/TLS for Encryption and Authentication
-
-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.
-
-.Prerequisites
-
-You must have the following files in PEM format:
-
-* An X.509 CA certificate (used for signing the router certificate for the SSL/TLS server authentication feature).
-* A private key (with or without password protection) for the router.
-* An X.509 router certificate signed by the X.509 CA certificate.
-
-.Procedure
-
-* In the router's configuration file, add an `sslProfile` section:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-sslProfile {
- name: _NAME_
- ciphers: _CIPHERS_
- caCertFile: _PATH_.pem
- certFile: _PATH_.pem
- privateKeyFile: _PATH_.pem
- password: _PASSWORD/PATH_TO_PASSWORD_FILE_
- ...
-}
-----
-
-`name`:: A name for the SSL/TLS profile. You can use this name to refer to the profile from the incoming and outgoing connections.
-+
-For example:
-+
-[options="nowrap"]
-----
-name: router-ssl-profile
-----
-
-`ciphers`:: 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.
-+
-To enable a cipher list, enter one or more cipher strings separated by colons (`:`). For example:
-+
-[options="nowrap"]
-----
-ciphers: ALL:!aNULL:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
-----
-+
-To see the full list of available ciphers, use the `openssl ciphers` command. For more information about each cipher, see the link:https://www.openssl.org/docs/manmaster/man1/ciphers.html[ciphers man page^].
-
-`caCertFile`:: The absolute path to the file that contains the public certificates of trusted certificate authorities (CA).
-+
-For example:
-+
-[options="nowrap"]
-----
-caCertFile: /qdrouterd/ssl_certs/ca-cert.pem
-----
-
-`certFile`:: 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.
-+
-For example:
-+
-[options="nowrap"]
-----
-certFile: /qdrouterd/ssl_certs/router-cert-pwd.pem
-----
-
-`privateKeyFile`:: The absolute path to the file containing the PEM-formatted private key for the above certificate.
-+
-For example:
-+
-[options="nowrap"]
-----
-privateKeyFile: /qdrouterd/ssl_certs/router-key-pwd.pem
-----
-
-`passwordFile` or `password`:: 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.
-+
-For example:
-+
-[options="nowrap"]
-----
-password: routerKeyPassword
-----
-
-For information about additional `sslProfile` attributes, see link:{qdrouterdConfManPageUrl}#_sslprofile[sslProfile] in the `qdrouterd.conf` man page.
---
-
-[id='setting-up-sasl-for-authentication-and-payload-encryption']
-=== Setting Up SASL for Authentication and Payload Encryption
-
-If you plan to use SASL to authenticate connections, you must first add the SASL attributes to the `router` 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.
-
-.Prerequisites
-
-Before you can set up SASL, you must have the following:
-
-* xref:generating-sasl-database[The SASL database is generated.]
-* xref:configuring-sasl-database[The SASL configuration file is configured.]
-* The Cyrus SASL plugin is installed for each SASL mechanism you plan to use.
-+
-Cyrus SASL uses plugins to support specific SASL mechanisms. Before you can use a particular SASL mechanism, the relevant plugin must be installed. For example, you need the `cyrus-sasl-plain` plugin to use SASL PLAIN authentication.
-+
---
-// Note about searching for an installing SASL plugins.
-include::{FragmentDir}/fragment-router-sasl-para.adoc[]
---
-
-.Procedure
-
-* In the router's configuration file, add the following attributes to the `router` section:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-router {
- ...
- saslConfigDir: _PATH_
- saslConfigName: _FILE_NAME_
-}
-----
-
-`saslConfigDir`:: The absolute path to the SASL configuration file.
-+
-For example:
-+
-[options="nowrap"]
-----
-saslConfigDir: /qdrouterd/security
-----
-
-`saslConfigName`:: The name of the SASL configuration file. This name should _not_ include the `.conf` file extension.
-+
-For example:
-+
-[options="nowrap"]
-----
-saslConfigName: qdrouterd_sasl
-----
---
-
-[id='securing-incoming-connections']
-=== Securing Incoming Connections
-
-You can secure incoming connections by configuring each connection's `listener` entity for encryption, authentication, or both.
-
-.Prerequisites
-
-Before securing incoming connections, the security protocols you plan to use should be set up.
-
-.Choices
-
-* xref:adding-ssl-encryption-to-incoming-connection[Add SSL/TLS encryption]
-* xref:adding-sasl-authentication-to-incoming-connection[Add SASL authentication]
-* xref:adding-ssl-client-authentication-to-incoming-connection[Add SSL/TLS client authentication]
-* xref:adding-sasl-payload-encryption-to-incoming-connection[Add SASL payload encryption]
-
-[id='adding-ssl-encryption-to-incoming-connection']
-==== Adding SSL/TLS Encryption to an Incoming Connection
-
-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.
-
-.Procedure
-
-* In the router's configuration file, add the following attributes to the connection's `listener` entity:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-listener {
- ...
- sslProfile: _SSL_PROFILE_NAME_
- requireSsl: yes
-}
-----
-
-`sslProfile`:: The name of the SSL/TLS profile you set up.
-
-`requireSsl`:: Enter `yes` to require all clients connecting to the router on this connection to use encryption.
---
-
-[id='adding-sasl-authentication-to-incoming-connection']
-==== Adding SASL Authentication to an Incoming Connection
-
-You can configure an incoming connection to authenticate the client using SASL. You can use SASL authentication with or without SSL/TLS encryption.
-
-.Procedure
-
-* In the router's configuration file, add the following attributes to the connection's `listener` section:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-listener {
- ...
- authenticatePeer: yes
- saslMechanisms: _MECHANISMS_
-}
-----
-
-`authenticatePeer`:: Set this attribute to `yes` to require the router to authenticate the identity of a remote peer before it can use this incoming connection.
-
-`saslMechanisms`:: The SASL authentication mechanism (or mechanisms) to use for peer authentication. You can choose any of the Cyrus SASL authentication mechanisms _except_ for `ANONYMOUS`. To specify multiple authentication mechanisms, separate each mechanism with a space.
-+
-For a full list of supported Cyrus SASL authentication mechanisms, see link:https://www.cyrusimap.org/sasl/sasl/authentication_mechanisms.html[Authentication Mechanisms^].
---
-
-[id='adding-ssl-client-authentication-to-incoming-connection']
-==== Adding SSL/TLS Client Authentication to an Incoming Connection
-
-You can configure an incoming connection to authenticate the client using SSL/TLS.
-
-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.
-
-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.
-
-You can use SSL/TLS client authentication with or without SASL authentication.
-
-.Procedure
-
-* In the router's configuration, file, add the following attribute to the connection's `listener` entity:
-+
---
-[options="nowrap"]
-----
-listener {
- ...
- authenticatePeer: yes
-}
-----
-
-`authenticatePeer`:: Set this attribute to `yes` to require the router to authenticate the identity of a remote peer before it can use this incoming connection.
---
-
-[id='adding-sasl-payload-encryption-to-incoming-connection']
-==== Adding SASL Payload Encryption to an Incoming Connection
-
-If you do not use SSL/TLS, you can still encrypt the incoming connection by using SASL payload encryption.
-
-.Procedure
-
-* In the router's configuration file, add the following attributes to the connection's `listener` section:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-listener {
- ...
- requireEncryption: yes
- saslMechanisms: _MECHANISMS_
-}
-----
-
-`requireEncryption`:: Set this attribute to `yes` to require the router to use SASL payload encryption for the connection.
-
-`saslMechanisms`:: 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.
-+
-For a full list of supported Cyrus SASL authentication mechanisms, see link:https://www.cyrusimap.org/sasl/sasl/authentication_mechanisms.html[Authentication Mechanisms^].
---
-
-[id='securing-outgoing-connections']
-=== Securing Outgoing Connections
-
-You can secure outgoing connections by configuring each connection's `connector` entity for encryption, authentication, or both.
-
-.Prerequisites
-
-Before securing outgoing connections, the security protocols you plan to use should be set up.
-
-.Choices
-
-* xref:adding-ssl-authentication-to-outgoing-connection[Add SSL/TLS authentication]
-* xref:adding-sasl-authentication-to-outgoing-connection[Add SASL authentication]
-
-[id='adding-ssl-authentication-to-outgoing-connection']
-==== Adding SSL/TLS Client Authentication to an Outgoing Connection
-
-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.
-
-You can use SSL/TLS client authentication with or without SASL authentication.
-
-.Procedure
-
-* In the router's configuration file, add the `sslProfile` attribute to the connection's `connector` entity:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-connector {
- ...
- sslProfile: _SSL_PROFILE_NAME_
-}
-----
-
-`sslProfile`:: The name of the SSL/TLS profile you set up.
---
-
-[id='adding-sasl-authentication-to-outgoing-connection']
-==== Adding SASL Authentication to an Outgoing Connection
-
-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.
-
-.Procedure
-
-* In the router's configuration file, add the `saslMechanisms` attribute to the connection's `connector` entity:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-connector {
- ...
- saslMechanisms: _MECHANISMS_
- saslUsername: _USERNAME_
- saslPassword: _PASSWORD_
-}
-----
-
-`saslMechanisms`:: 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.
-+
-For a full list of supported Cyrus SASL authentication mechanisms, see link:https://www.cyrusimap.org/sasl/sasl/authentication_mechanisms.html[Authentication Mechanisms^].
-`saslUsername`:: If any of the SASL mechanisms uses username/password authentication, then provide the username to connect to the external container.
-`saslPassword`:: If any of the SASL mechanisms uses username/password authentication, then provide the password to connect to the external container.
---
-
-[id='integrating-with-kerberos']
-=== Integrating with Kerberos
-
-By using the `GSSAPI` SASL mechanism, you can configure {RouterName} to authenticate incoming connections using Kerberos.
-
-.Prerequisites
-
-* A Kerberos infrastructure must be deployed in your environment.
-
-* In the Kerberos environment, a service principal of `amqp/_HOSTNAME_@_REALM_` must be configured.
-+
-This is the service principal that {RouterName} uses.
-
-* The `cyrus-sasl-gssapi` package must be installed on each client and router host machine.
-
-* xref:setting-up-sasl-for-authentication-and-payload-encryption[SASL must be set up for {RouterName}].
-
-.Procedure
-
-. On the router's host machine, open the `/etc/sasl2/qdrouterd.conf` configuration file.
-+
---
-.An `/etc/sasl2/qdrouterd.conf` Configuration File
-====
-[options="nowrap"]
-----
-pwcheck_method: auxprop
-auxprop_plugin: sasldb
-sasldb_path: qdrouterd.sasldb
-keytab: /etc/krb5.keytab
-mech_list: ANONYMOUS DIGEST-MD5 EXTERNAL PLAIN GSSAPI
-----
-====
---
-
-. Verify the following:
-** The `mech_list` attribute contains the `GSSAPI` mechanism.
-** The `keytab` attribute points to the location of the keytab file.
-
-
-. Open the router's configuration file.
-
-. For each incoming connection that should use Kerberos for authentication, set the router's `listener` to use the `GSSAPI` mechanism.
-+
---
-.A `listener` in the Router Configuration File
-====
-[options="nowrap"]
-----
-listener {
- ...
- authenticatePeer: yes
- saslMechanisms: GSSAPI
-}
-----
-====
-
-For more information about these attributes, see xref:adding-sasl-authentication-to-incoming-connection[].
---
-
-== Authorizing Access to Messaging Resources
-
-You can restrict the number of user connections, and control access to AMQP messaging resources by configuring _policies_.
-
-=== Types of Policies
-
-You can configure two different types of policies: _global policies_ and _vhost policies_.
-
-Global policies::
-Settings for the router. A global policy defines the maximum number of incoming user connections for the router (across all vhost policies), and defines how the router should use vhost policies.
-
-Vhost policies::
-Connection and AMQP resource limits for a messaging endpoint (called an AMQP virtual host, or _vhost_). A vhost policy defines what a client can access on a messaging endpoint over a particular connection.
-+
-[NOTE]
-====
-A vhost is typically the name of the host to which the client connection is directed. For example, if a client application opens a connection to the `amqp://mybroker.example.com:5672/queue01` URL, the vhost would be `mybroker.example.com`.
-====
-
-The resource limits defined in global and vhost policies are applied to user connections only. The limits do not affect inter-router connections or router connections that are outbound to waypoints.
-
-=== How {RouterName} Applies Policies
-
-{RouterName} uses both global and vhost policies to determine whether to permit a connection, and if it is permitted, to apply the appropriate resource limits.
-
-When a client creates a connection to the router, the router first determines whether to allow or deny the connection. This decision is based on the following criteria:
-
-* Whether the connection will exceed the router's global connection limit (defined in the global policy)
-* Whether the connection will exceed the vhost's connection limits (defined in the vhost policy that matches the host to which the connection is directed)
-
-If the connection is allowed, the router assigns the user (the authenticated user name from the connection) to a user group, and enforces the user group's resource limits for the lifetime of the connection.
-
-=== Configuring Global Policies
-
-You can set the incoming connection limit for the router and define how it should use vhost policies by configuring a global policy.
-
-.Procedure
-
-* In the router configuration file, add a `policy` section.
-+
---
-[options="nowrap",subs="+quotes"]
-----
-policy = {
- maxConnections: 10000 // <1>
- enableVhostPolicy: true // <2>
- policyDir: /etc/qpid-dispatch/policies/ // <3>
- defaultVhost: $default // <4>
-}
-----
-<1> The maximum number of concurrent client connections allowed for this router. This limit is always enforced, even if no other policy settings have been defined. The limit is applied to all incoming connections regardless of remote host, authenticated user, or targeted vhost. The default (and the maximum) value is `65535`.
-
-<2> Enables the router to enforce the connection denials and resource limits defined in the configured vhost policies. The default is `false`, which means that the router will not enforce any vhost policies.
-+
-[NOTE]
-====
-Setting `enableVhostPolicy` to `false` improves the router's performance.
-====
-
-<3> The absolute path to a directory that holds vhost policy definition files in JSON format (`*.json`). The router processes all of the vhost policies in each JSON file that is in this directory. For more information, see xref:configuring-vhost-policies-json[].
-
-<4> The name of the default vhost policy. This policy rule set is applied to a connection for which a vhost policy has not otherwise been configured. Processing for the default vhost is enabled by default and set to select vhost '$default'. To disable default vhost processing set defaultVhost to blank or do not define a vhost named '$default'.
---
-
-=== Configuring Vhost Policies
-
-You configure vhost policies to define the connection limits and AMQP resource limits for a messaging endpoint.
-
-A vhost policy consists of the following:
-
-* Connection limits
-+
-These limits control the number of users that can be connected to the vhost simultaneously.
-
-* User groups
-+
-A user group defines the messaging resources that the group members are permitted to access. Each user group defines the following:
-
-** A set of users that can connect to the vhost (the group members)
-** The remote hosts from which the group members may connect to the router network
-** The AMQP resources that the group members are permitted to access on the vhost
-
-You can use the following methods to configure vhost policies:
-
-* xref:configuring-vhost-policies-router[Configure vhost policies directly in the router configuration file]
-* xref:configuring-vhost-policies-json[Configure vhost policies as JSON files]
-
-[id='configuring-vhost-policies-router']
-==== Configuring Vhost Policies in the Router Configuration File
-
-You can configure vhost policies in the router configuration file by configuring `vhost` entities. However, if multiple routers in your router network should be configured with the same vhost configuration, you will need to add the `vhost` configuration to each router's configuration file.
-
-.Procedure
-
-. In the router configuration file, add a `vhost` section and define the connection limits for it.
-+
---
-The connection limits apply to all users that are connected to the vhost. These limits control the number of users that can be connected simultaneously to the vhost.
-
-[options="nowrap",subs="+quotes"]
-----
-vhost = {
- hostname: example.com // <1>
- maxConnections: 10000 // <2>
- maxConnectionsPerUser: 1000 // <3>
- maxConnectionsPerHost: 1000 // <4>
- allowUnknownUser: false // <5>
- ...
-}
-----
-
-<1> The host name of the vhost. This vhost policy will be applied to any client connection that is directed to the hostname that you specify.
-
-<2> The global maximum number of concurrent client connections allowed for this vhost. The default is `65535`.
-
-<3> The maximum number of concurrent client connections allowed for any user. The default is `65535`.
-
-<4> The maximum number of concurrent client connections allowed for any remote host (the host from which the client is connecting). The default is `65535`.
-
-<5> Whether unknown users (users who are not members of a defined user group) are allowed to connect to the vhost. Unknown users are assigned to the `$default` user group and receive `$default` settings. The default is `false`, which means that unknown users are not allowed.
---
-
-. In the `vhost` section, beneath the connection settings that you added, add the necessary user groups.
-+
---
-A user group defines what messaging resources the members of the group are allowed to access.
-
-[options="nowrap",subs="+quotes"]
-----
-vhost {
- ...
- groups: {
- admin: { // <1>
- users: admin1, admin2 // <2>
- remoteHosts: 127.0.0.1, ::1 // <3>
- sources: * // <4>
- targets: * // <5>
- },
- ...
- }
-}
-----
-
-<1> The name of the user group.
-
-<2> A list of authenticated users for this user group. Use commas to separate multiple users. A user may belong to only one vhost user group.
-
-<3> A list of remote hosts from which the users may connect. A host can be a hostname, IP address, or IP address range. Use commas to separate multiple hosts. To allow access from all remote hosts, specify a wildcard `*`. To deny access from all remote hosts, leave this attribute blank.
-
-<4> A list of AMQP source addresses from which users in this group may receive messages. To specify multiple AMQP addresses, separate the addresses with either a comma or a space. If you do not specify any addresses, users in this group are not allowed to receive messages from any addresses.
-+
-You can use the substitution token `${user}` to specify an AMQP address that contains a user's authenticated user name. This enables you to allow access to resources specific to each user in the user group without having to name each user individually. You can only specify the `${user}` token once in an AMQP address name. If there are multiple tokens in an address, only the leftmost token will be substituted.
-+
-You can use an asterisk (`*`) wildcard to match one or more characters in an AMQP address. However, this wildcard is only recognized if it is the last character in the address name.
-+
-.Allowing Access to All Addresses
-====
-[options="nowrap"]
-----
-sources: *
-----
-====
-+
-.Restricting Access to All Addresses
-====
-[options="nowrap"]
-----
-sources:
-----
-====
-+
-.Allowing Access to Specific Addresses
-====
-[options="nowrap"]
-----
-sources: myaddress01, myaddress02, myaddress03
-----
-====
-+
-.Allowing Access to User-Specific Addresses
-====
-This definition allows access to any address that meets any of the following rules:
-
-* Starts with the prefix `tmp_` and ends with the user name
-* Starts with the prefix `temp` followed by any additional characters
-* Starts with the user name, is followed by `-home-`, and ends with any additional characters
-
-[options="nowrap"]
-----
-sources: tmp_${user}, temp*, ${user}-home-*
-----
-====
-
-<5> A list of AMQP target addresses from which users in this group may send messages. You can specify multiple AMQP addresses and use user name substitution and wildcards the same way as with source addresses.
---
-
-. If necessary, add any advanced user group settings to the vhost user group.
-+
-The advanced user group settings enable you to define resource limits based on the AMQP connection open, session begin, and link attach phases of the connection. For more information, see link:{qdrouterdConfManPageUrl}#_vhostUserGroupSettings[Vhost User Group Settings^].
-
-[id='configuring-vhost-policies-json']
-==== Configuring Vhost Policies as JSON Files
-
-As an alternative to using the router configuration file, you can configure vhost policies in JSON files. If you have multiple routers that need to share the same vhost configuration, you can put the vhost configuration JSON files in a location accessible to each router, and then configure the routers to apply the vhost policies defined in these JSON files.
-
-.Procedure
-
-. Determine where to store the vhost policy JSON files.
-+
-The directory should be accessible by each router that needs to apply these vhost policies.
-
-. In the directory you determined, create a JSON file for each vhost policy.
-+
-The vhost policy is configured the same way as a `vhost` entity in the router configuration file, only using JSON syntax. For more information about vhost policy attributes, see xref:configuring-vhost-policies-router[].
-+
-.Sample Vhost Policy JSON File
-====
-[source,json,options="nowrap"]
-----
-{
- "vhost": {
- "name": "example.com",
- "maxConnectionsPerUser": 100,
- "allowUnknownUser": true,
- "groups": {
- "admin": {
- "users": ["admin1", "admin2"],
- "sources": "*",
- "targets": "*"
- },
- "developers": {
- "users": ["dev1", "dev2", "dev3"],
- "remoteHosts": "*",
- "sources": ["myqueue1", "myqueue2"],
- "targets": ["myqueue1", "myqueue2"]
- }
- }
- }
-}
-----
-====
-
-. In the router configuration file, locate the `policy` entity and set the `policyDir` attribute to point to the directory where the vhost policy JSON files are stored.
-+
-.A `policy` Entity
-====
-[options="nowrap"]
-----
-policy = {
- maxConnections: 1000
- enableVhostPolicy: true
- policyDir: /etc/vhost-policies/ // <1>
- defaultVhost: $default
-}
-----
-<1> The absolute path to a directory that holds vhost policy definition files in JSON format (*.json). The router processes all of the vhost policies in each JSON file that is in this directory.
-====
-
-. Repeat the previous step for each additional router that should use the vhost policies located in the vhost policy directory.
-
-=== Example: Configuring a Vhost Policy
-
-In this example, a vhost policy defines resource limits for clients connecting to the `example.com` host.
-
-.A Vhost Policy in the Router Configuration File
-====
-[options="nowrap"]
-----
-vhost {
- name: example.com // <1>
- maxConnectionsPerUser: 10 // <2>
- allowUnknownUser: true // <3>
- groups: {
- admin: {
- users: admin-01, admin-02 // <4>
- remoteHosts: 127.0.0.1, ::1 // <5>
- sources: * // <6>
- targets: * // <6>
- },
- $default: {
- remoteHosts: * // <7>
- sources: news*, sports*, chat* // <8>
- targets: chat* // <9>
- }
- }
-}
-----
-
-<1> The rules defined in this vhost policy will be applied to any user connecting to `example.com`.
-
-<2> Each user can open up to 10 connections to the vhost.
-
-<3> Any user can connect to this vhost. Users that are not part of the `admin` group are assigned to the `$default` group.
-
-<4> If the `admin-01` or `admin-02` user connects to the vhost, they are assigned to the `admin` user group.
-
-<5> Users in the `admin` user group must connect from localhost. If the admin user attempts to connect from any other host, the connection will be denied.
-
-<6> Users in the admin user group can send and receive from any address offered by the vhost.
-
-<7> Any non-admin user is permitted to connect from any host.
-
-<8> Non-admin users are permitted to receive messages from any addresses that start with the `news`, `sports`, or `chat` prefixes.
-
-<9> Non-admin users are permitted to send messages to any address that start with the `chat` prefix.
-====
-
-=== Example: Using a Vhost Policy to Limit Memory Consumption (Advanced)
-
-By using the advanced vhost policy attributes, you can control how much system buffer memory a user connection can potentially consume.
-
-In this example, a stock trading site provides services for stock traders. However, the site must also accept high-capacity, automated data feeds from stock exchanges. To prevent trading activity from consuming memory needed for the feeds, a larger amount of system buffer memory is allotted to the feeds than to the traders.
-
-This examples uses the `maxSessions` and `maxSessionWindow` attributes to set the buffer memory consumption limits for each AMQP session. These settings are passed directly to the AMQP connection and session negotiations, and do not require any processing cycles on the router.
-
-This example does not show the vhost policy settings that are unrelated to buffer allocation.
-
-.A Vhost Policy to Limit Memory Consumption
-====
-[options="nowrap"]
-----
-vhost {
- name: traders.com // <1>
- groups: {
- traders: {
- users: trader-1, trader-2, ... // <2>
- maxFrameSize: 10000 // <3>
- maxSessionWindow: 5000000 // <3>
- maxSessions: 1 // <4>
- ...
- },
- feeds: {
- users: nyse-feed, nasdaq-feed // <5>
- maxFrameSize: 60000 // <6>
- maxSessionWindow: 1200000000 // <6>
- maxSessions: 3 // <7>
- ...
- }
- }
-}
-----
-
-<1> The rules defined in this vhost policy will be applied to any user connecting to `traders.com`.
-
-<2> The `traders` group includes `trader-01`, `trader-02`, and any other user defined in the list.
-
-<3> At most, 5,000,000 bytes of data can be in flight on each session.
-
-<4> Only one session per connection is allowed.
-
-<5> The `feeds` group includes two users.
-
-<6> At most, 1,200,000,000 bytes of data can be in flight on each session.
-
-<7> Up to three sessions per connection are allowed.
-====
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/cyrus-sasl.adoc
----------------------------------------------------------------------
diff --git a/doc/new-book/cyrus-sasl.adoc b/doc/new-book/cyrus-sasl.adoc
deleted file mode 100644
index 3618ffc..0000000
--- a/doc/new-book/cyrus-sasl.adoc
+++ /dev/null
@@ -1,90 +0,0 @@
-////
-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
-////
-
-[id='cyrus-sasl']
-= Using Cyrus SASL to Provide Authentication
-
-// Just doing some basic editing for now; for future releases, this content will need some more work. Also need to determine if it should be moved from an appendix to the section that deals with setting up SASL.
-
-{RouterName} uses the Cyrus SASL library for SASL authentication. Therefore, if you want to use SASL, you must set up the Cyrus SASL database and configure it.
-
-[id='generating-sasl-database']
-== Generating a SASL Database
-
-To generate a SASL database to store credentials, enter the following command:
-
-[options="nowrap",subs="+quotes"]
-----
-$ sudo saslpasswd2 -c -f _SASL_DATABASE_NAME_.sasldb -u _DOMAIN_NAME_ _USER_NAME_
-----
-
-This command creates or updates the specified SASL database, and adds the specified user name to it. The command also prompts you for the user name's password.
-
-// What is the goal here - to add user credentials to the database? If so, do you need to run this command for every user that you want to add? When it says that the command prompts for the password, does that mean you use the prompt to set the user's password?
-
-The full user name is the user name you entered plus the domain name (`__USER_NAME__`@`__DOMAIN_NAME__`). Providing a domain name is not required when you add a user to the database, but if you do not provide one, a default domain will be added automatically (the hostname of the machine on which the tool is running). For example, in the command above, the full user name would be `user1@domain.com`.
-
-== Viewing Users in a SASL Database
-
-To view the user names stored in the SASL database:
-
-[options="nowrap",subs="+quotes"]
-----
-$ sudo sasldblistusers2 -f qdrouterd.sasldb
-user2@domain.com: __PASSWORD__
-user1@domain.com: __PASSWORD__
-----
-
-[id='configuring-sasl-database']
-== Configuring a SASL Database
-
-To use the SASL database to provide authentication in {RouterName}:
-
-. Open the `/etc/sasl2/qdrouterd.conf` configuration file.
-
-. Set the following attributes:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-pwcheck_method: auxprop
-auxprop_plugin: sasldb
-sasldb_path: __SASL_DATABASE_NAME__
-mech_list: __MECHANISM1 ...__
-----
-
-`sasldb_path`:: The name of the SASL database to use.
-+
-For example:
-+
-[options="nowrap"]
-----
-sasldb_path: qdrouterd.sasldb
-----
-
-`mech_list`:: The SASL mechanisms to enable for authentication. To add multiple mechanisms, separate each entry with a space.
-+
-For example:
-+
-[options="nowrap"]
-----
-mech_list: ANONYMOUS DIGEST-MD5 EXTERNAL PLAIN
-----
-// Where can users find a list of supported mechanisms?
---
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/getting-started.adoc
----------------------------------------------------------------------
diff --git a/doc/new-book/getting-started.adoc b/doc/new-book/getting-started.adoc
deleted file mode 100644
index 021dcba..0000000
--- a/doc/new-book/getting-started.adoc
+++ /dev/null
@@ -1,156 +0,0 @@
-////
-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
-////
-
-[id='getting-started']
-= Getting Started
-
-Before configuring {RouterName}, 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.
-
-[id='starting-the-router']
-== Starting the Router
-
-.Procedure
-
-// Step 1 for starting the router.
-include::{FragmentDir}/fragment-starting-router-step.adoc[]
-+
-[NOTE]
-====
-You can specify a different configuration file with which to start the router. For more information, see xref:methods-for-changing-router-configuration[_Changing a Router's Configuration_].
-====
-+
-The router starts, using the default configuration file stored at `/etc/qpid-dispatch/qdrouterd.conf`.
-
-. View the log to verify the router status:
-+
-[options="nowrap"]
-----
-$ qdstat --log
-----
-+
-This example shows that the router was correctly installed, is running, and is ready to route traffic between clients:
-+
-[options="nowrap"]
-----
-$ qdstat --log
-Fri May 20 09:38:03 2017 SERVER (info) Container Name: Router.A // <1>
-Fri May 20 09:38:03 2017 ROUTER (info) Router started in Standalone mode // <2>
-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 // <3>
-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 // <4>
-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 // <5>
-----
-<1> The name of this router instance.
-<2> By default, the router starts in _standalone_ mode, which means that it cannot connect to other routers or be used in a router network.
-<3> The management agent. It provides the `$management` address, through which management tools such as `qdmanage` and `qdstat` 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 link:https://www.oasis-open.org/committees/download.php/54441/AMQP%20Management%20v1.0%20WD09[AMQP management specification (Draft 9)].
-<4> A listener is started on all available network interfaces and listens for connections on the standard AMQP port (5672, which is not encrypted).
-<5> Threads for handling message traffic and all other internal operations.
-
-== Routing Messages in a Peer-to-Peer Configuration
-
-// XXX Calling this peer-to-peer poses some problems. It's also
-// technically client-server in this instance, and most people think
-// those two things are exclusive.
-
-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.
-
-.Peer-to-peer Communication
-image::01-peer-to-peer.png[Peer-to-peer Communication, align="center"]
-
-As the diagram indicates, the configuration consists of an {RouterName} 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.
-
-A broker is not used in this example, so there is no _"store and forward"_ 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.
-
-This example uses a {ClientAmqpPythonName} client to start a receiver client, and then send five messages from the sender client.
-
-.Prerequisites
-
-{ClientAmqpPythonName} must be installed before you can complete the peer-to-peer routing example. For more information, see {ClientAmqpPythonUrl}.
-
-.Procedure
-
-. xref:starting-the-receiver-client[Start the receiver client].
-. xref:sending-messages[Send messages].
-
-[id='starting-the-receiver-client']
-=== Starting the Receiver Client
-
-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.
-
-[NOTE]
-====
-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.
-====
-
-.Procedure
-
-* To start the receiver by using the Python receiver client, navigate to the Python examples directory and run the `simple_recv.py` example:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-$ cd __INSTALL_DIR__/examples/python/
-$ python simple_recv.py -a 127.0.0.1:5672/examples -m 5
-----
-
-This command starts the receiver and listens on the default address (`127.0.0.1:5672/examples`). The receiver is also set to receive a maximum of five messages.
---
-
-[id='sending-messages']
-=== Sending Messages
-
-After starting the receiver client, you can send messages from the sender. These messages will travel through the router to the receiver.
-
-.Procedure
-
-* In a new terminal window, navigate to the Python examples directory and run the `simple_send.py` example:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-$ cd __INSTALL_DIR__/examples/python/
-$ python simple_send.py -a 127.0.0.1:5672/examples -m 5
-----
-
-This command sends five auto-generated messages to the default address (`127.0.0.1:5672/examples`) and then confirms that they were delivered and acknowledged by the receiver:
-
-[options="nowrap"]
-----
-all messages confirmed
-----
-
-The receiver client receives the messages and displays their content:
-
-[options="nowrap"]
-----
-{u'sequence': 1L}
-{u'sequence': 2L}
-{u'sequence': 3L}
-{u'sequence': 4L}
-{u'sequence': 5L}
-----
---
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/images/01-peer-to-peer.png
----------------------------------------------------------------------
diff --git a/doc/new-book/images/01-peer-to-peer.png b/doc/new-book/images/01-peer-to-peer.png
deleted file mode 100644
index 5c834aa..0000000
Binary files a/doc/new-book/images/01-peer-to-peer.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/images/balanced-routing.png
----------------------------------------------------------------------
diff --git a/doc/new-book/images/balanced-routing.png b/doc/new-book/images/balanced-routing.png
deleted file mode 100644
index fedcdbf..0000000
Binary files a/doc/new-book/images/balanced-routing.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/images/brokered-messaging.png
----------------------------------------------------------------------
diff --git a/doc/new-book/images/brokered-messaging.png b/doc/new-book/images/brokered-messaging.png
deleted file mode 100644
index ae129d4..0000000
Binary files a/doc/new-book/images/brokered-messaging.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/images/closest-routing.png
----------------------------------------------------------------------
diff --git a/doc/new-book/images/closest-routing.png b/doc/new-book/images/closest-routing.png
deleted file mode 100644
index ba3f0a5..0000000
Binary files a/doc/new-book/images/closest-routing.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/images/console1.png
----------------------------------------------------------------------
diff --git a/doc/new-book/images/console1.png b/doc/new-book/images/console1.png
deleted file mode 100644
index f131884..0000000
Binary files a/doc/new-book/images/console1.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/images/console_charts.png
----------------------------------------------------------------------
diff --git a/doc/new-book/images/console_charts.png b/doc/new-book/images/console_charts.png
deleted file mode 100644
index 169c2ca..0000000
Binary files a/doc/new-book/images/console_charts.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/images/console_entity.png
----------------------------------------------------------------------
diff --git a/doc/new-book/images/console_entity.png b/doc/new-book/images/console_entity.png
deleted file mode 100644
index 130c7e7..0000000
Binary files a/doc/new-book/images/console_entity.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/images/console_login.png
----------------------------------------------------------------------
diff --git a/doc/new-book/images/console_login.png b/doc/new-book/images/console_login.png
deleted file mode 100644
index 63e22c6..0000000
Binary files a/doc/new-book/images/console_login.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/images/console_overview.png
----------------------------------------------------------------------
diff --git a/doc/new-book/images/console_overview.png b/doc/new-book/images/console_overview.png
deleted file mode 100644
index af25f36..0000000
Binary files a/doc/new-book/images/console_overview.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/images/console_schema.png
----------------------------------------------------------------------
diff --git a/doc/new-book/images/console_schema.png b/doc/new-book/images/console_schema.png
deleted file mode 100644
index ba56c7b..0000000
Binary files a/doc/new-book/images/console_schema.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/images/console_topology.png
----------------------------------------------------------------------
diff --git a/doc/new-book/images/console_topology.png b/doc/new-book/images/console_topology.png
deleted file mode 100644
index ae4b22a..0000000
Binary files a/doc/new-book/images/console_topology.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/images/link-routing.png
----------------------------------------------------------------------
diff --git a/doc/new-book/images/link-routing.png b/doc/new-book/images/link-routing.png
deleted file mode 100644
index 0c1b9e4..0000000
Binary files a/doc/new-book/images/link-routing.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/images/message-routing.png
----------------------------------------------------------------------
diff --git a/doc/new-book/images/message-routing.png b/doc/new-book/images/message-routing.png
deleted file mode 100644
index 42f4638..0000000
Binary files a/doc/new-book/images/message-routing.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/images/multicast-routing.png
----------------------------------------------------------------------
diff --git a/doc/new-book/images/multicast-routing.png b/doc/new-book/images/multicast-routing.png
deleted file mode 100644
index d4548a6..0000000
Binary files a/doc/new-book/images/multicast-routing.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/images/path-redundancy-01.png
----------------------------------------------------------------------
diff --git a/doc/new-book/images/path-redundancy-01.png b/doc/new-book/images/path-redundancy-01.png
deleted file mode 100644
index ba8f10d..0000000
Binary files a/doc/new-book/images/path-redundancy-01.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/images/path-redundancy-02.png
----------------------------------------------------------------------
diff --git a/doc/new-book/images/path-redundancy-02.png b/doc/new-book/images/path-redundancy-02.png
deleted file mode 100644
index 6d4a1f5..0000000
Binary files a/doc/new-book/images/path-redundancy-02.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/images/path-redundancy-temp-decoupling-01.png
----------------------------------------------------------------------
diff --git a/doc/new-book/images/path-redundancy-temp-decoupling-01.png b/doc/new-book/images/path-redundancy-temp-decoupling-01.png
deleted file mode 100644
index c3c6631..0000000
Binary files a/doc/new-book/images/path-redundancy-temp-decoupling-01.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/images/path-redundancy-temp-decoupling-02.png
----------------------------------------------------------------------
diff --git a/doc/new-book/images/path-redundancy-temp-decoupling-02.png b/doc/new-book/images/path-redundancy-temp-decoupling-02.png
deleted file mode 100644
index ecab8b1..0000000
Binary files a/doc/new-book/images/path-redundancy-temp-decoupling-02.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/images/sharded-queue-01.png
----------------------------------------------------------------------
diff --git a/doc/new-book/images/sharded-queue-01.png b/doc/new-book/images/sharded-queue-01.png
deleted file mode 100644
index ab25be0..0000000
Binary files a/doc/new-book/images/sharded-queue-01.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/images/sharded-queue-02.png
----------------------------------------------------------------------
diff --git a/doc/new-book/images/sharded-queue-02.png b/doc/new-book/images/sharded-queue-02.png
deleted file mode 100644
index 7e73e6d..0000000
Binary files a/doc/new-book/images/sharded-queue-02.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/introduction.adoc
----------------------------------------------------------------------
diff --git a/doc/new-book/introduction.adoc b/doc/new-book/introduction.adoc
deleted file mode 100644
index 37eb37c..0000000
--- a/doc/new-book/introduction.adoc
+++ /dev/null
@@ -1,124 +0,0 @@
-////
-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
-////
-
-[id='introduction']
-= Introduction
-
-[id='overview']
-== Overview
-
-The {RouterName} 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.
-
-A messaging client can make a single AMQP connection into a messaging
-bus built of {RouterName} 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.
-
-The router is an intermediary for messages but it is _not_ a broker. It
-does not _take responsibility for_ 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, _and_ it will route
-the acknowledgement of that message by the ultimate receiver back across
-the same path. This means that _responsibility_ for the message is
-transfered from the original sender to the ultimate receiver __as if
-they were directly connected__. However this is done via a flexible
-network that allows highly configurable routing of the message
-transparent to both sender and receiver.
-
-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.
-
-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 {RouterName} 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.
-
-For an exampe of using {RouterName} 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 {RouterName} network,
-_all_ the receivers are connected to _all_ the brokers. If there is a
-message anywhere it can be delivered to any receiver.
-
-{RouterName} 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.
-
-[id='benefits']
-== Benefits
-
-Simplifies connectivity
-
-* An endpoint can do all of its messaging through a single transport
-connection
-* Avoid opening holes in firewalls for incoming connections
-
-Provides messaging connectivity where there is no TCP/IP connectivity
-
-* 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).
-
-Simplifies reliability
-
-* Reliability and availability are provided using redundant topology,
-not server clustering
-* Reliable end-to-end messaging without persistent stores
-* Use a message broker only when you need store-and-forward semantics
-
-[id='features']
-== Features
-
-* Can be deployed stand-alone or in a network of routers
-** Supports arbitrary network topology - no restrictions on redundancy
-+
-- Automatic route computation - adjusts quickly to changes in topology
-* Provides remote access to brokers or other AMQP servers
-* Security
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org
[08/11] qpid-dispatch git commit: DISPATCH-851: Move the new book
into primary position and reorg the docs
Posted by jr...@apache.org.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/logging.adoc
----------------------------------------------------------------------
diff --git a/doc/new-book/logging.adoc b/doc/new-book/logging.adoc
deleted file mode 100644
index 32b7e93..0000000
--- a/doc/new-book/logging.adoc
+++ /dev/null
@@ -1,346 +0,0 @@
-////
-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
-////
-
-[id='logging']
-= Logging
-
-Logging enables you to diagnose error and performance issues with {RouterName}.
-
-{RouterName} consists of internal modules that provide important information about the router. For each module, you can specify logging levels, the format of the log file, and the location to which the logs should be written.
-
-[id='logging-modules-you-can-configure']
-== Logging Modules
-
-{RouterName} logs are broken into different categories called _logging modules_. Each module provides important information about a particular aspect of {RouterName}.
-
-=== The `DEFAULT` Logging Module
-
-The default module. This module applies defaults to all of the other logging modules.
-
-=== The `ROUTER` Logging Module
-
-This module provides information and statistics about the local router. This includes how the router connects to other routers in the network, and information about the remote destinations that are directly reachable from the router (link routes, waypoints, autolinks, and so on).
-
-In this example, on `Router.A`, the `ROUTER` log shows that `Router.B` is the next hop. It also shows the cost for `Router.A` to reach the other routers on the network:
-
-[options="nowrap"]
-----
-Tue Jun 7 13:28:27 2016 ROUTER (trace) Node Router.C next hop set: Router.B
-Tue Jun 7 13:28:27 2016 ROUTER (trace) Node Router.C valid origins: []
-Tue Jun 7 13:28:27 2016 ROUTER (trace) Node Router.C cost: 2
-Tue Jun 7 13:28:27 2016 ROUTER (trace) Node Router.B valid origins: []
-Tue Jun 7 13:28:27 2016 ROUTER (trace) Node Router.B cost: 1
-----
-
-On `Router.B`, the `ROUTER` log provides more information about valid origins:
-
-[options="nowrap"]
-----
-Tue Jun 7 13:28:25 2016 ROUTER (trace) Node Router.C cost: 1
-Tue Jun 7 13:28:26 2016 ROUTER (trace) Node Router.A created: maskbit=2
-Tue Jun 7 13:28:26 2016 ROUTER (trace) Node Router.A link set: link_id=1
-Tue Jun 7 13:28:26 2016 ROUTER (trace) Node Router.A valid origins: ['Router.C']
-Tue Jun 7 13:28:26 2016 ROUTER (trace) Node Router.A cost: 1
-Tue Jun 7 13:28:27 2016 ROUTER (trace) Node Router.C valid origins: ['Router.A']
-----
-
-=== The `ROUTER_CORE` Logging Module
-
-This module provides information about the local router's operations on active connections and links. This includes operations related to opened and closed connections, messages sent, deliveries, and flow control.
-
-[options="nowrap"]
-----
-Tue Jun 7 13:42:07 2016 ROUTER_CORE (trace) Core action 'link_flow'
-Tue Jun 7 13:42:08 2016 ROUTER_CORE (trace) Core action 'link_deliver'
-Tue Jun 7 13:42:08 2016 ROUTER_CORE (trace) Core action 'send_to'
-Tue Jun 7 13:42:08 2016 ROUTER_CORE (trace) Core action 'link_flow'
-----
-
-=== The `ROUTER_HELLO` Logging Module
-
-This module provides information about the _Hello_ protocol used by interior routers to exchange Hello messages, which include information about the router's ID and a list of its reachable neighbors (the other routers with which this router has bidirectional connectivity).
-
-The logs for this module are helpful for monitoring or resolving issues in the network topology, and for determining to which other routers a router is connected, and the hop-cost for each of those connections.
-
-In this example, on `Router.A`, the `ROUTER_HELLO` log shows that it is connected to `Router.B`, and that `Router.B` is connected to `Router.A` and `Router.C`:
-
-[options="nowrap"]
-----
-Tue Jun 7 13:50:21 2016 ROUTER_HELLO (trace) RCVD: HELLO(id=Router.B area=0 inst=1465307413 seen=['Router.A', 'Router.C']) // <1>
-Tue Jun 7 13:50:21 2016 ROUTER_HELLO (trace) SENT: HELLO(id=Router.A area=0 inst=1465307416 seen=['Router.B']) // <2>
-Tue Jun 7 13:50:22 2016 ROUTER_HELLO (trace) RCVD: HELLO(id=Router.B area=0 inst=1465307413 seen=['Router.A', 'Router.C'])
-Tue Jun 7 13:50:22 2016 ROUTER_HELLO (trace) SENT: HELLO(id=Router.A area=0 inst=1465307416 seen=['Router.B'])
-----
-<1> `Router.A` received a Hello message from `Router.B`, which can see `Router.A` and `Router.C`.
-<2> `Router.A` sent a Hello message to `Router.B`, which is the only router it can see.
-
-On `Router.B`, the `ROUTER_HELLO` log shows the same router topology from a different perspective:
-
-[options="nowrap"]
-----
-Tue Jun 7 13:50:18 2016 ROUTER_HELLO (trace) SENT: HELLO(id=Router.B area=0 inst=1465307413 seen=['Router.A', 'Router.C']) // <1>
-Tue Jun 7 13:50:18 2016 ROUTER_HELLO (trace) RCVD: HELLO(id=Router.A area=0 inst=1465307416 seen=['Router.B']) // <2>
-Tue Jun 7 13:50:19 2016 ROUTER_HELLO (trace) RCVD: HELLO(id=Router.C area=0 inst=1465307411 seen=['Router.B']) // <3>
-----
-<1> `Router.B` sent a Hello message to `Router.A` and `Router.C`.
-<2> `Router.B` received a Hello message from `Router.A`, which can only see `Router.B`.
-<3> `Router.B` received a Hello message from `Router.C`, which can only see `Router.B`.
-
-=== The `ROUTER_LS` Logging Module
-
-This module provides information about link-state data between routers, including Router Advertisement (RA), Link State Request (LSR), and Link State Update (LSU) messages.
-
-Periodically, each router sends an LSR to the other routers and receives an LSU with the requested information. Exchanging the above information, each router can compute the next hops in the topology, and the related costs.
-
-This example shows the RA, LSR, and LSU messages sent between three routers:
-
-[options="nowrap"]
-----
-Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) SENT: LSR(id=Router.A area=0) to: Router.C //
-Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) SENT: LSR(id=Router.A area=0) to: Router.B //
-Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) SENT: RA(id=Router.A area=0 inst=1465308600 ls_seq=1 mobile_seq=1) // <1>
-Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) RCVD: LSU(id=Router.B area=0 inst=1465308595 ls_seq=2 ls=LS(id=Router.B area=0 ls_seq=2 peers={'Router.A': 1L, 'Router.C': 1L})) // <2>
-Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) RCVD: LSR(id=Router.B area=0)
-Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) SENT: LSU(id=Router.A area=0 inst=1465308600 ls_seq=1 ls=LS(id=Router.A area=0 ls_seq=1 peers={'Router.B': 1}))
-Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) RCVD: RA(id=Router.C area=0 inst=1465308592 ls_seq=1 mobile_seq=0)
-Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) SENT: LSR(id=Router.A area=0) to: Router.C
-Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) RCVD: LSR(id=Router.C area=0) // <3>
-Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) SENT: LSU(id=Router.A area=0 // inst=1465308600 ls_seq=1 ls=LS(id=Router.A area=0 ls_seq=1 peers={'Router.B': 1}))
-Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) RCVD: LSU(id=Router.C area=0 inst=1465308592 ls_seq=1 ls=LS(id=Router.C area=0 ls_seq=1 peers={'Router.B': 1L})) // <4>
-Tue Jun 7 14:10:03 2016 ROUTER_LS (trace) Computed next hops: {'Router.C': 'Router.B', 'Router.B': 'Router.B'} // <5>
-Tue Jun 7 14:10:03 2016 ROUTER_LS (trace) Computed costs: {'Router.C': 2L, 'Router.B': 1}
-Tue Jun 7 14:10:03 2016 ROUTER_LS (trace) Computed valid origins: {'Router.C': [], 'Router.B': []}
-----
-<1> `Router.A` sent LSR requests and an RA advertisement to the other routers on the network.
-<2> `Router.A` received an LSU from `Router.B`, which has two peers: `Router.A`, and `Router.C` (with a cost of `1`).
-<3> `Router.A` received an LSR from both `Router.B` and `Router.C`, and replied with an LSU.
-<4> `Router.A` received an LSU from `Router.C`, which only has one peer: `Router.B` (with a cost of `1`).
-<5> After the LSR and LSU messages are exchanged, `Router.A` computed the router topology with the related costs.
-
-=== The `ROUTER_MA` Logging Module
-
-This module provides information about the exchange of mobile address information between routers, including Mobile Address Request (MAR) and Mobile Address Update (MAU) messages exchanged between routers. You can use this log to monitor the state of mobile addresses attached to each router.
-
-This example shows the MAR and MAU messages sent between three routers:
-
-[options="nowrap"]
-----
-Tue Jun 7 14:27:20 2016 ROUTER_MA (trace) SENT: MAU(id=Router.A area=0 mobile_seq=1 add=['Cmy_queue', 'Dmy_queue', 'M0my_queue_wp'] del=[]) // <1>
-Tue Jun 7 14:27:21 2016 ROUTER_MA (trace) RCVD: MAR(id=Router.C area=0 have_seq=0) // <2>
-Tue Jun 7 14:27:21 2016 ROUTER_MA (trace) SENT: MAU(id=Router.A area=0 mobile_seq=1 add=['Cmy_queue', 'Dmy_queue', 'M0my_queue_wp'] del=[])
-Tue Jun 7 14:27:22 2016 ROUTER_MA (trace) RCVD: MAR(id=Router.B area=0 have_seq=0) // <3>
-Tue Jun 7 14:27:22 2016 ROUTER_MA (trace) SENT: MAU(id=Router.A area=0 mobile_seq=1 add=['Cmy_queue', 'Dmy_queue', 'M0my_queue_wp'] del=[])
-Tue Jun 7 14:27:39 2016 ROUTER_MA (trace) RCVD: MAU(id=Router.C area=0 mobile_seq=1 add=['M0my_test'] del=[]) // <4>
-Tue Jun 7 14:27:51 2016 ROUTER_MA (trace) RCVD: MAU(id=Router.C area=0 mobile_seq=2 add=[] del=['M0my_test']) // <5>
-----
-<1> `Router.A` sent MAU messages to the other routers in the network to notify them about the addresses added for `my_queue` and `my_queue_wp`.
-<2> `Router.A` received a MAR message in response from `Router.C`.
-<3> `Router.A` received another MAR message in response from `Router.B`.
-<4> `Router.C` sent a MAU message to notify the other routers that it added and address for `my_test`.
-<5> `Router.C` sent another MAU message to notify the other routers that it deleted the address for `my_test` (because the receiver is detached).
-
-=== The `MESSAGE` Logging Module
-
-This module provides information about AMQP messages sent and received by the router, including information about the address, body, and link. You can use this log to find high-level information about messages on a particular router.
-
-In this example, `Router.A` has sent and received some messages related to the Hello protocol, and sent and received some other messages on a link for a mobile address:
-
-[options="nowrap"]
-----
-Tue Jun 7 14:36:54 2016 MESSAGE (trace) Sending Message{to='amqp:/_topo/0/Router.B/qdrouter' body='\d1\00\00\00\1b\00\00\00\04\a1\02id\a1\08R'} on link qdlink.p9XmBm19uDqx50R
-Tue Jun 7 14:36:54 2016 MESSAGE (trace) Received Message{to='amqp:/_topo/0/Router.A/qdrouter' body='\d1\00\00\00\8e\00\00\00
-\a1\06ls_se'} on link qdlink.phMsJOq7YaFsGAG
-Tue Jun 7 14:36:54 2016 MESSAGE (trace) Received Message{ body='\d1\00\00\00\10\00\00\00\02\a1\08seque'} on link qdlink.FYHqBX+TtwXZHfV
-Tue Jun 7 14:36:54 2016 MESSAGE (trace) Sending Message{ body='\d1\00\00\00\10\00\00\00\02\a1\08seque'} on link qdlink.yU1tnPs5KbMlieM
-Tue Jun 7 14:36:54 2016 MESSAGE (trace) Sending Message{to='amqp:/_local/qdhello' body='\d1\00\00\00G\00\00\00\08\a1\04seen\d0'} on link qdlink.p9XmBm19uDqx50R
-Tue Jun 7 14:36:54 2016 MESSAGE (trace) Sending Message{to='amqp:/_topo/0/Router.C/qdrouter' body='\d1\00\00\00\1b\00\00\00\04\a1\02id\a1\08R'} on link qdlink.p9XmBm19uDqx50R
-----
-
-=== The `SERVER` Logging Module
-
-This module provides information about how the router is listening for and connecting to other containers in the network (such as clients, routers, and brokers). This includes the state of AMQP messages sent and received by the broker (open, begin, attach, transfer, flow, and so on), and the related content of those messages.
-
-For example, this log shows details about how the router handled a link attachment:
-
-[options="nowrap"]
-----
-Tue Jun 7 14:39:52 2016 SERVER (trace) [2]: <- AMQP
-Tue Jun 7 14:39:52 2016 SERVER (trace) [1]: <- AMQP
-Tue Jun 7 14:39:52 2016 SERVER (trace) [1]:0 <- @open(16) [container-id="Router.B", max-frame-size=16384, channel-max=32767, idle-time-out=8000, offered-capabilities=:"ANONYMOUS-RELAY", properties={:product="qpid-dispatch-router", :version="0.6.0"}]
-Tue Jun 7 14:39:52 2016 SERVER (trace) [1]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=15, outgoing-window=2147483647]
-Tue Jun 7 14:39:52 2016 SERVER (trace) [1]:RAW: "\x00\x00\x00\x1e\x02\x00\x00\x00\x00S\x11\xd0\x00\x00\x00\x0e\x00\x00\x00\x04@R\x00R\x0fp\x7f\xff\xff\xff"
-Tue Jun 7 14:39:52 2016 SERVER (trace) [1]:1 -> @begin(17) [next-outgoing-id=0, incoming-window=15, outgoing-window=2147483647]
-Tue Jun 7 14:39:52 2016 SERVER (trace) [1]:RAW: "\x00\x00\x00\x1e\x02\x00\x00\x01\x00S\x11\xd0\x00\x00\x00\x0e\x00\x00\x00\x04@R\x00R\x0fp\x7f\xff\xff\xff"
-Tue Jun 7 14:39:52 2016 SERVER (trace) [1]:0 -> @attach(18) [name="qdlink.uSSeXPSfTHhxo8d", handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=false, capabilities=:"qd.router"], target=@target(41) [durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=false, capabilities=:"qd.router"], initial-delivery-count=0]
-Tue Jun 7 14:39:52 2016 SERVER (trace) [1]:RAW: "\x00\x00\x00\x91\x02\x00\x00\x00\x00S\x12\xd0\x00\x00\x00\x81\x00\x00\x00\x0a\xa1\x16qdlink.uSSeXPSfTHhxo8dR\x00AP\x02P\x00\x00S(\xd0\x00\x00\x00'\x00\x00\x00\x0b@R\x00\xa3\x0blink-detachR\x00B@@@@@\xa3\x09qd.router\x00S)\xd0\x00\x00\x00#\x00\x00\x00\x07@R\x00\xa3\x0blink-detachR\x00B@\xa3\x09qd.router@@R\x00"
-----
-
-=== The `AGENT` Logging Module
-
-This module provides information about configuration changes made to the router from either editing the router's configuration file or using `qdmanage`.
-
-In this example, on `Router.A`, `address`, `linkRoute`, and `autoLink` entities were added to the router's configuration file. When the router was started, the `AGENT` module applied these changes, and they are now viewable in the log:
-
-[options="nowrap"]
-----
-Tue Jun 7 15:07:32 2016 AGENT (debug) Add entity: ConnectorEntity(addr=127.0.0.1, allowRedirect=True, cost=1, host=127.0.0.1, identity=connector/127.0.0.1:5672:BROKER, idleTimeoutSeconds=16, maxFrameSize=65536, name=BROKER, port=5672, role=route-container, stripAnnotations=both, type=org.apache.qpid.dispatch.connector, verifyHostname=True)
-Tue Jun 7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigAddressEntity(distribution=closest, identity=router.config.address/0, name=router.config.address/0, prefix=my_address, type=org.apache.qpid.dispatch.router.config.address, waypoint=False)
-Tue Jun 7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigAddressEntity(distribution=balanced, identity=router.config.address/1, name=router.config.address/1, prefix=my_queue_wp, type=org.apache.qpid.dispatch.router.config.address, waypoint=True)
-Tue Jun 7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigLinkrouteEntity(connection=BROKER, direction=in, distribution=linkBalanced, identity=router.config.linkRoute/0, name=router.config.linkRoute/0, prefix=my_queue, type=org.apache.qpid.dispatch.router.config.linkRoute)
-Tue Jun 7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigLinkrouteEntity(connection=BROKER, direction=out, distribution=linkBalanced, identity=router.config.linkRoute/1, name=router.config.linkRoute/1, prefix=my_queue, type=org.apache.qpid.dispatch.router.config.linkRoute)
-Tue Jun 7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigAutolinkEntity(addr=my_queue_wp, connection=BROKER, direction=in, identity=router.config.autoLink/0, name=router.config.autoLink/0, type=org.apache.qpid.dispatch.router.config.autoLink)
-Tue Jun 7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigAutolinkEntity(addr=my_queue_wp, connection=BROKER, direction=out, identity=router.config.autoLink/1, name=router.config.autoLink/1, type=org.apache.qpid.dispatch.router.config.autoLink)
-----
-
-=== The `CONTAINER` Logging Module
-
-This module provides information about the nodes related to the router. This includes only the AMQP relay node.
-
-[options="nowrap"]
-----
-Tue Jun 7 14:46:18 2016 CONTAINER (trace) Container Initialized
-Tue Jun 7 14:46:18 2016 CONTAINER (trace) Node Type Registered - router
-Tue Jun 7 14:46:18 2016 CONTAINER (trace) Node of type 'router' installed as default node
-----
-
-=== The `ERROR` Logging Module
-
-This module provides detailed information about error conditions encountered during execution.
-
-In this example, `Router.A` failed to start when an incorrect path was specified for the router's configuration file:
-
-[options="nowrap"]
-----
-$ sudo qdrouterd --conf xxx
-Wed Jun 15 09:53:28 2016 ERROR (error) Python: Exception: Cannot load configuration file xxx: [Errno 2] No such file or directory: 'xxx'
-Wed Jun 15 09:53:28 2016 ERROR (error) Traceback (most recent call last):
- File "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py", line 155, in configure_dispatch
- config = Config(filename)
- File "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py", line 41, in __init__
- self.load(filename, raw_json)
- File "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py", line 123, in load
- with open(source) as f:
-Exception: Cannot load configuration file xxx: [Errno 2] No such file or directory: 'xxx'
-
-Wed Jun 15 09:53:28 2016 MAIN (critical) Router start-up failed: Python: Exception: Cannot load configuration file xxx: [Errno 2] No such file or directory: 'xxx'
-qdrouterd: Python: Exception: Cannot load configuration file xxx: [Errno 2] No such file or directory: 'xxx'
-----
-
-=== The `POLICY` Logging Module
-
-This module provides information about policies that have been configured for the router.
-
-In this example, `Router.A` has no limits on maximum connections, and the default application policy is disabled:
-
-[options="nowrap"]
-----
-Tue Jun 7 15:07:32 2016 POLICY (info) Policy configured maximumConnections: 0, policyFolder: '', access rules enabled: 'false'
-Tue Jun 7 15:07:32 2016 POLICY (info) Policy fallback defaultApplication is disabled
-----
-
-[id='configure-default-logging']
-== Configuring Logging
-
-You can specify the types of events that should be logged, the format of the log entries, and where those entries should be sent.
-
-.Procedure
-
-. In the router's configuration file, add a `log` section to set the default logging properties:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-log {
- module: DEFAULT
- enable: _LOGGING_LEVEL_
- includeTimestamp: yes
- ...
-}
-----
-
-`module`:: Specify `DEFAULT`.
-`enable`:: The logging level. You can specify any of the following levels (from lowest to highest):
-+
-//tag::logging-levels[]
-* `trace` - provides the most information, but significantly affects system performance
-* `debug` - useful for debugging, but affects system performance
-* `info` - provides general information without affecting system performance
-* `notice` - provides general information, but is less verbose than `info`
-* `warning` - provides information about issues you should be aware of, but which are not errors
-* `error` - error conditions that you should address
-* `critical` - critical system issues that you must address immediately
-
-+
-To specify multiple levels, use a comma-separated list. You can also use `+` to specify a level and all levels above it. For example, `trace,debug,warning+` enables trace, debug, warning, error, and critical levels. For default logging, you should typically use the `info+` or `notice+` level. These levels will provide general information, warnings, and errors for all modules without affecting the performance of {RouterName}.
-//end::logging-levels[]
-`includeTimestamp`:: Set this to `yes` to include the timestamp in all logs.
-
-For information about additional log attributes, see link:{qdrouterdConfManPageUrl}#_log[log] in the `qdrouterd.conf` man page.
---
-
-. Add an additional `log` section for each logging module that should not follow the default logging configuration:
-+
---
-
-[options="nowrap",subs="+quotes"]
-----
-log {
- module: _MODULE_NAME_
- enable: _LOGGING_LEVEL_
- ...
-}
-----
-
-`module`:: The name of the module for which you are configuring logging. For a list of valid modules, see xref:logging-modules-you-can-configure[].
-`enable`:: The logging level. You can specify any of the following levels (from lowest to highest):
-+
-include::logging.adoc[tags=logging-levels]
-
-For information about additional log attributes, see link:{qdrouterdConfManPageUrl}#_log[log] in the `qdrouterd.conf` man page.
---
-
-== Viewing Log Entries
-
-You may need to view log entries to diagnose errors, performance problems, and other important issues. A log entry consists of an optional timestamp, the logging module, the logging level, and the log message.
-
-=== Viewing Log Entries on the Console
-
-By default, log entries are logged to the console, and you can view them there. However, if the `output` attribute is set for a particular logging module, then you can find those log entries in the specified location (`stderr`, `syslog`, or a file).
-
-=== Viewing Log Entries on the CLI
-
-You can use the `qdstat` tool to view a list of recent log entries.
-
-.Procedure
-
-* Use the *`qdstat --log`* command to view recent log entries.
-+
---
-You can use the `--limit` parameter to limit the number of log entries that are displayed. For more information about `qdstat`, see {qdstatManPageLink}.
-
-This example displays the last three log entries for `Router.A`:
-
-[options="nowrap",subs="+quotes"]
-----
-$ qdstat --log --limit=3 -r ROUTER.A
-Wed Jun 7 17:49:32 2017 ROUTER_CORE (none) Core action 'link_deliver'
-Wed Jun 7 17:49:32 2017 ROUTER_CORE (none) Core action 'send_to'
-Wed Jun 7 17:49:32 2017 SERVER (none) [2]:0 -> @flow(19) [next-incoming-id=1, incoming-window=61, next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=1, link-credit=250, drain=false]
-----
---
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/management-entities.adoc
----------------------------------------------------------------------
diff --git a/doc/new-book/management-entities.adoc b/doc/new-book/management-entities.adoc
deleted file mode 100644
index 3f677e3..0000000
--- a/doc/new-book/management-entities.adoc
+++ /dev/null
@@ -1,24 +0,0 @@
-////
-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
-////
-
-= Management Entities
-
-The {RouterName} management schema provides a set of management entities that you can use to configure and operate a router.
-
-For details about the management entities, see {ManagementEntitiesLink}.
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/management.adoc
----------------------------------------------------------------------
diff --git a/doc/new-book/management.adoc b/doc/new-book/management.adoc
deleted file mode 100644
index fa933de..0000000
--- a/doc/new-book/management.adoc
+++ /dev/null
@@ -1,38 +0,0 @@
-////
-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
-////
-
-= Management
-
-You can manage {RouterName} using both graphical and command-line tools.
-
-{ConsoleName}:: A graphical tool for monitoring and managing {RouterName} routers.
-`qdstat`:: A command-line tool for monitoring the status of {RouterName} routers.
-`qdmanage`:: A command-line tool for viewing and updating the configuration of {RouterName} routers.
-
-// Using the Console
-include::using-console.adoc[leveloffset=+1]
-
-// Monitoring Using qdstat
-include::monitoring-using-qdstat.adoc[leveloffset=+1]
-
-// Managing Using qdmanage
-include::managing-using-qdmanage.adoc[leveloffset=+1]
-
-// Management Entities
-include::management-entities.adoc[leveloffset=+1]
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/managing-using-qdmanage.adoc
----------------------------------------------------------------------
diff --git a/doc/new-book/managing-using-qdmanage.adoc b/doc/new-book/managing-using-qdmanage.adoc
deleted file mode 100644
index b22bd6d..0000000
--- a/doc/new-book/managing-using-qdmanage.adoc
+++ /dev/null
@@ -1,679 +0,0 @@
-////
-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
-////
-
-[id='managing-router']
-= Managing {RouterName} Using `qdmanage`
-
-You can use `qdmanage` to view and modify the configuration of a running router at runtime. Specifically, `qdmanage` enables you to create, read, update, and delete the sections and attributes in the router's configuration file without having to restart the router.
-
-[NOTE]
-====
-The `qdmanage` tool implements the AMQP management specification, which means that you can use it with any standard AMQP-managed endpoint, not just with {RouterName}.
-====
-
-== Syntax for Using `qdmanage`
-
-You can use `qdmanage` with the following syntax:
-
-[options="nowrap",subs="+quotes"]
-----
-$ qdmanage [__CONNECTION_OPTIONS__] __OPERATION__ [__OPTIONS__]
-----
-
-This specifies:
-
-* One or more optional `connection_options` to specify the router on which to perform the operation, or to supply security credentials if the router only accepts secure connections.
-+
-If you do not specify any connection options, `qdmanage` connects to the router listening on localhost and the default AMQP port (5672).
-* The `operation` to perform on the router.
-* One or more optional `options` to specify a configuration entity on which to perform the operation or how to format the command output.
-
-When you enter a `qdmanage` command, it is executed as an AMQP management operation request, and then the response is returned as command output in JSON format.
-
-For example, the following command executes a query operation on a router, and then returns the response in JSON format:
-
-[options="nowrap"]
-----
-$ qdmanage query --type listener
-[
- {
- "stripAnnotations": "both",
- "addr": "127.0.0.1",
- "multiTenant": false,
- "requireSsl": false,
- "idleTimeoutSeconds": 16,
- "saslMechanisms": "ANONYMOUS",
- "maxFrameSize": 16384,
- "requireEncryption": false,
- "host": "0.0.0.0",
- "cost": 1,
- "role": "normal",
- "http": false,
- "maxSessions": 32768,
- "authenticatePeer": false,
- "type": "org.apache.qpid.dispatch.listener",
- "port": "amqp",
- "identity": "listener/0.0.0.0:amqp",
- "name": "listener/0.0.0.0:amqp"
- }
-]
-----
-
-For more information about `qdmanage`, see the {qdmanageManPageLink}.
-
-== Managing Network Connections
-
-You can use `qdmanage` to view, create, update, and delete listeners and connectors for any router in your router network.
-
-=== Managing Listeners
-
-Listeners define how clients can connect to a router. The following table lists the `qdmanage` commands you can use to perform common operations on listeners.
-
-For more information about the attributes you can use with these commands, see link:{qdrouterdConfManPageUrl}#_listener[listener] in the `qdrouterd.conf` man page.
-
-//tag::qdmanage-connection-options-note[]
-[NOTE]
-====
-The commands in this table demonstrate operations on the local router listening on localhost and the default AMQP port (5672). If you want to perform an operation on a different router in the router network, you must specify the necessary connection options. For more information, see link:{qdmanageManPageUrl}#_connection_options[Connection Options] in the qdmanage man page.
-====
-//end::qdmanage-connection-options-note[]
-
-[cols="30,70"]
-|===
-| To... | Use this command...
-
-|View the router’s listeners
-a|
-[options="nowrap"]
-----
-qdmanage query --type=listener
-----
-
-|View the roles and ports on which the router is listening
-a|
-[options="nowrap"]
-----
-qdmanage query role port --type=listener
-----
-
-|View the attributes configured for a listener
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage read --name=_LISTENER_NAME_
-----
-
-|Create a listener
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage create --type=listener --_ATTRIBUTE_=_VALUE_ ...
-----
-
-|Create multiple listeners
-a|
-. Enter this command:
-+
-[options="nowrap"]
-----
-qdmanage create --stdin
-----
-. Configure the listeners using a JSON map:
-+
-[options="nowrap",subs="+quotes"]
-----
-[{"type"="listener", "_ATTRIBUTE_":"_VALUE_"...}, {"type"="listener", "_ATTRIBUTE_":"_VALUE_"...}...]
-----
-
-These commands use a JSON map to create two listeners.
-
-|Update a listener
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --type=listener --_ATTRIBUTE_=_VALUE_ ...
-----
-
-|Update multiple listeners
-a|
-. Enter this command:
-+
-[options="nowrap"]
-----
-qdmanage update --stdin
-----
-. Configure the listeners using a JSON map:
-+
-[options="nowrap",subs="+quotes"]
-----
-[{"type"="listener", "_ATTRIBUTE_":"_VALUE_"...}, {"type"="listener", "_ATTRIBUTE_":"_VALUE_"...}...]
-----
-
-These commands use a JSON map to update two listeners.
-
-|Delete an attribute from a listener
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --type=listener --_ATTRIBUTE_
-----
-
-|Delete a listener
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage delete --name=_LISTENER_NAME_
-----
-
-|===
-
-[id='managing-connectors']
-=== Managing Connectors
-
-Connectors define how the router can connect to other endpoints in your messaging network, such as brokers and other routers. The following table lists the `qdmanage` commands you can use to perform common operations on connectors.
-
-For more information about the attributes you can use with these commands, see link:{qdrouterdConfManPageUrl}#_connector[connector] in the `qdrouterd.conf` man page.
-
-// Note about qdmanage connection options.
-include::managing-using-qdmanage.adoc[tags=qdmanage-connection-options-note]
-
-[cols="30,70"]
-|===
-| To... | Use this command...
-
-|View the router’s connectors
-a|
-[options="nowrap"]
-----
-qdmanage query --type=connector
-----
-
-|View the roles and ports on which the router can connect to other endpoints
-a|
-[options="nowrap"]
-----
-qdmanage query role port --type=connector
-----
-
-|If the router is connected to a broker, view the alternate URLs on which the router can connect to the broker if the primary connection fails
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage query failoverUrls --type=connector --name=CONNECTOR_NAME
-----
-
-|View the attributes configured for a connector
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage read --name=_CONNECTOR_NAME_
-----
-
-|Create a connector
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage create --type=connector --_ATTRIBUTE_=_VALUE_ ...
-----
-
-|Create multiple connectors
-a|
-. Enter this command:
-+
-[options="nowrap"]
-----
-qdmanage create --stdin
-----
-. Configure the connectors using a JSON map:
-+
-[options="nowrap",subs="+quotes"]
-----
-[{"type"="connector", "_ATTRIBUTE_":"_VALUE_"...}, {"type"="connector", "_ATTRIBUTE_":"_VALUE_"...}...]
-----
-
-These commands use a JSON map to create two connectors.
-
-|Update a connector
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --type=connector --_ATTRIBUTE_=_VALUE_ ...
-----
-
-|Update multiple connectors
-a|
-. Enter this command:
-+
-[options="nowrap"]
-----
-qdmanage update --stdin
-----
-. Configure the connectors using a JSON map:
-+
-[options="nowrap",subs="+quotes"]
-----
-[{"type"="connector", "_ATTRIBUTE_":"_VALUE_"...}, {"type"="connector", "_ATTRIBUTE_":"_VALUE_"...}...]
-----
-
-These commands use a JSON map to update two connectors.
-
-|Delete an attribute from a connector
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --type=connector --_ATTRIBUTE_
-----
-
-|Delete a connector
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage delete --name=_CONNECTOR_NAME_
-----
-
-|===
-
-== Managing Security
-
-{RouterName} supports both SSL/TLS and SASL security protocols for encrypting and authenticating incoming and outgoing connections for your routers. You can use `qdmanage` to view, create, update, and delete security policies for any router in your router network.
-
-=== Managing SSL/TLS Encryption and Authentication
-
-{RouterName} supports SSL/TLS for certificate-level encryption and mutual authentication. The following table lists the common `qdmanage` commands you can use to secure incoming and outgoing connections for a router in your router network.
-
-For more information about the attributes you can use with these commands, see link:{qdrouterdConfManPageUrl}#_sslprofile[sslProfile] and link:{qdrouterdConfManPageUrl}#_listener[listener] in the `qdrouterd.conf` man page.
-
-// Note about qdmanage connection options.
-include::managing-using-qdmanage.adoc[tags=qdmanage-connection-options-note]
-
-[cols="30,70"]
-|===
-| To... | Use this command...
-
-|View the router’s SSL configuration
-a|
-[options="nowrap"]
-----
-qdmanage query --type=sslProfile
-----
-
-|Set up SSL for the router
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage create --type=sslProfile --name=_NAME_ --certDB=_PATH_ --certFile=_PATH_ --privateKeyFile=_PATH_ --_ATTRIBUTE_=_VALUE_ ...
-----
-
-|Add SSL/TLS encryption to an incoming connection
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_LISTENER_NAME_ --sslProfile=_NAME_ --requireSsl=yes
-----
-
-|Change SSL/TLS encryption on an incoming connection
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_LISTENER_NAME_ --_ATTRIBUTE_=_VALUE_ ...
-----
-
-|Add SSL/TLS client authentication to an incoming connection
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_LISTENER_NAME_ --authenticatePeer=yes
-----
-
-|Remove SSL/TLS client authentication from an incoming connection
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_LISTENER_NAME_ --authenticatePeer=no
-----
-
-|Add SSL/TLS client authentication to an outgoing connection
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_CONNECTOR_NAME_ --sslProfile=_NAME_
-----
-
-|Remove SSL/TLS client authentication from an outgoing connection
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_CONNECTOR_NAME_ --sslProfile
-----
-
-|Delete an SSL profile
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage delete --name=_SSL_PROFILE_NAME_
-----
-
-|===
-
-=== Managing SASL Encryption and Authentication
-
-{RouterName} supports SASL for authentication and payload encryption. The following table lists the common `qdmanage` commands you can use to secure incoming and outgoing connections for a router in your router network.
-
-For more information about the attributes you can use with these commands, see link:{qdrouterdConfManPageUrl}#_router[router] and link:{qdrouterdConfManPageUrl}#_listener[listener] in the `qdrouterd.conf` man page.
-
-// Note about qdmanage connection options.
-include::managing-using-qdmanage.adoc[tags=qdmanage-connection-options-note]
-
-[cols="30,70"]
-|===
-| To... | Use this command...
-
-|Set up SASL for the router
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --type=router --saslConfigDir=_PATH_ --saslConfigName=_NAME_
-----
-
-|Add SASL authentication to an incoming connection
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_LISTENER_NAME_ --authenticatePeer=yes --saslMechanisms=_MECHANISMS_
-----
-
-|Change SASL mechanisms for an incoming connection
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_LISTENER_NAME_ --saslMechanisms=_MECHANISMS_
-----
-
-|Add SASL authentication to an outgoing connection
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_CONNECTOR_NAME_ --saslMechanisms=_MECHANISMS_ --saslUsername=_USERNAME_ --saslPassword=_PASSWORD_
-----
-
-|Change SASL mechanisms for an outgoing connection
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_CONNECTOR_NAME_ --saslMechanisms=_MECHANISMS_
-----
-
-|Add SASL payload encryption to an incoming connection
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_LISTENER_NAME_ --requireEncryption=yes --saslMechanisms=_MECHANISMS_
-----
-
-|Change SASL mechanisms for an incoming connection
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_LISTENER_NAME_ --saslMechanisms=_MECHANISMS_
-----
-
-|Remove SASL payload encryption from an incoming connection
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_LISTENER_NAME_ --requireEncryption=no --saslMechanisms
-----
-
-|Delete a SASL configuration
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --type=router --saslConfigDir --saslConfigName
-----
-
-|===
-
-== Managing Routing
-
-{RouterName} supports both message routing and link routing for distributing messages between senders and receivers. You can use `qdmanage` to view how addresses and link routes are configured in your environment, and define how a router should distribute messages.
-
-=== Managing Message Routing
-
-Message routing involves configuring addresses to define how {RouterName} should distribute messages. The following table lists the common `qdmanage` commands you can use to configure addresses for a router in your router network.
-
-For more information about the attributes you can use with these commands, see link:{qdrouterdConfManPageUrl}#_address[address] and link:{qdrouterdConfManPageUrl}#_autolink[autolink] in the `qdrouterd.conf` man page.
-
-// Note about qdmanage connection options.
-include::managing-using-qdmanage.adoc[tags=qdmanage-connection-options-note]
-
-[cols="30,70"]
-|===
-| To... | Use this command...
-
-|View addresses
-a|
-[options="nowrap"]
-----
-qdmanage query --type=address
-----
-
-[options="nowrap",subs="+quotes"]
-----
-qdmanage read --name=_ADDRESS_NAME_
-----
-
-|View address distribution patterns
-a|
-[options="nowrap"]
-----
-qdmanage query prefix distribution --type=address
-----
-
-|View waypoints to broker queues
-a|
-[options="nowrap"]
-----
-qdmanage query prefix --type=address --waypoint=yes
-----
-
-|View autolinks
-a|
-[options="nowrap"]
-----
-qdmanage query --type=autolink
-----
-
-|Set a distribution pattern for an address
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage create --type=address --prefix=_ADDRESS_PREFIX_ --distribution=_DISTRIBUTION_PATTERN_ ...
-----
-
-|Set distribution patterns for multiple addresses
-a|
-. Enter this command:
-+
-[options="nowrap",subs="+quotes"]
-----
-qdmanage create --stdin
-----
-
-. Configure the addresses using a JSON map:
-+
-[options="nowrap",subs="+quotes"]
-----
-[{"type":"address", "prefix":"_ADDRESS_PREFIX_", "distribution":"_DISTRIBUTION_PATTERN_", "_ATTRIBUTE_":"_VALUE_", ...}, {"type":"address", "prefix":"_ADDRESS_PREFIX_", "distribution":"_DISTRIBUTION_PATTERN_", "_ATTRIBUTE_":"_VALUE_", ...} ...]
-----
-
-These commands configure two addresses.
-
-|Connect an address to a broker queue
-a|
-. Enter this command:
-+
-[options="nowrap"]
-----
-qdmanage create --stdin
-----
-
-. Create an address waypoint, an incoming autolink, and an outgoing autolink:
-+
-[options="nowrap",subs="+quotes"]
-----
-[{"type":"address", "prefix":"_ADDRESS_PREFIX_", "waypoint":"yes"}, {"type":"autolink", "addr":"_ADDRESS_NAME_", "connection":"_CONNECTOR/LISTENER_NAME_", "direction":"in"}, {"type":"autolink", "addr":"_ADDRESS_NAME_", "connection":"_CONNECTOR/LISTENER_NAME_", "direction":"out"}]
-----
-
-|Update an address configuration
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_ADDRESS_NAME_ --_ATTRIBUTE_=_VALUE_ ...
-----
-
-|Update an autolink
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_AUTOLINK_NAME_ --_ATTRIBUTE_=_VALUE_ ...
-----
-
-|Delete an address configuration
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage delete --name=_ADDRESS_NAME_
-----
-
-|Delete an autolink
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage delete --name=_AUTOLINK_NAME_
-----
-
-|===
-
-=== Managing Link Routing
-
-A link route is a chain of links between a sender and receiver that provides a private messaging path. The following table lists the common `qdmanage` commands you can use to view, create, update, and delete link routes.
-
-For more information about the attributes you can use with these commands, see the link:{qdrouterdConfManPageUrl}#_linkroute[linkRoute] in the `qdrouterd.conf` man page.
-
-// Note about qdmanage connection options.
-include::managing-using-qdmanage.adoc[tags=qdmanage-connection-options-note]
-
-[cols="30,70"]
-|===
-| To... | Use this command...
-
-|View link routes
-a|
-[options="nowrap"]
-----
-qdmanage query --type=linkRoute
-----
-
-[options="nowrap",subs="+quotes"]
-----
-qdmanage read --name=_LINK_ROUTE_NAME_
-----
-
-|Create a link route
-a|
-. Enter this command:
-+
-[options="nowrap"]
-----
-qdmanage create --stdin
-----
-
-. Create an incoming and outgoing link route:
-+
-[options="nowrap",subs="+quotes"]
-----
-[{"type":"linkRoute", "prefix":"_ADDRESS_PREFIX_", "connection":"_CONNECTOR/LISTENER_NAME_", "direction":"in", ...}, {"type":"linkRoute", "prefix":"_ADDRESS_PREFIX_", "connection":"_CONNECTOR/LISTENER_NAME_", "direction":"out", ...}]
-----
-
-|Update a link route
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_LINK_ROUTE_NAME_ --_ATTRIBUTE_=_VALUE_ ...
-----
-
-|Delete a link route
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage delete --name=_INCOMING_LINK_ROUTE_NAME_
-qdmanage delete --name=_OUTGOING_LINK_ROUTE_NAME_
-----
-
-|===
-
-== Managing Logging
-
-{RouterName} logs are broken into different categories called logging modules. Each module provides important information about a particular aspect of a router. The following table lists the common `qdmanage` commands you can use to view and change the configuration of a logging module.
-
-For more information about the attributes you can use with these commands, see link:{qdrouterdConfManPageUrl}#_log[log] in the `qdrouterd.conf` man page.
-
-// Note about qdmanage connection options.
-include::managing-using-qdmanage.adoc[tags=qdmanage-connection-options-note]
-
-[cols="30,70"]
-|===
-| To... | Use this command...
-
-|View the logging configuration
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage query --type=log
-----
-
-|View the logging configuration for a logging module
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage read --type=log --module=_LOGGING_MODULE_NAME_
-----
-
-|Set the default logging configuration
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage create --type=log --module=DEFAULT --enable=_LOGGING_LEVEL_ --includeTimestamp=yes --_ATTRIBUTE_=_VALUE_
-----
-
-|Enable logging for a logging module
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage create --type=log --module=_LOGGING_MODULE_NAME_ --enable=_LOGGING_LEVEL_ --_ATTRIBUTE_=_VALUE_ ...
-----
-
-|Change the logging configuration for a logging module
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --type=log --module=_LOGGING_MODULE_NAME_ --_ATTRIBUTE_=_VALUE_ ...
-----
-
-|===
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/monitoring-using-qdstat.adoc
----------------------------------------------------------------------
diff --git a/doc/new-book/monitoring-using-qdstat.adoc b/doc/new-book/monitoring-using-qdstat.adoc
deleted file mode 100644
index c0b1c64..0000000
--- a/doc/new-book/monitoring-using-qdstat.adoc
+++ /dev/null
@@ -1,392 +0,0 @@
-////
-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
-////
-
-[id='monitoring-using-qdstat']
-= Monitoring {RouterName} Using `qdstat`
-
-You can use `qdstat` to view the status of routers on your router network. For example, you can view information about the attached links and configured addresses, available connections, and nodes in the router network.
-
-== Syntax for Using `qdstat`
-
-You can use `qdstat` with the following syntax:
-
-[options="nowrap",subs="+quotes"]
-----
-$ qdstat __OPTION__ [__CONNECTION_OPTIONS__] [__SECURE_CONNECTION_OPTIONS__]
-----
-
-This specifies:
-
-* An `option` for the type of information to view.
-* One or more optional `connection_options` to specify a router for which to view the information.
-+
-If you do not specify a connection option, `qdstat` connects to the router listening on localhost and the default AMQP port (5672).
-* The `secure_connection_options` if the router for which you want to view information only accepts secure connections.
-
-For more information about `qdstat`, see the {qdstatManPageLink}.
-
-== Viewing General Statistics for a Router
-
-You can view information about a router in the router network, such as its working mode and ID.
-
-.Procedure
-
-* Use the following command:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-$ qdstat -g [__CONNECTION_OPTIONS__]
-----
-
-This example shows general statistics for the local router:
-
-[options="nowrap"]
-----
-$ qdstat -g
-Router Statistics
- attr value
- =========================
- Version 0.8.0
- Mode standalone
- Area 0
- Router Id Router.A
- Link Routes 0
- Auto Links 0
- Links 2
- Nodes 0
- Addresses 4
- Connections 1
-----
---
-
-== Viewing a List of Connections to a Router
-
-You can view:
-
-* Connections from clients (sender/receiver)
-* Connections from and to other routers in the network
-* Connections to other containers (such as brokers)
-* Connections from the tool itself
-
-.Procedure
-
-* Use this command:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-$ qdstat -c [__CONNECTION_OPTIONS__]
-----
-
-For more information about the fields displayed by this command, see link:{qdstatManPageUrl}#_qdstat_c[the qdstat -c output columns^].
-
-In this example, two clients are connected to `Router.A`. `Router.A` is connected to `Router.B` and a broker.
-
-Viewing the connections on Router.A displays the following:
-
-[options="nowrap"]
-----
-$ qdstat -c -r Router.A
-Connections
-id host container role dir security authentication tenant
-==================================================================================================================================
- 2 127.0.0.1:5672 route-container out no-security anonymous-user // <1>
- 10 127.0.0.1:5001 Router.B inter-router out no-security anonymous-user // <2>
- 12 localhost.localdomain:42972 161211fe-ba9e-4726-9996-52d6962d1276 normal in no-security anonymous-user // <3>
- 14 localhost.localdomain:42980 a35fcc78-63d9-4bed-b57c-053969c38fda normal in no-security anonymous-user // <3>
- 15 localhost.localdomain:42982 0a03aa5b-7c45-4500-8b38-db81d01ce651 normal in no-security anonymous-user // <4>
-----
-<1> This connection shows that `Router.A` is connected to a broker, because the `role` is `route-container`, and the `dir` is `out`.
-<2> `Router.A` is also connected to another router on the network (the `role` is `inter-router`), establishing an output connection (the `dir` is `out`).
-<3> These connections show that two clients are connected to `Router.A`, because the `role` is `normal`, and the `dir` is `in`.
-<4> The connection from `qdstat` to `Router.A`. This is the connection that `qdstat` uses to query `Router.A` and display the command output.
-
-`Router.A` is connected to `Router.B`. Viewing the connections on `Router.B` displays the following:
-
-[options="nowrap"]
-----
-$ qdstat -c -r Router.B
-Connections
-id host container role dir security authentication tenant
-====================================================================================================
- 1 localhost.localdomain:51848 Router.A inter-router in no-security anonymous-user // <1>
-----
-<1> This connection shows that `Router.B` is connected to `Router.A` through an incoming connection (the `role` is `inter-router` and the `dir` is `in`). There is not a connection from `qdstat` to `Router.B`, because the command was run from `Router.A` and forwarded to `Router.B`.
---
-
-== Viewing AMQP Links Attached to a Router
-
-You can view a list of AMQP links attached to the router from clients (sender/receiver), from or to other routers into the network, to other containers (for example, brokers), and from the tool itself.
-
-.Procedure
-* Use this command:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-$ qdstat -l [__CONNECTION_OPTIONS__]
-----
-
-For more information about the fields displayed by this command, see link:{qdstatManPageUrl}#_qdstat_l[the qdstat -l output columns^].
-
-In this example, `Router.A` is connected to both `Router.B` and a broker. A link route is configured for the `my_queue` queue and waypoint (with autolinks), and for the `my_queue_wp` queue on the broker. In addition, there is a receiver connected to `my_address` (message routing based), another to `my_queue`, and the a third one to `my_queue_wp`.
-
-In this configuration, the router uses only one connection to the broker for both the waypoints (related to `my_queue_wp`) and the link route (related to `my_queue`).
-
-Viewing the links displays the following:
-
-[options="nowrap"]
-----
-$ qdstat -l
-Router Links
- type dir conn id id peer class addr phs cap undel unsett del presett acc rej rel mod admin oper
- ==============================================================================================================================================
- router-control in 2 7 250 0 0 2876 0 0 0 0 0 enabled up // <1>
- router-control out 2 8 local qdhello 250 0 0 2716 0 0 0 0 0 enabled up
- inter-router in 2 9 250 0 0 1 0 0 0 0 0 enabled up
- inter-router out 2 10 250 0 0 1 0 0 0 0 0 enabled up
- endpoint in 1 11 mobile my_queue_wp 1 250 0 0 3 0 0 0 0 0 enabled up // <2>
- endpoint out 1 12 mobile my_queue_wp 0 250 0 0 3 0 0 0 0 0 enabled up
- endpoint out 4 15 mobile my_address 0 250 0 0 0 0 0 0 0 0 enabled up // <3>
- endpoint out 6 18 19 250 0 0 1 0 0 0 0 0 enabled up // <4>
- endpoint in 1 19 18 0 0 0 1 0 0 0 0 0 enabled up // <5>
- endpoint out 19 40 mobile my_queue_wp 1 250 0 0 1 0 0 0 0 0 enabled up // <6>
- endpoint in 24 48 mobile $management 0 250 0 0 1 0 0 0 0 0 enabled up
- endpoint out 24 49 local temp.mx5HxzUe2Eddw_s 250 0 0 0 0 0 0 0 0 enabled up
-----
-<1> The `conn id` 2 connection has four links (in both directions) for inter-router communications with `Router.B`, such as control messages and normal message-routed deliveries.
-<2> There are two autolinks (`conn id 1`) for the waypoint for `my_queue_wp`. There is an incoming (`id 11`) and outgoing (`id 12`) link to the broker, and another `out` link (`id 40`) to the receiver.
-<3> A `mobile` link for `my_address`. The `dir` is `out` related to the receiver attached to it.
-<4> The `out` link from the router to the receiver for `my_queue`. This enables the router to deliver messages to the receiver.
-<5> The `in` link to the router for `my_queue`. This enables the router to get messages from `my_queue` so that they can be sent to the receiver on the `out` link.
-<6> The remaining links are related to the `$management` address and are used by `qdstat` to receive the information that is displayed by this command.
---
-
-== Viewing Known Routers on a Network
-
-To see the topology of the router network, you can view known routers on the network.
-
-.Procedure
-
-* Use this command:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-$ qdstat -n [__CONNECTION_OPTIONS__]
-----
-
-For more information about the fields displayed by this command, see link:{qdstatManPageUrl}#_qdstat_n[the qdstat -n output columns^].
-
-In this example, `Router.A` is connected to `Router.B`, which is connected to `Router.C`. Viewing the router topology on `Router.A` shows the following:
-
-[options="nowrap"]
-----
-$ qdstat -n -r Router.A
-Routers in the Network
- router-id next-hop link cost neighbors valid-origins
- ==========================================================================
- Router.A (self) - ['Router.B'] [] // <1>
- Router.B - 0 1 ['Router.A', 'Router.C'] [] // <2>
- Router.C Router.B - 2 ['Router.B'] [] // <3>
-----
-<1> `Router.A` has one neighbor: `Router.B`.
-<2> `Router.B` is connected to `Router.A` and `Router.C` over `link` 0. The `cost` for `Router.A` to reach `Router.B` is 1, because the two routers are connected directly.
-<3> `Router.C` is connected to `Router.B`, but not to `Router.A`. The `cost` for `Router.A` to reach `Router.C` is 2, because messages would have to pass through `Router.B` as the `next-hop`.
-
-`Router.B` shows a different view of the router topology:
-
-[options="nowrap"]
-----
-$ qdstat -n -v -r Router.B
-Routers in the Network
- router-id next-hop link cost neighbors valid-origins
- ==========================================================================
- Router.A - 0 1 ['Router.B'] ['Router.C']
- Router.B (self) - ['Router.A', 'Router.C'] []
- Router.C - 1 1 ['Router.B'] ['Router.A']
-----
-
-The `neighbors` list is the same when viewed on `Router.B`. However, from the perspective of `Router.B`, the destinations on `Router.A` and `Router.C` both have a `cost` of `1`. This is because `Router.B` is connected to `Router.A` and `Router.C` through links.
-
-The `valid-origins` column shows that starting from `Router.C`, `Router.B` has the best path to reach `Router.A`. Likewise, starting from `Router.A`, `Router.B` has the best path to reach `Router.C`.
-
-Finally, `Router.C` shows the following details about the router topology:
-
-[options="nowrap"]
-----
-$ qdstat -n -v -r Router.C
-Routers in the Network
- router-id next-hop link cost neighbors valid-origins
- ==========================================================================
- Router.A Router.B - 2 ['Router.B'] []
- Router.B - 0 1 ['Router.A', 'Router.C'] []
- Router.C (self) - ['Router.B'] []
-----
-
-Due to a symmetric topology, the `Router.C` perspective of the topology is very similar to the `Router.A` perspective. The primary difference is the `cost`: the cost to reach `Router.B` is `1`, because the two routers are connected. However, the cost to reach `Router.A` is `2`, because the messages would have to pass through `Router.B` as the `next-hop`.
---
-
-== Viewing Addresses Known to a Router
-
-You can view message-routed and link-routed addresses known to a router.
-
-.Procedure
-
-* Use the following command:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-$ qdstat -a [__CONNECTION_OPTIONS__]
-----
-
-For more information about the fields displayed by this command, see link:{qdstatManPageUrl}#_qdstat_a[the qdstat -a output columns^].
-
-In this example, `Router.A` is connected to both `Router.B` and a broker. The broker has two queues:
-
-* `my_queue` (with a link route on `Router.A`)
-* `my_queue_wp` (with a waypoint and autolinks configured on `Router.A`)
-
-In addition, there are three receivers: one connected to `my_address` for message routing, another connected to `my_queue`, and the last one connected to `my_queue_wp`.
-
-Viewing the addresses displays the following information:
-
-[options="nowrap"]
-----
-$ 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 8 0 0 8 0
- local $management closest 1 0 0 0 0 0 0 0 0
- router Router.B closest 0 0 1 0 0 0 5 0 5 // <1>
- mobile my_address 0 closest 0 1 0 0 1 1 0 0 0 // <2>
- link-in my_queue linkBalanced 0 0 0 1 0 0 0 0 0 // <3>
- link-out my_queue linkBalanced 0 0 0 1 0 0 0 0 0
- mobile my_queue_wp 1 balanced 0 1 0 0 1 1 0 0 0 // <4>
- mobile my_queue_wp 0 balanced 0 1 0 0 1 1 0 0 0
- local qdhello flood 1 1 0 0 0 0 0 741 706 // <5>
- local qdrouter flood 1 0 0 0 0 0 0 4 0
- topo qdrouter flood 1 0 1 0 0 0 27 28 28
- local qdrouter.ma multicast 1 0 0 0 0 0 0 1 0
- topo qdrouter.ma multicast 1 0 1 0 0 0 2 0 3
- local temp.IJSoXoY_lX0TiDE closest 0 1 0 0 0 0 0 0 0
-----
-<1> An address related to `Router.B` with a `remote` at 1. This is the consumer from `Router.B`.
-<2> The `my_address` address has one local consumer, which is related to the single receiver attached on that address. The `in` and `out` fields are both 1, which means that one message has traveled through this address using the `closest` distribution method.
-<3> The incoming link route for the `my_queue` address. This address has one locally-attached container (`cntnr`) as a destination (in this case, the broker). The following entry is the outgoing link for the same address.
-<4> The incoming autolink for the `my_queue_wp` address and configured waypoint. There is one local consumer (`local`) for the attached receiver. The following entry is the outgoing autolink for the same address. A single message has traveled through the autolinks.
-<5> The `qdhello`, `qdrouter`, and `qdrouter.ma` addresses are used to periodically update the network topology and deliver router control messages. These updates are made automatically through the inter-router protocol, and are based on all of the messages the routers have exchanged. In this case, the distribution method (`distrib`) for each address is either flood or multicast to ensure the control messages reach all of the routers in the network.
---
-
-== Viewing a Router's Autolinks
-
-You can view a list of the autolinks that are associated with waypoint addresses for a node on another container (such as a broker).
-
-.Procedure
-
-* Use the following command:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-$ qdstat --autolinks [__CONNECTION_OPTIONS__]
-----
-
-For more information about the fields displayed by this command, see link:{qdstatManPageUrl}#_qdstat_autolinks[the qdstat --autolinks output columns^].
-
-In this example, a router is connected to a broker. The broker has a queue called `my_queue_wp`, to which the router is configured with a waypoint and autolinks. Viewing the autolinks displays the following:
-
-[options="nowrap"]
-----
-$ qdstat --autolinks
-AutoLinks
- addr dir phs link status lastErr
- ==============================================
- my_queue_wp in 1 4 active // <1>
- my_queue_wp out 0 5 active // <2>
-----
-<1> The incoming autolink from `my_queue_wp`. As indicated by the `status` field, the link is active, because the broker is running and the connection for the link is already established (as indicated by the `link` field).
-<2> The outgoing autlink to `my_queue_wp`. Like the incoming link, it is active and has an established connection.
---
-
-== Viewing the Status of a Router's Link Routes
-
-You can view the status of each incoming and outgoing link route.
-
-.Procedure
-
-* Use the following command:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-$ qdstat --linkroutes [__CONNECTION_OPTIONS__]
-----
-
-For more information about the fields displayed by this command, see link:{qdstatManPageUrl}#_qdstat_linkroutes[the qdstat --linkroutes output columns^].
-
-In this example, a router is connected to a broker. The router is configured with a link route to the `my_queue` queue on the broker. Viewing the link routes displays the following:
-
-[options="nowrap"]
-----
-$ qdstat --linkroutes
-Link Routes
- prefix dir distrib status
- =====================================
- my_queue in linkBalanced active // <1>
- my_queue out linkBalanced active // <2>
-----
-<1> The incoming link route from `my_queue` to the router. This route is currently active, because the broker is running.
-<2> The outgoing link from the router to `my_queue`. This route is also currently active.
---
-
-== Viewing Memory Consumption Information
-
-If you need to perform debugging or tracing for a router, you can view information about its memory consumption.
-
-.Procedure
-
-* Use the following command:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-$ qdstat -m [__CONNECTION_OPTIONS__]
-----
-
-This command displays information about allocated objects, their size, and their usage by application threads:
-
-[options="nowrap"]
-----
-$ qdstat -m
-Types
- type size batch thread-max total in-threads rebal-in rebal-out
- ===========================================================================================
- qd_bitmask_t 24 64 128 64 64 0 0
- qd_buffer_t 536 16 32 80 80 0 0
- qd_composed_field_t 64 64 128 256 256 0 0
- qd_composite_t 112 64 128 320 320 0 0
- ...
-----
---
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org
[06/11] qpid-dispatch git commit: DISPATCH-851: Move the new book
into primary position and reorg the docs
Posted by jr...@apache.org.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/theory_of_operation.adoc
----------------------------------------------------------------------
diff --git a/doc/new-book/theory_of_operation.adoc b/doc/new-book/theory_of_operation.adoc
deleted file mode 100644
index dc50154..0000000
--- a/doc/new-book/theory_of_operation.adoc
+++ /dev/null
@@ -1,394 +0,0 @@
-////
-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
-////
-
-= Theory of Operation
-
-This section introduces some key concepts about the router.
-
-== Overview
-
-The {RouterName} is an _application layer_ program running as a normal
-user program or as a daemon.
-
-{RouterName} accepts AMQP connections from clients and creates AMQP
-connections to brokers or AMQP-based services. {RouterName} classifies
-incoming AMQP messages and routes the
-messages between message producers and message consumers.
-
-{RouterName} 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. {RouterName} relies on
-redundant network paths to provide continued connectivity in the face
-of system or network failure.
-
-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.
-
-== Connections
-
-{RouterName} connects clients, servers, AMQP services, and other
-routers through network connections.
-
-=== Listener
-
-{RouterName} provides _listeners_ 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.
-
-Several types of listeners are defined by their role.
-
-[cols="20,80"]
-|===
-| Role | Description
-| normal | The connection is used for AMQP clients using normal message delivery.
-| inter-router | 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 | 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.
-|===
-
-=== Connector
-
-{RouterName} can also be configured to create outbound connections to
-messaging brokers or other AMQP entities using _connectors_. 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.
-
-Several types of connectors are defined by their role.
-
-[cols="20,80"]
-|===
-| Role | Description
-| normal | 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.
-| inter-router | 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 | 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.
-|===
-
-== Addresses
-
-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 _to_ and _reply-to_ fields of a message's properties. They are also
-used during the creation of links in the _address_ field of a _source_ or
-a _target_.
-
-[NOTE]
-====
-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.
-====
-
-Addresses designate various kinds of entities in a messaging network:
-
-* Endpoint processes that consume data or offer a service
-* Topics that match multiple consumers to multiple producers
-* Entities within a messaging broker:
-** Queues
-** Durable Topics
-** Exchanges
-
-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.
-
-{RouterName} maintains several classes of address based on how the address is
-configured or discovered.
-
-[cols="25,75"]
-|===
-| Address Type | Description
-| mobile | The address is a rendezvous point between senders and receivers. The router aggregates and serializes messages from senders and distributes messages to receivers.
-| link route | The address defines a private messaging path between a sender and a receiver. The router simply passes messages between the end points.
-|===
-
-=== Mobile Addresses
-
-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.
-
-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.
-
-Mobile addresses may be discovered during normal router operation or
-configured through management settings.
-
-==== Discovered Mobile Addresses
-
-Mobile addresses are created when a client creates a link to a source
-or destination address that is unknown to the router network.
-
-Suppose a service provider wants to offer _my-service_ that clients
-may use. The service provider must open a receiver link with source
-address _my-service_. The router creates a mobile address
-_my-service_ and propagates the address so that it is known to every
-router in the network.
-
-Later a client wants to use the service and creates a sending link
-with target address _my-service_. The router matches the service
-provider's receiver having source address _my-service_ to the client's
-sender having target address _my-service_ and routes messages between
-the two.
-
-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.
-
-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 _my-service_ 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.
-
-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.
-
-==== Configured Mobile Addresses
-
-Mobile addresses may be configured using the router _autoLink_
-object. An address created via an _autoLink_ represents a queue,
-topic, or other service in an external broker. Logically the
-_autoLink_ addresses are treated by the router network as if the
-broker had connected to the router and offered the services itself.
-
-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.
-
-Multiple _autoLink_ 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.
-
-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.
-
-=== Link Route Addresses
-
-Link route addresses may be configured using the router _linkRoute_
-object. An link route address represents a queue, topic, or other
-service in an external broker similar to addresses configured by
-_autoLink_ 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.
-
-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.
-
-== Message Routing
-
-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:
-
-* Routing pattern - balanced, closest, multicast
-* Routing mechanism - message routed, link routed
-
-// * TODO: describe these???
-// * Undeliverable action - drop, hold and retry, redirect
-// * Reliability - N destinations, etc.
-
-=== Routing Patterns
-
-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.
-
-Note that the routing patterns fall into two categories: Anycast
-(Balanced and Closest) and Multicast. There is no concept of
-"unicast" in which there is only one consumer for an address.
-
-Anycast distribution delivers each message to one consumer whereas
-multicast distribution delivers each message to all consumers.
-
-Anycast delivery is reliable when the message deliveries are
-unsettled. There is a reliability contract that the router network
-abides by when delivering unsettled messages to anycast addresses.
-For every such delivery sent by a producer, the router network
-guarantees that one of the following outcomes will occur:
-
-* The delivery shall be settled with ACCEPTED or REJECTED disposition
- where the disposition is supplied by the consumer.
-* The delivery shall be settled with RELEASED disposition, meaning
- that the message was not delivered to any consumer.
-* The delivery shall be settled with MODIFIED disposition, meaning
- that the message may have been delivered to a consumer but should be
- considered in-doubt and re-sent.
-* The connection to the producer shall be dropped, signifying that all
- unsettled deliveries should now be considered in-doubt by the
- producer and later re-sent.
-
-Multicast delivery is not reliable. If a producer sends an unsettled
-delivery, the ingress router shall settle the delivery with ACCEPTED
-disposition regardless of whether the message was delivered to any
-consumers.
-
-==== Balanced
-
-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.
-
-==== Closest
-
-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.
-
-==== Multicast
-
-Having multiple consumers on the same address at the same time,
-messages are routed such that each consumer receives one copy of the
-message.
-
-
-=== Routing Mechanisms
-
-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 _routing_:
-
- 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.
-
-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.
-
-==== Message Routed
-
-Message routing occurs upon delivery of a message and is done based on
-the address in the message's _to_ field.
-
-When a delivery arrives on an incoming message-routing link, the
-router extracts the address from the delivered message's _to_ 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.
-
-Message routing can also occur without an address in the
-message's _to_ field if the incoming link has a target address. In
-fact, if the sender uses a link with a target address, the _to_ field
-shall be ignored even if used.
-
-==== Link Routed
-
-Link routing occurs when a new link is attached to the router across
-one of its AMQP connections. It is done based on the _target.address_
-field of an inbound link and the _source.address_ field of an outbound
-link.
-
-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.
-
-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.
-
-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.
-
-=== Message Settlement
-
-Messages may be delivered with varying degrees of reliability.
-
-* At most once
-* At least once
-* Exactly once
-
-The reliability is negotiated between the client and server during
-link establishment. The router handles all levels of reliability by treating
-messages as either _pre-settled_ or _unsettled_.
-
-[cols="20,80"]
-|===
-| Delivery | Handling
-| pre-settled | 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.
-| unsettled | 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.
-|===
-
-== Security
-
-{RouterName} 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.
-
-The router `policy` module is an optional authorization mechanism
-enforcing user connection restrictions and AMQP resource access
-control.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/understand-router-configuration.adoc
----------------------------------------------------------------------
diff --git a/doc/new-book/understand-router-configuration.adoc b/doc/new-book/understand-router-configuration.adoc
deleted file mode 100644
index a576f65..0000000
--- a/doc/new-book/understand-router-configuration.adoc
+++ /dev/null
@@ -1,206 +0,0 @@
-////
-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
-////
-
-[id='router-configuration']
-= Configuration
-
-Before starting {RouterName}, 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.
-
-== Accessing the Router Configuration File
-
-The router's configuration is defined in the router configuration file. You can access this file to view and modify that configuration.
-
-.Procedure
-
-* Open the following file: `/etc/qpid-dispatch/qdrouterd.conf`.
-+
---
-When {RouterName} is installed, `qdrouterd.conf` is installed in this directory by default. When the router is started, it runs with the settings defined in this file.
-
-For more information about the router configuration file (including available entities and attributes), see the {qdrouterdManPageLink}.
---
-
-== How the Router Configuration File is Structured
-
-Before you can make changes to a router configuration file, you should understand how the file is structured.
-
-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:
-
-[options="nowrap"]
-----
-sectionName {
- attributeName: attributeValue
- attributeName: attributeValue
- ...
-}
-----
-
-[id='methods-for-changing-router-configuration']
-== Changing a Router's Configuration
-
-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.
-
-.Choices
-* xref:making-permanent-change-to-router-configuration[Make a permanent change to the router's configuration].
-* xref:changing-configuration-for-running-router[Change the configuration for a running router.]
-
-[id='making-permanent-change-to-router-configuration']
-=== Making a Permanent Change to the Router's Configuration
-
-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.
-
-.Procedure
-
-. Do one of the following:
-+
-* Edit the default configuration file (`/etc/qpid-dispatch/qdrouterd.conf`).
-* Create a new configuration file.
-
-. Start (or restart) the router.
-+
-If you created a new configuration file, you must specify the path using the `--conf` parameter. For example, the following command starts the router with a non-default configuration file:
-+
-[options="nowrap"]
-----
-$ sudo qdrouterd -d --conf /etc/qpid-dispatch/new-configuration-file.conf
-----
-
-[id='changing-configuration-for-running-router']
-=== Changing the Configuration for a Running Router
-
-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.
-
-.Procedure
-
-* Use `qdmanage` to change the configuration.
-+
-For more information about using `qdmanage`, see xref:managing-router[Managing {RouterName} Using _qdmanage_].
-
-== Default Configuration Settings
-
-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.
-
-When you installed {RouterName}, the default configuration file was added at the following path: `/etc/qpid-dispatch/qdrouterd.conf`. 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.
-
-.Default Configuration File
-
-[options="nowrap"]
-----
-router {
- mode: standalone // <1>
- id: Router.A // <2>
-}
-
-listener { // <3>
- host: 0.0.0.0 // <4>
- port: amqp // <5>
- authenticatePeer: no // <6>
-}
-
-address { // <7>
- prefix: closest
- distribution: closest
-}
-
-address {
- prefix: multicast
- distribution: multicast
-}
-
-address {
- prefix: unicast
- distribution: closest
-}
-
-address {
- prefix: exclusive
- distribution: closest
-}
-
-address {
- prefix: broadcast
- distribution: multicast
-}
-----
-<1> By default, the router operates in _standalone_ 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.
-<2> The unique identifier of the router. This ID is used as the `container-id` (container name) at the AMQP protocol level. It is required, and the router will not start if this attribute is not defined.
-<3> The `listener` entity handles incoming connections from client endpoints.
-<4> The IP address on which the router will listen for incoming connections. By default, the router is configured to listen on all network interfaces.
-<5> 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.
-<6> Specifies whether the router should authenticate peers before they can connect to the router. By default, peer authentication is not required.
-<7> By default, the router is configured to use the message routing mechanism. Each `address` entity defines how messages that are received with a particular address `prefix` should be distributed. For example, all messages with addresses that start with `closest` will be distributed using the `closest` distribution pattern.
-
-[NOTE]
-====
-If a client requests a message with an address that is not defined in the router's configuration file, the `balanced` distribution pattern will be used automatically.
-====
-
-== Setting Essential Configuration Properties
-
-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.
-
-.Procedure
-
-. Open the router's configuration file.
-+
-If you are changing the router's default configuration file, the file is located at `/etc/qpid-dispatch/qdrouterd.conf`.
-
-. To define essential router information, change the following attributes as needed in the `router` section:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-router {
- mode: _STANDALONE/INTERIOR_
- id: _ROUTER_ID_
-}
-----
-
-`mode`:: Specify one of the following modes:
-+
-* `standalone` - 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.
-* `interior` - Use this mode if the router is part of a router network and needs to collaborate with other routers.
-`id`:: The unique identifier for the router. This ID will also be the container name at the AMQP protocol level.
-
-For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_router[router] in the `qdrouterd.conf` man page.
---
-
-. If necessary for your environment, secure the router.
-+
---
-* xref:setting-up-ssl-for-encryption-and-authentication[Set up SSL/TLS for encryption, authentication, or both]
-* xref:setting-up-sasl-for-authentication-and-payload-encryption[Set up SASL for authentication and payload encryption]
---
-
-. Connect the router to other routers, clients, and brokers.
-+
---
-* xref:adding-incoming-connections[Add incoming connections]
-* xref:adding-outgoing-connections[Add outgoing connections]
---
-
-. Set up routing for your environment:
-+
---
-* xref:routing-messages-between-clients[Configure the router to route messages between clients directly]
-* xref:routing-messages-through-broker[Configure the router to route messages through a broker queue]
-* xref:creating-link-route[Create a link route to define a private messaging path between endpoints]
---
-
-. xref:logging[Set up logging].
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/using-console.adoc
----------------------------------------------------------------------
diff --git a/doc/new-book/using-console.adoc b/doc/new-book/using-console.adoc
deleted file mode 100644
index 4e03eb2..0000000
--- a/doc/new-book/using-console.adoc
+++ /dev/null
@@ -1,126 +0,0 @@
-////
-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
-////
-
-= Using {ConsoleName}
-
-[[console-overview]]
-== Console Overview
-
-The console is an HTML based web site that displays information about a qpid dispatch router network.
-
-The console requires an HTML web server that can serve static html, javascript, style sheets, and images.
-
-The console only provides limited information about the clients that are attached to the router network and is therfore more appropriate for administrators needing to know the layout and health of the router network.
-
-[[console-installation]]
-== Console Installation
-
-[discrete]
-=== Prerequisites
-
-The following need to be installed before running a console:
-
-* One or more dispatch routers. See the documentation for the dispatch
-router for help in starting a router network.
-* A websockets to tcp proxy.
-* A web server. This can be any server capable of serving static
-html/js/css/image files.
-
-[discrete]
-=== Procedure
-
-To install a websockets to tcp proxy:
-
-----
-sudo dnf install python-websockify
-websockify localhost:5673 localhost:5672
-----
-
-This will start the proxy listening to ws traffic on port 5673 and
-translating it to tcp on port 5672. One of the routers in the network
-needs to have a listener configured on port 5672. That listener's role
-should be 'normal'. For example:
-
-----
-listener {
- host: 0.0.0.0
- role: normal
- port: amqp
- saslMechanisms: ANONYMOUS
-}
-----
-
-[[the-console-files]]
-=== The Console Files
-
-The files for the console are located under the console/stand-alone
-directory in the source tree
-* 'index.html'
-* 'plugin/'
-
-Copy these files to a directory under the the html or webapps directory
-of your web server. For example, for apache tomcat the files should be
-under webapps/dispatch. Then the console is available as 'http://localhost:8080/dispatch'
-
-[[console-operation]]
-== Console Operation
-
-[[logging-in-to-a-router-network]]
-=== Logging into a Router Network
-
-image:console_login.png[image]
-
-Enter the address of the websockets to tcp proxy that is connected to a router in the network.
-
-The Autostart checkbox, when checked, will automatically log in with the previous host:port the next time you start the console.
-
-[[overview-page]]
-=== Overview Page
-
-image:console_overview.png[image]
-
-On the overview page, aggregate information about routers, addresses, and connections is displayed.
-
-[[topology-page]]
-=== Topology Page
-
-image:console_topology.png[image]
-
-This page displays the router network in a graphical form showing how the routers are connected and information about the individual routers and links.
-
-[[list-page]]
-=== List Page
-
-image:console_entity.png[image]
-
-Displays detailed information about entities such as routers, links, addresses, memory.
-
-[[charts-page]]
-=== Charts Page
-
-image:console_charts.png[image]
-
-This page displays graphs of numeric values that are on the list page.
-
-[[schema-page]]
-=== Schema Page
-
-image:console_schema.png[image]
-
-This page displays the json schema that is used to manage the router network.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/notes/code-conventions.txt
----------------------------------------------------------------------
diff --git a/doc/notes/code-conventions.txt b/doc/notes/code-conventions.txt
deleted file mode 100644
index fb0829c..0000000
--- a/doc/notes/code-conventions.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-#
-# 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.
-#
-
-
-Code conventions
-================
-
-Python code
------------
-
-Python code should be http://www.python.org/dev/peps/pep-0008/[PEP-8]
-compliant. In particular:
-
-* Use four-space indents
-* Do not use studlyCaps for function, method, and variable names;
-instead use underscore_separated_names
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/CMakeLists.txt
----------------------------------------------------------------------
diff --git a/docs/CMakeLists.txt b/docs/CMakeLists.txt
new file mode 100644
index 0000000..361796f
--- /dev/null
+++ b/docs/CMakeLists.txt
@@ -0,0 +1,27 @@
+##
+## 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.
+##
+
+option(DOC_VERBOSE "Verbose output from doc tools for debugging" OFF)
+option(DOC_XMLLINT "Use xmllint to verify XML output" OFF)
+
+add_custom_target(docs)
+add_custom_target(doc DEPENDS docs)
+
+add_subdirectory(books)
+add_subdirectory(man)
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/README.md
----------------------------------------------------------------------
diff --git a/docs/README.md b/docs/README.md
new file mode 100644
index 0000000..16a95b6
--- /dev/null
+++ b/docs/README.md
@@ -0,0 +1,40 @@
+<!--
+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
+-->
+
+# Qpid Dispatch documentation
+
+## Building the documentation
+
+Documentation is built when you run `make docs`. You need the
+following tools to build the documentation.
+
+* asciidoctor (1.5.6) for books
+* asciidoc (8.6.8) for man pages
+
+The versions above are known to work, earlier versions may or may not.
+
+## Writing documentation
+
+Documentation is written in AsciiDoc markup.
+
+* 'books/': AsciiDoc source for the user guide
+* 'man/': AsciiDoc source for Unix man pages
+* 'notes/': Developer notes: project information, design notes, or
+ anything else that's primarily of developer interest; these are not
+ installed.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/CMakeLists.txt
----------------------------------------------------------------------
diff --git a/docs/books/CMakeLists.txt b/docs/books/CMakeLists.txt
new file mode 100644
index 0000000..e7dcfb7
--- /dev/null
+++ b/docs/books/CMakeLists.txt
@@ -0,0 +1,54 @@
+##
+## 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.
+##
+
+find_program (ASCIIDOCTOR_EXE asciidoctor DOC "Generate books")
+
+set (
+ books
+ ${CMAKE_CURRENT_BINARY_DIR}/user-guide/index.html
+ ${CMAKE_CURRENT_BINARY_DIR}/old-user-guide/index.html
+ )
+
+if (ASCIIDOCTOR_EXE)
+ # Don't follow symlinks and don't warn about it
+ cmake_policy(SET CMP0009 NEW)
+ file (GLOB_RECURSE png_files RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} *.png)
+
+ foreach (file ${png_files})
+ execute_process (
+ COMMAND ${CMAKE_COMMAND} -E copy_if_different
+ ${CMAKE_CURRENT_SOURCE_DIR}/${file}
+ ${CMAKE_CURRENT_BINARY_DIR}/${file}
+ )
+ endforeach ()
+
+ foreach (dir user-guide old-user-guide)
+ add_custom_command (
+ OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${dir}/index.html
+ COMMAND ${ASCIIDOCTOR_EXE} ${CMAKE_CURRENT_SOURCE_DIR}/${dir}/book.adoc -o ${dir}/index.html
+ DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${dir}/book.adoc
+ )
+ endforeach ()
+
+else ()
+ message (STATUS "AsciiDoctor not found: Not generating books")
+endif ()
+
+add_custom_target (books DEPENDS ${books})
+add_dependencies (docs books)
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/common/fragment-router-sasl-para.adoc
----------------------------------------------------------------------
diff --git a/docs/books/common/fragment-router-sasl-para.adoc b/docs/books/common/fragment-router-sasl-para.adoc
new file mode 100644
index 0000000..c6264e4
--- /dev/null
+++ b/docs/books/common/fragment-router-sasl-para.adoc
@@ -0,0 +1,20 @@
+////
+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
+////
+
+To see a list of Cyrus SASL plugins in a `dnf`-based Linux system, use the `dnf search cyrus-sasl` command. To install a Cyrus SASL plugin, use the `dnf install _PLUGIN_` command.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/common/fragment-starting-router-step.adoc
----------------------------------------------------------------------
diff --git a/docs/books/common/fragment-starting-router-step.adoc b/docs/books/common/fragment-starting-router-step.adoc
new file mode 100644
index 0000000..4e9117b
--- /dev/null
+++ b/docs/books/common/fragment-starting-router-step.adoc
@@ -0,0 +1,29 @@
+////
+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
+////
+
+. To start the router, use the *`qdrouterd`* command.
++
+--
+This example uses the default configuration to start the router as a daemon:
+
+[options="nowrap"]
+----
+$ qdrouterd -d
+----
+--
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/old-user-guide/addressing.adoc
----------------------------------------------------------------------
diff --git a/docs/books/old-user-guide/addressing.adoc b/docs/books/old-user-guide/addressing.adoc
new file mode 100644
index 0000000..d138425
--- /dev/null
+++ b/docs/books/old-user-guide/addressing.adoc
@@ -0,0 +1,133 @@
+////
+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
+////
+
+[[addressing]]
+Addressing
+----------
+
+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 `to`
+and `reply-to` fields of a message's properties. They are also used
+during the creation of links in the `address` field of a `source` or
+a `target`.
+
+Addresses designate various kinds of entities in a messaging network:
+
+* Endpoint processes that consume data or offer a service
+* Topics that match multiple consumers to multiple producers
+* Entities within a messaging broker:
+** Queues
+** Durable Topics
+** Exchanges
+
+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.
+
+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.
+
+Address semantics include the following considerations:
+
+* _Routing pattern_ - direct, multicast, balanced
+* _Undeliverable action_ - drop, hold and retry, redirect
+* _Reliability_ - N destinations, etc.
+
+[[routing-patterns]]
+Routing patterns
+~~~~~~~~~~~~~~~~
+
+Routing patterns constrain the paths that a message can take across a
+network.
+
+[width="100%",cols="18%,82%",options="header",]
+|=======================================================================
+|_Pattern_ |_Description_
+|_Direct_ |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.
+
+|_Multicast_ |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.
+
+|_Balanced_ |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.
+|=======================================================================
+
+[[routing-mechanisms]]
+Routing mechanisms
+~~~~~~~~~~~~~~~~~~
+
+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 __routing__:
+
+_____________________________________________________________________________________________________________________________________________________________________________________________________________________________________
+In a network built of multiple routers connected by connections (i.e.,
+nodes and edges in a graph), _routing_ determines which connection to
+use to send a message directly to its destination or one step closer to
+its destination.
+_____________________________________________________________________________________________________________________________________________________________________________________________________________________________________
+
+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.
+
+[[message-routing]]
+Message routing
+^^^^^^^^^^^^^^^
+
+Message routing occurs upon delivery of a message and is done based on
+the address in the message's `to` field.
+
+When a delivery arrives on an incoming link, the router extracts the
+address from the delivered message's `to` 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.
+
+[width="100%",cols="20%,80%",options="header",]
+|=======================================================================
+|_Delivery_ |_Handling_
+|_pre-settled_ |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.
+
+|_unsettled_ |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.
+|=======================================================================
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/old-user-guide/amqp-mapping.adoc
----------------------------------------------------------------------
diff --git a/docs/books/old-user-guide/amqp-mapping.adoc b/docs/books/old-user-guide/amqp-mapping.adoc
new file mode 100644
index 0000000..4f540c5
--- /dev/null
+++ b/docs/books/old-user-guide/amqp-mapping.adoc
@@ -0,0 +1,175 @@
+////
+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
+////
+
+[[amqp-mapping]]
+AMQP Mapping
+------------
+
+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.
+
+[[message-annotations]]
+Message Annotations
+~~~~~~~~~~~~~~~~~~~
+
+The following Message Annotation fields are defined by Dispatch Router:
+
+[width="100%",cols="23%,19%,58%",options="header",]
+|=======================================================================
+|_Field_ |_Type_ |_Description_
+|x-opt-qd.ingress |string |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.
+
+|x-opt-qd.trace |list of string |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.
+
+|x-opt-qd.to |string |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 _to_ 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.
+
+|x-opt-qd.phase |integer |The address-phase, if not zero, for messages
+flowing between routers.
+|=======================================================================
+
+[[sourcetarget-capabilities]]
+Source/Target Capabilities
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following Capability values are used in Sources and Targets.
+
+[width="100%",cols="19%,81%",options="header",]
+|=======================================================================
+|_Capability_ |_Description_
+|qd.router |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.
+
+|qd.router-data |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.
+|=======================================================================
+
+[[dynamic-node-properties]]
+Dynamic-Node-Properties
+~~~~~~~~~~~~~~~~~~~~~~~
+
+The following dynamic-node-properties are used by Dispatch in Sources.
+
+[width="100%",cols="23%,77%",options="header",]
+|=======================================================================
+|_Property_ |_Description_
+|x-opt-qd.address |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.
+|=======================================================================
+
+[[addresses-and-address-formats]]
+Addresses and Address Formats
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following AMQP addresses and address patterns are used within
+Dispatch Router.
+
+[[address-patterns]]
+Address Patterns
+^^^^^^^^^^^^^^^^
+
+[width="100%",cols="38%,62%",options="header",]
+|=======================================================================
+|_Pattern_ |_Description_
+|`_local/<addr>` |An address that references a locally attached endpoint.
+Messages using this address pattern shall not be routed over more than
+one link.
+
+|`_topo/0/<router>/<addr>` |
+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.
+
+The '0' component immediately preceding the router-id is a placeholder
+for an _area_ which may be used in the future if area routing is
+implemented.
+
+|`<addr>` |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.
+|=======================================================================
+
+[[supported-addresses]]
+Supported Addresses
+^^^^^^^^^^^^^^^^^^^
+
+[width="100%",cols="36%,64%",options="header",]
+|=======================================================================
+|_Address_ |_Description_
+|`$management` |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.
+
+|`_topo/0/Router.E/$management` |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.
+
+|`_local/qdhello` |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.
+
+|`_local/qdrouter` |The router entity in each of the connected routers.
+This address is used by a router to communicate with other routers in
+the network.
+
+|`_topo/0/Router.E/qdrouter` |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.
+|=======================================================================
+
+[[implementation-of-the-amqp-management-specification]]
+Implementation of the AMQP Management Specification
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Qpid Dispatch is manageable remotely via AMQP. It is compliant with the
+emerging AMQP Management specification (draft 9).
+
+Differences from the specification:
+
+- The `name` 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.
+- The `REGISTER` and `DEREGISTER` operations are not implemented. The router
+ automatically discovers peer routers via the router network and makes
+ their management addresses available via the standard `GET-MGMT-NODES`
+ operation.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/old-user-guide/auto_links.adoc
----------------------------------------------------------------------
diff --git a/docs/books/old-user-guide/auto_links.adoc b/docs/books/old-user-guide/auto_links.adoc
new file mode 100644
index 0000000..5ef8bc7
--- /dev/null
+++ b/docs/books/old-user-guide/auto_links.adoc
@@ -0,0 +1,323 @@
+////
+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
+////
+
+[[indirect-waypoints-and-auto-links]]
+Indirect Waypoints and Auto-Links
+---------------------------------
+
+This feature was introduced in Qpid Dispatch 0.6. It is a significant
+improvement on an earlier somewhat experimental feature called
+Waypoints.
+
+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.
+
+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:
+
+_________________________________________________________________________________________
+* The name of the connector/listener that resulted in the connection of
+the container, or
+* The AMQP container-id of the remote container.
+_________________________________________________________________________________________
+
+[[queue-waypoint-example]]
+Queue Waypoint Example
+~~~~~~~~~~~~~~~~~~~~~~
+
+Here is an example configuration for routing messages deliveries through
+a pair of queues on a broker:
+
+----
+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
+}
+----
+
+The +address+ entity identifies a namespace 'queue.' that will be used
+for routing messages through queues via autolinks. The four +autoLink+ entities
+identify the head and tail of two queues on the broker that will be connected
+via auto-links.
+
+If there is no broker connected, the auto-links shall remain
+_inactive_. This can be observed by using the `qdstat` tool:
+
+---------------------------
+$ 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
+---------------------------
+
+If a broker comes online with a queue called 'queue.first', the
+auto-links will attempt to activate:
+
+--------------------
+$ 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
+--------------------
+
+Note that two of the auto-links are in _failed_ state because the queue
+does not exist on the broker.
+
+If we now use the Qpid Proton example application `simple_send.py` to send
+three messages to 'queue.first' via the router:
+
+--------------------------
+$ python simple_send.py -a 127.0.0.1/queue.first -m3
+all messages confirmed
+--------------------------
+
+and then look at the address statistics on the router:
+
+----------------------------
+$ 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
+----------------------------
+
+we see that 'queue.first' appears twice in the list of addresses. The
++phs+, or phase column shows that there are two phases for the
+address. Phase '0' is for routing message deliveries from producers to
+the tail of the queue (the +out+ auto-link associated with the queue).
+Phase 1 is for routing deliveries from the head of the queue to
+subscribed consumers.
+
+Note that three deliveries have been counted in the "in" and "out"
+columns for phase '0'. The "in" column represents the three messages
+that arrived from `simple_send.py` and the +out+ column represents the three
+deliveries to the queue on the broker.
+
+If we now use `simple_recv.py` to receive three messages from this address:
+
+--------------
+$ 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)}
+--------------
+
+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.
+
+----------------------------
+$ 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
+----------------------------
+
+Note that even in a multi-router network, and with multiple producers
+and consumers for 'queue.first', all deliveries will be routed through
+the queue on the connected broker.
+
+[[sharded-queue-example]]
+Sharded Queue Example
+~~~~~~~~~~~~~~~~~~~~~
+
+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.
+
+----
+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
+}
+----
+
+In the above configuration, there are two instances of _queue.first_ on
+brokers 1 and 2. Message traffic from producers to address _queue.first_
+shall be balanced between the two instance and messages from the queues
+shall be balanced across the collection of subscribers to the same
+address.
+
+[[dynamically-adding-shards]]
+Dynamically Adding Shards
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+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 `qdmanage`:
+
+----
+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
+----
+
+[[address-renaming]]
+Using a Different External Address on an Auto-Link
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+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 +externalAddr+ that
+allows the waypoint to have a different address than that which is
+used by the senders and receivers.
+
+Here's an example:
+
+----
+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
+}
+
+----
+
+In the above configuration, the router network provides waypoint
+routing for the address _queue.first_, 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.
+
+In this example, the endpoints (senders and receivers) are unaware of
+the _broker_queue_ address and simply interact with _queue.first_.
+Likewise, the broker is unaware of the _queue.first_ address and
+behaves as though a sender and a receiver is attached each using the
+address _broker_queue_.
+
+The +qdstat+ tool shows the external address for auto-links.
+
+--------------------
+$ 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
+--------------------
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/old-user-guide/basic_usage.adoc
----------------------------------------------------------------------
diff --git a/docs/books/old-user-guide/basic_usage.adoc b/docs/books/old-user-guide/basic_usage.adoc
new file mode 100644
index 0000000..2eb030a
--- /dev/null
+++ b/docs/books/old-user-guide/basic_usage.adoc
@@ -0,0 +1,203 @@
+////
+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
+////
+
+[[basic-usage-and-examples]]
+Basic Usage and Examples
+------------------------
+
+[[standalone-and-interior-modes]]
+Standalone and Interior Modes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The router can operate stand-alone or as a node in a network of routers.
+The mode is configured in the _router_ 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.
+
+If your router is running in stand-alone mode, _qdstat -a_ will look
+like the following:
+
+-----------------------------------------------------------------------------------------------------------------
+$ 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
+-----------------------------------------------------------------------------------------------------------------
+
+Note that there are a number of known addresses. _$management_ is the
+address of the router's embedded management agent.
+_temp.1GThUllfR7N+BDP_ is the temporary reply-to address of the _qdstat_
+client making requests to the agent.
+
+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:
+
+-------------------------------------------------------------------------------------------------------------------
+$ 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
+-------------------------------------------------------------------------------------------------------------------
+
+[[mobile-subscribers]]
+Mobile Subscribers
+~~~~~~~~~~~~~~~~~~
+
+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.
+
+To illustrate a subscription on a stand-alone router, you can use the
+examples that are provided with Qpid Proton. Using the _simple_recv.py_
+example receiver:
+
+-------------------------------------------------
+$ python ./simple_recv.py -a 127.0.0.1/my-address
+-------------------------------------------------
+
+This command creates a receiving link subscribed to the specified
+address. To verify the subscription:
+
+-----------------------------------------------------------------------------------------------------------------
+$ 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
+-----------------------------------------------------------------------------------------------------------------
+
+You can then, in a separate command window, run a sender to produce
+messages to that address:
+
+-------------------------------------------------
+$ python ./simple_send.py -a 127.0.0.1/my-address
+-------------------------------------------------
+
+[[dynamic-reply-to]]
+Dynamic Reply-To
+~~~~~~~~~~~~~~~~
+
+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.
+
+-------------------------------------------------------------------
+#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();
+}
+-------------------------------------------------------------------
+
+The equivalent program written in Python against the Proton Messenger
+API:
+
+----------------------------------------------------------------
+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()
+----------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/old-user-guide/book.adoc
----------------------------------------------------------------------
diff --git a/docs/books/old-user-guide/book.adoc b/docs/books/old-user-guide/book.adoc
new file mode 100644
index 0000000..439a103
--- /dev/null
+++ b/docs/books/old-user-guide/book.adoc
@@ -0,0 +1,71 @@
+////
+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
+////
+
+Qpid Dispatch Router Book
+=========================
+:toc:
+:numbered:
+:doctype: book
+
+include::introduction.adoc[]
+include::theory_of_operation.adoc[]
+
+[[using-qpid-dispatch]]
+Using Qpid Dispatch
+-------------------
+
+:leveloffset: 1
+
+include::default_config.adoc[]
+include::tools.adoc[]
+include::basic_usage.adoc[]
+include::link_routing.adoc[]
+include::auto_links.adoc[]
+
+:leveloffset: 0
+
+:leveloffset: 2
+
+include::policy.adoc[]
+
+:leveloffset: 0
+
+[[technical-details-and-specifications]]
+Technical Details and Specifications
+------------------------------------
+
+:leveloffset: 1
+
+include::client_compatibility.adoc[]
+include::addressing.adoc[]
+include::amqp-mapping.adoc[]
+//include::{generated_book}/schema.adoc[]
+
+:leveloffset: 0
+
+[[console]]
+Console
+-------
+:leveloffset: 1
+
+include::console_overview.adoc[]
+include::console_installation.adoc[]
+include::console_operation.adoc[]
+
+:leveloffset: 0
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/old-user-guide/client_compatibility.adoc
----------------------------------------------------------------------
diff --git a/docs/books/old-user-guide/client_compatibility.adoc b/docs/books/old-user-guide/client_compatibility.adoc
new file mode 100644
index 0000000..7930240
--- /dev/null
+++ b/docs/books/old-user-guide/client_compatibility.adoc
@@ -0,0 +1,39 @@
+////
+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
+////
+
+[[client-compatibility]]
+Client Compatibility
+--------------------
+
+Dispatch Router should, in theory, work with any client that is
+compatible with AMQP 1.0. The following clients have been tested:
+
+[width="100%",cols="22%,78%",options="header",]
+|=======================================================================
+|_Client_ |_Notes_
+|qpid::messaging |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.
+
+|Proton Reactor |The Proton Reactor API is compatible with Dispatch
+Router.
+
+|Proton Messenger |Messenger works with Dispatch Router.
+|=======================================================================
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/old-user-guide/console1.png
----------------------------------------------------------------------
diff --git a/docs/books/old-user-guide/console1.png b/docs/books/old-user-guide/console1.png
new file mode 100644
index 0000000..f131884
Binary files /dev/null and b/docs/books/old-user-guide/console1.png differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/old-user-guide/console_charts.png
----------------------------------------------------------------------
diff --git a/docs/books/old-user-guide/console_charts.png b/docs/books/old-user-guide/console_charts.png
new file mode 100644
index 0000000..169c2ca
Binary files /dev/null and b/docs/books/old-user-guide/console_charts.png differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/old-user-guide/console_entity.png
----------------------------------------------------------------------
diff --git a/docs/books/old-user-guide/console_entity.png b/docs/books/old-user-guide/console_entity.png
new file mode 100644
index 0000000..130c7e7
Binary files /dev/null and b/docs/books/old-user-guide/console_entity.png differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/old-user-guide/console_installation.adoc
----------------------------------------------------------------------
diff --git a/docs/books/old-user-guide/console_installation.adoc b/docs/books/old-user-guide/console_installation.adoc
new file mode 100644
index 0000000..cda9f18
--- /dev/null
+++ b/docs/books/old-user-guide/console_installation.adoc
@@ -0,0 +1,68 @@
+////
+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
+////
+
+[[console-installation]]
+Console installation
+--------------------
+
+[[prerequisites]]
+Prerequisites
+~~~~~~~~~~~~~
+
+The following need to be installed before running a console:
+
+* One or more dispatch routers. See the documentation for the dispatch
+router for help in starting a router network.
+* A websockets to tcp proxy.
+* A web server. This can be any server capable of serving static
+html/js/css/image files.
+
+To install a websockets to tcp proxy:
+
+----
+sudo dnf install python-websockify
+websockify localhost:5673 localhost:5672
+----
+
+This will start the proxy listening to ws traffic on port 5673 and
+translating it to tcp on port 5672. One of the routers in the network
+needs to have a listener configured on port 5672. That listener's role
+should be 'normal'. For example:
+
+----
+listener {
+ host: 0.0.0.0
+ role: normal
+ port: amqp
+ saslMechanisms: ANONYMOUS
+}
+----
+
+[[the-console-files]]
+The console files
+~~~~~~~~~~~~~~~~~
+
+The files for the console are located under the console/stand-alone
+directory in the source tree
+* 'index.html'
+* 'plugin/'
+
+Copy these files to a directory under the the html or webapps directory
+of your web server. For example, for apache tomcat the files should be
+under webapps/dispatch. Then the console is available as 'http://localhost:8080/dispatch'
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/old-user-guide/console_login.png
----------------------------------------------------------------------
diff --git a/docs/books/old-user-guide/console_login.png b/docs/books/old-user-guide/console_login.png
new file mode 100644
index 0000000..63e22c6
Binary files /dev/null and b/docs/books/old-user-guide/console_login.png differ
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/old-user-guide/console_operation.adoc
----------------------------------------------------------------------
diff --git a/docs/books/old-user-guide/console_operation.adoc b/docs/books/old-user-guide/console_operation.adoc
new file mode 100644
index 0000000..233ffc8
--- /dev/null
+++ b/docs/books/old-user-guide/console_operation.adoc
@@ -0,0 +1,71 @@
+////
+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
+////
+[[console-operation]]
+Console operation
+-----------------
+
+[[logging-in-to-a-router-network]]
+Logging in to a router network
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+image:console_login.png[image]
+
+Enter the address of the websockets to tcp proxy that is connected to a router in the network.
+
+The Autostart checkbox, when checked, will automatically log in with the previous host:port the next time you start the console.
+
+[[overview-page]]
+Overview page
+~~~~~~~~~~~~~
+
+image:book/console_overview.png[image]
+
+On the overview page, aggregate information about routers, addresses, and connections is displayed.
+
+[[topology-page]]
+Topology page
+~~~~~~~~~~~~~
+
+image:console_topology.png[image]
+
+This page displays the router network in a graphical form showing how the routers are connected and information about the individual routers and links.
+
+[[list-page]]
+List page
+~~~~~~~~~
+
+image:console_entity.png[image]
+
+Displays detailed information about entities such as routers, links, addresses, memory.
+
+[[charts-page]]
+Charts page
+~~~~~~~~~~~
+
+image:console_charts.png[image]
+
+This page displays graphs of numeric values that are on the list page.
+
+[[schema-page]]
+Schema page
+~~~~~~~~~~~
+
+image:console_schema.png[image]
+
+This page displays the json schema that is used to manage the router network.
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/docs/books/old-user-guide/console_overview.adoc
----------------------------------------------------------------------
diff --git a/docs/books/old-user-guide/console_overview.adoc b/docs/books/old-user-guide/console_overview.adoc
new file mode 100644
index 0000000..10cf023
--- /dev/null
+++ b/docs/books/old-user-guide/console_overview.adoc
@@ -0,0 +1,27 @@
+////
+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
+////
+[[console-overview]]
+Console overview
+----------------
+
+The console is an HTML based web site that displays information about a qpid dispatch router network.
+
+The console requires an HTML web server that can serve static html, javascript, style sheets, and images.
+
+The console only provides limited information about the clients that are attached to the router network and is therfore more appropriate for administrators needing to know the layout and health of the router network.
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org