Pourquoi les sockets TCP / IP sont-ils considérés comme des «fichiers ouverts»?

29

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é.

networking files socket Mike B
la source

Réponses:

34

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.

Greg Hewgill
la source
23
"Kernel handles" est une terminologie Windows. Vous préférez vous référer aux "descripteurs de fichiers", c'est ainsi que ces entités sont généralement appelées avec Unix et Linux.
jlliagre
11
Cette réponse couvre trop. Les sockets sont des fichiers. Ils donnent accès à des flux d'octets via l' interface read/ write, qui est au cœur de ce que signifie être un fichier.
4
@ WumpusQ.Wumbley, mais alors vous avez l' 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).
kostix
@MikeB, ce livre devrait vous familiariser avec la plupart des concepts liés à Unix. Hautement recommandé.
kostix
3
L'idée «tout est un fichier» signifie que «fichier» est un type de données abstrait avec de nombreux sous-types. La plupart des sous-types prennent en charge des méthodes supplémentaires en plus des éléments de base pris en charge par tous les fichiers. les prises ont beaucoup d'extras. bloquer les appareils et les fichiers normaux ont cherché. les répertoires sont vraiment étranges (l'écriture ne fonctionne pas et si la lecture fonctionne, ce n'est pas utile). La présence de méthodes supplémentaires ne signifie pas que ces choses ne font pas partie de la catégorie générale des choses que nous appelons "fichiers".
27

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:

  • user.h :struct file *u_ofile[NOFILE]
  • param.h :#define NOFILE 20

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.

Bien 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.

Stuart Caie
la source
L'une des meilleures réponses dans ce sujet, merci
user859375
6

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.

Courses de légèreté avec Monica
la source
2
Bienvenue à U & L.SE. J'aime cette réponse.
eyoung100