You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Tobias Duckworth <th...@gmail.com> on 2016/07/08 16:26:43 UTC
qpid-proton 0.12.2 connection_engine and ssl
Hi,
I've used qpid-proton-0.12.2 in my application as a connection_engine or
io::socket_engine. I need to arrange for the connect and reading/writing
to happen asynchronously and my implementation sits within an existing
io framework.
Everything has integrated quite nicely, apart from SSL, which I cannot
get to work.
I have some straightforward C++ examples, one of which derives from
connection_engine, and the other from container. I can see that for the
container example ssl_init gets called from connection_options.cpp and
everything then works nicely, whereas for the connection_engine example
it does not.
The problem seems to be that for the connection_engine build 'outbound'
is not set, and therefore ssl_init does not get called.
Please could someone explain how to implement an amqp client using the
connection_engine framework that supports SSL?
Many thanks,
Toby
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: qpid-proton 0.12.2 connection_engine and ssl
Posted by Alan Conway <ac...@redhat.com>.
On Wed, 2016-07-20 at 08:00 -0700, Tobias Duckworth wrote:
> The proton::value conversions are pretty comprehensive actually, I'm
> not sure
> I need any more than it already caters for.
>
> However, since a common use case might be converting to a string
> (even if
> just for debug purposes), I think a conversion to an empty string by
> means
> of an additional function that doesn't throw an exception would be
> nice to
> have.
I just added proton::to_string(value) (also takes scalar or url) that
does exactly that. It's just a wrapper for ostream << but it's a handy
wrapper - same idea as std::to_string. Also I made an empty scalar or
value print as "" instead of "<null>". On reflection that seems more
consistent with C++ practice - e.g. an empty std::string prints as "",
not "<empty-string>".
The strings are mostly intended just to be readable. The string reps
for scalar types (or values containing a scalar type) are identical to
their normal ostream operator<< so compatible with istream operator>>,
but complex types use a python-esque syntax which you should not try to
parse or use for anything but debugging.
Cheers,
Alan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: qpid-proton 0.12.2 connection_engine and ssl
Posted by Tobias Duckworth <to...@duckworth.uk.com>.
The proton::value conversions are pretty comprehensive actually, I'm not sure
I need any more than it already caters for.
However, since a common use case might be converting to a string (even if
just for debug purposes), I think a conversion to an empty string by means
of an additional function that doesn't throw an exception would be nice to
have.
For now just checking whether the proton::value is empty or not suffices
though :-)
Toby
--
View this message in context: http://qpid.2158936.n2.nabble.com/qpid-proton-0-12-2-connection-engine-and-ssl-tp7647090p7647952.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: qpid-proton 0.12.2 connection_engine and ssl
Posted by Alan Conway <ac...@redhat.com>.
On Wed, 2016-07-20 at 04:31 -0700, Tobias Duckworth wrote:
> The decode::no_more_data problem...
>
> The body of the message is empty, why not just return an empty
> string?
>
> I can work around this by doing a proton::value body =
> message.body(); if
> (!body.empty())
>
> But seems a bit hardcore to throw an exception, just saying.
> I do understand that string is an easy example, and perhaps the
> conversion
> to an integer is less obvious.
>
This is the AMQP/C++ data conversion layer. I aimed at making it more
"type safe" in the spirit of C++ than the conversions in python. I also
wanted to make it possible to interrogate and construct exact on-the-
wire AMQP types, as well as doing easy "obvious" conversions to/from
native C++ types.
Note you can do ostream << value to get a printable string, but for an
empty value that will give you "<null>" not "".
In 0.13, the get and as_(), as_int() functions been deprecated in
favour of these more general templates:
value v;
// throw unless v contains exactly the AMQP type corresponding to T
proton::get<T>(v);�
// ok if v contains any type that std::is_convertible to T.
proton::coerce<T>(v);�
What other kinds of conversions would you like to see? We could easily
add a proton::to_string() to return the printable string, I could
perhaps be convinced that the printable string for an empty value
should be "".
Thanks,
Alan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: qpid-proton 0.12.2 connection_engine and ssl
Posted by Tobias Duckworth <to...@duckworth.uk.com>.
The decode::no_more_data problem...
The body of the message is empty, why not just return an empty string?
I can work around this by doing a proton::value body = message.body(); if
(!body.empty())
But seems a bit hardcore to throw an exception, just saying.
I do understand that string is an easy example, and perhaps the conversion
to an integer is less obvious.
Toby
--
View this message in context: http://qpid.2158936.n2.nabble.com/qpid-proton-0-12-2-connection-engine-and-ssl-tp7647090p7647931.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: qpid-proton 0.12.2 connection_engine and ssl
Posted by Robbie Gemmell <ro...@gmail.com>.
Some more comparative traces may (or may not) help folks advise,
possibly even some example code to go with it.
On 20 July 2016 at 11:34, Tobias Duckworth <to...@duckworth.uk.com> wrote:
> Yes, so just to clarify...
>
> Azure is sending a response to my message authenticating with the hub, and
> the behaviour is different between the reactor/messenger build and
> connection_engine. Not sure why.
>
> In the reactor build, I'm able to convert the message body to a string and
> print it out, whereas in the connection_engine build this causes a
> decode_error:
>
> terminate called after throwing an instance of 'proton::decode_error'
> what(): decode: no more data
> Aborted (core dumped)
>
> Any ideas about why the behaviour here might differ?
>
>
>
>
> --
> View this message in context: http://qpid.2158936.n2.nabble.com/qpid-proton-0-12-2-connection-engine-and-ssl-tp7647090p7647928.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: qpid-proton 0.12.2 connection_engine and ssl
Posted by Tobias Duckworth <to...@duckworth.uk.com>.
Yes, so just to clarify...
Azure is sending a response to my message authenticating with the hub, and
the behaviour is different between the reactor/messenger build and
connection_engine. Not sure why.
In the reactor build, I'm able to convert the message body to a string and
print it out, whereas in the connection_engine build this causes a
decode_error:
terminate called after throwing an instance of 'proton::decode_error'
what(): decode: no more data
Aborted (core dumped)
Any ideas about why the behaviour here might differ?
--
View this message in context: http://qpid.2158936.n2.nabble.com/qpid-proton-0-12-2-connection-engine-and-ssl-tp7647090p7647928.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: qpid-proton 0.12.2 connection_engine and ssl
Posted by Alan Conway <ac...@redhat.com>.
On Wed, 2016-07-20 at 01:49 -0700, Tobias Duckworth wrote:
> Thanks for the hint guys.
>
> This was indeed the problem.
>
> I was able to solve it by simply calling
> connection().host(<HostName>) in
> the on_start() function.
>
> One or two other things did not behave quite how I was expecting, for
> example in the on_message() function I was dumping out the body of
> the
> message as a string, and this was causing a decode:no_more_data
> problem,
> which terminated my program. This doesn't happen in the reactor
> build, so
> not sure what's going on there.
>
> Anyway, the good news is that I am now able to authenticate with
> Azure and
> send messages back and forth to an IoTHub device.
>
> So it's all working now.
> Many thanks for your help,
> Toby
>
>�
Thanks for persevering, I've made a note to address/test this in doc,
examples etc. for using SSL. If you have a chance to look at the 0.13
connection engine interface I'd like to know your thoughts. The
socket_engine is gone in 0.13 but I may bring it back if the raw
connection_engine is too much work for projects like yours.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: qpid-proton 0.12.2 connection_engine and ssl
Posted by Tobias Duckworth <to...@duckworth.uk.com>.
Thanks for the hint guys.
This was indeed the problem.
I was able to solve it by simply calling connection().host(<HostName>) in
the on_start() function.
One or two other things did not behave quite how I was expecting, for
example in the on_message() function I was dumping out the body of the
message as a string, and this was causing a decode:no_more_data problem,
which terminated my program. This doesn't happen in the reactor build, so
not sure what's going on there.
Anyway, the good news is that I am now able to authenticate with Azure and
send messages back and forth to an IoTHub device.
So it's all working now.
Many thanks for your help,
Toby
--
View this message in context: http://qpid.2158936.n2.nabble.com/qpid-proton-0-12-2-connection-engine-and-ssl-tp7647090p7647917.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: qpid-proton 0.12.2 connection_engine and ssl
Posted by Tobias Duckworth <to...@duckworth.uk.com>.
Here's the JIRA with the wireshark traces attached...
https://issues.apache.org/jira/browse/PROTON-1261
Thanks,
Toby
--
View this message in context: http://qpid.2158936.n2.nabble.com/qpid-proton-0-12-2-connection-engine-and-ssl-tp7647090p7647888.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: qpid-proton 0.12.2 connection_engine and ssl
Posted by Tobias Duckworth <to...@duckworth.uk.com>.
Here are the same traces for the working scenario - Connecting to Azure using
qpid-proton reactor/messenger and opening a session, sender, and receiver...
URL hub = amqps://TWDIoTHub.azure-devices.net:5671
on_start
[0x23c2280]: -> AMQP
[0x23c2280]:0 -> @open(16)
[container-id="aa950979-10ce-436b-842b-65409350b729",
hostname="TWDIoTHub.azure-devices.net:5671", channel-max=32767]
[0x23c2280]: <- AMQP
[0x23c2280]:0 <- @open(16)
[container-id="DeviceGateway_33ad1677df724b8a8dbe3acf05ad349b",
hostname="10.0.4.51", max-frame-size=65536, channel-max=8191,
idle-time-out=240000]
on_connection_open
[0x23c2280]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=2147483647]
[0x23c2280]:0 -> @attach(18) [name="1/1", handle=0, role=true,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="$cbs",
durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0,
timeout=0, dynamic=false], initial-delivery-count=0]
[0x23c2280]:0 -> @attach(18) [name="1/2", handle=1, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0,
timeout=0, dynamic=false], target=@target(41) [address="$cbs", durable=0,
timeout=0, dynamic=false], initial-delivery-count=0]
[0x23c2280]:0 -> @flow(19) [incoming-window=2147483647, next-outgoing-id=0,
outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=10,
drain=false]
[0x23c2280]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=1,
incoming-window=5000, outgoing-window=5000, handle-max=262143]
on_session_open
[0x23c2280]:0 <- @attach(18) [name="1/2", handle=1, role=true,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0,
timeout=0, dynamic=false], target=@target(41) [address="$cbs", durable=0,
timeout=0, dynamic=false], max-message-size=1048576]
[0x23c2280]:0 <- @flow(19) [next-incoming-id=0, incoming-window=5000,
next-outgoing-id=1, outgoing-window=2147483646, handle=1, delivery-count=0,
link-credit=100, available=0, echo=false]
[0x23c2280]:0 <- @attach(18) [name="1/1", handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="$cbs",
durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0,
timeout=0, dynamic=false], initial-delivery-count=0,
max-message-size=1048576]
--
View this message in context: http://qpid.2158936.n2.nabble.com/qpid-proton-0-12-2-connection-engine-and-ssl-tp7647090p7647884.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: qpid-proton 0.12.2 connection_engine and ssl
Posted by Alan Conway <ac...@redhat.com>.
On Tue, 2016-07-19 at 16:50 -0400, Alan Conway wrote:
> On Tue, 2016-07-19 at 17:36 +0100, Gordon Sim wrote:
> >
> > On 19/07/16 10:58, Tobias Duckworth wrote:
> > >
> > >
> > > Thanks, wasn't aware of PN_TRACE_FRM, here's some output from
> > > connecting to
> > > Azure and attempting to open a receiver then sender with that
> > > tracing
> > > enabled:
> > >
> > > Address: https://TWDIoTHub.azure-devices.net:5671
> > > [0x6dd470]:��-> AMQP
> > >
> > > on_start
> > > [0x6dd470]:0 -> @open(16)
> > > [container-id="77e8331f-ca64-4b22-8200-311024ede12d", channel-
> > > max=32767]
> >
> > I think perhaps the missing hostname is the issue? In the trace
> > that�
> > works you have:
> >
> > �> on_start
> > �> [0x23c2280]:��-> AMQP
> > �> [0x23c2280]:0 -> @open(16)
> > �> [container-id="aa950979-10ce-436b-842b-65409350b729",
> > �> hostname="TWDIoTHub.azure-devices.net:5671", channel-max=32767]
> >
> > The error looks like some sort of null pointer issue, perhaps when�
> > looking up the node for the link, using the hostname as context?
> >
> > >
> > >
> > > [0x6dd470]:0 <- @detach(22) [handle=0, closed=true, error=@error(
> > > 29
> > > )
> > > [condition=:"amqp:internal-error", description="Object reference
> > > not set to
> > > an instance of an object.",
> > > info={:exception="System.NullReferenceException:
> > > Object reference not set to an instance of an
> > > object.\x0d\x0a\x0d\x0aServer
> >
> > �
> That is very likely. The connection_engine doesn't fill in the
> hostname
> for you, the reactor's SSL code very likely does. If that's the case
> please put a comment on�https://issues.apache.org/jira/browse/PROTON-
> 12
> 55�so I'll fix that when I get to it.
>�
Forgot to say: if this is the problem, the workaround is to call�
� pn_connection_set_hostname(pn_connection_t *connection, const char
*hostname);
just after you call
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: qpid-proton 0.12.2 connection_engine and ssl
Posted by Alan Conway <ac...@redhat.com>.
On Tue, 2016-07-19 at 17:36 +0100, Gordon Sim wrote:
> On 19/07/16 10:58, Tobias Duckworth wrote:
> >
> > Thanks, wasn't aware of PN_TRACE_FRM, here's some output from
> > connecting to
> > Azure and attempting to open a receiver then sender with that
> > tracing
> > enabled:
> >
> > Address: https://TWDIoTHub.azure-devices.net:5671
> > [0x6dd470]:��-> AMQP
> >
> > on_start
> > [0x6dd470]:0 -> @open(16)
> > [container-id="77e8331f-ca64-4b22-8200-311024ede12d", channel-
> > max=32767]
>
> I think perhaps the missing hostname is the issue? In the trace that�
> works you have:
>
> �> on_start
> �> [0x23c2280]:��-> AMQP
> �> [0x23c2280]:0 -> @open(16)
> �> [container-id="aa950979-10ce-436b-842b-65409350b729",
> �> hostname="TWDIoTHub.azure-devices.net:5671", channel-max=32767]
>
> The error looks like some sort of null pointer issue, perhaps when�
> looking up the node for the link, using the hostname as context?
>
> >
> > [0x6dd470]:0 <- @detach(22) [handle=0, closed=true, error=@error(29
> > )
> > [condition=:"amqp:internal-error", description="Object reference
> > not set to
> > an instance of an object.",
> > info={:exception="System.NullReferenceException:
> > Object reference not set to an instance of an
> > object.\x0d\x0a\x0d\x0aServer
>
>�
That is very likely. The connection_engine doesn't fill in the hostname
for you, the reactor's SSL code very likely does. If that's the case
please put a comment on�https://issues.apache.org/jira/browse/PROTON-12
55�so I'll fix that when I get to it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: qpid-proton 0.12.2 connection_engine and ssl
Posted by Gordon Sim <gs...@redhat.com>.
On 19/07/16 10:58, Tobias Duckworth wrote:
> Thanks, wasn't aware of PN_TRACE_FRM, here's some output from connecting to
> Azure and attempting to open a receiver then sender with that tracing
> enabled:
>
> Address: https://TWDIoTHub.azure-devices.net:5671
> [0x6dd470]: -> AMQP
>
> on_start
> [0x6dd470]:0 -> @open(16)
> [container-id="77e8331f-ca64-4b22-8200-311024ede12d", channel-max=32767]
I think perhaps the missing hostname is the issue? In the trace that
works you have:
> on_start
> [0x23c2280]: -> AMQP
> [0x23c2280]:0 -> @open(16)
> [container-id="aa950979-10ce-436b-842b-65409350b729",
> hostname="TWDIoTHub.azure-devices.net:5671", channel-max=32767]
The error looks like some sort of null pointer issue, perhaps when
looking up the node for the link, using the hostname as context?
> [0x6dd470]:0 <- @detach(22) [handle=0, closed=true, error=@error(29)
> [condition=:"amqp:internal-error", description="Object reference not set to
> an instance of an object.", info={:exception="System.NullReferenceException:
> Object reference not set to an instance of an object.\x0d\x0a\x0d\x0aServer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: qpid-proton 0.12.2 connection_engine and ssl
Posted by Robbie Gemmell <ro...@gmail.com>.
Providing traces from the other (working) scenario as well would
likely be useful, by comparing the two it could be more obvious what
is upsetting the server.
Robbie
On 19 July 2016 at 10:58, Tobias Duckworth <to...@duckworth.uk.com> wrote:
> Thanks, wasn't aware of PN_TRACE_FRM, here's some output from connecting to
> Azure and attempting to open a receiver then sender with that tracing
> enabled:
>
> Address: https://TWDIoTHub.azure-devices.net:5671
> [0x6dd470]: -> AMQP
>
> on_start
> [0x6dd470]:0 -> @open(16)
> [container-id="77e8331f-ca64-4b22-8200-311024ede12d", channel-max=32767]
>
> [0x6dd470]: <- AMQP
> [0x6dd470]:0 <- @open(16)
> [container-id="DeviceGateway_5245347c74864eca98e80fc05547102b",
> hostname="10.0.4.43", max-frame-size=65536, channel-max=8191,
> idle-time-out=240000]
>
> on_connection_open
> [0x6dd470]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
> outgoing-window=2147483647]
> [0x6dd470]:0 -> @attach(18) [name="fbad141a-325e-4751-b2fe-3524960cff1e/1",
> handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0,
> source=@source(40) [address="$cbs", durable=0, timeout=0, dynamic=false],
> target=@target(41) [durable=0, timeout=0, dynamic=false],
> initial-delivery-count=0]
> [0x6dd470]:0 -> @attach(18) [name="fbad141a-325e-4751-b2fe-3524960cff1e/2",
> handle=1, role=false, snd-settle-mode=2, rcv-settle-mode=0,
> source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41)
> [address="$cbs", durable=0, timeout=0, dynamic=false],
> initial-delivery-count=0]
> [0x6dd470]:0 -> @flow(19) [incoming-window=2147483647, next-outgoing-id=0,
> outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=10,
> drain=false]
> [0x6dd470]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=1,
> incoming-window=5000, outgoing-window=5000, handle-max=262143]
>
> on_session_open
> [0x6dd470]:0 <- @attach(18) [name="fbad141a-325e-4751-b2fe-3524960cff1e/1",
> handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0,
> initial-delivery-count=0, max-message-size=1048576]
> [0x6dd470]:0 <- @detach(22) [handle=0, closed=true, error=@error(29)
> [condition=:"amqp:internal-error", description="Object reference not set to
> an instance of an object.", info={:exception="System.NullReferenceException:
> Object reference not set to an instance of an object.\x0d\x0a\x0d\x0aServer
> stack trace: \x0d\x0a at
> Microsoft.Azure.Devices.Gateway.Cloud.Common.Amqp.AmqpExtensionMethods.GetIotHubName(AmqpConnection
> connection) in
> D:\jenkins\workspace\Build\common\Microsoft.Azure.Devices.Gateway.Cloud.Common\Amqp\AmqpExtensionMethods.cs:line
> 17\x0d\x0a at
> Microsoft.Azure.Devices.Gateway.Runtime.Amqp.AmqpGatewayProtocolHead.<OpenLinkAsync>d__83.MoveNext()
> in
> D:\jenkins\workspace\Build\gateway\runtime\Amqp\AmqpGatewayProtocolHead.cs:line
> 624\x0d\x0a\x0d\x0aException rethrown at [0]: \x0d\x0a at
> Microsoft.Azure.Devices.Common.Cloud.ExceptionDispatcher.Throw(Exception
> exception) in
> D:\jenkins\workspace\Build\common\Microsoft.Azure.Devices.Common\ExceptionDispatcher.cs:line
> 14\x0d\x0a at
> Microsoft.Azure.Devices.Common.Cloud.TaskHelpers.EndAsyncResult(IAsyncResult
> asyncResult) in
> D:\jenkins\workspace\Build\common\Microsoft.Azure.Devices.Common\TaskHelpers.cs:line
> 310\x0d\x0a at
> Microsoft.Azure.Amqp.AmqpLink.OnProviderLinkOpened(IAsyncResult result)"}]]
> [0x6dd470]:0 <- @attach(18) [name="fbad141a-325e-4751-b2fe-3524960cff1e/2",
> handle=1, role=true, snd-settle-mode=2, rcv-settle-mode=0,
> max-message-size=1048576]
> [0x6dd470]:0 <- @detach(22) [handle=1, closed=true, error=@error(29)
> [condition=:"amqp:internal-error", description="Object reference not set to
> an instance of an object.", info={:exception="System.NullReferenceException:
> Object reference not set to an instance of an object.\x0d\x0a\x0d\x0aServer
> stack trace: \x0d\x0a at
> Microsoft.Azure.Devices.Gateway.Cloud.Common.Amqp.AmqpExtensionMethods.GetIotHubName(AmqpConnection
> connection) in
> D:\jenkins\workspace\Build\common\Microsoft.Azure.Devices.Gateway.Cloud.Common\Amqp\AmqpExtensionMethods.cs:line
> 17\x0d\x0a at
> Microsoft.Azure.Devices.Gateway.Runtime.Amqp.AmqpGatewayProtocolHead.<OpenLinkAsync>d__83.MoveNext()
> in
> D:\jenkins\workspace\Build\gateway\runtime\Amqp\AmqpGatewayProtocolHead.cs:line
> 624\x0d\x0a\x0d\x0aException rethrown at [0]: \x0d\x0a at
> Microsoft.Azure.Devices.Common.Cloud.ExceptionDispatcher.Throw(Exception
> exception) in
> D:\jenkins\workspace\Build\common\Microsoft.Azure.Devices.Common\ExceptionDispatcher.cs:line
> 14\x0d\x0a at
> Microsoft.Azure.Devices.Common.Cloud.TaskHelpers.EndAsyncResult(IAsyncResult
> asyncResult) in
> D:\jenkins\workspace\Build\common\Microsoft.Azure.Devices.Common\TaskHelpers.cs:line
> 310\x0d\x0a at
> Microsoft.Azure.Amqp.AmqpLink.OnProviderLinkOpened(IAsyncResult result)"}]]
>
>
> Doesn't make a great deal of sense to me, but it does look as though the
> error is indeed firmly inside Azure.
>
> Please let me know if this makes any more sense to you.
>
> You mention that service bus authenticates to the link - I think that Azure
> is slightly different, although not certain. I was playing around with
> service bus before Azure, and service bus takes a username/password in the
> address. Whereas Azure firstly requires a TLS/SSL handshake in order to
> connect at all, and then after that the authentication is achieved by
> opening a sender on the endpoint '$cbs' and sending a message containing a
> shared access signature and some specific fields in the properties. If this
> succeeds, authentication is complete and a corresponding message is sent to
> a receiver opened on the path '$cbs'. After this one can open senders and
> receivers at device endpoints and communicate directly with devices.
>
>
>
> --
> View this message in context: http://qpid.2158936.n2.nabble.com/qpid-proton-0-12-2-connection-engine-and-ssl-tp7647090p7647865.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: qpid-proton 0.12.2 connection_engine and ssl
Posted by Tobias Duckworth <to...@duckworth.uk.com>.
Thanks, wasn't aware of PN_TRACE_FRM, here's some output from connecting to
Azure and attempting to open a receiver then sender with that tracing
enabled:
Address: https://TWDIoTHub.azure-devices.net:5671
[0x6dd470]: -> AMQP
on_start
[0x6dd470]:0 -> @open(16)
[container-id="77e8331f-ca64-4b22-8200-311024ede12d", channel-max=32767]
[0x6dd470]: <- AMQP
[0x6dd470]:0 <- @open(16)
[container-id="DeviceGateway_5245347c74864eca98e80fc05547102b",
hostname="10.0.4.43", max-frame-size=65536, channel-max=8191,
idle-time-out=240000]
on_connection_open
[0x6dd470]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=2147483647]
[0x6dd470]:0 -> @attach(18) [name="fbad141a-325e-4751-b2fe-3524960cff1e/1",
handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0,
source=@source(40) [address="$cbs", durable=0, timeout=0, dynamic=false],
target=@target(41) [durable=0, timeout=0, dynamic=false],
initial-delivery-count=0]
[0x6dd470]:0 -> @attach(18) [name="fbad141a-325e-4751-b2fe-3524960cff1e/2",
handle=1, role=false, snd-settle-mode=2, rcv-settle-mode=0,
source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41)
[address="$cbs", durable=0, timeout=0, dynamic=false],
initial-delivery-count=0]
[0x6dd470]:0 -> @flow(19) [incoming-window=2147483647, next-outgoing-id=0,
outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=10,
drain=false]
[0x6dd470]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=1,
incoming-window=5000, outgoing-window=5000, handle-max=262143]
on_session_open
[0x6dd470]:0 <- @attach(18) [name="fbad141a-325e-4751-b2fe-3524960cff1e/1",
handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0,
initial-delivery-count=0, max-message-size=1048576]
[0x6dd470]:0 <- @detach(22) [handle=0, closed=true, error=@error(29)
[condition=:"amqp:internal-error", description="Object reference not set to
an instance of an object.", info={:exception="System.NullReferenceException:
Object reference not set to an instance of an object.\x0d\x0a\x0d\x0aServer
stack trace: \x0d\x0a at
Microsoft.Azure.Devices.Gateway.Cloud.Common.Amqp.AmqpExtensionMethods.GetIotHubName(AmqpConnection
connection) in
D:\jenkins\workspace\Build\common\Microsoft.Azure.Devices.Gateway.Cloud.Common\Amqp\AmqpExtensionMethods.cs:line
17\x0d\x0a at
Microsoft.Azure.Devices.Gateway.Runtime.Amqp.AmqpGatewayProtocolHead.<OpenLinkAsync>d__83.MoveNext()
in
D:\jenkins\workspace\Build\gateway\runtime\Amqp\AmqpGatewayProtocolHead.cs:line
624\x0d\x0a\x0d\x0aException rethrown at [0]: \x0d\x0a at
Microsoft.Azure.Devices.Common.Cloud.ExceptionDispatcher.Throw(Exception
exception) in
D:\jenkins\workspace\Build\common\Microsoft.Azure.Devices.Common\ExceptionDispatcher.cs:line
14\x0d\x0a at
Microsoft.Azure.Devices.Common.Cloud.TaskHelpers.EndAsyncResult(IAsyncResult
asyncResult) in
D:\jenkins\workspace\Build\common\Microsoft.Azure.Devices.Common\TaskHelpers.cs:line
310\x0d\x0a at
Microsoft.Azure.Amqp.AmqpLink.OnProviderLinkOpened(IAsyncResult result)"}]]
[0x6dd470]:0 <- @attach(18) [name="fbad141a-325e-4751-b2fe-3524960cff1e/2",
handle=1, role=true, snd-settle-mode=2, rcv-settle-mode=0,
max-message-size=1048576]
[0x6dd470]:0 <- @detach(22) [handle=1, closed=true, error=@error(29)
[condition=:"amqp:internal-error", description="Object reference not set to
an instance of an object.", info={:exception="System.NullReferenceException:
Object reference not set to an instance of an object.\x0d\x0a\x0d\x0aServer
stack trace: \x0d\x0a at
Microsoft.Azure.Devices.Gateway.Cloud.Common.Amqp.AmqpExtensionMethods.GetIotHubName(AmqpConnection
connection) in
D:\jenkins\workspace\Build\common\Microsoft.Azure.Devices.Gateway.Cloud.Common\Amqp\AmqpExtensionMethods.cs:line
17\x0d\x0a at
Microsoft.Azure.Devices.Gateway.Runtime.Amqp.AmqpGatewayProtocolHead.<OpenLinkAsync>d__83.MoveNext()
in
D:\jenkins\workspace\Build\gateway\runtime\Amqp\AmqpGatewayProtocolHead.cs:line
624\x0d\x0a\x0d\x0aException rethrown at [0]: \x0d\x0a at
Microsoft.Azure.Devices.Common.Cloud.ExceptionDispatcher.Throw(Exception
exception) in
D:\jenkins\workspace\Build\common\Microsoft.Azure.Devices.Common\ExceptionDispatcher.cs:line
14\x0d\x0a at
Microsoft.Azure.Devices.Common.Cloud.TaskHelpers.EndAsyncResult(IAsyncResult
asyncResult) in
D:\jenkins\workspace\Build\common\Microsoft.Azure.Devices.Common\TaskHelpers.cs:line
310\x0d\x0a at
Microsoft.Azure.Amqp.AmqpLink.OnProviderLinkOpened(IAsyncResult result)"}]]
Doesn't make a great deal of sense to me, but it does look as though the
error is indeed firmly inside Azure.
Please let me know if this makes any more sense to you.
You mention that service bus authenticates to the link - I think that Azure
is slightly different, although not certain. I was playing around with
service bus before Azure, and service bus takes a username/password in the
address. Whereas Azure firstly requires a TLS/SSL handshake in order to
connect at all, and then after that the authentication is achieved by
opening a sender on the endpoint '$cbs' and sending a message containing a
shared access signature and some specific fields in the properties. If this
succeeds, authentication is complete and a corresponding message is sent to
a receiver opened on the path '$cbs'. After this one can open senders and
receivers at device endpoints and communicate directly with devices.
--
View this message in context: http://qpid.2158936.n2.nabble.com/qpid-proton-0-12-2-connection-engine-and-ssl-tp7647090p7647865.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: qpid-proton 0.12.2 connection_engine and ssl
Posted by Cliff Jansen <cl...@gmail.com>.
Service bus authenticates to the link ("entity"), so it is perfectly normal
to have connection and session operations succeed with bogus credentials
followed by a link attach failure.
However, I can't say that you actually have an authentication issue since
you have success with at least one of the test programs you have created.
Perhaps running the client with environment variable
PN_TRACE_FRM=1
set to see what Proton is actually sending and receiving?
On Monday, 18 July 2016, Tobias Duckworth <to...@duckworth.uk.com> wrote:
> OK, so I managed to fire up a local broker that requires SSL and everything
> works fine... I can open sessions, senders, receivers, send a message etc.
>
> So it seems that the problem is specific to Azure, although not sure why it
> works with the non connection_engine build, but not with the
> connection_engine. I'm guessing there's something I'm not doing in relation
> to SSL setup that Azure requires, but have not yet found what it is. Also
> find it a little strange that the connection can be opened, sessions
> opened,
> but things fall apart when links are opened.
>
> Anyway, seems not to be a fundamental problem with using libcurl to deal
> with all the SSL side of things, which is good.
>
> Toby
>
>
>
>
> --
> View this message in context:
> http://qpid.2158936.n2.nabble.com/qpid-proton-0-12-2-connection-engine-and-ssl-tp7647090p7647803.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org <javascript:;>
> For additional commands, e-mail: users-help@qpid.apache.org <javascript:;>
>
>
Re: qpid-proton 0.12.2 connection_engine and ssl
Posted by Tobias Duckworth <to...@duckworth.uk.com>.
Yes I will provide wireshark traces later on today.
I already had a look at these last week, and they look quite different.
Mainly in the sizes of the packets for each transaction. I imagined that
this might simply be due to the different SSL being employed, but could be
wrong.
Toby
--
View this message in context: http://qpid.2158936.n2.nabble.com/qpid-proton-0-12-2-connection-engine-and-ssl-tp7647090p7647866.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: qpid-proton 0.12.2 connection_engine and ssl
Posted by Alan Conway <ac...@redhat.com>.
On Mon, 2016-07-18 at 02:03 -0700, Tobias Duckworth wrote:
> OK, so I managed to fire up a local broker that requires SSL and
> everything
> works fine... I can open sessions, senders, receivers, send a message
> etc.
>
> So it seems that the problem is specific to Azure, although not sure
> why it
> works with the non connection_engine build, but not with the
> connection_engine.
I am very curious about that, if there are interop issues in the engine
I want to fix them. Can you get a couple of wireshark traces, one from
a working session with the reactor and another from the failed session
with the connection engine? Stick them on a JIRA and I'll take a look.
The reactor and the engine have separate mechanisms for generating AMQP
container and link-ids, that is my first suspect.�
> I'm guessing there's something I'm not doing in relation
> to SSL setup that Azure requires, but have not yet found what it is.
> Also
> find it a little strange that the connection can be opened, sessions
> opened,
> but things fall apart when links are opened.
Me too. It is possible that there is some data (e.g. auth username)
that the reactor is getting from SSL which the engine is not, and Azure
is expecting it - but I would expect that to fail during connection
setup. My guess is SSL is not the issue here, some AMQP difference in
the engine is.
>
> Anyway, seems not to be a fundamental problem with using libcurl to
> deal
> with all the SSL side of things, which is good.
>�
Thanks for pressing forward with this. I promise to make it easier in
future :)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: qpid-proton 0.12.2 connection_engine and ssl
Posted by Tobias Duckworth <to...@duckworth.uk.com>.
OK, so I managed to fire up a local broker that requires SSL and everything
works fine... I can open sessions, senders, receivers, send a message etc.
So it seems that the problem is specific to Azure, although not sure why it
works with the non connection_engine build, but not with the
connection_engine. I'm guessing there's something I'm not doing in relation
to SSL setup that Azure requires, but have not yet found what it is. Also
find it a little strange that the connection can be opened, sessions opened,
but things fall apart when links are opened.
Anyway, seems not to be a fundamental problem with using libcurl to deal
with all the SSL side of things, which is good.
Toby
--
View this message in context: http://qpid.2158936.n2.nabble.com/qpid-proton-0-12-2-connection-engine-and-ssl-tp7647090p7647803.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: qpid-proton 0.12.2 connection_engine and ssl
Posted by Tobias Duckworth <to...@duckworth.uk.com>.
BTW, talking to an Azure IoT hub works just fine with a non connection engine
build.
The links open without issue and I'm able to send and receive messages with
devices on my IoTHub.
Are the reactor builds with messaging adaptors doing something extra when
links are setup perhaps?
Toby
--
View this message in context: http://qpid.2158936.n2.nabble.com/qpid-proton-0-12-2-connection-engine-and-ssl-tp7647090p7647768.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: qpid-proton 0.12.2 connection_engine and ssl
Posted by Tobias Duckworth <to...@duckworth.uk.com>.
Hmmm,
Maybe I spoke too soon.
I'm testing my SSL workaround against a Microsoft Azure IoTHub using amqps.
What I find is that the connection opens fine, I can open many sessions
(after fixing the bug with session opening in qpid-proton-0.12.2), but as
soon as I try to open a link (sender or receiver) on any session I get the
following:
on_link_open
on_link_error
So I take a look at the local and remote conditions and find the following:
local name =
local description =
local str = No error condition
remote name = amqp:internal-error
remote description = Object reference not set to an instance of an object.
remote str = amqp:internal-error: Object reference not set to an instance of
an object.
At this stage I'm not sure whether this is something specific to Azure, or
whether it's a general problem with the way I'm doing the SSL, although it
seems unlikely as a lot of communication takes place to open the connection
and the various sessions.
If anyone has any ideas they would be most welcomely received.
I think I need to try to fire up a local broker that needs SSL in order to
get further with this.
Toby
--
View this message in context: http://qpid.2158936.n2.nabble.com/qpid-proton-0-12-2-connection-engine-and-ssl-tp7647090p7647767.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: qpid-proton 0.12.2 connection_engine and ssl
Posted by Alan Conway <ac...@redhat.com>.
On Wed, 2016-07-13 at 07:03 -0700, Tobias Duckworth wrote:
> Hi Alan,
>
> Yes, I'm pleased to say that it works. For those interested, here's
> how I
> did it:
>
> Derive from io::socket_engine and reimplement io_read and io_write.
> Just
> make them call through to curl_easy_recv and curl_easy_send
> respectively.
> Make sure you construct your class derived from socket engine with
> the
> constructor that just takes a file descriptor (rather than the URL
> one).
>
Lovely! The socket_engine is gone in 0.13 because it was too socket-
specific. If you have time I'd like your opinion on whether coding
directly to the current connection_engine class would too onerous.
Alternatively if you are able to send me some code I can try converting
it to see what that looks like.
If it turns out to be a lot more troublesome I might bring back the
socket_engine since sockets + some reactive poller is a common case in
Unix.
> In setting up the socket you'll need to do the following:
>
> ��������curl_easy_setopt(m_easy, CURLOPT_URL, m_url.c_str());
> ��������curl_easy_setopt(m_easy, CURLOPT_CONNECT_ONLY, 1L);
>
> I'm using a curl_multi to contain a number of curl_easy, so that the
> connection can be established asynchronously. If you also choose this
> approach, then you'll need so define socket and timer callback
> functions:
>
> ����curl_multi_setopt(m_multi, CURLMOPT_SOCKETFUNCTION,
> staticOnSocket);
> ����curl_multi_setopt(m_multi, CURLMOPT_SOCKETDATA, this);
> ����curl_multi_setopt(m_multi, CURLMOPT_TIMERFUNCTION,
> staticOnTimerRequest);
> ����curl_multi_setopt(m_multi, CURLMOPT_TIMERDATA, this);
>
> In these callbacks do the usual curl_multi_socket_action, and then
> iterate
> over the list of messages returned (if any). When you get
> CURLMSG_DONE, then
> you can get the socket file descriptor using
> curl_easy_getinfo(m_easy,
> CURLINFO_ACTIVESOCKET, &m_fd);
>
> Now you have your socket, and libcurl will have done all the SSL
> negotiations. You can just create an instance of your class derived
> from
> io::socket_engine using the socket and everything should spring into
> life.
>
> One other thing worth mentioning is that you have to fiddle the URL a
> little
> for the amqps case.
> When it's just straight amqp, just strip then scheme from the
> proton::url
> before passing it to libcurl (i.e. amqp://my.domain.place:PORT ->
> my.domain.place:PORT)
> When it's amqps you'll need to trick libcurl into thinking it's https
> (i.e.
> amqps://my.domain.place:PORT -> https://my.domain.place:PORT)
>
> Hope this helps anyone else trying to achieve SSL connections with
> the
> connection_engine model.
>
> Toby
>
>
>
>
> --
> View this message in context: http://qpid.2158936.n2.nabble.com/qpid-
> proton-0-12-2-connection-engine-and-ssl-tp7647090p7647560.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: qpid-proton 0.12.2 connection_engine and ssl
Posted by Tobias Duckworth <to...@duckworth.uk.com>.
Hi Alan,
Yes, I'm pleased to say that it works. For those interested, here's how I
did it:
Derive from io::socket_engine and reimplement io_read and io_write. Just
make them call through to curl_easy_recv and curl_easy_send respectively.
Make sure you construct your class derived from socket engine with the
constructor that just takes a file descriptor (rather than the URL one).
In setting up the socket you'll need to do the following:
curl_easy_setopt(m_easy, CURLOPT_URL, m_url.c_str());
curl_easy_setopt(m_easy, CURLOPT_CONNECT_ONLY, 1L);
I'm using a curl_multi to contain a number of curl_easy, so that the
connection can be established asynchronously. If you also choose this
approach, then you'll need so define socket and timer callback functions:
curl_multi_setopt(m_multi, CURLMOPT_SOCKETFUNCTION, staticOnSocket);
curl_multi_setopt(m_multi, CURLMOPT_SOCKETDATA, this);
curl_multi_setopt(m_multi, CURLMOPT_TIMERFUNCTION,
staticOnTimerRequest);
curl_multi_setopt(m_multi, CURLMOPT_TIMERDATA, this);
In these callbacks do the usual curl_multi_socket_action, and then iterate
over the list of messages returned (if any). When you get CURLMSG_DONE, then
you can get the socket file descriptor using curl_easy_getinfo(m_easy,
CURLINFO_ACTIVESOCKET, &m_fd);
Now you have your socket, and libcurl will have done all the SSL
negotiations. You can just create an instance of your class derived from
io::socket_engine using the socket and everything should spring into life.
One other thing worth mentioning is that you have to fiddle the URL a little
for the amqps case.
When it's just straight amqp, just strip then scheme from the proton::url
before passing it to libcurl (i.e. amqp://my.domain.place:PORT ->
my.domain.place:PORT)
When it's amqps you'll need to trick libcurl into thinking it's https (i.e.
amqps://my.domain.place:PORT -> https://my.domain.place:PORT)
Hope this helps anyone else trying to achieve SSL connections with the
connection_engine model.
Toby
--
View this message in context: http://qpid.2158936.n2.nabble.com/qpid-proton-0-12-2-connection-engine-and-ssl-tp7647090p7647560.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: qpid-proton 0.12.2 connection_engine and ssl
Posted by Alan Conway <ac...@redhat.com>.
On Tue, 2016-07-12 at 09:41 -0700, Tobias Duckworth wrote:
> Thank you for your response.
>
> I'm already using libcurl to establish the socket connection, so will
> have a
> go at getting it to do all the reading/writing as well, and then see
> if I
> can convince it to do the SSL.
>
> Any reason you can think of that this wouldn't work?
>
For basic AMQP functionality no, the connection engine doesn't care
where the bytes came from or go to.�
For getting security information into your proton handler (e.g.
authenticated username, virtual host) I think we already have the hooks
we need on proton::connection, if there we identify any gaps they'll be
easy to fix.
Cheers,
Alan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: qpid-proton 0.12.2 connection_engine and ssl
Posted by Tobias Duckworth <to...@duckworth.uk.com>.
Thank you for your response.
I'm already using libcurl to establish the socket connection, so will have a
go at getting it to do all the reading/writing as well, and then see if I
can convince it to do the SSL.
Any reason you can think of that this wouldn't work?
Toby
--
View this message in context: http://qpid.2158936.n2.nabble.com/qpid-proton-0-12-2-connection-engine-and-ssl-tp7647090p7647318.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: qpid-proton 0.12.2 connection_engine and ssl
Posted by Alan Conway <ac...@redhat.com>.
On Fri, 2016-07-08 at 17:26 +0100, Tobias Duckworth wrote:
> Hi,
>
> I've used qpid-proton-0.12.2 in my application as a connection_engine
> or�
> io::socket_engine. I need to arrange for the connect and
> reading/writing�
> to happen asynchronously and my implementation sits within an
> existing�
> io framework.
>
> Everything has integrated quite nicely, apart from SSL, which I
> cannot�
> get to work.
>
> I have some straightforward C++ examples, one of which derives from�
> connection_engine, and the other from container. I can see that for
> the�
> container example ssl_init gets called from connection_options.cpp
> and�
> everything then works nicely, whereas for the connection_engine
> example�
> it does not.
>
> The problem seems to be that for the connection_engine build
> 'outbound'�
> is not set, and therefore ssl_init does not get called.
>
> Please could someone explain how to implement an amqp client using
> the�
> connection_engine framework that supports SSL?
Known problem:�https://issues.apache.org/jira/browse/PROTON-1255
You are motivating me to fix it.
There is another alternative: you can establish the secure stream (SSL)
outside of proton, and ignore proton's SSL support. If you try this
please report on the JIRA any problems you run into. The goal is for
connection_engine to support both. I'd appreciate your help verifying
the fix, if you want to put a watch on the JIRA. I've got some other
stuff distracting me but this is my top priority on proton now.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org