J'ai eu le même problème et franchement, j'ai fini par refaire mes propres classes. Pour deux raisons :
- Les libs que l'on trouve sur la toile sont soit des APIs Windows, soit des outils qui ont été faits dans les mêmes conditions que les tiennes. Il n'y a donc aucune garantie que ces trucs soient plus propres ni plus faciles à utiliser que ce que tu vas produire. Honnêtement, je n'ai pas cherché plus longtemps que çà non plus, mais si ce n'est pas destiné à un gros projet open-source servant de référence et repris par des dizaines de personnes, la recherche et l'investissement personnel deviennent plus importants que la rédaction de son propre code (ce n'est évidemment pas vrai pour tous les cas de figure).
- L'API des sockets BSD est à s'arracher les cheveux car c'était à la base une tentative d'universalisation de tous les modes de communication, et il ont essayé de couvrir large dès le départ. C'était une bonne idée, mais maintenant on se traîne depuis des décenies des choses qui ne servent à rien.
D'autre part, il y avait clairement une notion d'abstraction et de classification qui sont aujourd'hui caractéristiques de la programmation objet. Citons par exemple la notion d'adresse réseau sockaddr étendue en sockaddr_in mais par redéfinition. Même pas un union de structures puisque les familles de protocoles sont déclarées à postériori. Dans cette structure, une autre structure pour l'adresse en particulier, in_addr, laquelle ne contient en tout et pour tout qu'un seul et unique membre, un long de 32 bits !
A l'utilisation, on est obligé d'utiliser des cast explicites pour transformer un sockaddr_in en sockaddr général pour ne pas prendre de warnings à la compilation. Coté init, c'est pas triste non plus : le modèle a beau être cohérent, il est implémenté de telle manière que tout est à la charge du développeur : hton{sl}() à tout bout de champ à chaque fois qu'il faut changer une adresse, et obligé de spécifier à l'intérieur de chaque structure pourtant déjà spécialisé le type d'adresse (AF_INET), simplement pour que les fonctions dont on a dû abstraire les paramètres puisse les recaster dans l'autre sens en connaissance de cause. Au secours !
Par contre ...
... par contre, encapsuler tout ce merdier dans des classes n'est pas plus compliqué que d'écrire un programme réseau classique en C pour quelqu'un qui s'y est déjà collé, et on se retrouve au final avec trois ou quatre objets maximum, lequels ne sont pas dérivés plus loin. Du coup, la programmation des sockets qui a l'air si difficile en C semble très simple même avec ses propres objets.
Donc, d'expérience, ce qui est utile pour écrire un daemon text-based est :
- Ses propres sockets (ci-dessus).
- Un analyseur de regexp (en encapsulant encore les routines C système).
- Un mini-parser. Pas besoin de réécrire yacc, mais il n'y a rien de mieux qu'une grammaire BNF pour décrire la syntaxe d'une ligne valide.
- Un petit automate à pile. On trouve les classes, cette fois, mais ce n'est pas bien dur non plus de refaire le sien une fois pour toutes.
A partir de là, tu peux déclencher un événement sur n'importe quel flux d'entrée. En te démerdant bien, tu peux faire un programme complètement coopératif sans avoir besoin de pondre un thread.
# Sockets C - C++
Posté par Obsidian . En réponse au message choix pour l'écriture d'un serveur en C++. Évalué à 6.
- Les libs que l'on trouve sur la toile sont soit des APIs Windows, soit des outils qui ont été faits dans les mêmes conditions que les tiennes. Il n'y a donc aucune garantie que ces trucs soient plus propres ni plus faciles à utiliser que ce que tu vas produire. Honnêtement, je n'ai pas cherché plus longtemps que çà non plus, mais si ce n'est pas destiné à un gros projet open-source servant de référence et repris par des dizaines de personnes, la recherche et l'investissement personnel deviennent plus importants que la rédaction de son propre code (ce n'est évidemment pas vrai pour tous les cas de figure).
- L'API des sockets BSD est à s'arracher les cheveux car c'était à la base une tentative d'universalisation de tous les modes de communication, et il ont essayé de couvrir large dès le départ. C'était une bonne idée, mais maintenant on se traîne depuis des décenies des choses qui ne servent à rien.
D'autre part, il y avait clairement une notion d'abstraction et de classification qui sont aujourd'hui caractéristiques de la programmation objet. Citons par exemple la notion d'adresse réseau sockaddr étendue en sockaddr_in mais par redéfinition. Même pas un union de structures puisque les familles de protocoles sont déclarées à postériori. Dans cette structure, une autre structure pour l'adresse en particulier, in_addr, laquelle ne contient en tout et pour tout qu'un seul et unique membre, un long de 32 bits !
A l'utilisation, on est obligé d'utiliser des cast explicites pour transformer un sockaddr_in en sockaddr général pour ne pas prendre de warnings à la compilation. Coté init, c'est pas triste non plus : le modèle a beau être cohérent, il est implémenté de telle manière que tout est à la charge du développeur : hton{sl}() à tout bout de champ à chaque fois qu'il faut changer une adresse, et obligé de spécifier à l'intérieur de chaque structure pourtant déjà spécialisé le type d'adresse (AF_INET), simplement pour que les fonctions dont on a dû abstraire les paramètres puisse les recaster dans l'autre sens en connaissance de cause. Au secours !
Par contre ...
... par contre, encapsuler tout ce merdier dans des classes n'est pas plus compliqué que d'écrire un programme réseau classique en C pour quelqu'un qui s'y est déjà collé, et on se retrouve au final avec trois ou quatre objets maximum, lequels ne sont pas dérivés plus loin. Du coup, la programmation des sockets qui a l'air si difficile en C semble très simple même avec ses propres objets.
Donc, d'expérience, ce qui est utile pour écrire un daemon text-based est :
- Ses propres sockets (ci-dessus).
- Un analyseur de regexp (en encapsulant encore les routines C système).
- Un mini-parser. Pas besoin de réécrire yacc, mais il n'y a rien de mieux qu'une grammaire BNF pour décrire la syntaxe d'une ligne valide.
- Un petit automate à pile. On trouve les classes, cette fois, mais ce n'est pas bien dur non plus de refaire le sien une fois pour toutes.
A partir de là, tu peux déclencher un événement sur n'importe quel flux d'entrée. En te démerdant bien, tu peux faire un programme complètement coopératif sans avoir besoin de pondre un thread.
Bon courage.