OASIS Advanced Message Queuing Protocol (AMQP) TC

  • 1.  Global addressing model - brain dump

    Posted 09-14-2018 10:04
    For the Management spec I also need the Addressing spec to make progress, so I’m now taking a fresh look at this.   From the F2Fs I recall that our biggest holdup was that we’ve got tension between several distinct goals for addressing expressions: An address _expression_ should enable a “client” to find a “server” on an IP network to establish an AMQP TLS-first (5671) or TLS-upgrade (5672) connection, establish link(s) and transfer messages. The address _expression_ therefore needs to hold DNS/IP/TCP addressing information, a protocol selector, and a link target. An address _expression_ should enable a “sender” to have messages routed to a “receiver” inside a (yet poorly defined) AMQP network and fully abstracting the underlying IP layer, whereby the “receiver” address is a logical construct that doesn’t contain network-related information. With such an address, it should be possible to find the receiving container (and node) by ways of: resolving the logical address to container name/location OR evaluating routing rules based on filter expressions that indirectly yield a container location An address _expression_ should enable a “sender” to route messages to a “receiver” inside a singular AMQP container, where address expressions correspond directly to node names inside of said container.   We also have amqp/amqps URIs being used in the wild based on the current draft and I don’t want to break those.   Here’s a proposal for an extended URI format that aims to hit all the goals at once:   { amqp amqps } : [ //user:key@ip-endpoint/ ] [ (container-name)/ ] [ [ $ ] node-path ]   I’ll start the explanation with examples, because they’ll probably tell a whole lot of the story already: amqps://broker.example.com/queue1 – DNS qualified address of a TCP/IP endpoint of an AMQP container with path for the “queue1” AMQP node amqp:(london-branch-34)/atm – Logical AMQP network address of “london-branch-34” with path for the “atm” AMQP node amqps://megabank.example.com/(london-branch-34)/atm – DNS qualified address of a “gateway” into an AMQP network, with logical AMQP network address as suffix amqp:()/control – Anonymous AMQP network address to be resolved into a container location by evaluating message metadata, with path for the “control” node on the resulting container somewhere – Local container address of the “something” AMQP node $somewhere – AMQP reserved local container address   To start, I’m splitting up the AMQP notion of container into two distinct concepts: “gateway” and “container”. A gateway is a TCP/IP listener that speaks the AMQP wire protocol. Clients establish connections and sessions with gateways. Gateways are onramps into AMQP networks. A container is a host for AMQP nodes. Multiple containers may be interrelated (and opportunistically interconnected) to form a logical network, with lookup mechanisms that allow resolving logical names to specific containers. Each container MUST have a gateway. Each configured relationship between containers holds information about which gateway ought to be used to reach the respective container. The configured destination gateway for any container MAY, however, be an intermediary, meaning it might take one or more further network resolution/routing steps to reach the destination container. Not all gateways have to be containers. A gateway can just do connection/session handling and never host nodes and/or take ownership of links; it might be a pure relay bridging sessions to another gateway.   With the URI format, I am proposing a three-layer addressing model: With DNS/IP addressing in the ip-endpoint section, you pick an AMQP endpoint as gateway into an AMQP network. With container-name , you pick the AMQP container you want to communicate with via the chosen gateway. If omitted, the container is thought to be directly associated with “this” gateway (like today). If the container-name _expression_ is present but empty, it’s up to the gateway rules/configuration to determine the destination container based on the message/link properties or other criteria. With node-path , you  pick the AMQP node you want to route/link to inside the chosen/resolved container.     With a message addressed to amqps://megabank.example.com/(london-branch-34)/atm , a client first resolves the DNS name and IP address to some AMQP gateway instance via DNS and/or a load balancer, connects, and establishes a session – or reuses an existing session to that gateway.   Then, the client will either attempt to attach a link to (london-branch-34)/atm on the gateway-associated container, or identify an already existing link. Alternatively, it might attempt to route to said address via the container’s anonymous terminus by using it in the “properties:to” property.   How the (container-name) destination gets resolved is up to the container. In a simple case, a container might maintain a routing table with {container-name, gateway ip-endpoint} pairs, and will create/reuse connections/sessions to the listed gateways for routing/linking to the respective containers. The routing table may point to intermediary gateways. For link routing, the “(container-name)/node-path” _expression_ serves as the link target name in all containers acting as intermediaries. It resolves to node-path on the container that self-identifies as the given container-name.   In effect, you can attach a link to “(container-name)/node-path” on any container on a network supporting global addressing, and the container will then patch that link through to the next hop network destination configured for that container name, and until it gets to the target container. For anonymous terminus routing, messages get routed along to the next container’s anonymous terminus. The “routing cookies” spec then applies for how to establish reply routes.     Thoughts?


  • 2.  Re: [amqp] Global addressing model - brain dump

    Posted 09-19-2018 01:15
    This looks pretty sane to me. At first I found it odd to see container in the address but Qpid Dispatch router has a similar concept. It uses "magic" address prefixes to included router-ids in an address so e.g. amqp://host:port/$management is the management interface of the directly connected router, but amqp:/_topo/0/foo/$management lets you manage the router with id=foo. Using the standard container-id concept makes sense here - so in your scheme it would be amqp://host:port/(foo)/$management. Equating router-id and container-id seems like a sensible notion. On Fri, Sep 14, 2018 at 6:04 AM Clemens Vasters < clemensv@microsoft.com > wrote: For the Management spec I also need the Addressing spec to make progress, so I m now taking a fresh look at this. From the F2Fs I recall that our biggest holdup was that we ve got tension between several distinct goals for addressing expressions: An address _expression_ should enable a client to find a server on an IP network to establish an AMQP TLS-first (5671) or TLS-upgrade (5672) connection, establish link(s) and transfer messages. The address _expression_ therefore needs to hold DNS/IP/TCP addressing information, a protocol selector, and a link target. An address _expression_ should enable a sender to have messages routed to a receiver inside a (yet poorly defined) AMQP network and fully abstracting the underlying IP layer, whereby the receiver address is a logical construct that doesn t contain network-related information. With such an address, it should be possible to find the receiving container (and node) by ways of: resolving the logical address to container name/location OR evaluating routing rules based on filter expressions that indirectly yield a container location An address _expression_ should enable a sender to route messages to a receiver inside a singular AMQP container, where address expressions correspond directly to node names inside of said container. We also have amqp/amqps URIs being used in the wild based on the current draft and I don t want to break those. Here s a proposal for an extended URI format that aims to hit all the goals at once: { amqp amqps } : [ //user:key@ip-endpoint/ ] [ (container-name)/ ] [ [ $ ] node-path ] I ll start the explanation with examples, because they ll probably tell a whole lot of the story already: amqps:// broker.example.com/queue1 DNS qualified address of a TCP/IP endpoint of an AMQP container with path for the queue1 AMQP node amqp:(london-branch-34)/atm Logical AMQP network address of london-branch-34 with path for the atm AMQP node amqps:// megabank.example.com/(london-branch-34)/atm DNS qualified address of a gateway into an AMQP network, with logical AMQP network address as suffix amqp:()/control Anonymous AMQP network address to be resolved into a container location by evaluating message metadata, with path for the control node on the resulting container somewhere Local container address of the something AMQP node $somewhere AMQP reserved local container address To start, I m splitting up the AMQP notion of container into two distinct concepts: gateway and container . A gateway is a TCP/IP listener that speaks the AMQP wire protocol. Clients establish connections and sessions with gateways. Gateways are onramps into AMQP networks. A container is a host for AMQP nodes. Multiple containers may be interrelated (and opportunistically interconnected) to form a logical network, with lookup mechanisms that allow resolving logical names to specific containers. Each container MUST have a gateway. Each configured relationship between containers holds information about which gateway ought to be used to reach the respective container. The configured destination gateway for any container MAY, however, be an intermediary, meaning it might take one or more further network resolution/routing steps to reach the destination container. Not all gateways have to be containers. A gateway can just do connection/session handling and never host nodes and/or take ownership of links; it might be a pure relay bridging sessions to another gateway. With the URI format, I am proposing a three-layer addressing model: With DNS/IP addressing in the ip-endpoint section, you pick an AMQP endpoint as gateway into an AMQP network. With container-name , you pick the AMQP container you want to communicate with via the chosen gateway. If omitted, the container is thought to be directly associated with this gateway (like today). If the container-name _expression_ is present but empty, it s up to the gateway rules/configuration to determine the destination container based on the message/link properties or other criteria. With node-path , you pick the AMQP node you want to route/link to inside the chosen/resolved container. With a message addressed to amqps:// megabank.example.com/(london-branch-34)/atm , a client first resolves the DNS name and IP address to some AMQP gateway instance via DNS and/or a load balancer, connects, and establishes a session or reuses an existing session to that gateway. Then, the client will either attempt to attach a link to (london-branch-34)/atm on the gateway-associated container, or identify an already existing link. Alternatively, it might attempt to route to said address via the container s anonymous terminus by using it in the properties:to property. How the (container-name) destination gets resolved is up to the container. In a simple case, a container might maintain a routing table with {container-name, gateway ip-endpoint} pairs, and will create/reuse connections/sessions to the listed gateways for routing/linking to the respective containers. The routing table may point to intermediary gateways. For link routing, the (container-name)/node-path _expression_ serves as the link target name in all containers acting as intermediaries. It resolves to node-path on the container that self-identifies as the given container-name. In effect, you can attach a link to (container-name)/node-path on any container on a network supporting global addressing, and the container will then patch that link through to the next hop network destination configured for that container name, and until it gets to the target container. For anonymous terminus routing, messages get routed along to the next container s anonymous terminus. The routing cookies spec then applies for how to establish reply routes. Thoughts?


  • 3.  Re: [amqp] Global addressing model - brain dump

    Posted 09-19-2018 01:45
    I had a similar impression - it looks good. It works to existing conventions well, and it opens an avenue for container-based routing. What are the options we can consider for the notation? The parens sort of work for me, but I'd like to consider a larger set of candidates first. { amqp amqps } : [ //user:key@ip-endpoint/ ] [ @container-name ] [ [$] node-path ] amqp:@foo/news/eu amqp:// example.net/@foo/news/eu { amqp amqps } : [ //user:key@ip-endpoint/ ] [ [container-name] ] [ [$] node-path ] amqp:[foo]/news/eu amqp:// example.net/[foo]/news/eu { amqp amqps } : [ //user:key@ip-endpoint/ ] [ !container-name ] [ [$] node-path ] amqp:!foo/news/eu amqp:// example.net/!foo/news/eu Looking at it now, I have a slight preference for the @ notation, as long as it doesn't collide with other stuff. RFC 3986 seems to allow for it. On Tue, Sep 18, 2018 at 6:14 PM Alan Conway < aconway@redhat.com > wrote: This looks pretty sane to me. At first I found it odd to see container in the address but Qpid Dispatch router has a similar concept. It uses "magic" address prefixes to included router-ids in an address so e.g. amqp://host:port/$management is the management interface of the directly connected router, but amqp:/_topo/0/foo/$management lets you manage the router with id=foo. Using the standard container-id concept makes sense here - so in your scheme it would be amqp://host:port/(foo)/$management. Equating router-id and container-id seems like a sensible notion. On Fri, Sep 14, 2018 at 6:04 AM Clemens Vasters < clemensv@microsoft.com > wrote: For the Management spec I also need the Addressing spec to make progress, so I m now taking a fresh look at this. From the F2Fs I recall that our biggest holdup was that we ve got tension between several distinct goals for addressing expressions: An address _expression_ should enable a client to find a server on an IP network to establish an AMQP TLS-first (5671) or TLS-upgrade (5672) connection, establish link(s) and transfer messages. The address _expression_ therefore needs to hold DNS/IP/TCP addressing information, a protocol selector, and a link target. An address _expression_ should enable a sender to have messages routed to a receiver inside a (yet poorly defined) AMQP network and fully abstracting the underlying IP layer, whereby the receiver address is a logical construct that doesn t contain network-related information. With such an address, it should be possible to find the receiving container (and node) by ways of: resolving the logical address to container name/location OR evaluating routing rules based on filter expressions that indirectly yield a container location An address _expression_ should enable a sender to route messages to a receiver inside a singular AMQP container, where address expressions correspond directly to node names inside of said container. We also have amqp/amqps URIs being used in the wild based on the current draft and I don t want to break those. Here s a proposal for an extended URI format that aims to hit all the goals at once: { amqp amqps } : [ //user:key@ip-endpoint/ ] [ (container-name)/ ] [ [ $ ] node-path ] I ll start the explanation with examples, because they ll probably tell a whole lot of the story already: amqps:// broker.example.com/queue1 DNS qualified address of a TCP/IP endpoint of an AMQP container with path for the queue1 AMQP node amqp:(london-branch-34)/atm Logical AMQP network address of london-branch-34 with path for the atm AMQP node amqps:// megabank.example.com/(london-branch-34)/atm DNS qualified address of a gateway into an AMQP network, with logical AMQP network address as suffix amqp:()/control Anonymous AMQP network address to be resolved into a container location by evaluating message metadata, with path for the control node on the resulting container somewhere Local container address of the something AMQP node $somewhere AMQP reserved local container address To start, I m splitting up the AMQP notion of container into two distinct concepts: gateway and container . A gateway is a TCP/IP listener that speaks the AMQP wire protocol. Clients establish connections and sessions with gateways. Gateways are onramps into AMQP networks. A container is a host for AMQP nodes. Multiple containers may be interrelated (and opportunistically interconnected) to form a logical network, with lookup mechanisms that allow resolving logical names to specific containers. Each container MUST have a gateway. Each configured relationship between containers holds information about which gateway ought to be used to reach the respective container. The configured destination gateway for any container MAY, however, be an intermediary, meaning it might take one or more further network resolution/routing steps to reach the destination container. Not all gateways have to be containers. A gateway can just do connection/session handling and never host nodes and/or take ownership of links; it might be a pure relay bridging sessions to another gateway. With the URI format, I am proposing a three-layer addressing model: With DNS/IP addressing in the ip-endpoint section, you pick an AMQP endpoint as gateway into an AMQP network. With container-name , you pick the AMQP container you want to communicate with via the chosen gateway. If omitted, the container is thought to be directly associated with this gateway (like today). If the container-name _expression_ is present but empty, it s up to the gateway rules/configuration to determine the destination container based on the message/link properties or other criteria. With node-path , you pick the AMQP node you want to route/link to inside the chosen/resolved container. With a message addressed to amqps:// megabank.example.com/(london-branch-34)/atm , a client first resolves the DNS name and IP address to some AMQP gateway instance via DNS and/or a load balancer, connects, and establishes a session or reuses an existing session to that gateway. Then, the client will either attempt to attach a link to (london-branch-34)/atm on the gateway-associated container, or identify an already existing link. Alternatively, it might attempt to route to said address via the container s anonymous terminus by using it in the properties:to property. How the (container-name) destination gets resolved is up to the container. In a simple case, a container might maintain a routing table with {container-name, gateway ip-endpoint} pairs, and will create/reuse connections/sessions to the listed gateways for routing/linking to the respective containers. The routing table may point to intermediary gateways. For link routing, the (container-name)/node-path _expression_ serves as the link target name in all containers acting as intermediaries. It resolves to node-path on the container that self-identifies as the given container-name. In effect, you can attach a link to (container-name)/node-path on any container on a network supporting global addressing, and the container will then patch that link through to the next hop network destination configured for that container name, and until it gets to the target container. For anonymous terminus routing, messages get routed along to the next container s anonymous terminus. The routing cookies spec then applies for how to establish reply routes. Thoughts?


  • 4.  Re: [amqp] Global addressing model - brain dump

    Posted 10-05-2018 13:34
    On Fri, Sep 14, 2018 at 6:04 AM Clemens Vasters < clemensv@microsoft.com > wrote: For the Management spec I also need the Addressing spec to make progress, so I m now taking a fresh look at this. From the F2Fs I recall that our biggest holdup was that we ve got tension between several distinct goals for addressing expressions: An address _expression_ should enable a client to find a server on an IP network to establish an AMQP TLS-first (5671) or TLS-upgrade (5672) connection, establish link(s) and transfer messages. The address _expression_ therefore needs to hold DNS/IP/TCP addressing information, a protocol selector, and a link target. An address _expression_ should enable a sender to have messages routed to a receiver inside a (yet poorly defined) AMQP network and fully abstracting the underlying IP layer, whereby the receiver address is a logical construct that doesn t contain network-related information. With such an address, it should be possible to find the receiving container (and node) by ways of: resolving the logical address to container name/location OR evaluating routing rules based on filter expressions that indirectly yield a container location An address _expression_ should enable a sender to route messages to a receiver inside a singular AMQP container, where address expressions correspond directly to node names inside of said container. We also have amqp/amqps URIs being used in the wild based on the current draft and I don t want to break those. Here s a proposal for an extended URI format that aims to hit all the goals at once: { amqp amqps } : [ //user:key@ip-endpoint/ ] [ (container-name)/ ] [ [ $ ] node-path ] I ll start the explanation with examples, because they ll probably tell a whole lot of the story already: amqps:// broker.example.com/queue1 DNS qualified address of a TCP/IP endpoint of an AMQP container with path for the queue1 AMQP node amqp:(london-branch-34)/atm Logical AMQP network address of london-branch-34 with path for the atm AMQP node amqps:// megabank.example.com/(london-branch-34)/atm DNS qualified address of a gateway into an AMQP network, with logical AMQP network address as suffix amqp:()/control Anonymous AMQP network address to be resolved into a container location by evaluating message metadata, with path for the control node on the resulting container somewhere Local container address of the something AMQP node $somewhere AMQP reserved local container address To start, I m splitting up the AMQP notion of container into two distinct concepts: gateway and container . A gateway is a TCP/IP listener that speaks the AMQP wire protocol. Clients establish connections and sessions with gateways. Gateways are onramps into AMQP networks. A container is a host for AMQP nodes. Multiple containers may be interrelated (and opportunistically interconnected) to form a logical network, with lookup mechanisms that allow resolving logical names to specific containers. Each container MUST have a gateway. Each configured relationship between containers holds information about which gateway ought to be used to reach the respective container. The configured destination gateway for any container MAY, however, be an intermediary, meaning it might take one or more further network resolution/routing steps to reach the destination container. Not all gateways have to be containers. A gateway can just do connection/session handling and never host nodes and/or take ownership of links; it might be a pure relay bridging sessions to another gateway. If an endpoint is connected to a gateway that is not a container, what will the container-id field in the OPEN frame hold? With the URI format, I am proposing a three-layer addressing model: With DNS/IP addressing in the ip-endpoint section, you pick an AMQP endpoint as gateway into an AMQP network. With container-name , you pick the AMQP container you want to communicate with via the chosen gateway. If omitted, the container is thought to be directly associated with this gateway (like today). If the container-name _expression_ is present but empty, it s up to the gateway rules/configuration to determine the destination container based on the message/link properties or other criteria. With node-path , you pick the AMQP node you want to route/link to inside the chosen/resolved container. With a message addressed to amqps:// megabank.example.com/(london-branch-34)/atm , a client first resolves the DNS name and IP address to some AMQP gateway instance via DNS and/or a load balancer, connects, and establishes a session or reuses an existing session to that gateway. Then, the client will either attempt to attach a link to (london-branch-34)/atm on the gateway-associated container, or identify an already existing link. Alternatively, it might attempt to route to said address via the container s anonymous terminus by using it in the properties:to property. How the (container-name) destination gets resolved is up to the container. In a simple case, a container might maintain a routing table with {container-name, gateway ip-endpoint} pairs, and will create/reuse connections/sessions to the listed gateways for routing/linking to the respective containers. The routing table may point to intermediary gateways. For link routing, the (container-name)/node-path _expression_ serves as the link target name in all containers acting as intermediaries. It resolves to node-path on the container that self-identifies as the given container-name. In effect, you can attach a link to (container-name)/node-path on any container on a network supporting global addressing, and the container will then patch that link through to the next hop network destination configured for that container name, and until it gets to the target container. For anonymous terminus routing, messages get routed along to the next container s anonymous terminus. The routing cookies spec then applies for how to establish reply routes. Thoughts?


  • 5.  Re: [amqp] Global addressing model - brain dump

    Posted 10-05-2018 14:00
    On Fri, 5 Oct 2018 at 15:33, Ted Ross < tross@redhat.com > wrote: On Fri, Sep 14, 2018 at 6:04 AM Clemens Vasters < clemensv@microsoft.com > wrote: For the Management spec I also need the Addressing spec to make progress, so I m now taking a fresh look at this. From the F2Fs I recall that our biggest holdup was that we ve got tension between several distinct goals for addressing expressions: An address _expression_ should enable a client to find a server on an IP network to establish an AMQP TLS-first (5671) or TLS-upgrade (5672) connection, establish link(s) and transfer messages. The address _expression_ therefore needs to hold DNS/IP/TCP addressing information, a protocol selector, and a link target. An address _expression_ should enable a sender to have messages routed to a receiver inside a (yet poorly defined) AMQP network and fully abstracting the underlying IP layer, whereby the receiver address is a logical construct that doesn t contain network-related information. With such an address, it should be possible to find the receiving container (and node) by ways of: resolving the logical address to container name/location OR evaluating routing rules based on filter expressions that indirectly yield a container location An address _expression_ should enable a sender to route messages to a receiver inside a singular AMQP container, where address expressions correspond directly to node names inside of said container. We also have amqp/amqps URIs being used in the wild based on the current draft and I don t want to break those. Here s a proposal for an extended URI format that aims to hit all the goals at once: { amqp amqps } : [ //user:key@ip-endpoint/ ] [ (container-name)/ ] [ [ $ ] node-path ] I ll start the explanation with examples, because they ll probably tell a whole lot of the story already: amqps:// broker.example.com/queue1 DNS qualified address of a TCP/IP endpoint of an AMQP container with path for the queue1 AMQP node amqp:(london-branch-34)/atm Logical AMQP network address of london-branch-34 with path for the atm AMQP node amqps:// megabank.example.com/(london-branch-34)/atm DNS qualified address of a gateway into an AMQP network, with logical AMQP network address as suffix amqp:()/control Anonymous AMQP network address to be resolved into a container location by evaluating message metadata, with path for the control node on the resulting container somewhere Local container address of the something AMQP node $somewhere AMQP reserved local container address To start, I m splitting up the AMQP notion of container into two distinct concepts: gateway and container . A gateway is a TCP/IP listener that speaks the AMQP wire protocol. Clients establish connections and sessions with gateways. Gateways are onramps into AMQP networks. A container is a host for AMQP nodes. Multiple containers may be interrelated (and opportunistically interconnected) to form a logical network, with lookup mechanisms that allow resolving logical names to specific containers. Each container MUST have a gateway. Each configured relationship between containers holds information about which gateway ought to be used to reach the respective container. The configured destination gateway for any container MAY, however, be an intermediary, meaning it might take one or more further network resolution/routing steps to reach the destination container. Not all gateways have to be containers. A gateway can just do connection/session handling and never host nodes and/or take ownership of links; it might be a pure relay bridging sessions to another gateway. If an endpoint is connected to a gateway that is not a container, what will the container-id field in the OPEN frame hold? With the URI format, I am proposing a three-layer addressing model: With DNS/IP addressing in the ip-endpoint section, you pick an AMQP endpoint as gateway into an AMQP network. With container-name , you pick the AMQP container you want to communicate with via the chosen gateway. If omitted, the container is thought to be directly associated with this gateway (like today). If the container-name _expression_ is present but empty, it s up to the gateway rules/configuration to determine the destination container based on the message/link properties or other criteria. With node-path , you pick the AMQP node you want to route/link to inside the chosen/resolved container. With a message addressed to amqps:// megabank.example.com/(london-branch-34)/atm , a client first resolves the DNS name and IP address to some AMQP gateway instance via DNS and/or a load balancer, connects, and establishes a session or reuses an existing session to that gateway. Then, the client will either attempt to attach a link to (london-branch-34)/atm on the gateway-associated container, or identify an already existing link. Alternatively, it might attempt to route to said address via the container s anonymous terminus by using it in the properties:to property. How the (container-name) destination gets resolved is up to the container. In a simple case, a container might maintain a routing table with {container-name, gateway ip-endpoint} pairs, and will create/reuse connections/sessions to the listed gateways for routing/linking to the respective containers. The routing table may point to intermediary gateways. For link routing, the (container-name)/node-path _expression_ serves as the link target name in all containers acting as intermediaries. It resolves to node-path on the container that self-identifies as the given container-name. In effect, you can attach a link to (container-name)/node-path on any container on a network supporting global addressing, and the container will then patch that link through to the next hop network destination configured for that container name, and until it gets to the target container. For anonymous terminus routing, messages get routed along to the next container s anonymous terminus. The routing cookies spec then applies for how to establish reply routes. Thoughts? Stepping back for a second - where is this definition of 'address' meant to apply - is this form expected in the 'to' and 'reply-to' fields in a message, in the address field in source and target? Also as written the format appears to require always providing a user:key when specifying the ip endpoint as well as the amqp: or amqps: prefix (whereas they are omitted in some of the examples) -- Rob -- ______________________________ ______________________________ _________________ Red Hat GmbH, www.de.redhat.com , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill


  • 6.  Re: [amqp] Global addressing model - brain dump

    Posted 10-05-2018 14:02
    On Fri, Oct 5, 2018 at 9:33 AM Ted Ross < tross@redhat.com > wrote: On Fri, Sep 14, 2018 at 6:04 AM Clemens Vasters < clemensv@microsoft.com > wrote: For the Management spec I also need the Addressing spec to make progress, so I m now taking a fresh look at this. From the F2Fs I recall that our biggest holdup was that we ve got tension between several distinct goals for addressing expressions: An address _expression_ should enable a client to find a server on an IP network to establish an AMQP TLS-first (5671) or TLS-upgrade (5672) connection, establish link(s) and transfer messages. The address _expression_ therefore needs to hold DNS/IP/TCP addressing information, a protocol selector, and a link target. An address _expression_ should enable a sender to have messages routed to a receiver inside a (yet poorly defined) AMQP network and fully abstracting the underlying IP layer, whereby the receiver address is a logical construct that doesn t contain network-related information. With such an address, it should be possible to find the receiving container (and node) by ways of: resolving the logical address to container name/location OR evaluating routing rules based on filter expressions that indirectly yield a container location An address _expression_ should enable a sender to route messages to a receiver inside a singular AMQP container, where address expressions correspond directly to node names inside of said container. We also have amqp/amqps URIs being used in the wild based on the current draft and I don t want to break those. Here s a proposal for an extended URI format that aims to hit all the goals at once: { amqp amqps } : [ //user:key@ip-endpoint/ ] [ (container-name)/ ] [ [ $ ] node-path ] I ll start the explanation with examples, because they ll probably tell a whole lot of the story already: amqps:// broker.example.com/queue1 DNS qualified address of a TCP/IP endpoint of an AMQP container with path for the queue1 AMQP node amqp:(london-branch-34)/atm Logical AMQP network address of london-branch-34 with path for the atm AMQP node amqps:// megabank.example.com/(london-branch-34)/atm DNS qualified address of a gateway into an AMQP network, with logical AMQP network address as suffix amqp:()/control Anonymous AMQP network address to be resolved into a container location by evaluating message metadata, with path for the control node on the resulting container somewhere Local container address of the something AMQP node $somewhere AMQP reserved local container address To start, I m splitting up the AMQP notion of container into two distinct concepts: gateway and container . A gateway is a TCP/IP listener that speaks the AMQP wire protocol. Clients establish connections and sessions with gateways. Gateways are onramps into AMQP networks. A container is a host for AMQP nodes. Multiple containers may be interrelated (and opportunistically interconnected) to form a logical network, with lookup mechanisms that allow resolving logical names to specific containers. Each container MUST have a gateway. Each configured relationship between containers holds information about which gateway ought to be used to reach the respective container. The configured destination gateway for any container MAY, however, be an intermediary, meaning it might take one or more further network resolution/routing steps to reach the destination container. Not all gateways have to be containers. A gateway can just do connection/session handling and never host nodes and/or take ownership of links; it might be a pure relay bridging sessions to another gateway. If an endpoint is connected to a gateway that is not a container, what will the container-id field in the OPEN frame hold? A TCP router or an Envoy TCP proxy are examples of such a gateway - although without any AMQP-specific smarts. They tunnel an entire connection thru to an AMQP peer. I'm not sure how such a gateway could do more complex AMQP-specific routing (like redirecting sessions or links to multiple back-ends) without fabricating a container-id to the the inbound connection - in which case it would seem that it does have to be a container (or many containers)