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 mobile temp.reply-address/0001 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.reply-address/0001 is the 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 qdxhello Y 0 0 0 0 0 0 38 local qdxrouter Y 0 0 0 0 0 0 2 mobile temp.reply-address/0001 1 0 0 0 0 0 0
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 cubscribed 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 2 0 0 2 0 mobile my-address 1 0 0 0 0 0 0 mobile temp.reply-address/0001 1 0 0 0 0 0 0You 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 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();
}