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:41:00 UTC
[06/11] qpid-dispatch git commit: DISPATCH-851: Move the new book
into primary position and reorg the docs
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