Entiendo que "Todo es un archivo" es uno de los conceptos principales de Unix, pero los sockets utilizan diferentes API que proporciona el núcleo (como socket, sendto, recv, etc.), no como las interfaces normales del sistema de archivos.
¿Cómo se aplica aquí "Todo es un archivo"?
Respuestas:
los sockets usan diferentes API
Eso no es del todo cierto. Hay algunas funciones adicionales para usar con sockets, pero puede usar, por ejemplo, normal read()y write()en un socket fd.
¿Cómo se aplica aquí "Todo es un archivo"?
En el sentido de que está involucrado un descriptor de archivo.
Si su definición de "archivo" es una secuencia discreta de bytes almacenados en un sistema de archivos, entonces no todo es un archivo. Sin embargo, si su definición de archivo es más manejable, como un conducto para la información, es decir, una conexión de E / S, entonces "todo es un archivo" comienza a tener más sentido. Estas cosas inevitablemente involucran secuencias de bytes, pero su origen o destino pueden diferir contextualmente.
Sin embargo, en realidad no tiene la intención literal. Un demonio no es un archivo, un demonio es un proceso; pero si está haciendo IPC, su método de relacionarse con otro proceso podría ser mitigado por entidades de estilo de archivo.
"Todo es un archivo" es solo una exageración. Que era novela en 1970 y era una característica distintiva principal de UNIX. Pero es solo un concepto de marketing, no una base real de UNIX, porque obviamente no es cierto. No es beneficioso ni sensato tratar TODO como un archivo.
¿Es la CPU un archivo? ¿Su programa lee () una CPU para obtener una nueva instrucción? ¿Es la RAM un archivo? ¿Su programa lee () el siguiente byte?
En aquel entonces, había tipos de sistemas operativos que le daban una API para un disquete y una API diferente para un disco duro, una API diferente para cinta magnética y un montón de API diferentes para diferentes terminales, etc. Los sistemas mainframe de IBM tenían diferentes tipos de archivos en discos duros y le daban una API diferente para cada uno de ellos, ¡lo creas o no! Entonces, el enfoque UNIX "es un archivo", junto con el enfoque "stdin / stdout / stderr", trajo una abstracción muy elegante tanto para los usuarios como para los programadores.
Con la red, esta abstracción en particular simplemente no funcionó. Y no hay daño, solo un poco menos de elegancia general y coherencia del sistema operativo. Pero funciona. ¿Ves un archivo llamado /dev/myinternetz/www/google/com/tcp/80en alguna parte de tu sistema hoy? ¿Puedes abrir (), escribir () una consulta y leer () la respuesta en un HTML agradable? ¿No? Esto se debe a que esta abstracción "es un archivo" no era muy útil para interactuar en la red. No funcionaría demasiado bien en la práctica. Ley de abstracciones permeables en acción.
/dev/tcp/www.google.com/80. Sin embargo, no es un archivo real: bash solo lo está fingiendo.
/dev/memo /dev/kmemsi quisieras.
Los sockets son archivos. Puede usar ready writeen un socket: son equivalentes a llamar recvy sendcon flags=0. Los cierras con close. Puede moverlos con dupamigos si necesita mezclar los descriptores de archivo. Puede establecer algunos indicadores con fcntly usar el almacenamiento en búfer stdio después de llamar fdopen. La lista continua. Muy importante, puede llamar selecty pollen cualquier tipo de archivo, incluidos los sockets, por lo que estas funciones permiten que un programa se bloquee hasta que reciba información por cualquier medio simplemente enumerando descriptores de archivo.
Hay llamadas de sistema adicionales para algunos tipos de socket ( recvy send, shutdownetc.), como hay una llamada de sistema adicional para dispositivos ( ioctl).
No todos los archivos tienen nombres , y de los que los tienen, no siempre viven en la estructura de directorios. Las tuberías creadas por pipe( por ejemplo, en una tubería de shell) y las tomas creadas por socketpairno tienen nombres, pero siguen siendo archivos. Los sockets creados por sockettienen un nombre cuya sintaxis depende del dominio. Este nombre se pasa en un struct sockaddra bindy otras funciones. Para un AF_UNIXsocket Unix ( ), el nombre es a struct sockaddr_un, que es una familia y una cadena; dependiendo de la cadena, este puede ser un nombre de archivo (los sockets con nombre se pueden crear con mknodmuchas variantes de Unix) o no (el espacio de nombres abstracto). Para un AF_INETsocket IPv4 ( ), el nombre es a struct sockaddr_in, que contiene un número de puerto y una dirección IP, más el protocolde la socketllamada.
Si tiene statun socket, verá que tiene un número de inodo y otras características de los archivos normales, por lo que lo clasificaría como un archivo en el sistema de archivos. Ejemplo:
# 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. Información adicional para Linux (ext3): un socket tiene un inodo (que es un bloque de 256 bytes en el disco) pero no tiene ningún bloque de datos (puede verificar esto extrayendo el inodo y examinando los punteros del bloque de datos; o ejecutando debugfs 'stat' que muestra un Blockcount de 0). Por lo tanto, tiene metadatos de archivo (propietario, grupo, permisos, etc.) pero no tiene contenido de datos en el disco. Esto es idéntico a un archivo vacío regular ( touch /tmp/foo) que también tiene un conteo de bloques de 0. En el primer caso, el campo "tipo" en el inodo muestra "socket"; en el segundo caso, muestra "archivo normal".
Referencias: estructura de inodo ext2 ; stat, dumpe2fsy debugfscomandos.
fileo statconvertirlo en un archivo.