[Development] Notes from QtNetwork sessions

[Thiago Macieira]

On segunda-feira, 25 de junho de 2012 12.35.32, shane.kearns at accenture.com 
wrote:
> 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)

It would be better if the plugin were thread-safe, but it looks like the low-
level OS interface often isn't. Better to have a thread.

I think I need to do the same for QtDBus, otherwise this problem might show up 
again. That is, a bearer plugin is running in a separate thread, but the main 
thread (where the D-Bus socket is handled) is blocked waiting for the plugin 
to make up its mind.

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

I was entirely driven by the Internet-capable devices I've owned in the past 5 
years: in almost all cases, the application does not decide which AP to 
connect to. It simply asks to connect and the system does it (or not, like my 
laptop).

We can have an API for selection of AP, if we deem it necessary for the 0.1% 
of the applications. But that should not have a performance impact in the 
general case.

We discussed that general case and concluded that almost all applications are 
simply asking for whether the device is connected or could connect. They don't 
need to know which APs are in range, and neither does the system need to know 
whether APs in range are known: since the device could move into or out of 
range of a known AP in the meantime or the connection could fail when 
attempted, the presence of known APs is no guarantee.

> 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)

When I think "multihoming", I think different routes to reach the same server. 
Usually, that means two default routes. That happens when there's one device 
that has two adapters connected to the Internet.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120625/04ba37ed/attachment.sig>