Plusieurs fois (pour des projets Epitech notamment), j’ai eu à faire ce qu’on appelle des sockets Unix en C…

Des chaussettes unies haussées ?

Autrement dit, des programmes sur le modèle client/serveur qui se connectent via le protocole TCP/IP dans un environnement Unix (comme par exemple Linux), codés en C.

(Si vous n’avez pas compris ces premières lignes, inutile, j’en ai peur, d’en lire davantage… 😉

Des chaussettes difficiles à enfiler

Une socket est, en quelque sorte, un point d’entrée et de sortie de données échangées sur le réseau (ou localement !) que l’on doit ouvrir avant de pouvoir s’en servir.

J’ai eu à coder quelques programmes réseau en C sous Linux et il est, à chaque fois, des tâches par lesquelles on est obligé de passer :

• ouvrir la socket
• la mettre en service
• écouter et parler sur la socket

J’ai toujours trouvé ce procédé fastidieux. Par exemple, pour rendre opérationnelle une socket serveur, il ne faut pas moins de cinq appels de fonction (plus un pour accepter de nouveaux clients, une fois la socket dispo) ! Ce n’est guère beaucoup plus facile avec une socket client qui en demande quatre.

Et ce n’est que le début, car il faut ensuite communiquer avec, et cela de manière fiable, sans perte de données, etc… 🙂   C’est précisément pour cela que pour ce genre de procédé, on utilise généralement des buffers circulaires, autant pour des raisons pratiques que de place (ça prend une taille fixe)…

 

Une affaire réglée en deux coups de fonction à pot

Bref c’est galère. Alors pour éviter d’avoir à recoder tout ça à chaque fois, j’ai fait une mini-lib qui fait tout ça, avec quelques fonctionnalités en plus.

En résumé :

• une structure de type « t_sock » représentant une socket et tout ce qu’elle a besoin de contenir ;
• deux fonctions, create_socket et enable_socket, permettent une création et une mise en service facile de la socket, qu’elle soit serveur ou client ;
• deux fonctions de lecture/écriture read_from / send_to_socket, permettent de facilement recevoir et envoyer des données (les buffers circulaires sont embarqués dans la structure) ;
• un système de messages d’erreur (net_perror), pour afficher si on veut un message d’erreur ;
• un système de log dans un fichier (net_log_on / off)

Le code source et toute la documentation nécessaire est sur mon dépôt Bitbucket.

 

Foire Aux Questions

 

Comment on installe tout ça ?

RTFM ! (Téléchargez le dépôt GIT et lisez le contenu du dossier DOCUMENTATION ! 🙂 )

Je n’arrive pas à compiler ou utiliser la bibliothèque sur mon HipsterBSD ou mon Windows, c’est normal ?

Je n’ai pas du tout produit ce code dans le but d’être portable : c’est avant tout une bibliothèque pour mon usage personnel, venant de et destiné à un Linux 64 bits, que je partage à qui que ça puisse intéresser, c’est tout ! Et bien qu’il s’agisse de sockets UNIX, je ne garantis pas que ça marche sur un BSD, par exemple… (Il serait intéressant de tester !)

Je trouve que tu devrais ajouter une killer feature à cette lib / j’ai réussi à faire planter ta lib ! Va-t-il y avoir des améliorations / corrections ?

Vous pouvez toujours laisser un commentaire à cet article ou m’envoyer un mail ! J’essayerai d’être le plus réactif possible…

J’ai le droit de réutiliser cette lib n’importe comment ?

Non : j’ai placé mon code sous la LGPL. Wikipédia expliquera bien mieux que moi les termes de cette licence.

Pourquoi ne pas avoir fait une bibliothèque statique (en .a) ?

Une question assez technique. J’étais en réalité parti au début sur l’idée d’une bibliothèque statique, jusqu’à ce que le compilateur, GCC, me sorte ce warning :

Traduction : « coco, ce que tu fais c’est risqué ». C’est ainsi que j’ai pris la décision de faire une librairie dynamique. Ça marche tout aussi bien. J’ai trouvé un post sur Stack Overflow parlant de ce problème, et expliquant que les librairies dynamiques sont même mieux que les statiques : clic.

 

Bon ben voilà. Si vous avez d’autres choses à dire ou à proposer, laissez un petit commentaire…