Specification question: attach with no source/target

["Darryl L. Pierce" <dp...@redhat.com>]

In reading through the AMQP 1.0 specification, I have some (probably
fundamental) questions about the spec. Specifically, what is purpose of
establishing a link on a session that has either no source or not
target (or neither source nor target) set? In the spec it says that such
links will never produce nor receive messages, respectively.

If such is the case, then how would such links be used? What purpose do
they serve?

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/

Re: Specification question: attach with no source/target

["Darryl L. Pierce" <dp...@redhat.com>]

On Mon, Apr 22, 2013 at 09:31:09AM -0400, Rafael Schloming wrote:
> To understand this, it's helpful to think in terms of which state is
> associated with the transport layer and which is associated with the
> application layer. It also helps to think in terms of communication
> endpoints, i.e. an entity capturing the relevant state for a given
> communication layer. The link construct exists at the transport layer, and
> at the transport layer, link establishment never fails. An attach is always
> answered by another attach, and paired set of link endpoints (both local
> and remote) are always created. The source and target serve as a binding
> between the application level communication endpoint and the transport
> layer endpoint. The reason this can be null is because there isn't always
> an application level endpoint.
> 
> 
> As a concrete example you might consider sending an attach from a client to
> a broker and naming a queue that does not exist:
> 
>    Client -------- ATTACH(target="no-such-queue") ---> Broker
> 
> The broker then responds with an attach where the target is null:
> 
>    Client <------- ATTACH(target=null) --------------- Broker
> 
> The client then compares the target he asked for ("non-existent-queue")
> with the target he got (null) and can indicate an error to the user.
> 
> This might seem like an odd way to fail link establishment, however it is
> really a special case of a more general negotiation pattern, for example
> the same pattern might be used to do a kind of redirect:
> 
>    Client -------- ATTACH(target="old-queue") -------> Broker
>    Client <------- ATTACH(target="new-queue") -------- Broker
> 
> There are also other properties of sources and targets that can be
> negotiated in this way, e.g. distrubtion mode, filters, general
> capabilities and/or properties. So the general pattern is link
> establishment always succeeds at the transport layer, however at the
> application layer you might not get exactly what you asked for, and if the
> remote target/source is indicated as null, then you didn't get anything at
> all.

Ah, I see how it's useful. It just seemed odd without the concrete
examples. Thanks!

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/

Re: Specification question: attach with no source/target

[Ted Ross <tr...@redhat.com>]

On 04/22/2013 09:31 AM, Rafael Schloming wrote:
> This might seem like an odd way to fail link establishment, however it is
> really a special case of a more general negotiation pattern, for example
> the same pattern might be used to do a kind of redirect:
>
>     Client -------- ATTACH(target="old-queue") -------> Broker
>     Client <------- ATTACH(target="new-queue") -------- Broker

How is this example different from the use of the dynamic flag?  Is the 
following use case valid?

     Client -------- ATTACH(target="something-general") -------> Broker
     Client <------- ATTACH(target="something-specific") -------- Broker

-Ted

Re: Specification question: attach with no source/target

[Rafael Schloming <rh...@alum.mit.edu>]

To understand this, it's helpful to think in terms of which state is
associated with the transport layer and which is associated with the
application layer. It also helps to think in terms of communication
endpoints, i.e. an entity capturing the relevant state for a given
communication layer. The link construct exists at the transport layer, and
at the transport layer, link establishment never fails. An attach is always
answered by another attach, and paired set of link endpoints (both local
and remote) are always created. The source and target serve as a binding
between the application level communication endpoint and the transport
layer endpoint. The reason this can be null is because there isn't always
an application level endpoint.


As a concrete example you might consider sending an attach from a client to
a broker and naming a queue that does not exist:

   Client -------- ATTACH(target="no-such-queue") ---> Broker

The broker then responds with an attach where the target is null:

   Client <------- ATTACH(target=null) --------------- Broker

The client then compares the target he asked for ("non-existent-queue")
with the target he got (null) and can indicate an error to the user.

This might seem like an odd way to fail link establishment, however it is
really a special case of a more general negotiation pattern, for example
the same pattern might be used to do a kind of redirect:

   Client -------- ATTACH(target="old-queue") -------> Broker
   Client <------- ATTACH(target="new-queue") -------- Broker

There are also other properties of sources and targets that can be
negotiated in this way, e.g. distrubtion mode, filters, general
capabilities and/or properties. So the general pattern is link
establishment always succeeds at the transport layer, however at the
application layer you might not get exactly what you asked for, and if the
remote target/source is indicated as null, then you didn't get anything at
all.

--Rafael


On Mon, Apr 22, 2013 at 8:35 AM, Darryl L. Pierce <dp...@redhat.com>wrote:

> In reading through the AMQP 1.0 specification, I have some (probably
> fundamental) questions about the spec. Specifically, what is purpose of
> establishing a link on a session that has either no source or not
> target (or neither source nor target) set? In the spec it says that such
> links will never produce nor receive messages, respectively.
>
> If such is the case, then how would such links be used? What purpose do
> they serve?
>
> --
> Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
> Delivering value year after year.
> Red Hat ranks #1 in value among software vendors.
> http://www.redhat.com/promo/vendor/
>
>