meilleur moyen d'écrire un démon Linux [fermé]

Question

Pour le travail, j’ai besoin d’écrire un démon tcp pour répondre au logiciel de notre client et je me demandais si quelqu'un avait des conseils sur la meilleure façon de procéder.

Dois-je créer une fourchette pour chaque nouvelle connexion, comme d'habitude j'utiliserais des threads?

Answer 1

Cela dépend de votre application. Les threads et les conversions peuvent être des approches parfaitement valables, ainsi que la troisième option d'un modèle à événement unique. Si vous pouviez expliquer un peu plus précisément ce que vous écrivez, il serait utile de donner des conseils.

Pour ce que cela vaut, voici quelques directives générales:

• Si vous n'avez pas d'état partagé, utilisez le forking.
• Si vous avez un état partagé, utilisez des threads ou un système piloté par les événements.
• Si vous avez besoin de hautes performances avec un très grand nombre de connexions, évitez de créer des fardeaux, car leur temps système est trop élevé (en particulier, l'utilisation de la mémoire). Utilisez plutôt des threads, une boucle d'événement ou plusieurs threads de boucle d'événement (généralement un par CPU).

En règle générale, la conversion est la plus facile à mettre en oeuvre, car vous pouvez essentiellement ignorer toutes les autres connexions une fois que vous avez créé une fourchette; les threads les plus difficiles en raison des exigences de synchronisation supplémentaires; la boucle d'événements est plus difficile en raison de la nécessité de transformer votre traitement en une machine à états; et plusieurs threads exécutant des boucles d’événements, le plus difficile de tous (en raison de la combinaison de plusieurs facteurs).

Answer 2

Je suggérerais de chercher des connexions sur les threads tous les jours. Le problème des threads est l’espace mémoire partagé et la facilité avec laquelle il est possible de manipuler la mémoire d’un autre thread. Avec les processus forkés, toute communication entre les processus doit être faite intentionnellement par vous.

Il suffit de chercher et de trouver cette réponse SO: Quel est le but de fourchette? . Vous connaissez évidemment la réponse à cette question, mais la réponse n ° 1 de ce fil contient de bons arguments sur les avantages de fork ().

Answer 3

En dehors de la bonne réponse de @ hobodave, un autre avantage de "forking par connexion" est que vous pouvez implémenter votre serveur très simplement, en utilisant inetd ou tcpserver ou similaire: vous pouvez ensuite utiliser l’entrée standard et la sortie standard pour communiquer avec le socket ne devez pas faire de gestion de socket d’écoute (écoute des connexions, etc.), etc.

Answer 4

Une autre option, bien sûr, consiste à pré-numéroter plusieurs copies du démon, de les laisser en vie et de continuer à répondre aux requêtes. Tout dépend notamment de votre application, de la charge attendue et des exigences de performances.

Le moyen le plus simple et le plus simple consiste à écrire un démon basé sur inetd; votre logiciel peut ignorer le fait qu'il fonctionne sur une connexion TCP et simplement gérer les entrées / sorties via stdin / stdout. Cela fonctionne bien dans la grande majorité des cas.

Answer 5

Si vous ne prévoyez pas recevoir beaucoup de nouvelles connexions par seconde, envisagez de lancer inetd. Sinon ...

Téléchargez la source OpenSSH. Ils ont mis beaucoup de travail dans la séparation des privilèges juste, il est portable, et la sécurité a été examinée plus que toute autre chose.

Adaptez-le à vos besoins, vous pouvez probablement en jeter l'essentiel. Respectez le contrat de licence bien sûr. Suivez les futurs patchs avec un bon CSC.

Ne vous inquiétez pas des performances du forgeage des processus par rapport aux threads tant que vous n’avez pas la preuve que c’est un problème réel. Apache a fonctionné pendant des années et des années sur les sites les plus occupés avec un modèle simple, processus par client.

Si vous êtes vraiment ambitieux, vous pouvez utiliser une sorte de modèle d'E / S asynchrone non bloquant. J'aime Boost.Asio, mais j'aime beaucoup C ++.

Assurez-vous que votre code gère correctement les signaux. HUP pour recharger la configuration. TERME pour arrêter en douceur.

N'essayez pas d'écrire votre propre fichier journal. Utilisez syslog uniquement, ou écrivez simplement dans stderr qui peut être redirigé vers syslog. C’est très pénible d’essayer d’installer logrotate sur des serveurs maison qui se connectent tous différemment.

Answer 6

Si vous voulez éviter les threads / forks, je vous recommande d’utiliser toutes les E / S non bloquantes avec libevent . Libevent est relativement bien connu en tant que solution hautes performances pour la programmation événementielle.

Answer 7

Recherchez ACE (C ++ / Java) . Il comporte un certain nombre de réacteurs TCP threaded, event et forking qui répondent à vos besoins de communication. Vous pouvez également consulter Boost ASIO qui fait quelque chose similaire