Entendo que "Tudo é um arquivo" é um dos principais conceitos do Unix, mas os soquetes usam APIs diferentes fornecidas pelo kernel (como soquete, sendto, recv etc.), não como as interfaces normais do sistema de arquivos.
Como esse "Tudo é um arquivo" se aplica aqui?
Respostas:
soquetes usam APIs diferentes
Isso não é inteiramente verdade. Existem algumas funções adicionais para uso com soquetes, mas você pode usar, por exemplo, normal read()e write()em um soquete fd.
como esse "Tudo é um arquivo" se aplica aqui?
No sentido de que um descritor de arquivo está envolvido.
Se sua definição de "arquivo" é uma sequência discreta de bytes armazenados em um sistema de arquivos, nem tudo é um arquivo. No entanto, se sua definição de arquivo for mais semelhante a um identificador - um canal de informações, ou seja, uma conexão de E / S -, então "tudo é um arquivo" começa a fazer mais sentido. Essas coisas inevitavelmente envolvem seqüências de bytes, mas de onde elas vêm ou vão podem diferir contextualmente.
No entanto, não é realmente planejado literalmente. Um daemon não é um arquivo, um daemon é um processo; mas se você estiver executando o IPC, seu método de se relacionar com outro processo poderá ser mitigado pelas entidades de estilo de arquivo.
"Tudo é um arquivo" é apenas um exagero. Era uma novela na década de 1970 e era uma característica distintiva primária do UNIX. Mas é apenas um conceito de marketing, não uma base real do UNIX, porque obviamente não é verdade. Não é benéfico ou sensato tratar TUDO como um arquivo.
CPU é um arquivo? Seu programa lê () uma CPU para obter uma nova instrução? RAM é um arquivo? Seu programa lê () o próximo byte?
Naquela época, havia tipos de SO que forneciam uma API para um disquete e uma API diferente para um disco rígido, uma API diferente para fita magnética e várias APIs diferentes para terminais diferentes e assim por diante. Os sistemas de mainframe IBM tinham diferentes tipos de arquivos em discos rígidos e forneceram uma API diferente para cada um deles, acredite ou não! Portanto, a abordagem "é um arquivo" do UNIX, juntamente com a abordagem "stdin / stdout / stderr", trouxe uma abstração muito elegante para usuários e programadores.
Com a rede, essa abstração em particular simplesmente não deu certo. E não há mal, apenas um pouco menos elegância e coerência geral do sistema operacional. Mas funciona. Você vê um arquivo chamado /dev/myinternetz/www/google/com/tcp/80em qualquer lugar do seu sistema hoje? Você pode abrir (), escrever () uma consulta e ler () a resposta em bom HTML? Não? Isso ocorre porque a abstração "é um arquivo" não foi muito útil para interagir na rede. Não funcionaria muito bem na prática. Lei das abstrações com vazamentos em ação.
/dev/tcp/www.google.com/80. Porém, não é um arquivo real - o bash está apenas fingindo.
/dev/memou /dev/kmemse quiser.
Soquetes são arquivos. Você pode usar reade writeem um soquete: eles são equivalentes a chamadas recve sendcom flags=0. Você fechá-los com close. Você pode movê-los com dupamigos e se precisar embaralhar os descritores de arquivos. Você pode definir alguns sinalizadores com fcntle usar o buffer stdio após a chamada fdopen. A lista continua. Muito importante, você pode chamar selecte pollusar qualquer tipo de arquivo, incluindo soquetes, para que essas funções permitam que um programa seja bloqueado até receber entrada por qualquer meio, simplesmente listando descritores de arquivo.
Existem chamadas de sistema extras para alguns tipos de soquete ( recve send, shutdownetc.), como há uma chamada de sistema extra para dispositivos ( ioctl).
Nem todos os arquivos têm nomes e, dentre os que possuem, eles nem sempre vivem na estrutura de diretórios. Tubos criados por pipe( por exemplo, em um pipeline de shell) e soquetes criados por socketpairnão têm nomes, mas ainda são arquivos. Soquetes criados por socketpossuem um nome cuja sintaxe depende do domínio. Este nome é passado em um struct sockaddrpara binde outras funções. Para um AF_UNIXsoquete Unix ( ), o nome é a struct sockaddr_un, que é uma família e uma string; dependendo da string, esse pode ser um nome de arquivo (soquetes nomeados podem ser criados com mknodmuitas variantes do unix) ou não (o namespace abstrato). Para um AF_INETsoquete IPv4 ( ), o nome é a struct sockaddr_in, contendo um número de porta e endereço IP, além protocoldo da socketchamada.
Se você statusar um soquete, verá que ele possui um número de inode e outras características dos arquivos regulares, então eu o classificaria como um arquivo no sistema de arquivos. Exemplo:
# file live
live: socket
# stat live
File: `live'
Size: 0 Blocks: 0 IO Block: 4096 socket
Device: fc03h/64515d Inode: 198817 Links: 1
Access: (0660/srw-rw----) Uid: (23129/ icinga) Gid: (23130/icinga-cmd)
Access: 2014-11-07 09:27:59.000000000 -0800
Modify: 2014-11-05 09:27:03.000000000 -0800
Change: 2014-11-05 09:27:03.000000000 -0800
17/11. Informações adicionais para Linux (ext3): Um soquete possui um inode (que é um bloco de 256 bytes no disco), mas não possui nenhum bloco de dados (você pode verificar isso extraindo o inode e examinando os ponteiros do bloco de dados; ou por executando debugfs 'stat' que mostra um Blockcount de 0). Portanto, ele possui metadados de arquivo (proprietário, grupo, permissões etc.), mas nenhum conteúdo de dados no disco. Isso é idêntico a um arquivo vazio comum ( touch /tmp/foo) que também possui uma contagem de blocos igual a 0. No primeiro caso, o campo "type" no inode mostra "socket"; no segundo caso, mostra "arquivo regular".
Referências: estrutura ext2 inode ; stat, dumpe2fsE debugfscomandos.
fileou stattornar um arquivo.