Qt Network

Accéder au réseau

1. Portée de Qt Network

Qt Network intervient sur les couches 3 à 7 du modèle OSI.

Son utilisation est liée, la plupart du temps, au téléchargement de fichiers sur un serveur FTP, à la connexion à un serveur web HTTP ou de courrier. Tous les protocoles situés dans la couche 7 (application) sont exploitables par les programmes Qt. En effet, Qt nous fournit des API pour échanger des données avec d’autres machines en utilisant les protocoles TCP et UDP. Les échanges peuvent aussi être sécurisés grâce à l’utilisation de certificats SSL pour le chiffrement des communications (HTTPs ou FTPs par exemple).

Qt ne propose aucune implémentation des protocoles de la couche 7, en dehors de DNS et FTP. Vous ne trouverez pas d’API qui permette d’échanger des fichiers avec le protocole CIFS par exemple.

Voici les possibilités offertes par Qt Network :

• Couche 3 : adresse IPv4 et IPv6.

• Couche 4 : socket client et serveur TCP, socket UDP.

• Couche 5 : proxy Socks 5, certificats SSL.

• Couche 7 : résolution DNS, client HTTP, client FTP.

Sockets

Les classes de socket QTcpSocket et QUdpSocket héritent toutes les deux de la classe abstraite QAbstractSocket qui définit la quasi-totalité des fonctions dont elles disposent. Cette dernière hérite elle de QIODevice, tout comme QFile. La gestion d’un socket s’effectue donc de la même manière que celle d’un fichier et les flux de données se gèrent aussi de la même manière. Tout ce qui est possible avec un fichier l’est avec un socket.

Les exemples que nous fournissons sont tous orientés asynchrone. Nous utilisons les signaux, les slots et l’héritage de QObject.

public : 
 
   Controleur::Controleur(QObject* parent = nullptr)  
   : QObject(parent), socket_(new QTcpSocket(this))  { } 
 
private : 
   QTcpSocket* socket_ ;  

socket_->connectToHost("www.editions-eni.fr"...

Internet

dns_->setName("www.editions-eni.fr") ; 
dns_->lookup() ; 

dns_->setType(QDnsLookup::AAAA) ; //La résolution se fera sur IPv6 

Les interfaces réseau

Qt permet aussi de gérer les interfaces réseau et plus généralement la connectivité du point de vue du système. Cela comprend notamment la gestion des interfaces réseau.

La liste des interfaces réseau, qu’elles soient virtuelles, locales, physiques selon le protocole Ethernet, ou distantes en point à point, est gérée par la classe QNetworkConfigurationManager. Pour connaître la liste des interfaces réseau disponibles, il suffit d’appeler la fonction allConfigurations() qui retourne une instance de QList<QNetworkConfiguration>. La connexion par défaut, c’est-à-dire le plus souvent la connexion active, est obtenue grâce à un appel à la fonction defaultConfiguration().

La classe QNetworkConfiguration fournit des informations variées sur l’état (active ou inactive) et le type de connexion (LAN, WLAN, 2G/3G/4G, Bluetooth, etc.).

QNetworkConfigurationManager ncm; 
QList<QNetworkConfiguration> confs = ncm.allConfigurations(); 
QListIterator<QNetworkConfiguration> it(confs); 
 
while(it.hasNext()) 
{ 
    QNetworkConfiguration conf = it.next(); 
    qDebug() << "Configuration : " << conf.name(); ...

Les objets distants

Derrière ce terme se cache tout un monde de possibilités pour les développeurs d’applications. Même s’il n’est pas indispensable d’avoir une connexion réseau pour réaliser des appels distants entre deux applications sur un unique appareil, le principe même de ce type d’exécution est fortement lié aux principes des réseaux, c’est la raison pour laquelle nous avons choisi d’intégrer cet ajout dans le chapitre sur Qt Network.

Le mécanisme des objets distants est proche des appels de fonctions distants (RPC) qui est très ancien et qui a fait l’objet de différentes implémentations. En Java il s’agit de RMI, en Web il s’agit de XML-RPC ou plus généralement des webservices. Ce qu’on souhaite faire, au départ, avec des appels distants est d’alléger le client pour centraliser certaines fonctions sur un serveur. C’est le principe du client léger.

Il est proche mais pas tout à fait équivalent. Il est décrit par les ingénieurs de Qt comme de la communication interprocessus (IPC) car il étend les fonctionnalités de Qt pour les rendre utilisables à distance.

Ce type de mécanismes sont à la base d’un nouveau paradigme d’architecture logicielle : les microservices. L’idée...

Mécanismes communs

Les différences sont mineures entre les deux types de connexion, sur le plan de l’architecture logicielle et du code. C’est un peu comme de brancher un câble Ethernet directement sur un PC ou bien sur un switch réseau.

La première étape est la création du contrat d’interface entre les nœuds. Cela passe par la création d’un fichier portant l’extension .rep.

class Slider 
{ 
 PROP(int valeur=0); 
 SLOT(server_slot(int valeurRecue)); 
} 

Nous venons de déclarer une classe en utilisant un certain nombre de macros de Qt. En effet, ce fichier sera traité et compilé par l’utilitaire repc (Qt Remote Objects Compiler) et transformé en une classe avec des propriétés et des fonctions. 

La macro PROP a le même effet que la macro Q_PROPERTY, elle permet de déclarer une propriété nommée valeur avec ses accesseurs et son signal.

La macro SLOT sert à créer un slot qui sera appelé du côté du client lorsque le signal aura été reçu. Dans notre exemple, nous provoquerons un acquittement de la réception du signal afin d’informer le serveur que le signal a bien été reçu.

Dans le fichier .pro du projet, vous devez à présent ajouter plusieurs déclarations :

QT += remoteobjects 

ainsi que :

REPC_SOURCE = Slider.rep 
REPC_REPLICA = Slider.rep 

Ces deux dernières déclarations permettent de déclarer le contrat d’interface de la Source et du Replica. Bien entendu, si vous séparez le client et le serveur en plusieurs applications, vous effectuerez ces déclarations dans des projets séparés. REPC_SOURCE n’est nécessaire que pour le serveur et REPC_REPLICA n’est nécessaire que pour les réplicas.

Ensuite, exécutez qmake et compilez le projet. Deux nouveaux fichiers ont été créés par l’utilitaire...

Connexion via un concentrateur

Dans l’hypothèse où vous auriez plusieurs Replicas à connecter à une Source, vous devrez créer un Registry, sorte de concentrateur permettant de copier et rediriger les signaux entre les différents nœuds.

La représentation graphique de ce type de connexion est :

La seule différence avec la connexion point à point que nous avons vue précédemment se situe dans la configuration des nœuds.

Reprenons le code du contrôleur EcranServeur et ajoutons quelques lignes pour instancier le Registry :

EcranServeur.h

private: 
 ...  
 QRemoteObjectRegistryHost *registryNode_ = nullptr; 

EcranServeur.cpp :

EcranServeur::EcranServeur(QWidget *parent) : QWidget(parent)  
 , registryNode_(  
   new QRemoteObjectRegistryHost(  
     QUrl("local:registry")  
     , this)  
  )  
 , srcNode_(new QRemoteObjectHost(  
      QUrl("local:slider")  
      , QUrl("local:registry")  
      , QRemoteObjectHost::BuiltInSchemasOnly  
      , this  
  ))  
 
{ ... } 

Nous avons donc...