Menu Search

Qpid Dispatch Release 0.1

System Requirements and Dependencies

Documented capabilities available in version 0.1

Some of the capabilities listed in these pages for Dispatch are for future releases and are supplied for the purpose of illustrating the potential of a message router. This section outlines the actual capabilities of version 0.1:

Building, Testing, and Installing

Download and extract the source tar file:

$ wget
$ tar -xzf qpid-dispatch-0.1.tar.gz

Source the build configuration:

$ cd qpid-dispatch-0.1
$ source

Build and test the package. This will create two directories: 'build' and 'install'. Dispatch will be built in the 'build' directory and installed in the 'install' directory. The regression and system test suites will then be run against the installed bits.

$ bin/

If you wish to change the build configuration, go into the build directory, use cmake to configure your build then rebuild and/or reinstall from there:

$ cd build
$ cmake ..
$ make
$ make install


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:

$ qdrouterd

Client Compatibility

Dispatch Router should, in theory, work with any client that is compatible with AMQP 1.0. The following clients have been tested:

qpid::messagingThe 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 MessengerMessenger works with Dispatch Router.


Installed with the Dispatch Router kit is a command line tool called qdstat. This tool can be used to view manageable data inside Dispatch Router. The following options are useful for seeing that the router is doing:

-lPrint 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.
-aPrint a list of addresses known to the router.
-nPrint a list of known routers in the network.
-cPrint a list of connections to the router.

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:

$ amqp://

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:

$ -a amqp://

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:";
    std::string connectionOptions = "{protocol:amqp1.0}";

    Connection connection(url, connectionOptions);;
    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.setProperty("x-amqp-to", "amqp:/_local/$management");
    request.setProperty("operation", "DISCOVER-MGMT-NODES");
    request.setProperty("type", "");
    request.setProperty("name, "self");

    Message response = receiver.fetch();
    Variant content(response.getContentObject());
    std::cout << "Response: " << content << std::endl << std::endl;


The equivalent program written in Python against the Proton Messenger API:

from proton import Messenger, Message

def main():
    host = ""

    messenger = Messenger()
    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 = {u'operation' : u'DISCOVER-MGMT-NODES',
                          u'type'      : u'',
                          u'name'      : u'self'}


    print "Response: %r" % response.body



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:

Issues Addressed in this Release