Discussion :

[Sikamikanico]

Bonjour
Je développe un petit serveur (sous linux) qui peut être amener à gérer de nombreuses sockets. Je les surveille en utilisant select().
J'ai une socket server qui écoute sur un port spécifique.
Au delà de 1024 sockets environ, je ne peux plus en créer de nouvelles puisqu'il y a une limite sur ce nombre.
Lorsque quelqu'un cherche à se connecter, select() réagit et j'appelle ensuite accept() qui lui me renvoie l'erreur EMFILE. Du coup je laisse tomber ma création de socket.
Et là c'est le drame : lorsque j'arrive à nouveau à mon select(), celui-ci réagit comme ci ma server socket avait quelquechose de neuf, alors que je suis sur qu'il n'y a pas eu de nouveau client qui a essayé de se connecter dessus.
Du coup je part dans une boucle infinie qui bloque le reste du programme: un coup de select qui retourne aussitôt puis un accept qui échoue, etc, etc ad lib.

Alors je me demande s'il y'a quelque chose à faire pour éviter ce problème ?
Peut-être quelque chose à faire à ma server socket pour lui faire comprendre que je refuse la connexion ?
Ou alors carrément fermer ma server socket le temps que quelques sockets se déconnectent ?

Si quelqu'un peut m'aider, je lui en serai éternellement reconnaissant !

[wiztricks]

Bonsoir,

En supposant que la limite soit fixée et connue(*), on peut arrêter les accept avant de tomber dans l'erreur EMFILE (à 90% par exemple) et ne les reprendre que lorsque le nombre de connexion actives est inférieur à un certain nombre.
(*) la limite est le nombre de desripteurs de fichiers tolérée pour le process.

Ceci dit avec ce nombre de socket ouvertes, vous êtes probablement aussi en limite côté FD_SETSIZE (le nombre de descripteurs passés à select). Ce qui est d'autant plus génant que cette limite vous empêche de gérer les descripteurs qui seraient > FD_SETSIZE.

Je vous recommanderais donc de regarder côté poll ou mieux epoll qui sont plus performants de ce côté.

- W

[ram-0000]

Au delà de 1024 sockets environ...

Juste une idée comme cela, mais 1024 socket pour un select, cela me parait beaucoup (outre la limitation concernant le nombre de descripteurs de fichiers ouverts).

Peut être qu'il faudrait se tourner vers une autre techno. Je pense par exemple aux IOCP, c'est sous Windows mais il y a peut être un équivalent Linux.

[wiztricks]

Peut être qu'il faudrait se tourner vers une autre techno. Je pense par exemple aux IOCP, c'est sous Windows mais il y a peut être un équivalent Linux.

L'équivalent (*) est epoll sous Linux et kevent sous BSD.

(*) Vu que les philosophies de ces environnements sont assez lointaines, je m'attends toujours a recevoir des pierres avec ce genre de comparaisons.
Donc c'est comparable parce que tous sont O(1), ie l'overhead est identique quelque soit le nombre de 'descripteurs' ouverts - contrairement à select
-W

[Sikamikanico]

Merci (avec un peu de retard!) pour vos réponses.
Si je comprend bien, en utilisant epoll, je gagnerai en performance, mais par contre, il y aura toujours une limite dans le nombre de sockets ouvertes ?

[wiztricks]

Merci (avec un peu de retard!) pour vos réponses.
Si je comprend bien, en utilisant epoll, je gagnerai en performance, mais par contre, il y aura toujours une limite dans le nombre de sockets ouvertes ?

Les ressources nécessaires à la création/gestion des sockets sont, en dernier ressort, limitées par les capacités du matériel.
De plus, ce sont des données dynamiques (en mémoire vive), impossible à étendre simplement comme la capacité de stockage disque.

Il y a donc une limite "système" généralement difficile à dépasser sans recompiler et une limite "process" que vous pouvez ajuster (en deçà de la limite système).

Mais les facteurs qui limitent le plus restent physiques!

Derrière ces milliers de sockets, il y a des requêtes à traiter qui se traduisent par une durée de traitement, des coûts CPU/mémoire et, au dessous, des échanges de via un réseau qui n'a pas non plus une capacité infinie.


En général, le nombre de sockets supportables par un OS "moderne" est supérieur aux contraintes matérielles haut de gamme (plein de CPU et des Gigabits de bande passante).

Il faut que l'implémentation suive, ie autre chose que select qui a été pensé à une époque ou les ressources CPU, mémoire et réseau étaient plus chiches.

Accepter un nombre de clients supérieur aux capacités physiques disponibles signifie des temps de réponse dégradés, des overheads dus aux reprises qui s'ensuivent et un système qui s'écroule.

L'informatique reste un métier d'ingénieur, nous ne devrions(*) pas pratiquer une gestion du risque à la mode des banquiers !

Le design de votre application devra éviter que le système ne s'écroule et que les temps de réponses restent satisfaisants pour tous les clients acceptés.

Vous vous attacherez à définir ces conditions extrêmes et à tester que votre application y survit correctement.

- W
(*) cela se voit hélas dans certains projets.

[Sikamikanico]

Ok.
Effectivement, il y aura toujours une limite à gérer quel que soit la fonction utilisée...
Bon, avec tout ça, je pense que je vais y arriver. Je verrai pour passer à epoll par la suite (question de portabilité). En attendant, je vais rester encore un peu avec select et puis fermer ma server socket quand j'ai trop de clients...
Merci pour votre aide !