Bonjour,
 
Voilà le topo.
J'ai un souci sur une application qui tourne en production. C'est un programme serveur en C qui utilise select. Le souci c'est qu'arrivé à 1024 (limite système) connections simultanées ça part en sucette.
La solution d'augmenter la limite système n'est pas viable et plus le temps passe plus le nombre de connections simultanées augmente.
Je me suis donc dirigé vers epoll au lieu du select pour zapper cette limitation. Jusque là rien de bien méchant. Le souci c'est que je dois séparer le process d'écoute (qui accueil les nouvelles connections et les données reçues) de celui d'envoi. Pour cela, j'ai deux solutions qui s'offrent à moi soit le thread, soit le fork (oui je sais c'est une question qui revient sans cesse sur le net).
Concernant le thread, soit je fais 1 thread pour l'écoute et 1 pour l'envoi, soit 1 thread d'écoute et 1 thread par connections. Pour le fork ca sera bien évidemment 1 process par connection.
 
Ce qui me fait peur c'est les limitations.
Si je passe par du fork, je risque d'avoir rapidement plus de 2000 process en parallèle et donc de ralentir fortement le temps de réponse du serveur. D'un autre côté si un process plante (hormis le père) l'application continuera de tourner.
Si je prend l'option thread, ça sera un peu plus performant niveau ressource système mais en cas de souci tout est planté et le partage des variables est "délicat" (j'utilise un tableau de structure pour gérer les clients).
 
J'arête pas de lire du pour et du contre pour chaque solution sur plein de sites différents et du coup je sais plus quelle options choisir ...
Donc un peu d'aide à la décision serait la bienvenue ...
 
Voici quelques détails supplémentaire concernant le fonctionnement du serveur :
- Un client se connecte, s'identifie puis dialogue régulièrement (toutes les 30sec ou moins)
- Les échanges, une fois la connection établie, peuvent être à l'initiative du client et/ou du serveur
- Le nombre de connections simultanées est actuellement en moyenne de 1000 mais ne cesse d'augmenter (je prévois une moyenne à 2000 d'ici 3 mois environ)
- Sur réception du client, les données sont analysées et traitées dans la foulée

tu peux faire 1024 connexions par processus par défaut donc tu peux créer un nouveau processus/thread dès que tu atteins cette limite. Ou alors les créer dès le lancement de ton prog (style à la apache)

fork n'est pas si lent que ça (sous linux du moins), et au moins ça te cloisonne bien. Tu peux gérer les communications avec des files de messages. Si t'es chaud, tu peux même préforker à l'avance et/ou recycler tes processus pour de nouvelles connexions.
 
Côté thread t'as une autre limitation: chaque thread va avoir besoin de 2/8Mo pour sa pile propre et donc si t'es en 32bits, 2000 threads ça tiendra jamais.