amqp — archive

AW: [amqp] Addressing Model Blog Post

From: Clemens Vasters
To: [email protected]
Date: Thu, 08 Nov 2018 15:56:00 -0000

While the authority does not have to have a DNS mapping, that s the general assumption. If you want reach a place on an overlay network, you first need to be able to connect the edge of that overlay network and then route within that overlay network. Those are two address spaces. The goal of the URI construct is to be able to express both the edge address and address inside the overlay network in one address. If you just want the overlay network address, you use amqp:(scope)/foo Von: Alan Conway <[email protected]> Gesendet: Donnerstag, 8. November 2018 16:51 An: Clemens Vasters <[email protected]> Cc: Rob Godfrey <[email protected]>; oasis-amqp-list <[email protected]> Betreff: Re: [amqp] Addressing Model Blog Post I feel that the distinction between domain name and scope identifier is a hack. Why not follow internet tradition and make an AMQP address is a classic URI [amqp:][//authority][/path][?query] The authority (aka host) *is* the scope identifier. In an AMQP context (link or message to:/reply-to: address) we mandate dropping the redundant amqp[s]: prefix, which is pretty close to the last addressing draft I read. Introducing a new scope-id adds some flexibility, but also more complexity. Re-using the URI authority (aka DNS domain name, aka virtual host name) means we can re-use a lot more existing DNS, virtual host and URL technology that is already mature and well understood. A URI authority does not *have* to have a DNS IP mapping. If it does it is a connectable URL, if not it can still be used by apps that have a pre-existing connection to an AMQP router. Whether connectable or not, it can be used for AMQP-smart routing just like a separate scope-id could be. Virtual host names can be associated many-to-many with IP addresses, and once messages hit an AMQP router they can further be associated many-to-many with AMQP containers, on the same or different IP hosts. HTTP already does this. To bootstrap an application with amqp:// myhost.net/foo , the client connects to myhost.net and links to // myhost.net/foo for possible further routing, or to the relative address /foo if it is a direct connection to the final container (many existing AMQP apps will do this) For a non-connectable // myscope.net/foo , the client needs a pre-existing connection but the routing information is the same. I can't imagine any routing scenario where you don't have virtual host names to map your AMQP scope-ids flexibly to the proper IP "on-ramps". Also re-use of virtual host plays well with existing router apps (like Qpid Dispatch) which already use virtual host to effectively "fill in" missing scope/authority from "relative" addresses used by existing clients. In fact using a combination of AMQP URI authority and virtual host (if different) gives essentially your amqp://vhost/(authority)/ but without the awkward 2-stage UIR. On Thu, Nov 8, 2018 at 1:15 AM Clemens Vasters < [email protected] > wrote: This morning I don t like area anymore, either. Scope is good. (Oh how I hate naming things) Von: Alan Conway < [email protected] > Gesendet: Donnerstag, November 8, 2018 12:36 AM An: Clemens Vasters Cc: Rob Godfrey; oasis-amqp-list Betreff: Re: [amqp] Addressing Model Blog Post On Wed, Nov 7, 2018 at 6:59 AM Clemens Vasters < [email protected] > wrote: AMQP nodes and containers are introduced in the core AMQP specification. This specification introduces a further concept: areas. An area identifier is a string that follows DNS naming conventions. Area expressions are matching conditions that can be evaluated against area identifiers for routing or filtering. Area identifiers are used for routing messages or links across AMQP container boundaries, potentially with one or more containers acting as routing intermediaries. Instead of having to handle container-ids for all potential routing targets, routing intermediaries can evaluate area expressions to determine which container to direct the message to. An area identifier is a structured name that represents a logical routing target or source scope. The term area reflects that the addressed scope has further internal structure in form of nodes, and therefore an area never identifies a singular, specific target or source. While area identifiers follow DNS naming conventions, but they do not have to be registered in DNS and they don t have an associated IP address. They are just names describing logical scopes in a system, and the DNS-like structure helps expressing hierarchical relationships, structuring routing scopes from very broad to more scoped areas. While the identifier of a container MUST be unique and stable within an AMQP network, areas are more flexible. A container MAY have any number of associated area aliases. Reversely, an area alias MAY be associated with several containers. How about "scope identifier"? "area" doesn't really give me the idea of a namespace or name domain, and you used "scope" 5 times while explaining what "area" means.