J'ai besoin d'aide pour comprendre ce dont je suis sûr qu'il s'agit d'un concept fondamental sous Linux: la limite pour les fichiers ouverts. Plus précisément, je ne comprends pas pourquoi les sockets ouverts peuvent compter dans le nombre total de "fichiers ouverts" sur un système.
Quelqu'un peut-il expliquer pourquoi? Je comprends que cela remonte probablement au principe "tout est un fichier" sous Linux mais tout détail supplémentaire serait apprécié.
Réponses:
La limite des "fichiers ouverts" n'est pas vraiment réservée aux fichiers. C'est une limite sur le nombre de poignées de noyau qu'un seul processus peut utiliser à la fois. Historiquement, la seule chose que les programmes ouvraient généralement beaucoup était les fichiers, donc cela est devenu connu comme une limite sur le nombre de fichiers ouverts. Il existe une limite pour empêcher les processus de dire, d'ouvrir un grand nombre de fichiers et d'oublier accidentellement de les fermer, ce qui entraînera éventuellement des problèmes à l'échelle du système.
Une connexion socket est également une poignée de noyau. Les mêmes limites s'appliquent donc pour les mêmes raisons - il est possible qu'un processus ouvre des connexions réseau et oublie de les fermer.
Comme indiqué dans les commentaires, les descripteurs de noyau sont traditionnellement appelés descripteurs de fichiers dans les systèmes de type Unix.
read/ write, qui est au cœur de ce que signifie être un fichier.
shutdown(2)appel système sur eux, mais pas sur les fichiers, et vous ne pouvez pas lire à partir d'un socket en utilisant cat- c'est la raison netcatpour laquelle a été créée. Je dirais que (heureusement) les sockets dans les noyaux de type Unix se comportent comme des fichiers en termes d'E / S, mais la similitude s'arrête là. (Honnêtement, j'aimerais aussi entendre parler de quelqu'un ayant une expérience du Plan 9, car j'ai entendu dire qu'ils avaient obtenu l'unification de ces choses plus loin que les unités traditionnelles).
La raison pour laquelle les descripteurs de fichiers utilisation de TCP / IP est que, lorsque l'interface sockets a été conçu et mis en œuvre ( dans BSD Unix, en 1983 ), ses concepteurs a estimé qu'une connexion réseau est analogue à un fichier - vous pouvez read, writeet à la closefois , et qu'il cadrerait bien avec l'idée Unix de "tout est un fichier".
D'autres implémentations de pile réseau TCP / IP ne s'intégraient pas nécessairement avec le sous-système d'E / S de fichiers de leur système d'exploitation, un exemple étant MacTCP . Mais parce que l'interface des sockets BSD était si populaire, même ces autres implémentations ont choisi de répliquer l'API de socket avec ses fonctions de type Unix, vous avez donc obtenu des "descripteurs de fichiers", uniquement utilisés pour la communication TCP / IP, sur des systèmes qui ne le faisaient pas autrement avoir des descripteurs de fichiers.
L'autre partie de votre question est: pourquoi y a-t-il une limite? C'est parce que le moyen le plus rapide d'implémenter une table de recherche de descripteur de fichier est avec un tableau. Historiquement, la limite était codée en dur dans le noyau.
Voici le code d'Unix version 7 (1979) avec une limite codée en dur de 20 descripteurs de fichier par processus:
Par comparaison, Linux alloue dynamiquement de l'espace pour la table de descripteurs de fichiers d'un processus. La limite absolue par défaut est 8192, mais vous pouvez la régler à votre guise. Mon système affiche 191072 pouces /proc/sys/fs/file-max.
alloc_fdtable()struct fdtable#define NR_FILE 8192Bien qu'il n'y ait plus de limite absolue sous Linux, nous ne voulons cependant pas laisser les programmes devenir fous, donc l'administrateur (ou le conditionneur de distribution) fixe généralement des limites de ressources. Jetez un œil /etc/security/limits.confou courez ulimit -n.
Les fichiers ne sont pas seulement des fichiers sur disque ou en mémoire; ce sont des flux de données, dont ce ne sont que deux exemples.
Les points de terminaison distants sont un troisième exemple et vous interagissez avec ceux qui utilisent des sockets.