[jira] [Commented] (PROTON-160) Allow open.hostname to be configured independently of network hostname
[ https://issues.apache.org/jira/browse/PROTON-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13611805#comment-13611805 ] Rafael H. Schloming commented on PROTON-160: I've taken a stab at adding some functionality to the messenger API that addresses this area, namely the new pn_messenger_route API that I posted about on the list recently. The conversation above covers a wide range of topics though, so I'd like people to have a look at what I've done and let me know if there are still areas that need work for this JIRA, or if we can close it off and/or open some smaller/more specific JIRAs to address any remaining problem areas. 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, proton-j Affects Versions: 0.1, 0.2 Reporter: David Ingham Assignee: Rafael H. Schloming Labels: api Fix For: 0.5 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
[jira] [Commented] (PROTON-160) Allow open.hostname to be configured independently of network hostname
[ https://issues.apache.org/jira/browse/PROTON-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13598301#comment-13598301 ] Rob Godfrey commented on PROTON-160: I'm somewhat late to this party, but I am hitting this same issue in some work that I am doing. The solution I am looking for is, I think, that given by Gordon above - the ability to use configuration information such that Messenger resolves hostname to a TCP/IP address through custom configuration. In my use case I would have a single IP address that all hosts initially resolve to - this will be the redirector component. The redirector will then hold secondary configuration as to where the actual TCP/IP address to connect to is, and will send the redirect accordingly. Are we still looking to address this (excuse the pun) for 0.5? 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, proton-j Affects Versions: 0.1, 0.2 Reporter: David Ingham Assignee: Rafael H. Schloming Labels: api Fix For: 0.5 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
[jira] [Commented] (PROTON-160) Allow open.hostname to be configured independently of network hostname
[ https://issues.apache.org/jira/browse/PROTON-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505408#comment-13505408 ] Gordon Sim commented on PROTON-160: --- I greatly prefer option (3) as outlined at the end of comment #1(https://issues.apache.org/jira/browse/PROTON-160?focusedCommentId=13505199), i.e. having some way to configure a messenger to handle addresses (falling back to DNS based resolution if no rules exist/apply). Per-message addresses should ideally be logical with a flexible mapping to the physical addresses over which they should then be transferred. Option 3 seems the safest and neatest solution. I find option 1 confusing as well as I think being to tied to a particular pattern of use. I thinks URLs are actually a less than ideal choice for the address syntax as they confuse the notions of (hierarchical) domain scoped logical naming with 'connection strings', and adding in various options and parameters is I think the thin end of the wedge that will lead to muddiness. 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
[jira] [Commented] (PROTON-160) Allow open.hostname to be configured independently of network hostname
[ https://issues.apache.org/jira/browse/PROTON-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505441#comment-13505441 ] 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
[jira] [Commented] (PROTON-160) Allow open.hostname to be configured independently of network hostname
[ https://issues.apache.org/jira/browse/PROTON-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505706#comment-13505706 ] Affan Dar commented on PROTON-160: -- I think the assumption behind option (1) was that adding a connection level setting (such as an alias) may not be appropriate for the level that the messenger API is operating it. Seems like that is not a big issue which is great. Connection aliasing is a good solution and will work for all scenarios (reconnect, redirect etc). It will also make the receive side more symmetric with the send side which is goodness. 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
[jira] [Commented] (PROTON-160) Allow open.hostname to be configured independently of network hostname
[ https://issues.apache.org/jira/browse/PROTON-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505715#comment-13505715 ] Rafael H. Schloming commented on PROTON-160: Ok, thanks for wading through my ramblings. ;-) I'll take a crack at this and post again when I have something concrete. 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
[jira] [Commented] (PROTON-160) Allow open.hostname to be configured independently of network hostname
[ https://issues.apache.org/jira/browse/PROTON-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505243#comment-13505243 ] Affan Dar commented on PROTON-160: -- Regarding the messenger resolution process, the following semantic is one possibility and seems to reflect what you are thinking as well: - message.network_host, if specified, is the physical address of the host. I.e. this is the destination end point for the TCP connection. - message.address is the TLS endpoint of the host which is used in open.hostname and SASL etc. Furthermore, if message.network_host is not specified then this will also be used as the destination end point for the TCP connection, i.e. the easy default that you mentioned. - Messages with the same message.address can have different values in message.network_host and the connections associated with the respective networkhosts would be used to send these messages. I think PROTON-136 can benefit from this by using the message.address as the key for the session cache. Furthermore, are there plans on adding auto-redirect to the resolution process? I think it raises some other questions. If there is a JIRA tracking that work then I can add some comments to it. 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
