Computer systems manage their network interfaces via a set of configurations. Each configuration describes a set of parameters which instruct the system how a particular network interface is started. One of the most simplistic examples might be an Ethernet configuration that links a network card to a DHCP server. A more complex example might be a Wireless LAN configuration which may comprise of hardware details such as the WLAN card address, WLAN access point details (e.g ESSID, encryption details) and user specific information (for example username and password). Once the network interface was configured and started according to the configuration blue print, multiple applications are free to use this link layer connection/session for their own socket operations. This API carefully distinguishes a network session and the network connections (represented by socket sessions) which it supports.
The distinction between physical network interfaces, their mappping to multiple configurations, how such a mapping can create an active link layer connection and a network connection that can be created once the session has been established is important to understand the various elements of this API. The Bearer Management API in conjunction with QNetworkInterface follows the same principle. QNetworkInterface already provides the required abstraction for physical network interface. In addition QNetworkConfiguration encapsulates a network configuration which can be used to create, destroy and monitor link layer connections (represented by QNetworkSession object).
Service networks
Some mobile platforms use the concept of grouped access points (also called SNAP or Service Network Access Point). In principle multiple configurations are grouped together and possibly even prioritized when compared to each other. This is useful for use cases where all configurations serve a similar purpose or context. A common context could be that they provide access to the public Internet or possibly only to the office Intranet. By providing a pool of configurations the system can make a decision based on given priorities which usually map to factors such as speed, availability and cost. Furthermore the system can automatically roam from one access point to the next one while ensuring minimal impact on the user experience.
The QNetworkConfiguration::Type flag specifies to what category a configuration belongs. The QNetworkConfiguration::InternetAccessPoint type is the most common example. It represents a configuration that can be used to create a session. The above mentioned grouping behavior is provided by QNetworkConfiguration::ServiceNetwork configurations. Service networks are place holders until such time when the user attempts to open() a new session. At that point in time the system determines which of the configurations QNetworkConfiguration::children() is best to use. A service network can only have one level of indirection which implies children can only be of type QNetworkConfiguration::InternetAccessPoint.
Most systems allow the user to define the systems default configuration. Usually the default behavior is either a service network, a particular internet access point or the user instructs the platform to ask the user once an application requests the network. User interaction is generally implemented by some sort of system dialog which shows up at the appropriate point in time. The application does not have to handle the user input. This API provides the QNetworkConfigurationManager::defaultConfiguration() call which serves a similar purpose. The subsequent code snippet provides a quick way how an application can quickly create a new network session without having to interact with the user:
QNetworkConfigurationManager manager;
const bool canStartIAP = (manager.capabilities() & QNetworkConfigurationManager::BearerManagement);
QNetworkConfiguration cfg = manager.defaultConfiguration();
if (!cfg.isValid() || !canStartIAP)
return;
switch(cfg.type()) {
case QNetworkConfiguration::InternetAccessPoint:
break;
case QNetworkConfiguration::ServiceNetwork:
break;
case QNetworkConfiguration::UserChoice:
break;
}
QNetworkSession* session = new QNetworkSession(cfg);
session->open();
To accommodate the "Ask user" use case the default configuration can be of type QNetworkConfiguration::UserChoice. A user choice configuration is resolved as part of the QNetworkSession::open() call. Note that a UserChoice configuration is only ever returned via QNetworkConfigurationManager::defaultConfiguration() and not QNetworkConfigurationManager::allConfigurations().
On systems which do not maintain a list of defaultConfiguration() an invalid configuration is returned. A possible workaround could be to implement a custom dialog which is populated based on what QNetworkConfigurationManager::allConfigurations() returns.
Managing network sessions
A QNetworkSession object separates a state() and an isActive() condition.
The state() attribute enables developers to detect whether the system currently maintains a global network session for the given QNetworkConfiguration. If isActive() returns true the QNetworkSession instance at hand was at least one of the entities requesting the global network session. This distinction is required to support the notion of session registrations. For as long as there are one or more active QNetworkSession instances the underlying network interface is not shut down. Therefore the session state() can be used to monitor the state of network interfaces.
An active session is created by calling QNetworkSession::open() and closed via QNetworkSession::close(), respectively. If the session is disconnected at the time of the open() call the underlying interface is started; otherwise only the reference counter against the global session is incremeted. The opposite behavior can be observed when using close().
In some use cases it may be necessary to turn the interface off despite of active sessions. This can be achieved by calling stop(). An example use case could be a network manager type of application allowing the user to control the overall state of the devices connectivity.
Global (inter-process) session support is platform dependent and can be detected via QNetworkConfigurationManager::SystemSessionSupport. If the system does not support global session calling close() never stops the interface.
Roaming
Platform capabilities
Some API features are not available on all platforms. The QNetworkConfigurationManager::Capability should be used to detect platform features at runtime. The following table lists the various platform API's being used by this API. This may assist in the process of determining the feature support:
Platform | Backend capabilities |
Linux® | Linux uses the NetworkManager API which supports interface notifications and starting and stopping of network interfaces. |
Windows® XP | This platform supports interface notifications without active polling. |
Windows XP SP2+Hotfixes, Windows XP SP3, Windows Vista, Windows 7 | In addition to standard Windows XP wifi access point monitoring has been improved which includes the ability to start and stop wifi interfaces. This requires Windows to manage the wifi interfaces. |
Symbian® Platform & S60 3.1 | Symbian support is based on Symbian platforms RConnection. In addition to interface notifications, starting and stopping of network it provides system wide session support and direct connection routing. |
Symbian Platform & S60 3.2+ | This platform enjoys the most comprehensive feature set. In addition to the features support by the S60 3.1 Network roaming is supported. |
All other platforms (*nix, Mac OS®, Windows Mobile) | This backend is the fallback for all platforms supports network interface notifications via active polling only. |
Examples
Bearer Cloud Example
The Bearer Cloud example graphically represents the available access points to various networks and their sytlized distance from the user.
Bearer Monitor Example
The Bearer Monitor displays various networks or services by status and configuration.
Classes