Sockets et IPC réseau

#Communications entre processus par socketsCopier le lien

Les sockets offrent une API uniforme pour relier deux processus, que ce soit sur la même machine (sockets Unix) ou à travers un réseau (sockets IP). Un serveur installe un point d'écoute ; un client s'y connecte ; des octets transitent dans les deux sens.

#1. Cycle serveur-clientCopier le lien

Côté serveur, la chorégraphie suit toujours la même séquence : socket, bind, listen, puis une boucle accept qui récupère les connexions entrantes. Côté client, un simple connect suffit à établir le canal. Une fois la poignée de main terminée, les deux extrémités disposent d'un flux bidirectionnel que send/recv ou read/write peuvent manipuler. Les tampons noyau stockent temporairement les données ; si le lecteur ne suit pas, l'écrivain est bloqué ou reçoit EWOULDBLOCK en mode non bloquant.

1int server = socket(AF_INET, SOCK_STREAM, 0);2bind(server, (struct sockaddr *)&addr, sizeof addr);3listen(server, SOMAXCONN);4for (;;) {5    int client = accept(server, NULL, NULL);6    handle(client);7    close(client);8}

Ce squelette constitue la base d'innombrables serveurs, du démon SSH au proxy HTTP.

#2. UDP, sockets Unix et multiplexageCopier le lien

UDP (type SOCK_DGRAM) ne crée pas de connexion persistante. Chaque datagramme transporte sa propre adresse source ; l'application doit gérer les pertes éventuelles. À l'opposé, les sockets Unix (AF_UNIX) ne sortent pas de la machine locale : elles transmettent des fichiers de descripteurs et offrent de meilleures performances pour l'IPC interne. Les serveurs à grande échelle utilisent souvent des sockets non bloquantes combinées à select, poll, epoll ou kqueue pour surveiller plusieurs connexions sans monopoliser des threads.

#3. Protocoles applicatifsCopier le lien

Construire une API par-dessus des sockets nécessite de définir un format de message (texte, binaire), un framing (longueur en tête, séparateur), un protocole d'erreur et, idéalement, une observabilité (logs structurés, métriques). Sans ces éléments, le moindre problème réseau devient difficile à diagnostiquer. Les sockets TLS viennent ajouter une couche de chiffrement et d'authentification, mais la logique applicative reste identique.

#AtelierCopier le lien

Implémentez un micro-serveur TCP qui renvoie l'heure courante à chaque client. Commencez avec des sockets bloquantes pour valider la logique, puis refaites le même exercice en mode non bloquant avec select. Sur la même base de code, créez une variante AF_UNIX afin de mesurer la différence de latence entre communication locale et réseau.