Category:Developing Qt::Network: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
 
(Move content to a separate page, so this is just a quick intro to the category.)
 
(10 intermediate revisions by 6 users not shown)
Line 1: Line 1:
=Introduction=
The Qt Networking stack lives in <kbd>qtbase/src/network/</kbd> and its associated test infrastructure in <kbd>qtbase/tests/auto/network-settings.h</kbd> with build-support in <kbd>qtbase/tests/auto/testserver.pri</kbd> for the new containerised test server.
 
The QtNetwork module provides <span class="caps">TCP</span>/IP networking and higher layer network protocols to other modules.<br /> For example, QtWebkit and QtDeclarative.
 
The code is divided into submodules roughly corresponding to network layers.
 
Platform specific code is located in _platform.cpp files, with _generic.cpp or _tcp.cpp being a basic functionality version for other platforms without a detailed port.
 
=Breakdown by submodule=
 
==kernel==
 
The kernel contains classes which are used by multiple other layers, so don’t fit well in one place.<br /> It is a mix of “kernel” and “tools” classes, but there aren’t so many to need to further subdivide yet.
 
===Low level===
 
* qhostaddress – data type for an IP address
* qnetworkinterface – data type and code for enumerating interfaces (i.e. what shows up in the ifconfig/ipconfig command)
 
===<span class="caps">DNS</span>===
 
* qhostinfo – used to resolve a host name to an IP address
* qdnslookup – used for querying <span class="caps">DNS</span> records (e.g. <span class="caps">SVC</span>, MX..)
 
===Misc===
 
* qauthenticator – data type, also contains code for calculating authentication responses. Used by http (access) and proxies (socket)
* qnetworkproxy – data type, also contains code for enumerating proxies from the operating system. (see also socket layer for proxy handlers)
* qurlinfo – QFileInfo for urls… used by QFtp
 
==socket==
 
The socket subdirectory contains classes related to sockets. This is mainly <span class="caps">TCP</span>/IP related, but QLocalSocket is implemented on top of <span class="caps">TCP</span> only as a fallback. Note that QLocalSocket is not related to QAbstractSocket despite having a similar <span class="caps">API</span>.
 
Sockets are implemented using socket engines. Virtual functions are called on QAbstractSocketEngine, which are implemented by QNativeSocketEngine or a proxy.
 
===local sockets===
 
* qlocalsocket – implements a local loopback socket
* qlocalserver – implements a server socket to accept incoming connections
* qlocal*_unix – AF_UNIX socket implementation
* qlocal*_win – windows named pipe implementation
* qlocal*_tcp – <span class="caps">TCP</span> loopback implementation
 
===IP sockets===
 
* qabstractsocket – base class for QTcpSocket and QUdpSocket, contains most of the implementation for both
* qtcpsocket – <span class="caps">TCP</span> specific code
* qudpsocket – <span class="caps">UDP</span> specific code
* qtcpserver – server socket to accept incoming connections
 
===socket engines===
 
* qabstractsocketengine – base class (interface)
* qnativesocketengine – contains cross platform code for a real socket
* qnativesocketengine_(platform) – contains platform specific implementation using native <span class="caps">API</span>
* qhttpsocketengine – implements http proxy using the <span class="caps">CONNECT</span> method (caching methods are dealt with in the http code in the access layer)
 
==<span class="caps">SSL</span>==
 
Implements the secure sockets layer.<br /> See the article [[Hacking-on-Qts-SSL-Support|Hacking on Qts <span class="caps">SSL</span> Support]] for detail
 
==access==
 
Implements QNetworkAccessManager and related classes.<br /> This is the most complicated area of QtNetwork.
 
QNetworkAccessManager creates a class from the QNetworkReplyImpl family, and returns it to the application as a QNetworkReply<br /> There is a factory function to do this, plugins are not supported though.<br /> The generic QNetworkReplyImpl has a pointer to a backend which actually does the work.<br /> The non generic versions are optimised/specialised
 
<span class="caps">HTTP</span> is performed in a worker thread, to avoid disruption to the main UI thread (e.g. loading from network while scrolling)
 
Generally, a QAbstractSocket pointer is used to refer to a socket, and instantiated with either QTcpSocket or QSslSocket depending on the url scheme.
 
You can also take a look at [http://peter.hartmann.tk/blog/2012/02/inside-the-qt-http-stack.html this blogpost about the Qt <span class="caps">HTTP</span> stack.] ''[peter.hartmann.tk]''
 
===QNetworkAccessManager front end===
 
* qnetworkaccessmanager
* qnetworkrequest
* qnetworkreply
 
===QNetworkReply implementations===
 
* qnetworkreplyimpl – generic
* qnetworkreplydataimpl – handles the data scheme
* qnetworkreplyfileimpl – handles the file scheme
* qnetworkreplyhttpimpl – handles the http(s) scheme
* qnetworkaccesscachebackend – backend for loading from cache
* qnetworkaccessdebugpipebackend – backend for unit testing
* qnetworkaccessfilebackend – backend for file scheme (overlap/duplication?)
* qnetworkaccessftpbackend – backend for ftp scheme
 
===<span class="caps">FTP</span>===
 
* qftp – contains implementation for <span class="caps">FTP</span>
* qnetworkaccessftpbackend – backend for ftp scheme
 
===<span class="caps">HTTP</span>===
 
* qhttpmultipart – container for multipart mime types when uploading
* qhttpthreaddelegate – worker thread task, handles the inter thread communication. Owns the QHttpNetworkConnection
* qhttpnetworkconnection – a logical connection to a server, owns multiple channels on which it sends queued requests.
* qhttpnetworkconnectionchannel – a <span class="caps">TCP</span> socket connection to a server. May be reused if pipelineing is enabled.
* qhttpnetworkheader – creation and parsing of http headers. Inherited by QNetworkReply and QNetworkRequest
* qnetworkreplyhttpimpl – handles the http(s) scheme, creates the thread delegate.
 
===cache and cookies===
 
* qabstractnetworkcache – base class for a url:object cache
* qnetworkdiskcache – reference implementation for a cache backed by regular files in the filesystem
* qnetworkcookie – data type for a cookie and associated metadata (e.g. security information)
* qnetworkcookiejar – basic container for cookies, will be reimplemented by web browser or other application that needs persistant cookies
 
===general backend===
 
* qnetworkaccesscache – used to hold open tcp connections that can be reused later
* qnetworkaccessauthenticationmanager – cache of authentication credentials, tried first before emitting authenticationRequired signal
 
==bearer==
 
The bearer <span class="caps">API</span> is concerned with enumerating network bearers and controlling their lifetime.<br /> It is mainly important on mobile, battery powered devices<br /> Much of the implementation is in plugins (src/plugins/bearer/(platform))<br /> There is some overlap with QNetworkInterface, but that is a passive api.<br /> The fallback bearer implementation works by polling QNetworkInterface, but the real implementations use OS specific event driven <span class="caps">API</span>s.
 
An important concept is the “service network”, which is an ordered list of network configurations<br /> (e.g. “home <span class="caps">WLAN</span>”, “office <span class="caps">WLAN</span>”, “3G data”); and the “default configuration”, which is the user’s preferred choice according to global configuration in the OS. The default configuration normally is a service network where the OS supports this.
 
The bearer <span class="caps">API</span> is used elsewhere in the network module, e.g. QNetworkAccessManager starts the default configuration unless it has been configured differently. QNetworkProxy::systemProxyForQuery can use a network configuration to make sure the correct proxy is used in multihoming situationss.
 
* qnetworkconfigmanager – enumeration of network configurations, notification of configuration changes
* qnetworkconfiguration – data type for a network configuration
* qnetworksession – used to open/start a network configuration, and keep active for the object lifetime
* qsharednetworksession – A thread local singleton used by QNetworkAccessManager
* qbearerengine – interface to the backend
* qbearerplugin – plugin loading
 
=Areas for improvement=
 
* QAuthenticator (in the backend – the public interface is fine)
* QFtp (withdrawn as a public <span class="caps">API</span> in Qt5)
* QNetworkConfigurationManager (first construction blocks the thread for a noticable time)
* sockets in sockets (QSslSocket, QHttpSocketEngine, QSocks5SocketEngine) each have a QAbstractSocket, leading to multiple levels of buffering and potential for racy shutdown
* loading ssl certificates is slow and blocking (except linux which uses openssl demand loading, which only supports files)
* we should support plugins for <span class="caps">URL</span> scheme handlers (e.g. ldap:) so that other Qt modules or applications themselves can get new types of url using QNetworkAccessManager.
* see also [https://bugreports.qt.io/secure/IssueNavigator.jspa?mode=hide&requestId=12960 <span class="caps">JIRA</span>] ''[bugreports.qt.io]''

Latest revision as of 13:22, 8 October 2018

The Qt Networking stack lives in qtbase/src/network/ and its associated test infrastructure in qtbase/tests/auto/network-settings.h with build-support in qtbase/tests/auto/testserver.pri for the new containerised test server.

Retrieved from "https://wiki.qt.io/index.php?title=Category:Developing_Qt::Network&oldid=34575"