Speeding Up Your Qt App with New QtNetwork Features

Peter Hartmann




Friday, November 8, 2013 - 4:00pm to 5:00pm


Salon G/H

Presenter Bio

Peter is a software developer at BlackBerry, and has worked on Qt for the last 5 years, focusing mainly on networking areas (HTTP, SSL etc.) and other core areas like XML. He used to be the maintainer of the QtNetwork module, and has presented networking topics at the past 3 DevDays events.

Peter has previously worked for Trolltech and Nokia, and then joined BlackBerry one year ago, and helped porting Qt to the QNX and BlackBerry platforms.

At BlackBerry, he is busy keeping QtNetwork in shape, which is the network stack for all Cascades-based apps like Facebook, Twitter, LinkedIn, Foursquare etc.


Are you writing a Qt application that uses the network? Are you e.g. using data from Facebook, Twitter or Instagram? Then this presentation might help you get data from the Web faster. Usually, performance improvements on the network layer outperform improvements in e.g. the file system by around one order of magnitude. Often network speedups are in the range of hundreds of milliseconds, which is very hard or even impossible to achieve in any other layer of the Qt framework. Improving network latency will often create a speedup that is immediately visible. QtNetwork gained some new features in 5.1 and 5.2 that improve performance quite a bit. However, most of this new API will not be used unless the app developer enables it explicitly in his app. Some of these features include:

* API for making DNS lookup, TCP handshake, or SSL handshake before sending the actual HTTP request:
   If an app always needs to connect to the same server at startup, it could
   open the socket first thing when starting up (and if needed also do the SSL
   handshake), and then once all credentials for the HTTP request are ready,
   send it on the open socket; this can save several network round trips.

* SSL session resumption:
   If Qt has already made a SSL handshake to a server, it automatically re-uses
   SSL sessions upon connecting other sockets, saving one network round trip.

* Persisting TLS client sessions locally and reusing them:
   Even though SSL sessions are resumed on the second socket connected to a
   server, it still needs to make a full handshake on the first socket. However,
   the server often sends a TLS session ticket, which can be persisted locally
   (e.g. to disk or to a database) and then re-used on the first socket when
   connecting, saving one network round trip.

This talk will show you exampless on how to use these new features, as well as give some general practice on how to use QtNetwork in your application.

Presentation Track