You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Toralf Lund <to...@pgs.com> on 2011/08/16 17:16:27 UTC
Sender name vs address (C++ messaging API)
The QPid "messaging" API will allow me to create a sender by address,
but (only) look up existing senders by name - the
qpid::messaging::Session class has:
Sender createSender(const Address &address);
Sender createSender(const std::string &address);
Sender getSender(const std::string &name);
Can I make *any* assumptions about the name given an address? Is there a
way to look up a sender created earlier for an address? Or isn't this
supposed to be possible? In that case, what exactly is getSender() for?
I mean, I'm assuming name is given by Sender::getName(), but requiring a
Sender to allow the lookup sort of defeats the purpose of the whole
method. OK, you can could maintain an address-to-name map, but then it's
probably easier to store the Sender objects.
It seems like the name is quite simply identical to the address if
something simple like a queue name was passed on create, but I suspect
it's not quite that simple for more complex addresses...
- Toralf
This e-mail, including any attachments and response string, may contain proprietary information which is confidential and may be legally privileged. It is for the intended recipient only. If you are not the intended recipient or transmission error has misdirected this e-mail, please notify the author by return e-mail and delete this message and any attachment immediately. If you are not the intended recipient you must not use, disclose, distribute, forward, copy, print or rely on this e-mail in any way except as permitted by the author.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Sender name vs address (C++ messaging API)
Posted by Gordon Sim <gs...@redhat.com>.
On 08/18/2011 07:55 AM, Toralf Lund wrote:
> Gordon Sim wrote:
>> A 'link' is the logical association between a sender or receiver and
>> their target or source respectively. It a pathway along which messages
>> travel to or from some 'node'.
>
> Well, yes, that's what I've read, and I understand all the words, but I
> have no idea of what it really means... Perhaps the problem is that
> talking about "links" and "nodes" is completely misplaced in the context
> of AMQP, IMO. To me a link between nodes is something like a direct
> socket connection between applications running on two different
> computers, which is precisely what I'm trying to avoid by using AMQP.
> But that's a different discussion, of course... (And I know, the terms
> are from the AMQP crowd, not QPid developers.)
I think of a node as a rendezvous point through which producers and
consumers of messages coordinate. A link is then just the relationship
of my application process with that rendezvous, i.e. the desire to
publish or consume messages.
If a subscription is the desire to receive messages, there is an
analogous concept for publishing, i.e. a desire to send messages. I
don't know of any good term for that (a 'pubscription' perhaps :-), but
'link' is supposed to cover both of them. It is not intended to be tied
to any low level socket notions, merely a way to refer to inflows and
outflows of messages from my application process.
At least that's how I see it...
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Sender name vs address (C++ messaging API)
Posted by Toralf Lund <to...@pgs.com>.
Gordon Sim wrote:
> On 08/17/2011 07:44 AM, Toralf Lund wrote:
>
>> Gordon Sim wrote:
>>
>>> On 08/16/2011 04:16 PM, Toralf Lund wrote:
>>>
>>>> The QPid "messaging" API will allow me to create a sender by address,
>>>> but (only) look up existing senders by name - the
>>>> qpid::messaging::Session class has:
>>>>
>>>> Sender createSender(const Address &address);
>>>> Sender createSender(const std::string &address);
>>>> Sender getSender(const std::string &name);
>>>>
>>>> Can I make *any* assumptions about the name given an address? Is there a
>>>> way to look up a sender created earlier for an address? Or isn't this
>>>> supposed to be possible? In that case, what exactly is getSender() for?
>>>> I mean, I'm assuming name is given by Sender::getName(), but requiring a
>>>> Sender to allow the lookup sort of defeats the purpose of the whole
>>>> method. OK, you can could maintain an address-to-name map, but then it's
>>>> probably easier to store the Sender objects.
>>>>
>>>> It seems like the name is quite simply identical to the address if
>>>> something simple like a queue name was passed on create, but I suspect
>>>> it's not quite that simple for more complex addresses...
>>>>
>>> At present the C++ client will use the address name as the name for
>>> the sender or receiver where it can do so without ambiguity.
>>>
>>> If you create two senders (or two receivers) for the same address,
>>> then the second will have a numeric suffix added to the name to
>>> distinguish them.
>>>
>>> So e.g.
>>>
>>> Sender s1 = ssn.createSender("my-node");
>>> Sender s2 = ssn.createSender("my-node/my-subject");
>>>
>>> would result in s1 having name 'my-node', but s2 having name 'my-node_2'.
>>>
>> OK.
>>
>>> I would like to augment the logic to use the link name instead of the
>>> node name if explicitly specified in order to give more control where
>>> that is needed. Does that sound useful to you?
>>>
>> Uh, I must admit it is not entirely clear to me what a link name might
>> represent, but maybe...
>>
>
> A 'link' is the logical association between a sender or receiver and
> their target or source respectively. It a pathway along which messages
> travel to or from some 'node'.
>
Well, yes, that's what I've read, and I understand all the words, but I
have no idea of what it really means... Perhaps the problem is that
talking about "links" and "nodes" is completely misplaced in the context
of AMQP, IMO. To me a link between nodes is something like a direct
socket connection between applications running on two different
computers, which is precisely what I'm trying to avoid by using AMQP.
But that's a different discussion, of course... (And I know, the terms
are from the AMQP crowd, not QPid developers.)
>> What I'm looking for is a clear and consistent
>> way to distinguish senders in a case rather your example above, only I'd
>> use something more like:
>>
>> Sender s1 = ssn.createSender("my-node/my-subject");
>> Sender s2 = ssn.createSender("my-node/some-other-subject");
>>
>> using 'my-node' and 'my-node_2' for addressing might work, but is
>> obviously not ideal. Specifying an additional id of some kind would
>> probably be OK.
>>
>
> My initial thought was to use the link name. However on reflection that
> isn't really ideal either.
>
> What you really want is a way to give the senders a name of your own
> choosing *independent* of the address used (likewise for receivers).
>
> So either an overloaded createSender()/createReceiver() method that
> additionally took a name to use and/or a Sender::setName() to alter the
> name once you have created the sender. I think I prefer the former.
>
I agree.
- Toralf
This e-mail, including any attachments and response string, may contain proprietary information which is confidential and may be legally privileged. It is for the intended recipient only. If you are not the intended recipient or transmission error has misdirected this e-mail, please notify the author by return e-mail and delete this message and any attachment immediately. If you are not the intended recipient you must not use, disclose, distribute, forward, copy, print or rely on this e-mail in any way except as permitted by the author.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Sender name vs address (C++ messaging API)
Posted by Gordon Sim <gs...@redhat.com>.
On 08/17/2011 07:44 AM, Toralf Lund wrote:
> Gordon Sim wrote:
>> On 08/16/2011 04:16 PM, Toralf Lund wrote:
>>> The QPid "messaging" API will allow me to create a sender by address,
>>> but (only) look up existing senders by name - the
>>> qpid::messaging::Session class has:
>>>
>>> Sender createSender(const Address &address);
>>> Sender createSender(const std::string &address);
>>> Sender getSender(const std::string &name);
>>>
>>> Can I make *any* assumptions about the name given an address? Is there a
>>> way to look up a sender created earlier for an address? Or isn't this
>>> supposed to be possible? In that case, what exactly is getSender() for?
>>> I mean, I'm assuming name is given by Sender::getName(), but requiring a
>>> Sender to allow the lookup sort of defeats the purpose of the whole
>>> method. OK, you can could maintain an address-to-name map, but then it's
>>> probably easier to store the Sender objects.
>>>
>>> It seems like the name is quite simply identical to the address if
>>> something simple like a queue name was passed on create, but I suspect
>>> it's not quite that simple for more complex addresses...
>>
>> At present the C++ client will use the address name as the name for
>> the sender or receiver where it can do so without ambiguity.
>>
>> If you create two senders (or two receivers) for the same address,
>> then the second will have a numeric suffix added to the name to
>> distinguish them.
>>
>> So e.g.
>>
>> Sender s1 = ssn.createSender("my-node");
>> Sender s2 = ssn.createSender("my-node/my-subject");
>>
>> would result in s1 having name 'my-node', but s2 having name 'my-node_2'.
> OK.
>> I would like to augment the logic to use the link name instead of the
>> node name if explicitly specified in order to give more control where
>> that is needed. Does that sound useful to you?
> Uh, I must admit it is not entirely clear to me what a link name might
> represent, but maybe...
A 'link' is the logical association between a sender or receiver and
their target or source respectively. It a pathway along which messages
travel to or from some 'node'.
> What I'm looking for is a clear and consistent
> way to distinguish senders in a case rather your example above, only I'd
> use something more like:
>
> Sender s1 = ssn.createSender("my-node/my-subject");
> Sender s2 = ssn.createSender("my-node/some-other-subject");
>
> using 'my-node' and 'my-node_2' for addressing might work, but is
> obviously not ideal. Specifying an additional id of some kind would
> probably be OK.
My initial thought was to use the link name. However on reflection that
isn't really ideal either.
What you really want is a way to give the senders a name of your own
choosing *independent* of the address used (likewise for receivers).
So either an overloaded createSender()/createReceiver() method that
additionally took a name to use and/or a Sender::setName() to alter the
name once you have created the sender. I think I prefer the former.
>
> Not that I'm sure I'll set up the senders that way in the final
> application - this is prototyping...
>
> - Toralf
>
>
>
> This e-mail, including any attachments and response string, may contain
> proprietary information which is confidential and may be legally
> privileged. It is for the intended recipient only. If you are not the
> intended recipient or transmission error has misdirected this e-mail,
> please notify the author by return e-mail and delete this message and
> any attachment immediately. If you are not the intended recipient you
> must not use, disclose, distribute, forward, copy, print or rely on this
> e-mail in any way except as permitted by the author.
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Sender name vs address (C++ messaging API)
Posted by Toralf Lund <to...@pgs.com>.
Gordon Sim wrote:
> On 08/16/2011 04:16 PM, Toralf Lund wrote:
>
>> The QPid "messaging" API will allow me to create a sender by address,
>> but (only) look up existing senders by name - the
>> qpid::messaging::Session class has:
>>
>> Sender createSender(const Address &address);
>> Sender createSender(const std::string &address);
>> Sender getSender(const std::string &name);
>>
>> Can I make *any* assumptions about the name given an address? Is there a
>> way to look up a sender created earlier for an address? Or isn't this
>> supposed to be possible? In that case, what exactly is getSender() for?
>> I mean, I'm assuming name is given by Sender::getName(), but requiring a
>> Sender to allow the lookup sort of defeats the purpose of the whole
>> method. OK, you can could maintain an address-to-name map, but then it's
>> probably easier to store the Sender objects.
>>
>> It seems like the name is quite simply identical to the address if
>> something simple like a queue name was passed on create, but I suspect
>> it's not quite that simple for more complex addresses...
>>
>
> At present the C++ client will use the address name as the name for the
> sender or receiver where it can do so without ambiguity.
>
> If you create two senders (or two receivers) for the same address, then
> the second will have a numeric suffix added to the name to distinguish them.
>
> So e.g.
>
> Sender s1 = ssn.createSender("my-node");
> Sender s2 = ssn.createSender("my-node/my-subject");
>
> would result in s1 having name 'my-node', but s2 having name 'my-node_2'.
>
OK.
> I would like to augment the logic to use the link name instead of the
> node name if explicitly specified in order to give more control where
> that is needed. Does that sound useful to you?
>
Uh, I must admit it is not entirely clear to me what a link name might
represent, but maybe... What I'm looking for is a clear and consistent
way to distinguish senders in a case rather your example above, only I'd
use something more like:
Sender s1 = ssn.createSender("my-node/my-subject");
Sender s2 = ssn.createSender("my-node/some-other-subject");
using 'my-node' and 'my-node_2' for addressing might work, but is
obviously not ideal. Specifying an additional id of some kind would
probably be OK.
Not that I'm sure I'll set up the senders that way in the final
application - this is prototyping...
- Toralf
This e-mail, including any attachments and response string, may contain proprietary information which is confidential and may be legally privileged. It is for the intended recipient only. If you are not the intended recipient or transmission error has misdirected this e-mail, please notify the author by return e-mail and delete this message and any attachment immediately. If you are not the intended recipient you must not use, disclose, distribute, forward, copy, print or rely on this e-mail in any way except as permitted by the author.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Sender name vs address (C++ messaging API)
Posted by Gordon Sim <gs...@redhat.com>.
On 08/16/2011 04:16 PM, Toralf Lund wrote:
> The QPid "messaging" API will allow me to create a sender by address,
> but (only) look up existing senders by name - the
> qpid::messaging::Session class has:
>
> Sender createSender(const Address &address);
> Sender createSender(const std::string &address);
> Sender getSender(const std::string &name);
>
> Can I make *any* assumptions about the name given an address? Is there a
> way to look up a sender created earlier for an address? Or isn't this
> supposed to be possible? In that case, what exactly is getSender() for?
> I mean, I'm assuming name is given by Sender::getName(), but requiring a
> Sender to allow the lookup sort of defeats the purpose of the whole
> method. OK, you can could maintain an address-to-name map, but then it's
> probably easier to store the Sender objects.
>
> It seems like the name is quite simply identical to the address if
> something simple like a queue name was passed on create, but I suspect
> it's not quite that simple for more complex addresses...
At present the C++ client will use the address name as the name for the
sender or receiver where it can do so without ambiguity.
If you create two senders (or two receivers) for the same address, then
the second will have a numeric suffix added to the name to distinguish them.
So e.g.
Sender s1 = ssn.createSender("my-node");
Sender s2 = ssn.createSender("my-node/my-subject");
would result in s1 having name 'my-node', but s2 having name 'my-node_2'.
I would like to augment the logic to use the link name instead of the
node name if explicitly specified in order to give more control where
that is needed. Does that sound useful to you?
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org