[Development] QtCS19 Notes: Qt 6 Network Overview

Maurice Kalinowski Maurice.Kalinowski at qt.io
Thu Nov 21 08:52:59 CET 2019


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.
		



More information about the Development mailing list