une gestion par événements de la machine d'état (state-machine) ;
l'utilisation de co-routines (plus légères que des threads) pour la gestions des connections TCP ;
une résolution DNS UDP/TCP interne intégrée dans le coeur (gethostbyname est une fonction bloquante) ;
une communication entre threads et le coeur par messages ;
une gestion automatique du nombre de threads nécessaire pour une bonne montée en charge.
se résume tout bêtement à :
ExaProxy est écrit en style à événements (entrées-sorties non bloquantes) ce qui lui permet de gérer un grand nombre de connexions simultanément en limitant la consommation mémoire.
Pas besoin de rentrer dans les détails, ceux qui savent ce qu'est du code à événement infèrent les détails à partir de la simple information « style à événements », et ceux qui ne savent pas ont au moins une vague idée de ce que ça implique.
(Et en plus, la dépêche induit le doute avec tous ces détails ; par exemple, même si c'est ma spécialité, je ne suis pas sûr de comprendre le lien entre les événements, coroutines et threads mentionnés dans cette énumération.)
[^] # Re: c'est pas un peu compliqué tout ca
Posté par MrLapinot (site web personnel) . En réponse à la dépêche ExaProxy, un proxy HTTP filtrant. Évalué à 3.
C'est surtout très verbeux. Par exemple :
se résume tout bêtement à :
Pas besoin de rentrer dans les détails, ceux qui savent ce qu'est du code à événement infèrent les détails à partir de la simple information « style à événements », et ceux qui ne savent pas ont au moins une vague idée de ce que ça implique.
(Et en plus, la dépêche induit le doute avec tous ces détails ; par exemple, même si c'est ma spécialité, je ne suis pas sûr de comprendre le lien entre les événements, coroutines et threads mentionnés dans cette énumération.)