Discussion :

[Magus (Dave)]

Bonjour,

Dans le cadre de la réalisation d'un proxy HTTP, je m'interroge sur la façon appropriée de gérer les connexions. Je développe en C sous GNU/Linux, et j'utilise les sockets TCP.

Actuellement, je dispose d'un processus père qui écoute sur un socket. Quand une connexion arrive, fork est appelé pour créer un processus fils qui gère la connexion, et le père attend une nouvelle connexion. L'inconvénient étant qu'en cas de nombreuses connexions, le nombre de processus explose...

Mon idée est d'utiliser un processus père qui attend les nouvelles connexions, et un petit nombre (disons dix) de processus fils, créés à l'avance, qui gèrent les nouvelles connexions. Quand une nouvelle connexion arrive, le processus père cherche parmi les processus fils un qui soit en attente, pour lui indiquer de gérer cette connexion. Avec l'inconvénient que si les dix processus fils sont occupés (en cas de charge élevée), la connexion ne pourra pas être gérée immédiatement.

L'autre problème posé (dans les deux cas) est le cas des connexions persistantes. Entre client et proxy, impossible d'affecter une connexion à un processus fils, sinon seules dix connexions pourraient être ouvertes (ou bien il faudrait sans cesse fermer et rouvrir des connexions, on perd l'intérêt de la persistance) ; et il n'est pas non plus question de faire un fork à chaque nouvelle connexion... Je pensais faire en sorte que chacun des processus fils puisse gérer plusieurs connexions client-proxy (en utilisant un select par exemple, pour voir quel socket a des données en attente) et plusieurs connexions proxy-serveur, mais dans ce cas, si une requête ou une réponse est longue, les autres connexions affectées au même processus seront délaissées tant que toutes les données n'auront pas été transférées...

J'ai pensé utiliser les threads, mais de la même façon que les processus, il vaut mieux éviter d'en avoir un trop grand nombre, non ?

Voilà où en est ma réflexion. Si vous avez des avis sur la question, je suis preneur.

Merci d'avance.

[Mac LAK]

J'ai pensé utiliser les threads, mais de la même façon que les processus, il vaut mieux éviter d'en avoir un trop grand nombre, non ?

Bien sûr, il faut éviter d'en avoir trop, mais un thread est très très nettement moins coûteux qu'un processus... A l'heure où j'écris ce message, ma machine exécute 90 processus (ce qui est un peu élevé, je monte parfois à environ 200 mais quasiment jamais plus), et 769 threads (ce qui est une broutille, j'en ai presque 5000 quand elle tourne à plein régime)... Juste pour te donner une idée.

Tu peux faire un pool de threads, et utiliser ensuite des structures gérant la persistance de la connexion ainsi que des select pour gérer tes connexions afin de pouvoir en accepter beaucoup plus.

[|PaRa-BoL]

Vu que tu es sur un Linux, tu peux utiliser l'API "epoll()" qui gère très bien un très grand nombre de connexions par rapport à "select()".

- Sockets non bloquants
- utilisation de epoll
- gestion des évènements sur le filedescriptor du socket qui écoute => accept()
- évènements sur les sockets client => read() // write()

(Tu peux utiliser libevent pour gérer tout ça)

A lire : http://www.kegel.com/c10k.html

[Magus (Dave)]

Merci pour vos réponses, j'ai à présent une meilleure idée de la façon de procéder. La lecture de http://www.kegel.com/c10k.html était également très intéressante.

Je marque le topic comme Résolu mais je suis toujours preneur pour plus d'informations.

Cordialement