[Development] QtCS19 Notes: Qt 6 Network Overview

[Timur Pocheptsov]

I'll update wiki using this on Monday, thanks.


Best regards,
    Timur.
________________________________
From: Development <development-bounces at qt-project.org> on behalf of Maurice Kalinowski <Maurice.Kalinowski at qt.io>
Sent: Thursday, November 21, 2019 8:52 AM
To: development at qt-project.org <development at qt-project.org>
Subject: [Development] QtCS19 Notes: Qt 6 Network Overview

Hi,

Following the notes taken on the Networking session:

        - What to do in Networking for Qt 6
                ○ https://bugreports.qt.io/browse/QTBUG-75638 is the parent item to track
        - Get rid of stale backend
                ○ OpenSSL 1.1 and following supported
                ○ SSL2/3
        - Additional TLS
                ○ mbedTLS contribution exists, will get it in but requires work
        - QNetworkAccessmanager
                ○ Default policies
        - Removing bearer management
                ○ There has been complaints about it
                ○ Radio interfaces as bearer are not best option
                ○ Legacy from S60
                ○ Let's just get rid of it and move on
                ○ Webkit used bearer management to just identify whether you're online or not
                ○ However, system services exist
                        § We should have something similar in Qt
                        § WIP: Connection Monitoring
                ○ Proposal:
                        § Remove it
                        § Add requested features afterwards
                                □ Which socket is a connection using
                                □ Set preferred connection
        - We want to avoid temporary buffers, especially in TLS case
        - QSSLsocket need to change
                ○ Going through tcp socket is complicated
                ○ Lots of effort, might be too big for Qt 6
                ○ Similar to QDTLS, which does not go through QUDPSocket
        - (Connection loss)
                ○ Problem not 100% clear
                ○ We have connection caching
                ○ Should not be exposed to user
        - Move WebSocket to QtNetwork?
                ○ Not sure why this is needed in network itself
                ○ Currently not actively maintained
                ○ Before moving to QtNetwork it needs to be significantly refactored
        - Removing QFTP
                ○ This is about QFTP backend in QNetworkAccessManager
                ○ There are still public users, but how many?
                ○ Proposal: Disable it in 6.0 and check for amount of complaints
                        § If limited (as expected) remove in 6.2 completely
        - What about adding backends to QNetworkAccessManager?
                ○ Right now you can only exchange it
                ○ AP: Create research user story on JIRA
                ○ Help request
        - What about using libcurl as a backend?
                ○ Not only ftp, but everything?
                ○ It's not the best API, but provides a lot
                ○ We'd have to different underlying architectures, impossible to use libcurl with our own stuff
                ○ Libcurl also has its own secure transport implementation, etc…
                ○ Windows provides native API, what about that?
                        § Mac probably as well
        - More and more projects need to do certificate management etc
                ○ KNX, OpcUA, CoAP, …
                ○ Can we find an abstraction? Potentially move that into a separate module and have Qt Network use it?
                ○ QTBUG-76499, QTBUG-76876
                ○ It's a lot of work, but might be better than duplicating less work again and again
        - QUIC / HTTP3
                ○ Rather wait for it to stabilize, but on the radar
        - QIODevice and zero copy
                ○ Needs to move to QtCS core session as no time left
        - How to test
                ○ Current testserver is probably not the best option
                ○ Use docker images
                ○ Windows is not ready for nested virtualization
                ○ However, might be worth considering run the network test containers on one machine and then have the Windows VMs connect to this one.


_______________________________________________
Development mailing list
Development at qt-project.org
https://lists.qt-project.org/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20191122/24d261fa/attachment-0001.html>