A partir d'un des exemples de ce dépôt de code je vous propose une explication du fonctionnement de base du composant TSocket fourni avec l'unité System.Net.Socket.
Les sockets sont la base de la connexion entre deux logiciels sur un réseau éthernet. Ils autorisent un dialogue dans les deux sens une fois la connexion établie.
Plusieurs protocoles et modes de diffusion des données sont possibles. Le plus classique pour dialoguer entre des clients et un serveur est la connexion en TCP pour s'assurer que ce qui part arrive à destination.
Pour dialoguer on a en fait deux sockets réseau impliqués :
- un sur le serveur qui est ouvert en permanence et autorise la connexion des clients sur une ou plusieurs adresses IP et un port fixe
- un ouvert entre client et serveur qui sert à l'échange de données
Le serveur ouvre un socket et se met en écoute dessus (IPs+port).
Un client se connecte sur ce port. S'il est accepté un autre socket est créé sur le serveur avec un port dédié à ce client. Ils peuvent ensuite discuter sur ce canal dédié.
Comme le travail principal sur les sockets consiste à faire une boucle d'écoute, il est fortement recommandé d'utiliser des processus séparés pour ne pas bloquer l'interface utilisateur ou le reste du fonctionnement des programmes impliqués.
Comme tout dépend du port le nombre de sockets disponibles sur une machine est limité par conception.
Certains ports sont associés à des services recensés et/ou normalisés. Par exemple le port 80 pour le protocole http, 21 pour le FTP, ...
En pratique on fait ce qu'on veut mais un seul (logiciel) serveur peut se mettre en écoute sur un port d'une adresse IP.
Le tout est verrouillé par les pare feux installés sur les systèmes d'exploitation ou sur les réseaux.
Selon ce qu'on fait il peut être plus ou moins compliqué de faire ce que l'on veut sur autre chose que nos postes de développement. Alors soyez méfiants et faites des tests en dehors de vos appareils et réseaux habituels avant de mettre un projet en production. Et évitez d'utiliser le port d'un service normalisé pour autre chose.
Dans le projet de démo utilisé dans cette vidéo je suis parti sur un seul programme servant à la fois de client et de serveur. Rien ne nous en empêche (mais c'est un peu idiot de le faire dans de vrais projets car ça peut avoir des effets de bord alors qu'il y a bien d'autres façons pour discuter à l'intérieur du même programme).
Si vous ne voulez pas gérer la partie échange et réseau vous pouvez aussi utiliser la librairie "socket messaging" que j'ai créée pour simplifier tout ça et ne pas réinventer la roue à chaque fois. Il suffit de définir l'interface entre client et serveur sous forme de messages avec le programme de génération de code, de coder ce qu'on fait quand on reçoit les messages puis ce qu'on envoit. Ca devrait vous faire gagner un temps fou pour communiquer en TCP/IP.
