I'm sure others with more detailed knowledge of the background would be able to give a better answer, but in short I think the thing that you need to bear in mind is that proton Messenger is a *Message* oriented API as opposed to a *Connection* oriented API, so for example compare the approach taken with Messenger with say the qpid::messaging API and JMS which are both Connection oriented APIs (where you specify Connection, Session etc.).

Messenger is supposed to abstract the (client) user from needing to care about such things, so you specify the address that you want to send a Message to in the Message and let Messenger take care of the Connection and Session stuff. Of course for receiving messages Messenger does connect to the address given via pn_messenger_subscribe (though I'm not sure myself if it is on this call or the pn_messenger_recv call where the connection actually happens).

I guess that both approaches have their own relative advantages and disadvantages and TBH I'm generally more familiar with the Connection oriented APIs myself.

I think that you will likely just have to live with it, or if you can't then build your higher level API on top of qpid::messenger (which uses Proton engine under the hood when AMQP 1.0 is enabled) or build directly using the proton *Engine* API vice the Messenger API, though that'll take a bit more effort and energy and you'd likely want to look at the qpid::messaging implementation or the dispatch router code for how to talk engine directly (I've never braved using engine directly myself).

Sorry it's probably not the answer you were looking for.

Regards,
Frase


On 22/04/14 07:49, Chris White1 wrote:
Hi

I'm part of the IBM team developing MQ Light (
https://www.ibmdw.net/messaging/mq-light/) and we are implementing our
client API using the AMQP Messenger C API. Our client API has a connect
function, which is required  to be invoked before sending or receiving
messages. The AMQP Messager C API does not seem to have an API function to
perform a connect, without sending a message or subscribing to receive
messages.

Looking at the messenger.c source code I found that function
pn_messenger_resolve appears to give the connect behaviour we require. So
could the pn_messenger_resolve be added to the API please (maybe with a
different name, say: pn_messenger_connect, which seems more intuitive)?

I was thinking that the pn_messenger_start function should eventually be
doing the connect, but that does not take an address argument, so is
probably not appropriate.

I would also be interested in others opinions about this, as it may seem
to be a strange thing to want to do, i.e. why would you want to connect if
you're not going to send or receive messages?  A use case for this could
be that a server wants to be aware of active clients communicating with it
before they are ready to send or receive messages. Also a connect function
enables a client to determine if a server is available before exchanging
data with it.

Thanks
Chris

--------------------------------------------------------------------------
Chris White
MP 211
IBM United Kingdom Limited
Hursley Park
Winchester , England
SO21 2JN

Tel:  +44 (0)1962 818209 (Ext) or 37248209 (Int)
E-mail: [email protected]
--------------------------------------------------------------------------
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Reply via email to