qpid-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From acon...@apache.org
Subject svn commit: r1647638 - in /qpid/dispatch/trunk/doc: CMakeLists.txt book/CMakeLists.txt book/addressing.md book/amqp-mapping.md book/index.md book/introduction.md book/using.md
Date Tue, 23 Dec 2014 18:19:35 GMT
Author: aconway
Date: Tue Dec 23 18:19:34 2014
New Revision: 1647638

URL: http://svn.apache.org/r1647638
Log:
DISPATCH-26: Router documentation - use pandoc to generate router book in PDF and HTML.

If you install pandoc ("yum install pandoc" on yum-based systems) then make will
create PDF and HTML versions of the dispatch router book.

The source is still in markdown format, but note pandoc uses a different table
extension syntax so check an example in the existing .md files or the pandoc
documentation.

Did some edits to the existing book sources
- fleshed out the intro
- updated comments on management
- fixed up tables

Added:
    qpid/dispatch/trunk/doc/book/CMakeLists.txt
      - copied, changed from r1647637, qpid/dispatch/trunk/doc/CMakeLists.txt
    qpid/dispatch/trunk/doc/book/introduction.md
    qpid/dispatch/trunk/doc/book/using.md
Removed:
    qpid/dispatch/trunk/doc/book/index.md
Modified:
    qpid/dispatch/trunk/doc/CMakeLists.txt
    qpid/dispatch/trunk/doc/book/addressing.md
    qpid/dispatch/trunk/doc/book/amqp-mapping.md

Modified: qpid/dispatch/trunk/doc/CMakeLists.txt
URL: http://svn.apache.org/viewvc/qpid/dispatch/trunk/doc/CMakeLists.txt?rev=1647638&r1=1647637&r2=1647638&view=diff
==============================================================================
--- qpid/dispatch/trunk/doc/CMakeLists.txt (original)
+++ qpid/dispatch/trunk/doc/CMakeLists.txt Tue Dec 23 18:19:34 2014
@@ -19,3 +19,4 @@
 
 add_subdirectory(api)
 add_subdirectory(man)
+add_subdirectory(book)

Copied: qpid/dispatch/trunk/doc/book/CMakeLists.txt (from r1647637, qpid/dispatch/trunk/doc/CMakeLists.txt)
URL: http://svn.apache.org/viewvc/qpid/dispatch/trunk/doc/book/CMakeLists.txt?p2=qpid/dispatch/trunk/doc/book/CMakeLists.txt&p1=qpid/dispatch/trunk/doc/CMakeLists.txt&r1=1647637&r2=1647638&rev=1647638&view=diff
==============================================================================
--- qpid/dispatch/trunk/doc/CMakeLists.txt (original)
+++ qpid/dispatch/trunk/doc/book/CMakeLists.txt Tue Dec 23 18:19:34 2014
@@ -17,5 +17,25 @@
 ## under the License.
 ##
 
-add_subdirectory(api)
-add_subdirectory(man)
+# The dipatch book is written in MarkDown, this generates a HTML  version.
+# Requires pandoc, available on yum-based systems as pandoc.
+
+find_program(PANDOC pandoc)
+
+if (PANDOC)
+  set(src ${CMAKE_CURRENT_SOURCE_DIR})
+  set(BOOK ${src}/introduction.md ${src}/using.md ${src}/addressing.md ${src}/amqp-mapping.md)
+  set(CMD pandoc -s -S --toc -f markdown)
+  set(BASE ${CMAKE_CURRENT_BINARY_DIR}/qpid-dispatch-book)
+  set(HTML ${BASE}.html)
+  set(PDF ${BASE}.pdf)
+
+  add_custom_command (
+      OUTPUT qpid-dispatch-book.html qpid-dispatch-book.pdf
+      COMMAND ${CMD} -f markdown -o ${HTML} ${BOOK}
+      COMMAND ${CMD} -f markdown -o ${PDF} ${BOOK}
+      DEPENDS ${program} ${BOOK}
+      )
+  add_custom_target(book ALL DEPENDS ${HTML} ${BOOK})
+
+endif(PANDOC)

Modified: qpid/dispatch/trunk/doc/book/addressing.md
URL: http://svn.apache.org/viewvc/qpid/dispatch/trunk/doc/book/addressing.md?rev=1647638&r1=1647637&r2=1647638&view=diff
==============================================================================
--- qpid/dispatch/trunk/doc/book/addressing.md (original)
+++ qpid/dispatch/trunk/doc/book/addressing.md Tue Dec 23 18:19:34 2014
@@ -1,23 +1,23 @@
-;;
-;; 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.
-;;
+<!--
+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.
+-->
 
-# Dispatch 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
@@ -33,7 +33,7 @@ Addresses designate various kinds of ent
    - 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
@@ -56,10 +56,11 @@ Address semantics include the following
 
 Routing patterns constrain the paths that a message can take across a network.
 
-  || *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 (or links) 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. ||
+  | *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 (or links) 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
 
@@ -88,9 +89,10 @@ address from the delivered message's `to
 routing table.  The lookup results in zero or more outgoing links onto which the message
 shall be resent.
 
-  || *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. ||
+  | *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. |
 
 ### Link routing
 

Modified: qpid/dispatch/trunk/doc/book/amqp-mapping.md
URL: http://svn.apache.org/viewvc/qpid/dispatch/trunk/doc/book/amqp-mapping.md?rev=1647638&r1=1647637&r2=1647638&view=diff
==============================================================================
--- qpid/dispatch/trunk/doc/book/amqp-mapping.md (original)
+++ qpid/dispatch/trunk/doc/book/amqp-mapping.md Tue Dec 23 18:19:34 2014
@@ -1,23 +1,23 @@
-;;
-;; 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.
-;;
+<!--
+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.
+-->
 
-# Dispatch AMQP Mapping
+# AMQP Mapping
 
 Dispatch Router is an AMQP router and as such, it provides extensions,
 codepoints, and semantics for routing over AMQP.  This page documents
@@ -28,19 +28,21 @@ the details of Dispatch Router's use of
 
 The following Message Annotation fields are defined by Dispatch Router:
 
-  || *Field* || *Type* || *Description* ||
-  || <span style="white-space: nowrap;">x-opt-qd.ingress</span> || 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. ||
-  || <span style="white-space: nowrap;">x-opt-qd.trace</span> || 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.class || string || Message class.  This is used to allow the router to provide
separate paths for different classes of traffic. ||
+  | *Field* | *Type* | *Description* |
+  |---------|--------|---------------|
+  | <span style="white-space: nowrap;">x-opt-qd.ingress</span> | 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. |
+  | <span style="white-space: nowrap;">x-opt-qd.trace</span> | 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.class | string | Message class.  This is used to allow the router to provide
separate paths for different classes of traffic. |
 
 
 ## Source/Target Capabilities
 
 The following Capability values are used in Sources and Targets.
 
-  || *Capability* || *Description* ||
-  || qd.router || This capability is added to sources and targets that are used for inter-router
message exchange. ||
+  | *Capability* | *Description* |
+  |--------------|---------------|
+  | qd.router | This capability is added to sources and targets that are used for inter-router
message exchange. |
 
 
 ## Addresses and Address Formats
@@ -49,50 +51,32 @@ The following AMQP addresses and address
 
 ### Address Patterns
 
-  || *Pattern* || *Description* ||
-  || /_local/&lt;addr&gt; || An address that references a locally attached endpoint.
 Messages using this address pattern shall not be routed over more than one link. ||
-  || <span style="white-space: nowrap;">/_topo/&lt;area&gt;/&lt;router&gt;/&lt;addr&gt;</span>
|| 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. ||
-  || /&lt;addr&gt; || 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. ||
+  | *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/<area>/<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. |
+  | `<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
 
-  || *Address* || *Description* ||
-  || /_local/$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. ||
-  || <span style="white-space: nowrap;">/_topo/0/Router.E/agent</span> || 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. ||
-  || <span style="white-space: nowrap;">/_topo/0/Router.E/qdxrouter</span> ||
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. ||
+  | *Address* | *Description* |
+  |-----------|---------------|
+  | `_local/$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/agent` | 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/qdxrouter` | 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
 
-Qpid Dispatch is manageable remotely via AMQP.  It is compliant to a limited degree with
the emerging AMQP Management specification.  This section provides the details of what is
supported and what is not and what is planned and what is not.
+Qpid Dispatch is manageable remotely via AMQP.  It is compliant with the
+emerging AMQP Management specification (draft 9).  
 
-Non-compliance occurs for one of the following reasons:
+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 operation is not implementd. The router has its own mechansm to discover peers
that does not require this operation.
+- The DEREGISTER operation is not implementd. The router has its own mechansm to discover
peers that does not require this operation.
 
-  - Implementation of an optional feature is not planned
-  - Implementation is not complete as of the current time
-  
-### Compliance Matrix
-
-  || *Operation/Feature* || *Requirement* || *Supported* || *Remarks* ||
-  || CREATE || Should || No || There are currently no Manageable Entities for which this
is appropriate ||
-  || READ || Should || No || Not yet implemented ||
-  || UPDATE || Should || No || There are currently no Manageable Entities for which this
is appropriate ||
-  || DELETE || Should || No || There are currently no Manageable Entities for which this
is appropriate ||
-  || QUERY || Should || Yes || Query requests must provide either an entityType or a set
of attributeNames.  It will not support the general "get all attributes from all entityTypes"
query. ||
-  || GET-TYPES || Should || Yes || There are no types that implement base types ||
-  || GET-ATTRIBUTES || Should || Yes || ||
-  || GET-OPERATIONS || Should || Yes || ||
-  || GET-MGMT-NODES || Should || Yes || This operation yields the addresses of all of the
router nodes in the known network ||
-  || REGISTER || May || Not Planned || The router has a specific way to discover peers that
does not involve this operation ||
-  || DEREGISTER || May || Not Planned || The router has a specific way to discover peers
that does not involve this operation ||
-
-### Manageable Entities
-
-  || *Type Name* || *Description* ||
-  || org.apache.qpid.dispatch.allocator || Per-type memory allocation statistics ||
-  || org.apache.qpid.dispatch.connection || Connections to the router's container ||
-  || org.apache.qpid.dispatch.router || General state and statistics for the router node
||
-  || org.apache.qpid.dispatch.router.link || Per-link state and statistics for links attached
to the router node ||
-  || org.apache.qpid.dispatch.router.node || Per-node state and statistics for remote router
nodes in the known network ||
-  || org.apache.qpid.dispatch.router.address || Per-address state and statistics for addresses
known to this router ||

Added: qpid/dispatch/trunk/doc/book/introduction.md
URL: http://svn.apache.org/viewvc/qpid/dispatch/trunk/doc/book/introduction.md?rev=1647638&view=auto
==============================================================================
--- qpid/dispatch/trunk/doc/book/introduction.md (added)
+++ qpid/dispatch/trunk/doc/book/introduction.md Tue Dec 23 18:19:34 2014
@@ -0,0 +1,102 @@
+<!--
+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.
+-->
+
+# Dispatch Router
+
+## Overview
+
+The Dispatch router is an AMQP message message router that provides advanced
+interconnect capabilities. It allows flexible routing of messages between any
+AMQP-enabled endpoints, whether they be clients, servers, brokers or any other
+entity that can send or receive standard AMQP messages.
+
+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 reciever 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 difficult 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
+
+ - Simplifies connectivity
+   - An endpoint can do all of its messaging through a single transport connection
+   - Avoid opening holes in firewalls for incoming connections
+ - 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
+
+ - Supports arbitrary topology - no restrictions on redundancy
+ - Automatic route computation - adjusts quickly to changes in topology
+ - Cost-based route computation
+ - [Rich addressing semantics](#addressing)
+ - Security

Added: qpid/dispatch/trunk/doc/book/using.md
URL: http://svn.apache.org/viewvc/qpid/dispatch/trunk/doc/book/using.md?rev=1647638&view=auto
==============================================================================
--- qpid/dispatch/trunk/doc/book/using.md (added)
+++ qpid/dispatch/trunk/doc/book/using.md Tue Dec 23 18:19:34 2014
@@ -0,0 +1,246 @@
+<!--
+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 Qpid Dispatch
+
+## Configuration
+
+The default configuration file is installed in
+_install-prefix_/etc/qpid/qdrouterd.conf.  This configuration file will cause the router
+to run in standalone mode, listening on the standard AMQP port (5672).  Dispatch Router
+looks for the configuration file in the installed location by default.  If you wish
+to use a different path, the "-c" command line option will instruct Dispatch Router as to
+which configuration to load.
+
+To run the router, invoke the executable:
+o
+    $ qdrouterd [-c my-config-file]
+
+For more details of the configuration file see the `qdrouterd.conf(5)` man page.
+
+## Client Compatibility
+
+Dispatch Router should, in theory, work with any client that is compatible with AMQP 1.0.
+The following clients have been tested:
+
+  | *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 Messenger | Messenger works with Dispatch Router. |
+
+## Tools
+
+### qdstat
+
+*qdstat* is a command line tool that lets you view the status of a Dispatch
+Router.  The following options are useful for seeing that the router is doing:
+
+  | *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 routers. |
+  | -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. |
+
+For complete details see the `qdstat(8)` man page and the output of `qdstat --help`.
+
+### 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 route r
+    $ qdrouterd query --type connection
+
+You can enable debug logging by default like this:
+    $ qdrouter update log/DEFAULT level=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:
+    $ qdrouter create type=listener port=5555 
+
+Now you can connect to port 5555, for exampple
+    $ qdrouterd 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.
+
+## Features and Examples
+
+### 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  address      in-proc  local  remote  in  out  thru  to-proc  from-proc
+      ===============================================================================
+      local  $management  Y        0      0       1   0    0     1        0
+      local  temp.AY81ga           1      0       0   0    0     0        0
+
+Note that there are two known addresses. _$management_ is the address of the router's embedded
management agent.  _temp.AY81ga_ 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
two additional addresses which are used for inter-router communication:
+
+    $ qdstat -a
+    Router Addresses
+      class  address      in-proc  local  remote  in  out  thru  to-proc  from-proc
+      ===============================================================================
+      local  $management  Y        0      0       1   0    0     1        0
+      local  qdhello      Y        0      0       0   0    0     0        3
+      local  qdrouter     Y        0      0       0   0    0     0        1
+      local  temp.khOpGb           1      0       0   0    0     0        0
+
+
+### 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 _recv.py_ example receiver:
+
+    $ recv.py amqp://0.0.0.0/my-address
+
+This command creates a receiving link subscribed to the specified address.  To verify the
+subscription:
+
+    $ qdstat -a
+    Router Addresses
+      class   address      in-proc  local  remote  in  out  thru  to-proc  from-proc
+      ================================================================================
+      local   $management  Y        0      0       1   0    0     1        0
+      mobile  my-address            1      0       0   0    0     0        0
+      local   temp.fDt8_a           1      0       0   0    0     0        0
+
+You can then, in a separate command window, run a sender to produce messages to that
+address:
+
+    $ send.py -a amqp://0.0.0.0/my-address
+
+### 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()
+
+
+## Known Issues and Limitations
+
+This is an early test release.  It is expected that users will find bugs and other
+various instabilities.  The main goal of this release is to prove that the process can be
+run and that users can demonstrate basic functionality as described in this document.
+Nevertheless, the following are known issues with the 0.1 release:
+
+ - Subscriber addresses are not always cleaned up after a consumer disconnects.  See
+   <https://issues.apache.org/jira/browse/QPID-4964>.
+ - Dispatch Router does not currently use the target address of a client's sender link to
+   route messages.  It only looks at the "to" field in the message's headers.  See
+   <https://issues.apache.org/jira/browse/QPID-5175>.
+ - All subscription sources are treated as multicast addresses.  There is currently no
+   facility for provisioning different types of addresses.  Multicast means that if there
+   are multiple subscribers to the same address, they will all receive a copy of each
+   message sent to that address.
+ - SSL connectors and listeners are supported but very lightly (and not recently) tested.
+ - SASL authentication is not currently integrated into any authentication framework.  Use
+   ANONYMOUS for testing.
+



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


Mime
View raw message