Re: [Development] QtCoap: QNAM-like API or not

[Richard Moore]

On 18 January 2018 at 10:07, Konstantin Tokarev  wrote:

>
>
> Heap corruption can be detected with lots of existing tools, e.g. ASAN. It
> also won't be left unnoticed until it's too late, unlike memory leaks which
> may suddenly pop up when amount of data increases.
>
> Debugging out of memory conditions may be much harder.
>

​I suggested adding detection of QNetworkReplies that weren't delete after
a short time period (a few seconds perhaps) as an idea for gammaray to help
with this issue.

Cheers

Rich.
​
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCoap: QNAM-like API or not

[Konstantin Tokarev]

18.01.2018, 12:58, "Adrien LERAVAT" :
>>  From: Konstantin Tokarev [mailto:annu...@yandex.ru]
>>  Sent: Thursday, January 18, 2018 10:42 AM
>>
>>>   The API sounds interesting, but it's a departure of what we are used in 
>>> QNAM.
>>>   What happened to the idea of using a setter on the manager, for making 
>>> the replies self-delete if wanted? (it was mentioned on the > QtCS) That 
>>> had the advantage that can be added to QNAM as well, so both can end up 
>>> having a similar API.
>>>
>>>  Well it can surely solve the "forgot to delete reply" case, but as a 
>>> developer, if you're not aware of the change (not the one calling the 
>>> setter), the new behavior change will be far from obvious. Going from 
>>> "pseudo memory leak" to "dangling pointers & crashes" if they are not 
>>> careful enough.
>>
>>  On small device crashes are more favorable outcome than "pseudo" memory 
>> leaks, because the latter lead to delayed crashes and therefore are much 
>> harder to fix.
>
> Well if not tested, it might just as well corrupt part of the heap with no 
> further notice, so I'm not sure it is much better.

Heap corruption can be detected with lots of existing tools, e.g. ASAN. It also 
won't be left unnoticed until it's too late, unlike memory leaks which may 
suddenly pop up when amount of data increases.

Debugging out of memory conditions may be much harder.

> But the question probably boils down: should we keep QNAM API or not for 
> QtCoAP?
>
>>>  So it has the advantage to be applicable to QNAM, but doesn't really feel 
>>> like a user-proof solution to me.
>>>
>>>  Still it can be easily applied to QCoapClient, so if there is a consensus 
>>> around it, we can go that way.
>
> Adrien Leravat
> Software architect, Witekio
> http://witekio.com

-- 
Regards,
Konstantin

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCoap: QNAM-like API or not

[Adrien LERAVAT]

> From: Konstantin Tokarev [mailto:annu...@yandex.ru] 
> Sent: Thursday, January 18, 2018 10:42 AM 
> 
>>  The API sounds interesting, but it's a departure of what we are used in 
>> QNAM.
>>  What happened to the idea of using a setter on the manager, for making the 
>> replies self-delete if wanted? (it was mentioned on the > QtCS) That had the 
>> advantage that can be added to QNAM as well, so both can end up having a 
>> similar API.
>>
>> Well it can surely solve the "forgot to delete reply" case, but as a 
>> developer, if you're not aware of the change (not the one calling the 
>> setter), the new behavior change will be far from obvious. Going from 
>> "pseudo memory leak" to "dangling pointers & crashes" if they are not 
>> careful enough.
>
> On small device crashes are more favorable outcome than "pseudo" memory 
> leaks, because the latter lead to delayed crashes and therefore are much 
> harder to fix.

Well if not tested, it might just as well corrupt part of the heap with no 
further notice, so I'm not sure it is much better.
But the question probably boils down: should we keep QNAM API or not for 
QtCoAP? 

>> So it has the advantage to be applicable to QNAM, but doesn't really feel 
>> like a user-proof solution to me.
>>
>> Still it can be easily applied to QCoapClient, so if there is a consensus 
>> around it, we can go that way.

Adrien Leravat
Software architect, Witekio
http://witekio.com


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCoap: QNAM-like API or not

[Konstantin Tokarev]

14.01.2018, 20:50, "Adrien LERAVAT" :
> Hi all,
>
> Before feature freeze, we wanted to challenge the current API for the CoAP 
> module.
>
> It is currently similar to QNAM APIs:
>
> \code
>
> QCoapClient client;
>
> QCoapReply *reply = client.get(QUrl("1.2.3.4:5683"));
>
> connect(reply, ::finished, this, ::onFinished);
>
> ...
>
> MyClass::onFinished(QCoapReply* reply)
>
> {
>
>     qWarning() << reply->readAll();
>
>     reply->deleteLater();
>
> }
>
> \endcode
>
> With the clear drawback of explicit memory management needed by users. We made
>
> some tests with a container/RAII object for the reply, and it seems fine, but 
> before
>
> moving forward in this limited timeframe, we wanted to have your feedback.
>
> Sample below:
>
> \code
>
> QCoapClient client;
>
> QCoapRequest request = client.get(QUrl("1.2.3.4:5683"));
>
> connect(request.reply(), ::finished, this, ::onFinished);
>
> ...
>
> MyClass::onFinished(const QCoapRequest )
>
> {
>
>     qWarning() << request.reply()->readAll();
>
> }
> \endcode
>
> In that case, the QCoapReply life is managed with a 
> QSharedPointer in the request.
>
> QCoapRequest does not inherit from QObject. Anyone sees a problem with this 
> approach?

I dislike idea of using external reference counting, making it 
QExplicitlySharedDataPointer would be better

>
> As it wasn't merged to master yet, you can access the repo from its current 
> submission:
>
> https://codereview.qt-project.org/#/c/201311/
>
> Thanks,
>
> Adrien Leravat
>
> ,
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCoap: QNAM-like API or not

[Konstantin Tokarev]

18.01.2018, 12:35, "Adrien LERAVAT" :
> On Sunday 14 January 2018 17:49:48 Adrien LERAVAT wrote:
>>  > In that case, the QCoapReply life is managed with a
>>  > QSharedPointer in the request.
>>  >
>>  > QCoapRequest does not inherit from QObject. Anyone sees a problem with
>>  > this approach?
>
>>  The API sounds interesting, but it's a departure of what we are used in 
>> QNAM.
>>  What happened to the idea of using a setter on the manager, for making the 
>> replies self-delete if wanted? (it was mentioned on the > QtCS) That had the 
>> advantage that can be added to QNAM as well, so both can end up having a 
>> similar API.
>
> Well it can surely solve the "forgot to delete reply" case, but as a 
> developer, if you're not aware of the change (not the one calling the 
> setter), the new behavior change will be far from obvious. Going from "pseudo 
> memory leak" to "dangling pointers & crashes" if they are not careful enough.

On small device crashes are more favorable outcome than "pseudo" memory leaks, 
because the latter lead to delayed crashes and therefore are much harder to fix.

> So it has the advantage to be applicable to QNAM, but doesn't really feel 
> like a user-proof solution to me.
>
> Still it can be easily applied to QCoapClient, so if there is a consensus 
> around it, we can go that way.
>
> Adrien Leravat
> Software architect, Witekio
> http://witekio.com
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCoap: QNAM-like API or not

[Adrien LERAVAT]

On Sunday 14 January 2018 17:49:48 Adrien LERAVAT wrote:
> > In that case, the QCoapReply life is managed with a 
> > QSharedPointer in the request.
> > 
> > QCoapRequest does not inherit from QObject. Anyone sees a problem with 
> > this approach?

> The API sounds interesting, but it's a departure of what we are used in QNAM. 
> What happened to the idea of using a setter on the manager, for making the 
> replies self-delete if wanted? (it was mentioned on the > QtCS) That had the 
> advantage that can be added to QNAM as well, so both can end up having a 
> similar API.

Well it can surely solve the "forgot to delete reply" case, but as a developer, 
if you're not aware of the change (not the one calling the setter), the new 
behavior change will be far from obvious. Going from "pseudo memory leak" to 
"dangling pointers & crashes" if they are not careful enough. So it has the 
advantage to be applicable to QNAM, but doesn't really feel like a user-proof 
solution to me.

Still it can be easily applied to QCoapClient, so if there is a consensus 
around it, we can go that way. 

Adrien Leravat
Software architect, Witekio
http://witekio.com

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCoap: QNAM-like API or not

[Thiago Macieira]

On Monday, 15 January 2018 23:40:03 PST Maurice Kalinowski wrote:
> Personally, I do not see those two items (missing DTLS, release TP)
> conflicting. The only "problem" which might exist, if DTLS takes too long
> to implement and CoAP would stay for a very long time in TP mode.

I don't see a way out, though I'm hoping it won't be the case. "No security" 
is just not acceptable.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCoap: QNAM-like API or not

[Alejandro Exojo via Development]

On Sunday 14 January 2018 17:49:48 Adrien LERAVAT wrote:
> In that case, the QCoapReply life is managed with a
> QSharedPointer in the request.
> 
> QCoapRequest does not inherit from QObject. Anyone sees a problem with this
> approach?

The API sounds interesting, but it's a departure of what we are used in QNAM. 
What happened to the idea of using a setter on the manager, for making the 
replies self-delete if wanted? (it was mentioned on the QtCS) That had the 
advantage that can be added to QNAM as well, so both can end up having a 
similar API.

-- 
Viking Software, Qt and C++ developers for hire
http://www.vikingsoftware.com

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCoap: QNAM-like API or not

[Timur Pocheptsov]

Thiago, thanks for the clarification. Yeah, you have a point, I agree with 
those reasons though they are more server-related and CoAP module has no one 
yet. I was also thinking that having a TP status on CoAP module can help to 
mitigate possible API/design problems/inconsistency.


Maurice:


> if DTLS takes too long to implement and CoAP would stay for a very long time 
> in TP mode.


It should not, but it's too early/too late given feature-freeze in 2 weeks - so 
it's for 5.12.

Could we have CoAP as TP given DTLS will be in 5.12?


Best regards,

Timur.


From: Development <development-bounces+timur.pocheptsov=qt...@qt-project.org> 
on behalf of Maurice Kalinowski <maurice.kalinow...@qt.io>
Sent: Tuesday, January 16, 2018 8:40:03 AM
To: Thiago Macieira; development@qt-project.org
Subject: Re: [Development] QtCoap: QNAM-like API or not

> > They model their Coap client after QNAM and related classes (like
> > QNetworkRequest/Reply pair).
> >
> > As I understand it now - DTLS or not does not affect this API much -
> > they can later
>
> You don't know that. Until we know how DTLS will work, we won't know if
> there's any impact in the front-end API for CoAP. For example, can you use
> one CoAP server for both encrypted and not encrypted? Multicast and
> unicast?
>
> What's more, we CANNOT release a full CoAP API until it implements DTLS.
> It's just not acceptable to do so otherwise. Therefore, until there's DTLS, 
> the
> API is Technology Preview and subject to change. So I don't feel we need to
> review it yet. I have not spent any time myself.
>
[Maurice Kalinowski]

I guess having it as Technology Preview for a first release is the usual way to 
go anyways. That way, the API could still be changed afterwards, but also 
interested parties could get a first impression and suggest adoptions already, 
even though DTLS is not available yet.

Personally, I do not see those two items (missing DTLS, release TP) 
conflicting. The only "problem" which might exist, if DTLS takes too long to 
implement and CoAP would stay for a very long time in TP mode.

Maurice
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCoap: QNAM-like API or not

[Maurice Kalinowski]

> > They model their Coap client after QNAM and related classes (like
> > QNetworkRequest/Reply pair).
> >
> > As I understand it now - DTLS or not does not affect this API much -
> > they can later
> 
> You don't know that. Until we know how DTLS will work, we won't know if
> there's any impact in the front-end API for CoAP. For example, can you use
> one CoAP server for both encrypted and not encrypted? Multicast and
> unicast?
> 
> What's more, we CANNOT release a full CoAP API until it implements DTLS.
> It's just not acceptable to do so otherwise. Therefore, until there's DTLS, 
> the
> API is Technology Preview and subject to change. So I don't feel we need to
> review it yet. I have not spent any time myself.
> 
[Maurice Kalinowski] 

I guess having it as Technology Preview for a first release is the usual way to 
go anyways. That way, the API could still be changed afterwards, but also 
interested parties could get a first impression and suggest adoptions already, 
even though DTLS is not available yet.

Personally, I do not see those two items (missing DTLS, release TP) 
conflicting. The only "problem" which might exist, if DTLS takes too long to 
implement and CoAP would stay for a very long time in TP mode.

Maurice
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCoap: QNAM-like API or not

[Thiago Macieira]

On Sunday, 14 January 2018 22:15:15 PST Timur Pocheptsov wrote:
> > I don't think we can make any decisions on CoAP until DTLS support is
> > there. It may influence what the CoAP API looks like.
> 
> Thiago, could you, please, clarify this?

Sure. There's no DTLS API. Therefore, CoAP API cannot be implemented.

> They model their Coap client after QNAM and related classes (like
> QNetworkRequest/Reply pair).
> 
> As I understand it now - DTLS or not does not affect this API much - they
> can later

You don't know that. Until we know how DTLS will work, we won't know if 
there's any impact in the front-end API for CoAP. For example, can you use one 
CoAP server for both encrypted and not encrypted? Multicast and unicast?

What's more, we CANNOT release a full CoAP API until it implements DTLS. It's 
just not acceptable to do so otherwise. Therefore, until there's DTLS, the API 
is Technology Preview and subject to change. So I don't feel we need to review 
it yet. I have not spent any time myself.

> From client side QDtlsConnection I'm working on is not very different
> 
> from QSslSocket/QUdpSocket as we have them in Qt now (though it's none of
> them exactly).

We talked about sharing sockets and everything else. There's a lot that may 
change once you get to the final details.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCoap: QNAM-like API or not

[Timur Pocheptsov]

> I don't think we can make any decisions on CoAP until DTLS support is there.
> It may influence what the CoAP API looks like.


Thiago, could you, please, clarify this?


They model their Coap client after QNAM and related classes (like 
QNetworkRequest/Reply pair).

As I understand it now - DTLS or not does not affect this API much - they can 
later

add QSslConfiguration/sslErrors signal(s) in their API. Am I missing something?


>From client side QDtlsConnection I'm working on is not very different

from QSslSocket/QUdpSocket as we have them in Qt now (though it's none of them 
exactly).


Best regards,

Timur.


From: Development <development-bounces+timur.pocheptsov=qt...@qt-project.org> 
on behalf of Thiago Macieira <thiago.macie...@intel.com>
Sent: Monday, January 15, 2018 5:55:41 AM
To: development@qt-project.org
Subject: Re: [Development] QtCoap: QNAM-like API or not

On Sunday, 14 January 2018 09:49:48 PST Adrien LERAVAT wrote:
> Hi all,
>
>
> Before feature freeze, we wanted to challenge the current API for the CoAP
> module.

I don't think we can make any decisions on CoAP until DTLS support is there.
It may influence what the CoAP API looks like.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCoap: QNAM-like API or not

[Thiago Macieira]

On Sunday, 14 January 2018 09:49:48 PST Adrien LERAVAT wrote:
> Hi all,
> 
> 
> Before feature freeze, we wanted to challenge the current API for the CoAP
> module.

I don't think we can make any decisions on CoAP until DTLS support is there. 
It may influence what the CoAP API looks like.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCoap: QNAM-like API or not

[Ville Voutilainen]

On 14 January 2018 at 19:49, Adrien LERAVAT  wrote:
> With the clear drawback of explicit memory management needed by users. We
> made
>
> some tests with a container/RAII object for the reply, and it seems fine,
> but before
>
> moving forward in this limited timeframe, we wanted to have your feedback.
>
> Sample below:
>
>
> \code
>
> QCoapClient client;
>
> QCoapRequest request = client.get(QUrl("1.2.3.4:5683"));
>
> connect(request.reply(), ::finished, this, ::onFinished);
>
> ...
>
> MyClass::onFinished(const QCoapRequest )
>
> {
>
> qWarning() << request.reply()->readAll();
>
> }
>
> \endcode
>
>
> In that case, the QCoapReply life is managed with a
> QSharedPointer in the request.
>
> QCoapRequest does not inherit from QObject. Anyone sees a problem with this
> approach?


Doing automatic cleanup is certainly an improvement, but in addition
to that, I think it's useful if
the user can explicitly cleanup as well, as soon as she's done with
the reply, without waiting for the lifetime
of the request to end.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QtCoap: QNAM-like API or not

[Adrien LERAVAT]

Hi all,


Before feature freeze, we wanted to challenge the current API for the CoAP 
module.

It is currently similar to QNAM APIs:


\code

QCoapClient client;

QCoapReply *reply = client.get(QUrl("1.2.3.4:5683"));

connect(reply, ::finished, this, ::onFinished);

...

MyClass::onFinished(QCoapReply* reply)

{

qWarning() << reply->readAll();

reply->deleteLater();

}

\endcode


With the clear drawback of explicit memory management needed by users. We made

some tests with a container/RAII object for the reply, and it seems fine, but 
before

moving forward in this limited timeframe, we wanted to have your feedback.

Sample below:


\code

QCoapClient client;

QCoapRequest request = client.get(QUrl("1.2.3.4:5683"));

connect(request.reply(), ::finished, this, ::onFinished);

...

MyClass::onFinished(const QCoapRequest )

{

qWarning() << request.reply()->readAll();

}

\endcode


In that case, the QCoapReply life is managed with a QSharedPointer 
in the request.

QCoapRequest does not inherit from QObject. Anyone sees a problem with this 
approach?


As it wasn't merged to master yet, you can access the repo from its current 
submission:

https://codereview.qt-project.org/#/c/201311/


Thanks,

Adrien Leravat



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development