amqp — archive

[Ted Ross]

In reference to the AMQP Addressing Spec. v1.0 (wd01): ===== In the opening paragraph of section 3 (Addresses), the fields in which addresses have formal meaning are listed ({target,source}.address, to).  Shouldn't the reply-to field of the message properties be listed here as well? ===== Section 4.5 (Dynamic Routes) - I've read this a dozen times and I still don't know what the intent is.  What is meant by advertise ?  When source or target is mentioned, does this refer to local and or remote termini?  Is this simply a way of saying that a receiver may register its address with the peer? ===== Section 6.5 (Request/Response) - This needs some work. The issue here really comes down to: What does the requester put into the reply-to field, and How does the reply message get routed back to the requester. I claim that the reply-to address must not be generated by the requester.  This is for two reasons: The server endpoint may be processing requests from many different clients.  If the clients are generating reply addresses, they need to use some mechanism by which to guarantee that each address is unique.  If they are not unique, the response messages will likely be misdirected. In the case of a large network of intermediaries, there is likely to be a delay between the generation of the address and its propagation (by an unspecified mechanism) across the network.  This delay will be tacked onto the request/response latency. If the next-hop node upstream from the client/requester were to generate the reply address, both of the above problems would be avoided.  A server node, if connected to directly, can easily generate small and unique addresses for its connected clients.  A network access node (the node attached to by the client) can provide an address that is a-priori routable (i.e. its own address with a discriminator added) thus removing the need to propagate information across a network. I further claim that in the simple point-to-point case (no intermediary), the fact that the server assigns the reply-to addresses for its clients does _not_ constitute broker functionality and does not involve the creation of a temporary queue. I'm sure that my above claims will be debated.  However, if we agree that they have merit, we need a mechanism by which to convey the information from access-node/server to client.  The link-attach command has a dynamic field that can be used to signal that the target of an outgoing link needs to be assigned by the sending terminus.  This would allow a client to create a listening link to dynamic and wait for the peer to set the target address in the returning attach frame.  This address could then be used as a reply-to for any requests sent to the same container. Thoughts? Regards, -Ted