QtNetwork-Internals: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
 
No edit summary
Line 1: Line 1:
=Introduction=


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]''

Revision as of 11:41, 24 February 2015

Retrieved from "https://wiki.qt.io/index.php?title=QtNetwork-Internals&oldid=5461"