http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/book/policy.adoc ---------------------------------------------------------------------- diff --git a/doc/book/policy.adoc b/doc/book/policy.adoc deleted file mode 100644 index a4eb99b..0000000 --- a/doc/book/policy.adoc +++ /dev/null @@ -1,456 +0,0 @@ -//// -Licensed to the Apache Software Foundation (ASF) under one -or more contributor license agreements. See the NOTICE file -distributed with this work for additional information -regarding copyright ownership. The ASF licenses this file -to you under the Apache License, Version 2.0 (the -"License"); you may not use this file except in compliance -with the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, -software distributed under the License is distributed on an -"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY -KIND, either express or implied. See the License for the -specific language governing permissions and limitations -under the License -//// - -[id='policy'] -= Policy - -The Policy module is an optional authorization mechanism enforcing -user connection restrictions and AMQP resource access control. - -Policy is assigned when a connection is created. The connection -properties *AMQP virtual host*, *authenticated user name*, and *connection -remote host* are passed to the policy engine for a connection -allow/deny decision. If the connection is allowed then the user is -assigned to a group that names a set of AMQP resource limits that are -enforced for the lifetime of the connection. - -[NOTE] -==== -Policy limits are applied only to incoming user network connections. -Policy limits are not applied to interrouter connections nor are they -applied to router connections outbound to waypoints. -==== - -== Definitions - -=== vhost - -A _vhost_ is typically the name of the host to which the client AMQP -connection is directed. For example, suppose a client application opens -connection URL: - -[options="nowrap"] ----- -amqp://bigbroker.example.com:5672/favorite_subject ----- - -The client will signal virtual host name _bigbroker.example.com_ to -the router during AMQP connection startup. Router Policy intercepts -the virtual host _bigbroker.example.com_ and applies a vhost policy -with that name to the connection. - -== Policy Features - -=== Total Connection Limit - -A router may be configured with a total connection limit. This limit -controls the maximum number of simultaneous incoming user connections -that are allowed at any time. It protects the router from file -descriptor resource exhaustion in the face of many incoming client -connections. This limit is specified and enforced independently of -any other Policy settings. - -=== Vhost Policy - -Vhost policy defines users and assigns them to user groups. Each -user group defines the remote hosts from which the members may connect -to the router network, and what resources in the router network the -group members are allowed to access. - -Vhost policy also defines connection count limits to control the -number of users that may be simultaneously connected to the vhost. - -[NOTE] -==== -A vhost user may be assigned to one user group only. -==== - -=== Default Vhost - -A default vhost may be defined. The default vhost policy is used for -connections whose vhost is otherwise not defined in the policy database. - -xref:example2[Example 2] illustrates how the default vhost feature can -be used to apply a single vhost policy set of restrictions to any -number of vhost connections. - -=== Vhost Patterns - -Policy vhost names may be interpreted as literal host names or -as host name patterns. Vhost name patterns are a convenience -for letting a single policy rule cover a wide range of vhosts. - -Host name patterns consist of a series of host and domain name -labels and one or more tokens all concatenated with periods or dots. -A token can be one of the following: - -[options="header"] -|==== -| Token character | Match rule -| asterisk * | matches a single hostname label -| hash # | matches zero or more hostname labels -|==== - -Some simple examples show how given policy name patterns match -incoming connection vhost names. - -[options="header"] -|==== -| Policy pattern | Connection vhost | Policy match -| *.example.com | example.com | no -| *.example.com | www.example.com | yes -| *.example.com | srv2.www.example.com | no -| #.example.com | example.com | yes -| #.example.com | www.example.com | yes -| #.example.com | a.b.c.d.example.com | yes -| #.example.com | bighost.com | no -| www.*.test.example.com | www.test.example.com | no -| www.*.test.example.com | www.a.test.example.com | yes -| www.*.test.example.com | www.a.b.c.test.example.com | no -| www.#.test.example.com | www.test.example.com | yes -| www.#.test.example.com | www.a.test.example.com | yes -| www.#.test.example.com | www.a.b.c.test.example.com | yes -|==== - -Pattern matching applies the following precedence rules. - -[options="header"] -|==== -| Policy pattern | Precedence -| exact match | high -| asterisk * | medium -| hash # | low -|==== - -Policy vhost name patterns are optimised before they are used -in connection vhost name matching. As a result of this -optimisation the names stored for pattern match lookups are -not necessarily the same as the patterns specified in the -vhost policy hostname. The policy agent disallows vhost -name patterns that reduce to the same pattern as an existing name -pattern. For instance, name pattern _pass:[#.#.#.#.com]_ is reduced to _pass:[#.com]_. -Attempts to create a vhost name pattern whose optimised -name conflicts with an existing optimised name will be denied. - -== Policy Schema - -Policy configuration is specified in two schema objects. - -[options="nowrap"] ----- -policy = { - <global settings> -} - -vhost = { - id: vhost-name - <connection limits> - groups: { - group-name: { - <user group settings> - } - } -} ----- - -The _policy_ object is a singleton. Multiple _vhost_ objects may be -created as needed. - -=== Global Policy - -[options="header", cols="35,15,50"] -|==== -| attribute | default | description -| maxConnections | 65535 | Global maximum number of concurrent client connections allowed. This limit is always enforced even if no other policy settings have been defined. This limit is applied to all incoming connections regardless of remote host, authenticated user, or targeted vhost. -| enableVhostPolicy | false | Enable vhost policy connection denial, and resource limit enforcement. -| policyDir | "" | Absolute path to a directory that holds vhost definition .json files. All vhost definitions in all .json files in this directory are processed. -| defaultVhost | "$default" | Vhost rule set name to use for connections with a vhost that is otherwise not defined. Default vhost processing may be disabled either by erasing the definition of _defaultVhost_ or by not defining a _vhost_ object named _$default_. -| enableVhostNamePatterns | false | Enable vhost name patterns. When false vhost hostnames are treated as literal strings. When true vhost hostnames are treated as match patterns. -|==== - -=== Vhost Policy - -[options="header", cols="35,15,50"] -|==== -| attribute | default | description -| id | | Vhost name must be unique. -| maxConnections | 65535 | Maximum number of concurrent client connections allowed. -| maxConnectionsPerUser | 65535 | Maximum number of concurrent client connections allowed for any user. -| maxConnectionsPerRemoteHost | 65535 | Maximum number of concurrent client connections allowed for any remote host. -| allowUnknownUser | false | Allow unknown users who are not members of a defined user group. Unknown users are assigned to the '$default' user group and receive '$default' settings. -| groups | | A map where each key is a user group name and the value is a Vhost User Group Settings map. -|==== - -=== Vhost User Group Settings Map - -This object is the data value contained in entries in the policy/groups map. - -[options="header", cols="35,15,50"] -|==== -| Section/Attribute | default | description -| *Group Membership* | | -| users | "" | Comma separated list of authenticated users in this group. -| *Connection Restrictions* | | -| remoteHosts | "" | List of remote hosts from which the users may connect. List values may be host names, numeric IP addresses, numeric IP address ranges, or the wildcard '*'. An empty list denies all access. -| *AMQP Connection Open Limits* | | -| maxFrameSize | 2^31-1 | Largest frame that may be sent on this connection. (AMQP Open, max-frame-size) -| maxSessions | 65535 | Maximum number of sessions that may be created on this connection. (AMQP Open, channel-max) -| *AMQP Session Begin Limits* | | -| maxSessionWindow | 2^31-1 |Incoming capacity for new sessions measured in octets. AMQP Begin, incoming-window measured in AMQP frames is calculated by (maxSessionWindow / maxFrameSize). (AMQP Begin, incoming-window) -| *AMQP Link Attach* | | -| maxMessageSize | 0 | Largest message size supported by links created on this connection. If this field is zero there is no maximum size imposed by the link endpoint. (AMQP Attach, max-message-size) -| maxSenders | 2^31-1 | Maximum number of sending links that may be created on this connection. -| maxReceivers | 2^31-1 | Maximum number of receiving links that may be created on this connection. -| allowDynamicSource | false | This connection is allowed to create receiving links using the Dynamic Link Source feature. -| allowAnonymousSender | false | This connection is allowed to create sending links using the Anonymous Sender feature. -| allowUserIdProxy | false | This connection is allowed to send messages with a user_id property that differs from the connection's authenticated user id. -| sources | "" | List of Source addresses allowed when creating receiving links. This list may be expressed as a CSV string or as a list of strings. An empty list denies all access. -| targets | "" | List of Target addresses allowed when creating sending links. This list may be expressed as a CSV string or as a list of strings. An empty list denies all access. -| sourcePattern | "" | List of Source address patterns allowed when creating receiving links. This list must be expressed as a CSV string. An empty string denies all access. -| targetPattern | "" | List of Target address patterns allowed when creating sending links. This list must be expressed as a CSV string. An empty string denies all access. -|==== - -== Policy Wildcard and User Name Substitution - -Policy provides several conventions to make writing rules easier. - -=== Remote Host Wildcard - -Remote host rules may consist of a single asterisk character to -specify all hosts. - -[options="nowrap"] ----- - remoteHosts: * ----- - -The asterisk must stand alone and cannot be appended to a host name -or to an IP address fragment. - -=== AMQP Source and Target User Name Substitution - -The rule definitions for `sources`, `targets`, `sourcePattern`, and -`targetPattern` may include the username -substitution token - -[options="nowrap"] ----- - ${user} ----- - -The username substitution token is replaced with the authenticated user name for -the connection. Using this token, an administrator may allow access to -some resources specific to each user without having to name each user -individually. This token is substituted once for the leftmost -occurrence in the link name. - -=== AMQP Source and Target Link Name Match Wildcard - -The rule definitions for `sources` and `targets` may contain a trailing -asterisk character. -The asterisk is recognized only if it is the last character in the -link name. - -[options="nowrap"] ----- - sources: tmp_${user}, temp*, ${user}-home-* ----- - -The rule definitions for `sourcePattern` and `targetPattern` use the same -patterns defined for router addresses and link routes. The patterns consist of one or more -tokens separated by a forward slash /. A token can be one of the following: -a * character, a # character, or a sequence of characters that do not -include /, *, or #. The * token matches any single token. The # token -matches zero or more tokens. - -The user name substitution token may be used in a sourcePattern or in a -targetPattern subject to the following restrictions: - -* The user name substitution token must be the first or last token in the rule clause. -* The user name substitution token must stand alone within its delimited field. - It may not be concatenated with literal text prefixes or suffixes. - -For each rule definition multiple patterns may be specified in a comma -separated list. - -[options="nowrap"] ----- - sourcePattern: tmp.${user}, temp/#, ${user}.home/* ----- - -[NOTE] -==== -A rule definition may contain `sources` or `sourcePattern` but not both. -A rule definition may contain `targets` or `targetPattern` but not both. -==== - - - -== Composing Policies - -This section shows policy examples designed to illustrate some common use cases. - -=== Example 1. User Policy Disabled - -Policy is disabled when no policy configuation objects are defined. -Any number of connections are allowed and all users have -access to all AMQP resources in the network. - -[id='example2'] -=== Example 2. All Users Have Simple Connection Limits - -This example shows how to keep users from overwhelming the router with -connections. Any user can create up to ten connections and the router -will limit the aggregated user connection count to 100 connections -total. No other restrictions apply. - -This example also shows how to use a default vhost policy effectively. -Only one vhost policy is defined and all user connections regardless -of the requested vhost use that policy. - -[options="nowrap"] ----- -policy { - maxConnections: 100 <1> -} - -vhost { - name: $default <2> - maxConnectionsPerUser: 10 <3> - allowUnknownUser: true <4> - groups: { - $default: { - remoteHosts: * <5> - sources: * <6> - targets: * <6> - } - } -} ----- - -<1> The global maxConnections limit of 100 is enforced. -<2> No normal vhost names are defined; user is assigned to default vhost '$default'. -<3> The vhost maxConnectionsPerUser limit of 10 is enforced. -<4> No groups are defined to have any users but allowUnknownUser is true so all users are assigned to group $default. -<5> The user is allowed to connect from any remote host. -<6> The user is allowed to connect to any source or target in the AMQP network. Router system-wide values are used for the other AMQP settings that are unspecified in the vhost rules. - -=== Example 3. Admins Must Connect From Localhost - -This example shows how an admin group may be created and restricted -to accessing a vhost only from localhost. The admin users are allowed -to connect to any AMQP resources while normal users are restricted. - -In this example a user connects to vhost 'example.com'. - -[options="nowrap"] ----- -vhost { - name: example.com <1> - allowUnknownUser: true <3> - groups: { - admin: { - users: alice, bob <2> - remoteHosts: 127.0.0.1, ::1 <4> - sources: * <5> - targets: * <5> - }, - $default: { - remoteHosts: * <6> - sources: news*, sports*, chat* <7> - targets: chat* <7> - } - } -} ----- - -<1> A connection to vhost 'example.com' locates this vhost rule set. -<2> If one of users _alice_ or _bob_ is connecting then she or he is assigned to the 'admin' user group. -<3> Any other user is not defined by a user group. However, since the _allowUnknownUser_ setting is true then this user is assigned to the '$default' user group. -<4> Users in the 'admin' user group must connect from localhost. Connections for an 'admin' user from other hosts on the network are denied. -<5> Users in the 'admin' user group are allowed to access any resource offered by the vhost service. -<6> Other users are allowed to connect from any host. -<7> Other users have source and target name lists that restrict the resources they are allowed to access. - -=== Example 4. Limiting Possible Memory Consumption - -Policy provides a mechanism to control how much system buffer memory a -user connection can potentially consume. The formula for computing -buffer memory consumption for each session is -set directly by _maxSessionWindow_. - -By adjusting _maxSessions_, and _maxSessionWindow_ an -administrator can prevent a user from consuming too much memory by -buffering messages in flight. - -[NOTE] -==== -The settings passed into the AMQP protocol connection and session -negotiations. Normal AMQP session flow control limits buffer -consumption in due course with no processing cycles required by the -router. -==== - -In this example normal users, the traders, are given smaller buffer -allocations while high-capacity, automated data feeds are given a -higher buffer allocation. This example skips the details of settings -unrelated to buffer allocation. - -[options="nowrap"] ----- -vhost { - name: traders.com <1> - groups: { - traders: { - users: trader-1, trader-2, ... <2> - maxFrameSize: 10000 <3> - maxSessionWindow: 5000000 <3> - maxSessions: 1 <4> - ... - }, - feeds: { - users: nyse-feed, nasdaq-feed <5> - maxFrameSize: 60000 <6> - maxSessionWindow: 1200000000 <6> - maxSessions: 3 <7> - ... - } - } -} ----- - -<1> These rules are for vhost traders.com. -<2> The 'traders' group includes trader-1, trader-2, and any other user defined in the list. -<3> _maxFrameSize_ and _maxSessionWindow_ allow for at most 5,000,000 bytes of data to be in flight on each session. -<4> Only one session per connection is allowed. -<5> In the 'feeds' group two users are defined. -<6> _maxFrameSize_ and _maxSessionWindow_ allow for at most 1,200,000,000 bytes of data to be in flight on each session. -<7> Up to three sessions per connection are allowed. - -//// - -- Should we used signed ints for limits to allow for magic values? - -- In example 3, alice and bob cannot connect from an outside server and - get the $default settings. - -- Limits are enforced per router, so a vhost policy of maxConnections - 10 across 10 routers will allow 100 connections to that vhost. - -////
http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/book/schema_txt.py ---------------------------------------------------------------------- diff --git a/doc/book/schema_txt.py b/doc/book/schema_txt.py deleted file mode 100644 index 9f340f3..0000000 --- a/doc/book/schema_txt.py +++ /dev/null @@ -1,109 +0,0 @@ -## -## Licensed to the Apache Software Foundation (ASF) under one -## or more contributor license agreements. See the NOTICE file -## distributed with this work for additional information -## regarding copyright ownership. The ASF licenses this file -## to you under the Apache License, Version 2.0 (the -## "License"); you may not use this file except in compliance -## with the License. You may obtain a copy of the License at -## -## http://www.apache.org/licenses/LICENSE-2.0 -## -## Unless required by applicable law or agreed to in writing, -## software distributed under the License is distributed on an -## "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY -## KIND, either express or implied. See the License for the -## specific language governing permissions and limitations -## under the License -## - -""" -Generate the schema.md chapter for the dispatch book from the qdrouter.json schema. -""" -from __future__ import unicode_literals -from __future__ import division -from __future__ import absolute_import -from __future__ import print_function - -import sys, re -from qpid_dispatch_internal.management.qdrouter import QdSchema -from qpid_dispatch_internal.management.schema_doc import SchemaWriter - -class BookSchemaWriter(SchemaWriter): - - def run(self): - self.heading("Management Schema") - self.writeln(""" -This chapter documents the set of *management entity types* that define -configuration and management of a Dispatch Router. A management entity type has -a set of *attributes* that can be read, some attributes can also be -updated. Some entity types also support *operations* that can be called. - -All management entity types have the following standard attributes: - -type:: - The fully qualified type of the entity, - e.g. `org.apache.qpid.dispatch.router`. This document uses the short name - without the `org.apache.qpid.dispatch` prefix e.g. `router`. The dispatch - tools will accept the short or long name. - -name:: - A user-generated identity for the entity. This can be used in other entities - that need to refer to the named entity. - -identity:: - A system-generated identity of the entity. It includes - the short type name and some identifying information. E.g. `log/AGENT` or - `listener/localhost:amqp` - -There are two main categories of management entity type. - -Configuration Entities:: - Parameters that can be set in the configuration file - (see `qdrouterd.conf(5)` man page) or set at run-time with the `qdmanage(8)` - tool. - -Operational Entities:: - Run-time status values that can be queried using `qdstat(8)` or `qdmanage(8)` tools. -""") - - with self.section("Configuration Entities"): - self.writeln(""" -Configuration entities define the attributes allowed in the configuration file -(see `qdrouterd.conf(5)`) but you can also create entities once the router is -running using the `qdrouterd(8)` tool's `create` operation. Some entities can also -be modified using the `update` operation, see the entity descriptions below. -""") - self.entity_types_extending("configurationEntity") - - with self.section("Operational Entities"): - - self.writeln(""" -Operational entities provide statistics and other run-time attributes of the router. -The `qdstat(8)` tool provides a convenient way to query run-time statistics. -You can also use the general-purpose management tool `qdmanage(8)` to query -operational attributes. -""") - self.entity_types_extending("operationalEntity") - - with self.section("Management Operations"): - self.writeln(""" -The 'qdstat(8)' and 'qdmanage(8)' tools allow you to view or modify management entity -attributes. They work by invoking *management operations*. You can invoke these operations -from any AMQP client by sending a message with the appropriate properties and body to the -'$management' address. The message should have a 'reply-to' address indicating where the -response should be sent. -""") - def operation_section(title, entity_type): - with self.section(title): - self.operation_defs(entity_type) - operation_section("Operations for all entity types", self.schema.entity_type("entity")) - for e in self.schema.filter(lambda et: et.operation_defs and not et.name_is("entity")): - operation_section("Operations for '%s' entity type" % e.short_name, e) - -def main(): - """Generate schema markdown documentation from L{QdSchema}""" - BookSchemaWriter(sys.stdout, QdSchema()).run() - -if __name__ == '__main__': - main() http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/book/theory_of_operation.adoc ---------------------------------------------------------------------- diff --git a/doc/book/theory_of_operation.adoc b/doc/book/theory_of_operation.adoc deleted file mode 100644 index c2deab8..0000000 --- a/doc/book/theory_of_operation.adoc +++ /dev/null @@ -1,395 +0,0 @@ -//// -Licensed to the Apache Software Foundation (ASF) under one -or more contributor license agreements. See the NOTICE file -distributed with this work for additional information -regarding copyright ownership. The ASF licenses this file -to you under the Apache License, Version 2.0 (the -"License"); you may not use this file except in compliance -with the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, -software distributed under the License is distributed on an -"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY -KIND, either express or implied. See the License for the -specific language governing permissions and limitations -under the License -//// - -== Theory of Operation - -This section introduces some key concepts about the router. - -=== Overview - -The router is an _application layer_ program running as a normal -user program or as a daemon. - -The router accepts AMQP connections from clients and creates AMQP -connections to brokers or AMQP-based services. The router classifies -incoming AMQP messages and routes the -messages between message producers and message consumers. - -The router is meant to be deployed in topologies of multiple routers, -preferably with redundant paths. It uses link-state routing protocols -and algorithms similar to OSPF or IS-IS from the networking world to -calculate the best path from every message source to every message -destination and to recover quickly from failures. The router relies on -redundant network paths to provide continued connectivity in the face -of system or network failure. - -A messaging client can make a single AMQP connection into a messaging -bus built with routers and, over that connection, exchange messages -with one or more message brokers connected to any router in the -network. At the same time the client can exchange messages directly -with other endpoints without involving a broker at all. - -=== Connections - -The router connects clients, servers, AMQP services, and other -routers through network connections. - -==== Listener - -The router provides _listeners_ that accept client connections. -A client connecting to a router listener uses the -same methods that it would use to connect to a broker. From the -client's perspective the router connection and link establishment are -identical to broker connection and link establishment. - -Several types of listeners are defined by their role. - -[cols="20,80"] -|=== -| Role | Description -| normal | The connection is used for AMQP clients using normal message delivery. -| inter-router | The connection is assumed to be to another router in the network. Inter-router discovery and routing protocols can only be used over inter-router connections. -| route-container | The connection is a broker or other resource that holds known addresses. The router will use this connection to create links as necessary. The addresses are available for routing only after the remote resource has created a connection. -|=== - -==== Connector - -The router can also be configured to create outbound connections to -messaging brokers or other AMQP entities using _connectors_. A -connector is defined with the network address of the broker and the -name or names of the resources that are available in that broker. When -a router connects to a broker through a connector it uses the same -methods a normal messaging client would use when connecting to the -broker. - -Several types of connectors are defined by their role. - -[cols="20,80"] -|=== -| Role | Description -| normal | The connection is used for AMQP clients using normal message delivery. On this connector the router will initiate the connection but it will never create any links. Links are to be created by the peer that accepts the connection. -| inter-router | The connection is assumed to be to another router in the network. Inter-router discovery and routing protocols can only be used over inter-router connections. -| route-container | The connection is to a broker or other resource that holds known addresses. The router will use this connection to create links as necessary. The addresses are available for routing only after the router has created a connection to the remote resource. -|=== - -=== Addresses - -AMQP addresses are used to control the flow of messages across a -network of routers. Addresses are used in a number of different places -in the AMQP 1.0 protocol. They can be used in a specific message in -the _to_ and _reply-to_ fields of a message's properties. They are also -used during the creation of links in the _address_ field of a _source_ or -a _target_. - -[NOTE] -==== -Addresses in this discussion refer to AMQP protocol addresses and not -to TCP/IP network addresses. TCP/IP network addresses are used by -messaging clients, brokers, and routers to create AMQP connections. -AMQP protocol addresses are the names of source and destination -endpoints for messages within the messaging network. -==== - -Addresses designate various kinds of entities in a messaging network: - -* Endpoint processes that consume data or offer a service -* Topics that match multiple consumers to multiple producers -* Entities within a messaging broker: -** Queues -** Durable Topics -** Exchanges - -The syntax of an AMQP address is opaque as far as the router network -is concerned. A syntactical structure may be used by the administrator -who creates addresses but the router treats them as opaque -strings. - -The router maintains several classes of address based on how the address is -configured or discovered. - -[cols="25,75"] -|=== -| Address Type | Description -| mobile | The address is a rendezvous point between senders and receivers. The router aggregates and serializes messages from senders and distributes messages to receivers. -| link route | The address defines a private messaging path between a sender and a receiver. The router simply passes messages between the end points. -|=== - -==== Mobile Addresses - -Routers consider addresses to be mobile such that any users of an -address may be directly connected to any router in a network and may -move around the topology. In cases where messages are broadcast to or -balanced across multiple consumers, the address users may be connected -to multiple routers in the network. - -Mobile addresses are rendezvous points for senders and receivers. -Messages arrive at the mobile address and are dispatched to their -destinations according to the routing defined for the mobile address. -The details of these routing patterns are discussed later. - -Mobile addresses may be discovered during normal router operation or -configured through management settings. - -===== Discovered Mobile Addresses - -Mobile addresses are created when a client creates a link to a source -or destination address that is unknown to the router network. - -Suppose a service provider wants to offer _my-service_ that clients -may use. The service provider must open a receiver link with source -address _my-service_. The router creates a mobile address -_my-service_ and propagates the address so that it is known to every -router in the network. - -Later a client wants to use the service and creates a sending link -with target address _my-service_. The router matches the service -provider's receiver having source address _my-service_ to the client's -sender having target address _my-service_ and routes messages between -the two. - -Any number of other clients can create links to the service as -well. The clients do not have to know where in the router network the -service provider is physically located nor are the clients required to -connect to a specific router to use the service. Regardless of how -many clients are using the service the service provider needs only a -single connection and link into the router network. - -Another view of this same scenario is when a client tries to use the -service before service provider has connected to the network. In this -case the router network creates the mobile address _my-service_ as -before. However, since the mobile address has only client sender links -and no receiver links the router stalls the clients and prevents them -from sending any messages. Later, after the service provider connects -and creates the receiver link, the router will issue credits to the -clients and the messages will begin to flow between the clients and -the service. - -The service provider can connect, disconnect, and reconnect from a -different location without having to change any of the clients or -their connections. Imagine having the service running on a -laptop. One day the connection is from corporate headquarters and the -next day the connection is from some remote location. In this case the -service provider's computer will typically have different host IP -addresses for each connection. Using the router network the service -provider connects to the router network and offers the named service -and the clients connect to the router network and consume from the -named service. The router network routes messages between the mobile -addresses effectively masking host IP addresses of the service -provider and the client systems. - -===== Configured Mobile Addresses - -Mobile addresses may be configured using the router _autoLink_ -object. An address created via an _autoLink_ represents a queue, -topic, or other service in an external broker. Logically the -_autoLink_ addresses are treated by the router network as if the -broker had connected to the router and offered the services itself. - -For each configured mobile address the router will create a single -link to the external resource. Messages flow between sender links and -receiver links the same regardless if the mobile address was -discovered or configured. - -Multiple _autoLink_ objects may define the same address on multiple -brokers. In this case the router network creates a sharded resource -split between the brokers. Any client can seamlessly send and receive -messages from either broker. - -Note that the brokers do not need to be clustered or federated to -receive this treatment. The brokers may even be from different vendors -or be different versions of the same broker yet still work together to -provide a larger service platform. - -==== Link Route Addresses - -Link route addresses may be configured using the router _linkRoute_ -object. An link route address represents a queue, topic, or other -service in an external broker similar to addresses configured by -_autoLink_ objects. For link route addresses the router propagates a -separate link attachment to the broker resource for each incoming -client link. The router does not automatically create any links to the -broker resource. - -Using link route addresses the router network does not participate in -aggregated message distribution. The router simply passes message -delivery and settlement between the two end points. - -=== Message Routing - -Addresses have semantics associated with them that are assigned when -the address is provisioned or discovered. The semantics of an address -control how routers behave when they see the address being -used. Address semantics include the following considerations: - -* Routing pattern - balanced, closest, multicast -* Routing mechanism - message routed, link routed - -// * TODO: describe these??? -// * Undeliverable action - drop, hold and retry, redirect -// * Reliability - N destinations, etc. - -==== Routing Patterns - -Routing patterns define the paths that a message with a mobile address -can take across a network. These routing patterns can be used for both -direct routing, in which the router distributes messages between -clients without a broker, and indirect routing, in which the router -enables clients to exchange messages through a broker. - -Note that the routing patterns fall into two categories: Anycast -(Balanced and Closest) and Multicast. There is no concept of -"unicast" in which there is only one consumer for an address. - -Anycast distribution delivers each message to one consumer whereas -multicast distribution delivers each message to all consumers. - -Anycast delivery is reliable when the message deliveries are -unsettled. There is a reliability contract that the router network -abides by when delivering unsettled messages to anycast addresses. -For every such delivery sent by a producer, the router network -guarantees that one of the following outcomes will occur: - -* The delivery shall be settled with ACCEPTED or REJECTED disposition - where the disposition is supplied by the consumer. -* The delivery shall be settled with RELEASED disposition, meaning - that the message was not delivered to any consumer. -* The delivery shall be settled with MODIFIED disposition, meaning - that the message may have been delivered to a consumer but should be - considered in-doubt and re-sent. -* The connection to the producer shall be dropped, signifying that all - unsettled deliveries should now be considered in-doubt by the - producer and later re-sent. - -Multicast delivery is not reliable. If a producer sends an unsettled -delivery, the ingress router shall settle the delivery with ACCEPTED -disposition regardless of whether the message was delivered to any -consumers. - -===== Balanced - -An anycast method which allows multiple receivers to use the same -address. In this case, messages (or links) are routed to exactly one -of the receivers and the network attempts to balance the traffic load -across the set of receivers using the same address. This routing -delivers messages to receivers based on how quickly they settle the -deliveries. Faster receivers get more messages. - -===== Closest - -An anycast method in which even if there are more receivers for the -same address, every message is sent along the shortest path to reach -the destination. This means that only one receiver will get the -message. Each message is delivered to the closest receivers in terms -of topology cost. If there are multiple receivers with the same lowest -cost, deliveries will be spread evenly among those receivers. - -===== Multicast - -Having multiple consumers on the same address at the same time, -messages are routed such that each consumer receives one copy of the -message. - - -==== Routing Mechanisms - -The fact that addresses can be used in different ways suggests that -message routing can be accomplished in different ways. Before going -into the specifics of the different routing mechanisms, it would be -good to first define what is meant by the term _routing_: - - In a network built of multiple, interconnected routers 'routing' - determines which connection to use to send a message directly - to its destination or one step closer to its destination. - -Each router serves as the terminus of a collection of incoming and -outgoing links. Some of the links are designated for message routing, -and others are designated for link routing. In both cases, the links -either connect directly to endpoints that produce and consume -messages, or they connect to other routers in the network along -previously established connections. - -===== Message Routed - -Message routing occurs upon delivery of a message and is done based on -the address in the message's _to_ field. - -When a delivery arrives on an incoming message-routing link, the -router extracts the address from the delivered message's _to_ field and -looks the address up in its routing table. The lookup results in zero -or more outgoing links onto which the message shall be resent. - -Message routing can also occur without an address in the -message's _to_ field if the incoming link has a target address. In -fact, if the sender uses a link with a target address, the _to_ field -shall be ignored even if used. - -===== Link Routed - -Link routing occurs when a new link is attached to the router across -one of its AMQP connections. It is done based on the _target.address_ -field of an inbound link and the _source.address_ field of an outbound -link. - -Link routing uses the same routing table that message routing -uses. The difference is that the routing occurs during the link-attach -operation, and link attaches are propagated along the appropriate path -to the destination. What results is a chain of links, connected -end-to-end, from source to destination. It is similar to a virtual -circuit in a telecom system. - -Each router in the chain holds pairs of link termini that are tied -together. The router then simply exchanges all deliveries, delivery -state changes, and link state changes between the two termini. - -The endpoints that use the link chain do not see any difference in -behavior between a link chain and a single point-to-point link. All of -the features available in the link protocol (flow control, -transactional delivery, etc.) are available over a routed link-chain. - -==== Message Settlement - -Messages may be delivered with varying degrees of reliability. - -* At most once -* At least once -* Exactly once - -The reliability is negotiated between the client and server during -link establishment. The router handles all levels of reliability by treating -messages as either _pre-settled_ or _unsettled_. - -[cols="20,80"] -|=== -| Delivery | Handling -| pre-settled | If the arriving delivery is pre-settled (i.e., fire and forget), the incoming delivery shall be settled by the router, and the outgoing deliveries shall also be pre-settled. In other words, the pre-settled nature of the message delivery is propagated across the network to the message's destination. -| unsettled | Unsettled delivery is also propagated across the network. Because unsettled delivery records cannot be discarded, the router tracks the incoming deliveries and keeps the association of the incoming deliveries to the resulting outgoing deliveries. This kept association allows the router to continue to propagate changes in delivery state (settlement and disposition) back and forth along the path which the message traveled. -|=== - - -=== Security - -The router uses the SSL protocol and related certificates and SASL -protocol mechanisms to encrypt and authenticate remote peers. Router -listeners act as network servers and router connectors act as network -clients. Both connection types may be configured securely with SSL -and SASL. - -The router Policy module is an optional authorization mechanism -enforcing user connection restrictions and AMQP resource access -control. http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/book/tools.adoc ---------------------------------------------------------------------- diff --git a/doc/book/tools.adoc b/doc/book/tools.adoc deleted file mode 100644 index 6f8298d..0000000 --- a/doc/book/tools.adoc +++ /dev/null @@ -1,92 +0,0 @@ -//// -Licensed to the Apache Software Foundation (ASF) under one -or more contributor license agreements. See the NOTICE file -distributed with this work for additional information -regarding copyright ownership. The ASF licenses this file -to you under the Apache License, Version 2.0 (the -"License"); you may not use this file except in compliance -with the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, -software distributed under the License is distributed on an -"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY -KIND, either express or implied. See the License for the -specific language governing permissions and limitations -under the License -//// - -[[tools]] -Tools ------ - -[[qdstat]] -qdstat -~~~~~~ - -_qdstat_ is a command line tool that lets you view the status of a -Dispatch Router. The following options are useful for seeing what the -router is doing: - -[width="100%",cols="17%,83%",options="header",] -|======================================================================= -|_Option_ |_Description_ -|-l |Print a list of AMQP links attached to the router. Links are -unidirectional. Outgoing links are usually associated with a -subscription address. The tool distinguishes between _endpoint_ links -and _router_ links. Endpoint links are attached to clients using the -router. Router links are attached to other routers in a network of -routbers. - -|-a |Print a list of addresses known to the router. - -|-n |Print a list of known routers in the network. - -|-c |Print a list of connections to the router. - -|--autolinks |Print a list of configured auto-links. - -|--linkroutes |Print a list of configures link-routes. -|======================================================================= - -For complete details see the 'qdstat(8)' man page and the output of -`qdstat --help`. - -[[qdmanage]] -qdmanage -~~~~~~~~ - -_qdmanage_ is a general-purpose AMQP management client that allows you -to not only view but modify the configuration of a running dispatch -router. - -For example you can query all the connection entities in the router: - ----------------------------------- -$ qdmanage query --type connection ----------------------------------- - -To enable logging debug and higher level messages by default: - -------------------------------------------- -$ qdmanage update log/DEFAULT enable=debug+ -------------------------------------------- - -In fact, everything that can be configured in the configuration file can -also be created in a running router via management. For example to -create a new listener in a running router: - ------------------------------------------ -$ qdmanage create type=listener port=5555 ------------------------------------------ - -Now you can connect to port 5555, for exampple: - --------------------------------------------------- -$ qdmanage query -b localhost:5555 --type listener --------------------------------------------------- - -For complete details see the 'qdmanage(8)' man page and the output of -`qdmanage --help`. Also for details of what can be configured see the -'qdrouterd.conf(5)' man page. http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/common/fragment-router-sasl-para.adoc ---------------------------------------------------------------------- diff --git a/doc/common/fragment-router-sasl-para.adoc b/doc/common/fragment-router-sasl-para.adoc deleted file mode 100644 index c6264e4..0000000 --- a/doc/common/fragment-router-sasl-para.adoc +++ /dev/null @@ -1,20 +0,0 @@ -//// -Licensed to the Apache Software Foundation (ASF) under one -or more contributor license agreements. See the NOTICE file -distributed with this work for additional information -regarding copyright ownership. The ASF licenses this file -to you under the Apache License, Version 2.0 (the -"License"); you may not use this file except in compliance -with the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, -software distributed under the License is distributed on an -"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY -KIND, either express or implied. See the License for the -specific language governing permissions and limitations -under the License -//// - -To see a list of Cyrus SASL plugins in a `dnf`-based Linux system, use the `dnf search cyrus-sasl` command. To install a Cyrus SASL plugin, use the `dnf install _PLUGIN_` command. http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/common/fragment-starting-router-step.adoc ---------------------------------------------------------------------- diff --git a/doc/common/fragment-starting-router-step.adoc b/doc/common/fragment-starting-router-step.adoc deleted file mode 100644 index 4e9117b..0000000 --- a/doc/common/fragment-starting-router-step.adoc +++ /dev/null @@ -1,29 +0,0 @@ -//// -Licensed to the Apache Software Foundation (ASF) under one -or more contributor license agreements. See the NOTICE file -distributed with this work for additional information -regarding copyright ownership. The ASF licenses this file -to you under the Apache License, Version 2.0 (the -"License"); you may not use this file except in compliance -with the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, -software distributed under the License is distributed on an -"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY -KIND, either express or implied. See the License for the -specific language governing permissions and limitations -under the License -//// - -. To start the router, use the *`qdrouterd`* command. -+ --- -This example uses the default configuration to start the router as a daemon: - -[options="nowrap"] ----- -$ qdrouterd -d ----- --- \ No newline at end of file http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/index.adoc ---------------------------------------------------------------------- diff --git a/doc/index.adoc b/doc/index.adoc deleted file mode 100644 index 1095701..0000000 --- a/doc/index.adoc +++ /dev/null @@ -1,35 +0,0 @@ -//// -Licensed to the Apache Software Foundation (ASF) under one -or more contributor license agreements. See the NOTICE file -distributed with this work for additional information -regarding copyright ownership. The ASF licenses this file -to you under the Apache License, Version 2.0 (the -"License"); you may not use this file except in compliance -with the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, -software distributed under the License is distributed on an -"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY -KIND, either express or implied. See the License for the -specific language governing permissions and limitations -under the License -//// - -[[documentation-for-dispatch]] -Documentation for dispatch --------------------------- - -:index-only: - -link:book.html[Dispatch Router User Guide] (link:book.pdf[PDF Format]) - -Manual pages - -- link:qdrouterd.8.html[qdrouterd] -- link:qdrouterd.conf.5.html[qdrouterd.conf] -- link:qdstat.8.html[qdstat] -- link:qdmanage.8.html[qdmanage] - -Also check the link:http://qpid.apache.org/components/dispatch-router[Dispatch Router Website] http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/man/help2txt.py ---------------------------------------------------------------------- diff --git a/doc/man/help2txt.py b/doc/man/help2txt.py deleted file mode 100644 index 24aeb53..0000000 --- a/doc/man/help2txt.py +++ /dev/null @@ -1,69 +0,0 @@ -# -# Licensed to the Apache Software Foundation (ASF) under one -# or more contributor license agreements. See the NOTICE file -# distributed with this work for additional information -# regarding copyright ownership. The ASF licenses this file -# to you under the Apache License, Version 2.0 (the -# "License"); you may not use this file except in compliance -# with the License. You may obtain a copy of the License at -# -# http://www.apache.org/licenses/LICENSE-2.0 -# -# Unless required by applicable law or agreed to in writing, -# software distributed under the License is distributed on an -# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY -# KIND, either express or implied. See the License for the -# specific language governing permissions and limitations -# under the License -# - -""" -Convert --help output of a program into asciidoc text format. -""" -from __future__ import print_function -from __future__ import unicode_literals -from __future__ import division -from __future__ import absolute_import - - -import re, sys -from qpid_dispatch_internal.compat import PY_STRING_TYPE -from qpid_dispatch_internal.compat.subproc import check_output - - -def help2txt(help_out): - VALUE = r"(?:[\w-]+|<[^>]+>)" - DEFAULT = r"(?: +\([^)]+\))?" - OPTION = r"-[\w-]+(?:[ =]%s)?%s" % (VALUE, DEFAULT) # -opt[(=| )value][(default)] - OPTIONS = r"%s(?:, *%s)*" % (OPTION, OPTION) # opt[,opt...] - HELP = r"(?:[ \t]+\w.*$)|(?:(?:\n[ \t]+[^-\s].*$)+)" # same line or following lines indented. - OPT_HELP = r"^\s+(%s)(%s)" % (OPTIONS, HELP) - SUBHEAD = r"^((?: +\w+)*):$" - - # check_output returns binary in py3 - if not isinstance(help_out, PY_STRING_TYPE): - help_out = help_out.decode() - - options = re.search("^Options:$", help_out, re.IGNORECASE | re.MULTILINE) - if (options): help_out = help_out[options.end():] - result = "" - - def heading(text, depth): - return "%s %s\n\n" % ("="*depth, text) - - for item in re.finditer(r"%s|%s" % (OPT_HELP, SUBHEAD), help_out, re.IGNORECASE | re.MULTILINE): - if item.group(3): - result += heading(item.group(3).strip(), 3) - else: - result += "%s\n: %s\n\n" % (item.group(1), re.sub("\s+", " ", item.group(2)).strip()) - return result - -def main(argv): - if len(argv) < 2: raise ValueError("Wrong number of arguments\nUsage %s" - " <program> [args,...]" % argv[0]) - program = argv[1:] - print(help2txt(check_output(program))) - -if __name__ == "__main__": - main(sys.argv) - http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/man/qdmanage.8.adoc ---------------------------------------------------------------------- diff --git a/doc/man/qdmanage.8.adoc b/doc/man/qdmanage.8.adoc deleted file mode 100644 index 9f668b5..0000000 --- a/doc/man/qdmanage.8.adoc +++ /dev/null @@ -1,139 +0,0 @@ -//// -Licensed to the Apache Software Foundation (ASF) under one -or more contributor license agreements. See the NOTICE file -distributed with this work for additional information -regarding copyright ownership. The ASF licenses this file -to you under the Apache License, Version 2.0 (the -"License"); you may not use this file except in compliance -with the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, -software distributed under the License is distributed on an -"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY -KIND, either express or implied. See the License for the -specific language governing permissions and limitations -under the License -//// - -qdmanage(8) -========== -:doctype: manpage - -NAME ----- -qdmanage - management client to control or query qdrouterd(8) - -SYNOPSIS --------- -*qdmanage* ['OPTIONS'] 'OPERATION' ['ARGUMENTS'] - -DESCRIPTION ------------ -An AMQP management client for use with the Dispatch router daemon -('qdrouterd'). Sends AMQP management operations requests and prints -the response in JSON format. This is a generic AMQP management tool -and can be used with any standard AMQP managed endpoint, not just -with 'qdrouterd'. - -OPTIONS -------- - -include::{generated_man}/qdmanage_help.adoc[] - -OPERATIONS ----------- - -`query` ['ATTR'...]:: - Print attributes for multiple entities. Prints all entities by default, use - --type, --name or --identity options to restrict which entities are printed. - Prints the attributes named in the ATTR list, or all attributes if none are - listed. - -`create` ['ATTR=VALUE'...]:: - Create a new entity with the specified attributes. With the --stdin - option, read attributes from stdin. This can be a JSON map of - attributes to create a single entity, or a JSON list of maps to create - multiple entities. - -`read`:: - Print all of the attributes of a single entity, specified by the --name or - --identity options. - -`update` ['ATTR=VALUE'...]:: - Update the attributes of an existing entity. If an ATTR name is listed with - no =VALUE, that attribute will be deleted from the entity. With the --stdin - option, read attributes from stdin. This can be a JSON map of attributes to - update a single entity, or a JSON list of maps to update multiple entities. - -`delete`:: - Delete an entity specified by the --name or --identity options. - -`get-types` ['TYPE']:: - List entity types with their base types. With no arguments, list all - types. - -`get-operations` ['TYPE']:: - List entity types with their operations. With no arguments, list all - types. - -`get-attributes` ['TYPE']:: - List entity types with their attributes. With no arguments, list all - types. - -`get-annotations` ['TYPE']:: - List entity types with their annotations. With no arguments, list all - types. - -`get-mgmt-nodes`:: - List all other known management nodes connected to this one. - -`get-json-schema` ['INDENT']:: - Get the router schema in JSON format. Optional integer indent for - formatted output. - -`get-log` ['INDENT']:: - Get recent log entries from the router. - -FILES ------ - -{CMAKE_INSTALL_PREFIX}/{QD_DOC_INSTALL_DIR}/qdrouter.json:: - Management schema for 'qdrouterd'. -{CMAKE_INSTALL_PREFIX}/{QD_DOC_INSTALL_DIR}/qdrouter.json.readme.txt:: - Explanation of the management schema. - -EXAMPLES --------- - -.Show the logging configuration: --------------------------------------------------------------- -qdmanage query --type=log --------------------------------------------------------------- - -.Enable debug and higher log messages by default: --------------------------------------------------------------- -qdmanage update name=log/DEFAULT enable=debug+ --------------------------------------------------------------- - -.Enable trace log messages only for the MESSAGE module, and direct MESSAGE logs to the file _test.log_: --------------------------------------------------------------- -qdmanage update name=log/MESSAGE enable=trace output=test.log --------------------------------------------------------------- - -.Set MESSAGE logging back to the default: ------------------------------------------------- -qdmanage update name=log/MESSAGE enable=default ------------------------------------------------- - -.Disable MESSAGE logging: ---------------------------------------------- -qdmanage update name=log/MESSAGE enable=none ---------------------------------------------- - -SEE ALSO ----------- -'qdrouterd(8)', 'qdstat(8)', 'qdrouterd.conf(5)' - -http://qpid.apache.org/components/dispatch-router http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/man/qdrouterd.8.adoc ---------------------------------------------------------------------- diff --git a/doc/man/qdrouterd.8.adoc b/doc/man/qdrouterd.8.adoc deleted file mode 100644 index ae2c2a2..0000000 --- a/doc/man/qdrouterd.8.adoc +++ /dev/null @@ -1,54 +0,0 @@ -//// -Licensed to the Apache Software Foundation (ASF) under one -or more contributor license agreements. See the NOTICE file -distributed with this work for additional information -regarding copyright ownership. The ASF licenses this file -to you under the Apache License, Version 2.0 (the -"License"); you may not use this file except in compliance -with the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, -software distributed under the License is distributed on an -"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY -KIND, either express or implied. See the License for the -specific language governing permissions and limitations -under the License -//// - -qdrouterd(8) -=========== -:doctype: manpage - -NAME ----- -qdrouterd - routes AMQP messages. - -SYNOPSIS --------- -*qdrouterd* ['OPTIONS'] - - -DESCRIPTION ------------ -The Qpid Dispatch router ('qdrouterd') is a network daemon that directs -AMQP 1.0 messages between endpoints, such as messaging clients and -servers. - -OPTIONS -------- - -include::{generated_man}/qdrouterd_help.adoc[] - -FILES ------ - -{SYSCONF_INSTALL_DIR}/qdrouterd.conf:: - Configuration file. - -SEE ALSO --------- -'qdrouterd.conf(5)', 'qdstat(8)', 'qdmanage(8)' - -http://qpid.apache.org/components/dispatch-router http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/man/qdrouterd.conf.5.py ---------------------------------------------------------------------- diff --git a/doc/man/qdrouterd.conf.5.py b/doc/man/qdrouterd.conf.5.py deleted file mode 100644 index e2bdd8e..0000000 --- a/doc/man/qdrouterd.conf.5.py +++ /dev/null @@ -1,155 +0,0 @@ -# -# Licensed to the Apache Software Foundation (ASF) under one -# or more contributor license agreements. See the NOTICE file -# distributed with this work for additional information -# regarding copyright ownership. The ASF licenses this file -# to you under the Apache License, Version 2.0 (the -# "License"); you may not use this file except in compliance -# with the License. You may obtain a copy of the License at -# -# http://www.apache.org/licenses/LICENSE-2.0 -# -# Unless required by applicable law or agreed to in writing, -# software distributed under the License is distributed on an -# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY -# KIND, either express or implied. See the License for the -# specific language governing permissions and limitations -# under the License -# - -""" -Generate the qdrouterd.conf. man page from the qdrouterd management schema. -""" - -from __future__ import unicode_literals -from __future__ import division -from __future__ import absolute_import -from __future__ import print_function - -import sys -from qpid_dispatch_internal.management.qdrouter import QdSchema -from qpid_dispatch_internal.management.schema_doc import SchemaWriter -from qpid_dispatch_internal.compat import dict_itervalues - -CONNECTOR = 'org.apache.qpid.dispatch.connector' -LISTENER = 'org.apache.qpid.dispatch.listener' - -class ManPageWriter(SchemaWriter): - - def __init__(self): - super(ManPageWriter, self).__init__(sys.stdout, QdSchema()) - - def attribute_type(self, attr, holder): - # Don't show read-only attributes - if not attr.create and not attr.update: - # It is ok to show the console attributes - if not holder.short_name == "console": - return - super(ManPageWriter, self).attribute_type(attr, holder, show_create=False, show_update=False) - - - - def man_page(self): - self.writeln(r""" -qdrouterd.conf(5) -================= -:doctype: manpage - -NAME ----- -qdrouterd.conf - configuration file for the dispatch router. - -SYNOPSIS --------- -Provides the initial configuration when 'qdrouterd(8)' starts. The configuration -of a running router can be modified using 'qdmanage(8)'. - - -DESCRIPTION ------------ - -The configuration file is made up of sections with this syntax: - ----- -sectionName { - attributeName: attributeValue - attributeName: attributeValue - ... -} ----- - -For example you can define a router using the 'router' section - ----- -router { - mode: standalone - id: Router.A - ... -} ----- - -or define a listener using the 'listener' section - ----- -listener { - host: 0.0.0.0 - port: 20102 - saslMechanisms: ANONYMOUS - ... -} ----- - -or define a connector using the 'connector' section - ----- -connector { - role: inter-router - host: 0.0.0.0 - port: 20003 - saslMechanisms: ANONYMOUS - ... -} ----- - -An 'sslProfile' section with SSL credentials can be included in multiple 'listener' or 'connector' entities. Here's an example, note -how the 'sslProfile' attribute of 'listener' sections references the 'name' -attribute of 'sslProfile' sections. - ----- -sslProfile { - name: my-ssl - caCertFile: ca-certificate-1.pem - certFile: server-certificate-1.pem - privateKeyFile: server-private-key.pem -} - -listener { - sslProfile: my-ssl - host: 0.0.0.0 - port: 20102 - saslMechanisms: ANONYMOUS -} ----- -""") - - with self.section("Configuration Sections"): - - config = self.schema.entity_type("configurationEntity") - for entity_type in dict_itervalues(self.schema.entity_types): - if config in entity_type.all_bases: - with self.section(entity_type.short_name): - if entity_type.description: - self.para(entity_type.description) - self.attribute_types(entity_type) - - self.writeln(""" -SEE ALSO --------- - -*qdrouterd(8)*, *qdmanage(8)* - -http://qpid.apache.org/components/dispatch-router -""") - -if __name__ == '__main__': - ManPageWriter().man_page() http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/man/qdstat.8.adoc ---------------------------------------------------------------------- diff --git a/doc/man/qdstat.8.adoc b/doc/man/qdstat.8.adoc deleted file mode 100644 index bd62be4..0000000 --- a/doc/man/qdstat.8.adoc +++ /dev/null @@ -1,277 +0,0 @@ -//// -Licensed to the Apache Software Foundation (ASF) under one -or more contributor license agreements. See the NOTICE file -distributed with this work for additional information -regarding copyright ownership. The ASF licenses this file -to you under the Apache License, Version 2.0 (the -"License"); you may not use this file except in compliance -with the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, -software distributed under the License is distributed on an -"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY -KIND, either express or implied. See the License for the -specific language governing permissions and limitations -under the License -//// - -qdstat(8) -========= -:doctype: manpage - -NAME ----- -qdstat - show status and statistics for a running 'qdrouterd' - -SYNOPSIS --------- -*qdstat* ['OPTIONS'] - -DESCRIPTION ------------ -An AMQP monitoring tool that shows status information about networks of Dispatch routers. It can display connections, network nodes and links, and router stats such as memory use. - -OPTIONS -------- - -include::{generated_man}/qdstat_help.adoc[] - -OUTPUT COLUMNS --------------- - -qdstat -c -~~~~~~~~~ -id:: -The connection's unique identifier. - -host:: -The hostname or internet address of the remotely-connected AMQP container. - -container:: -The container name of the remotely-connected AMQP container. - -role:: -The connection's role: - - 'normal' - The normal connection from a client to a router. - - 'inter-router' - The connection between routers to form a network. - - 'route-container' - The connection to or from a broker or other host to receive link routes and waypoints. - -dir:: -The direction in which the connection was established: - - 'in' - The connection was initiated by the remote container. - - 'out' - The connection was initiated by this router. - -security:: -The security or encryption method, if any, used for this connection. - -authentication:: -The authentication method and user ID of the connection's authenticated user. - -qdstat -l -~~~~~~~~~ -type:: -The type of link: - - 'router-control' - An inter-router link that is reserved for control messages exchanged between routers. - - 'inter-router' - An inter-router link that is used for normal message-routed deliveries. - - 'endpoint' - A normal link to an external endpoint container. - -dir:: -The direction that messages flow on the link: - - 'in' - Deliveries flow inbound to the router. - - 'out' - Deliveries flow outbound from the router. - -conn id:: -The unique identifier of the connection over which this link is -attached. - -id:: -The unique identifier of this link. - -peer:: -For link-routed links, the unique identifier of the peer link. In -link routing, an inbound link is paired with an outbound link. - -class:: -The class of the address bound to the link: - - 'local' - The address that is local to this router (temporary). - - 'topo' - A topological address used for router control messages. - - 'router' - A summary router address used to route messages to a remote routerâs local addresses. - - 'mobile' - A mobile address for an attached consumer or producer. - - 'link-in' - The address match for incoming routed links. - - 'link-out' - The address match for outgoing routed links. - -addr:: -The address bound to the link. - -phs:: -The phase of the address bound to the link. - -cap:: -The capacity, in deliveries, of the link. - -undel:: -The number of undelivered messages stored on the link's FIFO. - -unsett:: -The number of unsettled deliveries being tracked by the link. - -del:: -The total number of deliveries that have transited this link. - -presett:: -The number of pre-settled deliveries that transited this link. - -psdrop:: -The number of pre-settled deliveries that were dropped due to congestion. - -acc:: -The number of deliveries on this link that were accepted. - -rej:: -The number of deliveries on this link that were rejected. - -rel:: -The number of deliveries on this link that were released. - -mod:: -The number of deliveries on this link that were modified. - -admin:: -The administrative status of the link: - - 'enabled' - The link is enabled for normal operation. - - 'disabled' - The link is disabled and should be quiescing or stopped (not yet supported). - -oper:: -The operational status of the link: - - 'up' - The link is operational. - - 'down' - The link is not attached. - - 'quiescing' - The link is in the process of quiescing (not yet supported). - - 'idle' - The link has completed quiescing and is idle (not yet supported). - -name:: -The link name (only shown if the -v option is provided). - -qdstat -n -^^^^^^^^^ - -router-id:: -The router's ID. - -next-hop:: -If this router is not a neighbor, this field identifies the next-hop neighbor used to reach this router. - -link:: -The ID of the link to the neighbor router. - -cost:: -The topology cost to this remote router (with -v option only). - -neighbors:: -The list of neighbor routers (the router's link-state). This field is available only if you specify the -v option. - -valid-origins:: -The list of origin routers for which the best path to the listed router passes through this router (available only with the -v option). - -qdstat -a -~~~~~~~~~ - -class:: -The class of the address: - - 'local' - The address that is local to this router. - - 'topo' - The topological address used for router control messages. - - 'router' - A summary router address used to route messages to a remote router's local addresses. - - 'mobile' - A mobile address for an attached consumer or producer. - -addr:: -The address text. - -phs:: -For mobile addresses only, the phase of the address. Direct addresses have only a phase 0. Waypoint addresses have multiple phases, normally 0 and 1. - -distrib:: -One of the following distribution methods used for this address: - - 'multicast' - A copy of each message is delivered once to each consumer for the address. - - 'closest' - Each message is delivered to only one consumer for the address. The closest (lowest cost) consumer will be chosen. If there are multiple lowest-cost consumers, deliveries will be spread across those consumers. - - 'balanced' - Each message is delivered to only one consumer for the address. The consumer with the fewest outstanding (unsettled) deliveries will be chosen. The cost of the route to the consumer is a threshold for delivery (that is, higher cost consumers will only receive deliveries if closer consumers are backed up). - - 'flood' - Used only for router-control traffic. This is multicast without the prevention of duplicate deliveries. - -in-proc:: -The number of in-process consumers for this address. - -local:: -For this router, the number of local consumers for this address. - -remote:: -The number of remote routers that have at least one consumer for this address. - -cntnr:: -The number of locally-attached containers that are destinations for link routes on this address. - -in:: -The number of deliveries for this address that entered the network on this router. - -out:: -The number of deliveries for this address that exited the network on this router. - -thru:: -The number of deliveries for this address that were forwarded to other routers. - -to-proc:: -The number of deliveries for this address that were delivered to an in-process consumer. - -from-proc:: -The number of deliveries for this address that were received from an in-process producer. - -qdstat --linkroutes -~~~~~~~~~~~~~~~~~~~ - -prefix:: -The address prefix of the link route. - -dir:: -The direction of matching links (from this router's perspective). - -distrib:: -The distribution method used for routed links. This value should always be 'linkBalanced', which is the only supported distribution for routed links. - -status:: -The operational status of the link route: - - 'active' - The route is actively routing attaches (it is ready for use). - - 'inactive' - The route is inactive, because no local destination is connected. - -qstat --autolinks -~~~~~~~~~~~~~~~~~ -addr:: -The auto link's address. - -dir:: -The direction that messages flow over the auto link: - - 'in' - Messages flow in from the route-container to the router network. - - 'out' - Messages flow out to the route-container from the router network. - -phs:: -The address phase for this auto link. - -link:: -The ID of the link managed by this auto link. - -status:: -The operational status of this auto link: - - 'inactive' - There is no connected container for this auto link. - - 'attaching' - The link is attaching to the container. - - 'failed' - The link-attach failed. - - 'active' - The link is operational. - - 'quiescing' - The link is quiescing (not yet supported). - - 'idle' - The link is idle (not yet supported). - -lastErr:: -The description of the last attach failure that occurred on this auto link. - -SEE ALSO --------- - -'qdrouterd(8)', 'qdmanage(8)', 'qdrouterd.conf(5)' - -http://qpid.apache.org/components/dispatch-router http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/attributes.adoc ---------------------------------------------------------------------- diff --git a/doc/new-book/attributes.adoc b/doc/new-book/attributes.adoc deleted file mode 100644 index 0162710..0000000 --- a/doc/new-book/attributes.adoc +++ /dev/null @@ -1,78 +0,0 @@ -//// -Licensed to the Apache Software Foundation (ASF) under one -or more contributor license agreements. See the NOTICE file -distributed with this work for additional information -regarding copyright ownership. The ASF licenses this file -to you under the Apache License, Version 2.0 (the -"License"); you may not use this file except in compliance -with the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, -software distributed under the License is distributed on an -"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY -KIND, either express or implied. See the License for the -specific language governing permissions and limitations -under the License -//// - -// Standard document attributes - -:data-uri!: -:doctype: article -:experimental: -:idprefix: -:imagesdir: images -:numbered: -:sectanchors!: -:sectnums: -:source-highlighter: highlightjs -:highlightjs-theme: solarized_dark -:toc: left -:linkattrs: -:toclevels: 3 - -// Component attributes - -:ProductName: Apache Qpid -:RouterLongName: {ProductName} Dispatch Router -:ClientAmqpPythonName: {ProductName} Proton Python -:ConsoleName: {RouterLongName} Console -:FragmentDir: common -:RouterName: Dispatch Router -:RouterSchemaDir: ../../build/doc/book -:DispatchRouterVersion: 1.0.1 - -// Book names - -:RouterBook: Using {RouterLongName} - -// Doc links - -:DispatchRouterUrlBase: https://qpid.apache.org/releases/qpid-dispatch-{DispatchRouterVersion} - -:ManagementEntitiesUrl: {DispatchRouterUrlBase}/man/managementschema.html -:ManagementEntitiesLink: link:{ManagementEntitiesUrl}[{RouterName} Management Schema^] - -:RouterBookUrl: {DispatchRouterUrlBase}/book/book.html -:RouterBookLink: link:{RouterBookUrl}[{RouterBook}] - -:qdmanageManPageUrl: {DispatchRouterUrlBase}/man/qdmanage.html -:qdmanageManPageLink: link:{qdmanageManPageUrl}[qdmanage man page^] - -:qdrouterdManPageUrl: {DispatchRouterUrlBase}/man/qdrouterd.html -:qdrouterdManPageLink: link:{qdrouterdManPageUrl}[qdrouterd man page^] - -:qdrouterdConfManPageUrl: {DispatchRouterUrlBase}/man/qdrouterd.conf.html -:qdrouterdConfManPageLink: link:{qdrouterdConfManPageUrl}[qdrouterd.conf man page^] - -:qdstatManPageUrl: {DispatchRouterUrlBase}/man/qdstat.html -:qdstatManPageLink: link:{qdstatManPageUrl}[qdstat man page^] - -:ClientAmqpPythonUrl: https://qpid.apache.org/proton/ - -// Other links - -:AmqpSpecUrl: http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-overview-v1.0-os.html -:AmqpSpecLink: link:{AmqpSpecUrl}[AMQP 1.0 specification^] http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/book.adoc ---------------------------------------------------------------------- diff --git a/doc/new-book/book.adoc b/doc/new-book/book.adoc deleted file mode 100644 index 4ed6bdf..0000000 --- a/doc/new-book/book.adoc +++ /dev/null @@ -1,61 +0,0 @@ -//// -Licensed to the Apache Software Foundation (ASF) under one -or more contributor license agreements. See the NOTICE file -distributed with this work for additional information -regarding copyright ownership. The ASF licenses this file -to you under the Apache License, Version 2.0 (the -"License"); you may not use this file except in compliance -with the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, -software distributed under the License is distributed on an -"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY -KIND, either express or implied. See the License for the -specific language governing permissions and limitations -under the License -//// - -include::attributes.adoc[] - -= {RouterBook} - -// Introduction -include::introduction.adoc[leveloffset=+1] - -// Theory of Operation -include::theory_of_operation.adoc[leveloffset=+1] - -// Getting Started -include::getting-started.adoc[leveloffset=+1] - -// Configuration -include::understand-router-configuration.adoc[leveloffset=+1] - -// Network Connections -include::configuration-connections.adoc[leveloffset=+1] - -// Security -include::configuration-security.adoc[leveloffset=+1] - -// Routing -include::routing.adoc[leveloffset=+1] - -// Logging -include::logging.adoc[leveloffset=+1] - -// Management -include::management.adoc[leveloffset=+1] - -// Reliability -include::reliability.adoc[leveloffset=+1] - -// Technical Details and Specifications -include::technical-details-specifications.adoc[leveloffset=+1] - -[appendix] -include::cyrus-sasl.adoc[leveloffset=+1] - -// Revision information -include::revision-info.adoc[] http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/common ---------------------------------------------------------------------- diff --git a/doc/new-book/common b/doc/new-book/common deleted file mode 120000 index 8332399..0000000 --- a/doc/new-book/common +++ /dev/null @@ -1 +0,0 @@ -../common/ \ No newline at end of file http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/f77f92cb/doc/new-book/configuration-connections.adoc ---------------------------------------------------------------------- diff --git a/doc/new-book/configuration-connections.adoc b/doc/new-book/configuration-connections.adoc deleted file mode 100644 index 26e10a2..0000000 --- a/doc/new-book/configuration-connections.adoc +++ /dev/null @@ -1,90 +0,0 @@ -//// -Licensed to the Apache Software Foundation (ASF) under one -or more contributor license agreements. See the NOTICE file -distributed with this work for additional information -regarding copyright ownership. The ASF licenses this file -to you under the Apache License, Version 2.0 (the -"License"); you may not use this file except in compliance -with the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, -software distributed under the License is distributed on an -"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY -KIND, either express or implied. See the License for the -specific language governing permissions and limitations -under the License -//// - -[id='router-network-connections'] -= Network Connections - -Connections define how the router communicates with clients, other routers, and brokers. You can configure _incoming connections_ to define how the router listens for data from clients and other routers, and you can configure _outgoing connections_ to define how the router sends data to other routers and brokers. - -[id='adding-incoming-connections'] -== Listening for Incoming Connections - -Listening for incoming connections involves setting the host and port on which the router should listen for traffic. - -.Procedure - -. In the router's configuration file, add a `listener`: -+ --- -[options="nowrap",subs="+quotes"] ----- -listener { - host: _HOST_NAME/ADDRESS_ - port: _PORT_NUMBER/NAME_ - ... -} ----- - -`host`:: Either an IP address (IPv4 or IPv6) or hostname on which the router should listen for incoming connections. -`port`:: The port number or symbolic service name on which the router should listen for incoming connections. - -For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_listener[listener] in the `qdrouterd.conf` man page. --- - -. If necessary, xref:securing-incoming-connections[secure the connection]. -+ -If you have set up SSL/TLS or SASL in your environment, you can configure the router to only accept encrypted or authenticated communication on this connection. - -. If you want the router to listen for incoming connections on additional hosts or ports, configure an additional `listener` entity for each host and port. - -[id='adding-outgoing-connections'] -== Adding Outgoing Connections - -Configuring outgoing connections involves setting the host and port on which the router connects to other routers and brokers. - -// Adding this here for now; in the future it might be better to have separate procedures for creating inter-router and route-container connections. -When a router connects to a broker, the broker might provide backup connection data that the router can use if the primary connection fails. If the primary connection fails, the router attempts to reconnect by using a combination of the primary and -- if provided -- backup connections in round-robin fashion until the connection is successful. For more information about viewing the backup connection data provided by the broker, see xref:managing-connectors[]. - -.Procedure - -. In the router's configuration file, add a `connector`: -+ --- -[options="nowrap",subs="+quotes"] ----- -connector { - name: _NAME_ - host: _HOST_NAME/ADDRESS_ - port: _PORT_NUMBER/NAME_ - ... -} ----- - -`name`:: The name of the `connector`. You should specify a name that describes the entity to which the connector connects. This name is used by configured addresses (for example, a `linkRoute` entity) in order to specify which connection should be used for them. -`host`:: Either an IP address (IPv4 or IPv6) or hostname on which the router should connect. -`port`:: The port number or symbolic service name on which the router should connect. - -For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_connector[connector] in the `qdrouterd.conf` man page. --- - -. If necessary, xref:securing-outgoing-connections[secure the connection]. -+ -If you have set up SSL/TLS or SASL in your environment, you can configure the router to only send encrypted or authenticated communication on this connection. - -. For each remaining router or broker to which this router should connect, configure an additional `connector` entity. --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@qpid.apache.org For additional commands, e-mail: commits-h...@qpid.apache.org
