Preciso de ajuda para entender o que tenho certeza de que é um conceito fundamental no Linux: o limite para arquivos abertos. Especificamente, estou confuso sobre por que os soquetes abertos podem contar para o número total de "arquivos abertos" em um sistema.
Alguém pode por favor explicar o motivo? Entendo que isso provavelmente remonta ao princípio "tudo é um arquivo" no Linux, mas qualquer detalhe adicional seria apreciado.
Respostas:
O limite de "arquivos abertos" não é realmente apenas para arquivos. É um limite para o número de manipuladores do kernel que um único processo pode usar ao mesmo tempo. Historicamente, a única coisa que os programas costumavam abrir muitos eram arquivos, então isso ficou conhecido como um limite no número de arquivos abertos. Há um limite para ajudar a impedir que os processos digam, abrindo muitos arquivos e acidentalmente esquecendo de fechá-los, o que causará problemas em todo o sistema.
Uma conexão de soquete também é um identificador de kernel. Portanto, os mesmos limites se aplicam pelos mesmos motivos - é possível que um processo abra conexões de rede e esqueça de fechá-las.
Conforme observado nos comentários, os identificadores de kernel são tradicionalmente chamados de descritores de arquivo em sistemas similares ao Unix.
read/ write, que é o coração do que significa ser um arquivo.
shutdown(2)syscall neles, mas não nos arquivos, e não pode ler de um soquete usando cat- esse é o motivo pelo qual netcatfoi criado. Eu diria que (felizmente) soquetes em kernels semelhantes ao Unix se comportam como arquivos em termos de E / S, mas a semelhança termina aí. (Honestamente, eu também gostaria de ouvir de alguém com experiência no Plano 9, porque soube que eles conseguiram a unificação dessas coisas além dos órgãos tradicionais).
A razão por que os descritores de arquivo usar TCP / IP soquetes é que, quando a interface soquetes foi inicialmente concebido e implementado ( em BSD Unix, em 1983 ), seus criadores sentiram que uma conexão de rede foi análogo a um arquivo - você pode read, writee closetanto , e que se encaixaria bem com a idéia do Unix de "tudo é um arquivo".
Outras implementações de pilha de rede TCP / IP não se integraram necessariamente ao subsistema de E / S de arquivos do sistema operacional, um exemplo sendo o MacTCP . Mas como a interface de soquetes BSD era tão popular, mesmo essas outras implementações optaram por replicar a API de soquete com suas funções semelhantes ao Unix, então você obteve "descritores de arquivo", usados apenas para comunicação TCP / IP, em sistemas que não possui descritores de arquivo.
A outra parte da sua pergunta é por que existe um limite? Isso ocorre porque a maneira mais rápida de implementar uma tabela de pesquisa de descritores de arquivos é com uma matriz. Historicamente, o limite era codificado no kernel.
Aqui está o código do Unix, versão 7 (1979), com um limite codificado de 20 descritores de arquivos por processo:
Por comparação, o Linux aloca espaço dinamicamente para a tabela de descritores de arquivos de um processo. O limite absoluto é 8192, mas você pode configurá-lo como desejar. Meu sistema lista 191072 pol /proc/sys/fs/file-max.
alloc_fdtable()struct fdtable#define NR_FILE 8192Apesar de não haver mais nenhum limite absoluto no Linux, mesmo assim, não queremos deixar os programas enlouquecerem, portanto o administrador (ou o empacotador de distribuição) geralmente define limites de recursos. Dê uma olhada /etc/security/limits.confou corra ulimit -n.
Arquivos não são apenas arquivos no disco ou na memória; são fluxos de dados, dos quais esses são apenas dois exemplos.
Os pontos de extremidade remotos são um terceiro exemplo e você interage com aqueles que usam soquetes.