On 03/28/2013 09:11 AM, Ken Giusti wrote:
At first I was a bit skeptical whether this really belongs in the messenger
API, but I've come to accept that it would have to be. Internally, messenger
does perform routing - mapping the 'to' address to the proper connection and
link. To me, this new API provides a level of control over that mapping
That said, the api needs a bit of fleshing out.
Assuming that we support multiple routes, then most obviously the api would
need to provide the ability to query the route table for a given mapping. I'd
also like to see a means for walking the route table in match order. And
deletions - can't forget that.
And to be clear - the match precedent is determined by the order in which
routes are added, correct? That may be hard to manage if the route table is
modified over time. Perhaps a route should be given a priority? Or maybe we
give routes precedence based on their restrictiveness - matching more
I am starting to think we need a proton routing plug-in API so that different
choices of routing rules, pattern matching, configuration files etc. can be
implemented without baking one set of choices into messenger. Such a plugin API
could be fairly simple and would allow choice and composition of functionality
from different plug-ins.
----- Original Message -----
From: "Rafael Schloming" <r...@alum.mit.edu>
Sent: Saturday, March 23, 2013 12:43:07 PM
Subject: RFC: new routing functionality for messenger
I've added a new API to messenger that gives the user some control
internal routing behaviour of a messenger. Please check it out and
I've pasted the C API/doxygen below. This is currently only exposed
the python binding via the route method on the Messenger class.
/** Adds a routing rule to a Messenger's internal routing table.
* The route procedure may be used to influence how a messenger will
* internally treat a given address or class of addresses. Every call
* to the route procedure will result in messenger appending a
* rule to its internal routing table.
* Whenever a message is presented to a messenger for delivery, it
* will match the address of this message against the set of routing
* rules in order. The first rule to match will be triggered, and
* instead of routing based on the address presented in the message,
* the messenger will route based on the address supplied in the
* The pattern matching syntax supports two types of matches, a '%'
* will match any character except a '/', and a '*' will match any
* character including a '/'.
* A routing address is specified as a normal AMQP address, however
* may additionally use substitution variables from the pattern match
* that triggered the rule.
* Any message sent to "foo" will be routed to "amqp://foo.com":
* pn_messenger_route("foo", "amqp://foo.com");
* Any message sent to "foobar" will be routed to
* pn_messenger_route("foobar", "amqp://foo.com/bar");
* Any message sent to bar/<path> will be routed to the corresponding
* path within the amqp://bar.com domain:
* pn_messenger_route("bar/*", "amqp://bar.com/$1");
* Route all messages over TLS:
* pn_messenger_route("amqp:*", "amqps:$1")
* Supply credentials for foo.com:
* Supply credentials for all domains:
* pn_messenger_route("amqp://*", "amqp://user:password@$1");
* Route all addresses through a single proxy while preserving the
* original destination:
* Route any address through a single broker:
* pn_messenger_route("*", "amqp://user:password@broker/$1");
* @param[in] messenger the Messenger
* @param[in] pattern a glob pattern
* @param[in] address an address indicating alternative routing
* @return an error code or zero on success
* @see error.h
PN_EXTERN int pn_messenger_route(pn_messenger_t *messenger, const
const char *address);