[Development] Notes from QtNetwork sessions

[shane.kearns at accenture.com]

From: Xizhi Zhu [mailto:xizhi.zhu at gmail.com]
> Do we have the mutex / blocking issues for the bearer tracked on Jira? I guess it needs some design,
> including the blocking constructor, before we really start to fix it.

There have been a number of issues in JIRA, most have been P1 emergencies for a given platform.
Over time it gives the impression that the bearer design is flawed, though I think we can live with the API.

My design thought is that the bearer backends (plugins) should only be called from the bearer thread.
That would mean having a proxy QObject in the bearer thread that communicates via signals with the public API classes that live in the user thread (e.g. QNetworkConfigurationManager)

Decoupling in this way would remove the mutexes, and relax the requirement for the backend plugins to be thread safe.
I think a problem has been that people implementing backend plugins haven't realised they needed to be thread safe until it starts crashing in system tests.

(I wish we had a whiteboard for this - design discussions are where the mailing list & IRC are least satisfactory)

The disadvantage is that the front end information can be out of date if the event loop isn't called to process queued signals. This is somewhat implied already due to the update API with a completion signal that already exists.

>> * The API currently lists the available wireless lans, thiago thinks that it
>>   should not do this and should say that the device can do wireless.
>IIRC, one background for this feature is that for Symbian the application can choose AP it connects. But I guess it's >not the case for most other systems, where the connection is chosen by the system. So, yes, +1 from me.

At least linux/windows/mac work like that (and the last releases of Symbian encourage using AP groups like "internet" over specific APs too).
I'd like input on what influence applications have (if any) on AP selection in Android / Blackberry

Multihoming is actually quite common if you consider VPNs.
(e.g. intranet traffic goes to the VPN, and everything else goes to the real network adaptor by default)

>> * Should we simply say if we're connected.
> QNetworkConfigurationManager::isOnline() is already doing this. But it's more useful especially for mobile devices to
> know which network type (3G or WLAN) it's using. (Or maybe I mis-understoodd this?)

The question was related to how much information needs to be available immediately after constructing QNetworkConfigurationManager. Currently the constructor blocks on the bearer thread doing an initial update.

>> * We should let people know what type of connection it is. (e.g. roaming / home 3G networks / WLAN)
> +1. There was some discussion before about merging some of the APIs exposed from QNetworkInfo
> (http://doc-snapshot.qt-project.org/5.0/qnetworkinfo.html) to the bearer class, e.g. QNetworkInfo::NetworkMode
> is more or less a duplicate of QNetworkConfiguration::BearerType. And QNetworkInfo::NetworkStatus is what we need here.

OK, so at least the information is available through another API for the common case where you have one 3G modem.
It would make sense to get this information in QNetworkConfiguration as well.
Unfortunately we have a dual meaning of "roaming" which is used for the QNetworkSession handover to another bearer as well as roaming on another 3G/GPRS data network.

________________________________
Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy.
______________________________________________________________________________________

www.accenture.com