I want to make a car on the road addressable (that is conceptually the target container) and then use the node structure to allow for addressing different aspects of that car. The car is roaming across a wild mix of 3G/4G/5G networks including
international roaming and never has a stable IP address. So Iâll give the car a rendezvous point in its general proximity that acts as a proxy and from where it can pick up messages (that is the container that actually gets routed to) as the car gets back
on the network, and that rendezvous point may shift.
When I want to send messages to that car, I connect to the edge of the car overlay network, find a path to whatever the right target container is (how that happens is indeed out of scope) and then direct messages to the nodes in that container.
I need a name for the onramp, a name for the car whereby itâs obscured whether thatâs the actual car or just a container acting as an intermediary for it, and a name for the map service in the car.
Von: Alan Conway <aconway@redhat.com>
Gesendet: Donnerstag, 8. November 2018 18:01
An: Clemens Vasters <clemensv@microsoft.com>
Cc: Rob Godfrey <rgodfrey@redhat.com>; oasis-amqp-list <amqp@lists.oasis-open.org>
Betreff: Re: [amqp] Addressing Model Blog Post
We canât just use the path because we really have three addressing realms:
-
IP network space
-
Inter-Container overlay network
-
Intra-Container node space
I don't think we do have 3 addressable realms - the structure of the inter-container network should not appear in user addresses.
Consider the IP analogy: I can connect to an IP address x, may packets carry only the address x. My packets pass through many IP routers, which have their own IP addresses, but I know *nothing* about them, in fact they may change during
the course of a single connection. It's up to the routers to decide "who's next" for a given address, it's not up to me to choose the route in my IP address.
Of course if your implementation wants to start every path with"(scope)" I've got no problem with that, but I don't think we need to force that convention on everyone. For example, dispatch router is configured with routing rules that
match arbitrary path prefixes and patterns, there's no need for special syntax.
The node space (the path) is something we canât futz with for backcompat reasons if nothing else.
Von: Alan Conway <aconway@redhat.com>
Gesendet: Donnerstag, 8. November 2018 17:29
An: Clemens Vasters <clemensv@microsoft.com>
Cc: Rob Godfrey <rgodfrey@redhat.com>; oasis-amqp-list <amqp@lists.oasis-open.org>
Betreff: Re: [amqp] Addressing Model Blog Post
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
OK I buy that, but I'm starting to feel that inventing something we can't name is a Hint from the Universe.
The URI framework already has a way to specify hierarchical scopes that are not part of the authority - the path.
Why is "amqp://foo.net/(a.b)/c/d"
preferable to "amqp://foo.net/a/b/c/d?
The former does not provide any information that clients can use, it is harder to construct/parse and it seems to imply knowledge of the internal routing of messages that clients really should not have. If (scope) is not an authority, a host name, or a container
ID, then it is simply part of a hierarchical string to be interpreted by AMQP entities, it has no special meaning that deserves special syntax. If you restructure your application something that was (a.b)/c might end up more like (a)/b/c or (a.b.c) - better
to expose an unchanging "a/b/c" to clients.
Von: Alan Conway <aconway@redhat.com>
Gesendet: Donnerstag, 8. November 2018 16:51
An: Clemens Vasters <clemensv@microsoft.com>
Cc: Rob Godfrey <rgodfrey@redhat.com>; oasis-amqp-list <amqp@lists.oasis-open.org>
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.
This morning I donât like âareaâ anymore, either. Scope is good.
(Oh how I hate naming things)
Von: Alan Conway <aconway@redhat.com>
Gesendet: Donnerstag, November 8, 2018 12:36 AM
An: Clemens Vasters
Cc: Rob Godfrey; oasis-amqp-list
Betreff: Re: [amqp] Addressing Model Blog Post
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.
|