Not to hijack this thread, but...

----- Original Message -----
> From: "Rafael Schloming" <r...@alum.mit.edu>
> To: proton@qpid.apache.org
> Sent: Tuesday, March 26, 2013 10:00:23 AM
> Subject: Re: RFC: new routing functionality for messenger
> 
> On Tue, Mar 26, 2013 at 7:19 AM, Bozo Dragojevic <bo...@digiverse.si>
> wrote:
> 
> > On 3/23/13 5:43 PM, Rafael Schloming wrote:
> >
> >> Hi,
> >>
> >> I've added a new API to messenger that gives the user some control
> >> over
> >> the
> >> internal routing behaviour of a messenger. Please check it out and
> >> comment.
> >> I've pasted the C API/doxygen below. This is currently only
> >> exposed
> >> through
> >> the python binding via the route method on the Messenger class.
> >>
> >> --Rafael
> >>
> >> /** 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
> >>   routing
> >>   * 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
> >>   rule.
> >>   *
> >>
> >
> > Can you help me work through this use-case:
> >
> >
> > A 'dumb' client, sends a message, and expects a reply:
> >
> >     // client.c
> >     pn_message_set_address(msg, "amqp://localhost/bla");
> >     pn_messenger_put(msgr, msg);
> >     pn_messenger_receive(msgr,1);
> >     msg = pn_messenger_get(msgr);
> >
> >
> >
> > The peer it connects to uses the new route functionality:
> >
> >     // server.c
> >     pn_messenger_subscribe(msgr, "~amqp://localhost/bla");
> >
> 
> I'm assuming you mean "amqp://~localhost/blah" above. ;-)
> 
> 
> >
> > 1) Are routes valid to use if there's a subscribe going on.
> >    I assume yes.
> >
> >     pn_messenger_route(msgr, "*", "amqp://broker/$1");
> >
> 
> It's certainly valid to use both at the same time.
> 
> 
> >
> > 2) How do they interact.
> >    I assume they don't, routing is only applied to outgoing
> >    messages.
> >
> 
> Actually routing should be applied equally to both, however now that
> I
> think about it I suspect you need to do the route before you do the
> subscribe in order for it to make a difference for the subscribe,
> although
> I expect that limitation to go away in the next round of changes.
> 
> 
> >
> > 3) Does the order of calls to route and subscribe matter.
> >    According to 2) it does not.
> >
> 
> Actually the order does matter (see above). I expect eventually the
> implementation will evolve in such a way that the order does not
> matter,
> however even so you would effectively end up getting a resubscribe
> when the
> new route goes into place, e.g. the following sequence of events
> could
> occur:
> 
> subscribe("foo.com/bar")
> ...
> ... if you do a recv here, messages might arrive directly from
> foo.com
> ...
> route("foo.com/bar", "fooproxy.com/baz")
> ...
> ... now you get messages via the proxy
> 
> 
> >
> >     pn_messenger_receive(msgr, 1);
> >     msg = pn_messenger_get(msgr);
> >
> >     /* echo */
> >     char *sender = pn_message_get_reply_to(msg);
> >     pn_message_set_address(msg, sender);
> >     pn_messenger_put(msgr, msg);
> >     pn_messenger_send(msgr);
> >
> >
> > 4) What would the pn_message_get_reply_to() return.
> >    The value as set by the client's messenger would be
> > amqp://some-uuid-value
> >
> 
> This is a very good question. I don't recall exactly why messenger
> sets the
> reply_to automatically as it does, it may even be an unintentional
> side
> effect of a couple of different changes, but I've been thinking that
> it
> shouldn't actually do this automatically, i.e. that you should always
> set a
> reply_to explicitly if that's what you want.
> 
> FWIW, it's not actually setting the reply_to value to
> some-random-uuid,
> it's actually setting it to amqp://the-name-of-the-messenger. It just
> so
> happens that the name of the messenger defaults to a UUID, but if you
> had
> constructed your messenger as pn_messenger("bob") rather than
> pn_messenger(NULL), then the reply_to would automatically get set to
> amqp://bob.
> 
> I was also thinking that it would be convenient to have some way to
> actually refer to the container name in an address, that way e.g.
> explicitly setting the reply_to = "amqp://${me}" would give the same
> effect
> that you currently get with the automatic setting, but would also be
> a bit
> more flexible.
> 


Yes, absolutely - this is a Must Have as far as I'm concerned.   Specifically:

1) The application should control whether Reply-to is set or not (currently 
always set by messenger)
2) The application should be able to get its local address (for reply-to) via 
messenger rather than require it to configured - the ${me} in the above.

If no objections I'm gonna JIRA these...




> 
> >
> > 5) Would the route above apply or not to this particular outgoing
> > reply
> > message.
> >
> 
> The rules always apply, the messenger impl doesn't really know the
> difference between that and any other address.
> 
> 
> >
> > 6) If yes, how will 'broker' learn how to talk to the original
> > client
> >
> 
> Another very good question. Unfortunately the answer right now
> depends on
> your broker as each broker assumes a private namespace, you would
> need to
> construct a reply_to that is known to your broker, e.g. create a
> reply-queue called "replies" on your broker and explicitly set your
> reply-to to amqp://broker/replies.
> 
> One of the areas that we are working on within the OASIS TC is
> defining an
> addressing standard such that this will be much more seamless, e.g.
> the
> clients could just use globally scoped names the same way they would
> in a
> peer to peer scenario, and you could have an intermediary that would
> be
> able to identify these and route/proxy accordingly. Obviously a
> legacy
> broker wouldn't necessarily function as a router/proxy, so you still
> might
> need to manually stitch together the reply-to chain depending on what
> kind
> of intermediary you are using.
> 
> One thing worth pointing out about this functionality that might not
> be
> obvious at first is that the route function doesn't currently touch
> what is
> in the to or reply-to field of a message. That always stays exactly
> as the
> user supplies it. The model is really a world where logically the to
> and
> reply-to identify a final destination/rendezvous point and therefore
> need
> to be preserved and carried forward by every intermediary in the
> network.
> Hence the name pn_messenger_route as what it is doing is determining
> the
> next hop, not doing some sort of rewriting.
> 
> It would, however, be possible to add an API that used the same or a
> similar mechanism to do rewriting, e.g.
> pn_messenger_rewrite(pn_messenger_t
> *m, const char *pattern, const char *address) could establish a
> distinct
> set of rules for rewrite the to/reply_to of incoming and/or outgoing
> messages. I can imagine this possibly being useful in legacy
> scenarios
> where you need the reply_to to match a particular form required for a
> given
> broker.
> 
> --Rafael
> 

-- 
-K

Reply via email to