I. Réseau : que cache ce terme ?▲
La programmation réseau peut avoir une définition différente selon les personnes. Il peut s'agir de développement serveur, client, P2P, web, web services… mais aussi de base de données, d'administration de base de données, ou encore d'administration de serveurs, de mise en place de cron (appelé aussi "crontab"), d'installation des serveurs (de jeu, de lobby…) sur des machines.
Cette liste non exhaustive donne une vision des connaissances liées au domaine du réseau que l'on peut avoir. Les connaissances nécessaires dépendront essentiellement de la société/structure que vous intégrerez : une large structure pourra découper le travail entre plusieurs membres plus spécialisés, là où dans un studio indépendant de petite taille vous vous retrouverez souvent à programmer le serveur, le client, à gérer la base de données, voire installer et gérer les serveurs (machines).
II. Communiquer sur le réseau : une histoire de protocoles▲
La communication sur internet et sur un réseau de manière générale, est effectuée par des paquets IP (Internet Protocole). Les paquets IP sont ensuite acheminés par le routeur jusqu'à leur destination via les réseaux électriques. Bien que la création de paquets IP directement soit possible, on préférera manipuler des surcouches comme UDP ou TCP.
L'UDP (User Datagram Protocol - protocole de datagramme utilisateur) est un protocole "orienté hors connexion", ou "en mode non connecté". Il s'agit simplement d'envoyer des données à une machine distante telle une bouteille à la mer, en mode " fire and forget ". Les paquets peuvent être perdus et ne jamais arriver, arriver en plusieurs exemplaires ou dans le désordre. La seule garantie est que, si un paquet arrive, il arrive entièrement et non en partie. Dans tous les cas l'expéditeur n'a aucun retour pour le lui indiquer. Pas plus que le destinataire n'a conscience d'une perte ou que ce qu'il reçoit en triple exemplaire est une duplication d'un unique message original.
C'est idéal pour les données dont l'utilité est limitée dans le temps, dans le cas d'un streaming, par exemple, ou d'un jeu vidéo où seules les dernières positions nous intéressent.
Le TCP (Transmission Control Protocol - protocole de contrôle des transmissions) est un protocole "orienté connexion", ou "en mode connecté" et est un flux bidirectionnel : quand A est connecté à B, B est également connecté à A. De plus, il s'agit d'un protocole dit "fiable" puisqu'il nous assure que toutes les données envoyées seront reçues sans perte et dans le bon ordre. Tant que la connexion n'est pas perdue entre les deux parties, elles finiront forcément par arriver.
TCP sera principalement utilisé dans les architectures client/serveur, lorsqu'une connexion continue avec le serveur distant (et donc du serveur vers le client) est nécessaire. Mais la mise en place de ce mécanisme a un coût, notamment en temps nécessaire à l'acheminement des données.
D'autres protocoles basés sur IP existent, vous pouvez en voir la liste complète ici : https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers. En pratique, vous utiliserez toujours TCP ou UDP, sauf si vous travaillez dans une branche extrêmement précise (ICMP pour la gestion des erreurs, par exemple). Aussi ils ne seront pas abordés dans ce cours qui traite uniquement de TCP et UDP.
III. Multithreading▲
Le code réseau se retrouve le plus souvent en milieu multithread. Pour un serveur, il pourra s'agir d'un thread qui écoute les connexions et d'un autre qui gère les données qui arrivent. Chez un client on pourra recevoir en continu les données dans un thread dédié afin qu'un autre (éventuellement le thread principal) puisse en disposer quand il le souhaite et qu'elles sont prêtes.
Comme bibliothèque de threading je vous propose TBB (Threading Building Block).
Ou tout simplement la bibliothèque standard qui le propose désormais.
Les seules fonctions nécessaires seront:
- la classe thread pour exécuter une fonction dans un thread;
- la fonction join pour attendre la fin de l'exécution du thread;
-
les mutex - les mutex simples feront largement l'affaire - et leurs deux méthodes:
Les verrous sont à éviter autant que possible: ils entraînent une baisse de performances, de la contention et, dans le pire des cas non maîtrisé, un deadlock. Toutefois, il existe des cas où leur utilisation est indispensable et je vous invite à savoir les utiliser plutôt qu'à les craindre.
IV. Portée du cours▲
Le cours vous permettra de mettre en pratique des échanges via TCP ou bien UDP en C++, en utilisant l'API socket (nommée winsock2 sur Windows), qui est en C.
Chaque partie vous présentera les fonctions nécessaires à sa réalisation, directement suivi d'un TP de mise en pratique pour les appliquer immédiatement.
Travaillant sous Windows, et puisqu'il s'agit du principal écosystème sur lequel les professionnels travaillent, je vous conseille Visual Studio comme IDE. Il est disponible gratuitement pour les étudiants d'universités appartenant à l'Academic Alliance (MSDNAA, renseignez-vous auprès de votre école), mais aussi à tous en version Express/Community.
Les codes fournis sont testés sous Visual Studio 2013 et 2015 dans les chapitres TCP, puis Visual Studio 2017 sur les premiers chapitres UDP et enfin Visual Studio 2019 à partir des chapitres de sérialisation, toujours sous Windows 10 et devraient fonctionner sous Unix et iOS, et les précédentes versions de Windows. N’hésitez pas à me contacter si un problème survient sur un certain compilateur ou OS – en ouvrant un sujet sur le forum C++ - et nous pourrons trouver une solution.
V. Chapitres▲
V-A. TCP▲
V-B. UDP▲
- Premiers pas
- Gérer les pertes et duplications d’identifiants
- S’assurer du bon fonctionnement de son code: mise en place de tests
- Créer son protocole par-dessus UDP
- Découpage et unification de paquets et création d’un protocole ordonné
- Envoi de paquets ordonné fiable
- Combiner tous les protocoles: les canaux de communication
- Gérer des connexions entre machines
- Debugger une application en réseau
V-C. Jeux▲
V-D. Divers▲
VI. Remerciements▲
Merci à LittleWhite, Francis Walter et François DORIN pour les relectures techniques.
Ainsi qu’à jacques_jean, f-leb, ClaudeLELOUP et Malick SECK pour les corrections orthographiques.