Je dois réaliser un serveur qui pourrait avoir de très nombreuses connexions ouvertes en permanence mais avec peu de traffic. (type messagerie instantanée).
Le facteur limitant n'est apparemment pas le nombre de connexion TCP simultanées que je peux maintenir établie, mais plutôt le nombre de threads.
On peut repousser cette limite à l'aide d'un thread pool, mais cela ne suffit pas car le traitement d'une requête peut impliquer l'attente de données supplémentaires. Si le client distant ne transmet pas de données, le thread est alors bloqué et ne peut être affecté à une autre tâche.
Ceci provient du fait que l'appel au read/recv de données supplémentaires se fait dans des appels de fonctions invoquées par le traitement de la tâche a effectuer. Il n'est alors pas possible d'interrompre le traitement pour le reprendre plus tard là où on l'a interrompu lorsque les nouvelles données sont arrivées.
Le serveur se trouve ainsi exposé à des attaques DOS où les threads sont bloqués volontairement en attente de données. Je pourrais mettre un timeout, mais une longue attente peut aussi être une situation normale. Je souhaiterais donc simplement que le thread ne soit pas bloqué en attente de read.
Il semble apparemment que c'est la technique de coroutine qu'il me faudrait utiliser. J'ai trouvé le package suivant pour réaliser cela. http://www.goron.de/~froese/coro/
Il y a aussi GNU Pth, mais je crains que l'utilisation dans une applicaton C++ demande une attention particulière. Quelle que soit la solution, cela risque d'être subtil a concevoir et à programmer.
Je voudrais donc savoir si ce problème a déjà été résolu et si oui comment.
Je voudrais aussi savoir dans quelle mesure le nombre de threads est un facteur limitant. Au fait quelle est la limite maximal du nombre de thread qu'on peut avoir sur un ordinateur linux 2.6 ?
Partager