Rafael H. Schloming commented on PROTON-160:

I was assuming auto-redirect was part of what was being asked for in 
PROTON-164, but if not we can split that into a separate Jira. I do think it 
would be good if we could make the redirect happen transparently, e.g. treat it 
as part of the resolution process.

Regarding the semantics being discussed, I'm unclear on the need for two 
messages with the same address to connect to different physical endpoints. What 
I'm leaning towards is some way to explicitly specify the TCP endpoint for a 
given address, but not necessarily on a per message basis, rather just a per 
address basis. This would omit both the problematic redirector scenario and 
maintain the semantic that for a given messenger, a given address will always 
resolve to a single connection. I like maintaining this property because I 
think it's a simpler model for users and in particular the security model here 
maps strongly to the one used by web browsers. You only need to look in one 
place (the to field) to figure out where a message is going, and your 
certificates are always validated against that.

To draw an analogy to a web browser, if the to field is the URL, then I think 
the approach option (1) is taking is basically adding another input field to 
your web browser UI that lets you override DNS lookup whenever you type in a 
URL. This would let you type in the same URL twice, and get completely 
different results depending on the value typed into this other field. What I'm 
suggesting with option (3) is pretty much like overriding your /etc/hosts file 
so whenever a given URL appears, it resolves to something you control, but it 
will always resolve to the same thing until you go change your hosts file. I 
think these both have equivalent capabilities, but I feel like option (3) is 
simpler for the scenarios where I can imagine needing this kind of thing.

As an aside, I think this aliasing thing would also give us a path towards more 
advanced configurations, e.g. imagine adding wildcard support and you have an 
easy way to instruct a messenger to direct all (or some subset) of messages 
through a single broker, e.g. alias * -> my-broker, or alias *.foo -> my-broker 
and alias *.bar -> your-broker.
> Allow open.hostname to be configured independently of network hostname
> ----------------------------------------------------------------------
>                 Key: PROTON-160
>                 URL: https://issues.apache.org/jira/browse/PROTON-160
>             Project: Qpid Proton
>          Issue Type: Improvement
>          Components: proton-c
>    Affects Versions: 0.1, 0.2
>            Reporter: David Ingham
> In a scaled-out, multi-tenant broker environment, the host on which the 
> container is running is often different from the host to which a client is 
> establishing the tcp connection. The 'hostname' field in the connection open 
> performative was added to support this scenario. Currently there's no way to 
> control this from the Messenger API.
> Options include:
> (1) (preferred) add a new 'networkhost' field to Message to allow the network 
> address to be specified. If provided, this information would be used when 
> establishing the network connection and the data in the 'address' field would 
> be used in the connection open hostname field. This is somewhat in line with 
> the way that connection redirect (amqp:connection:redirect) is specified.
> (2) extend the syntax of address with query string to supply hostname, e.g., 
> username:password@tcpaddress:tcpport/entityname?hostname=foo where 'foo' 
> would become the hostname used in the connection open frame. This is the 
> approach used by the current Qpid AMQP 1.0 JMS client.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to