En redes informáticas , STREAMS es el marco nativo en Unix System V para implementar controladores de dispositivos de caracteres , protocolos de red y comunicación entre procesos . En este marco, un flujo es una cadena de rutinas que pasan mensajes entre un programa y un controlador de dispositivo (o entre un par de programas). STREAMS se originó en la versión 8 Research Unix , como Streams (sin mayúsculas).
El diseño de STREAMS es una arquitectura modular para implementar E/S full-duplex entre el kernel y los controladores de dispositivos. Sus usos más frecuentes han sido en el desarrollo de E/S de terminal ( disciplina de línea ) y subsistemas de red. En System V Release 4, toda la interfaz del terminal se volvió a implementar utilizando STREAMS. [1] Un concepto importante en STREAMS es la capacidad de unir controladores (módulos de código personalizados que pueden modificar la funcionalidad de una interfaz de red u otro dispositivo) para formar una pila. Varios de estos controladores se pueden encadenar juntos en orden.
STREAMS se basó en el subsistema Streams I/O introducido en la octava edición de Research Unix (V8) por Dennis Ritchie , donde se usó para el subsistema de E/S de terminal y el conjunto de protocolos de Internet . Esta versión, aún no llamada STREAMS en mayúsculas, encajó la nueva funcionalidad bajo las llamadas al sistema de E/S de dispositivos existentes ( abrir , cerrar , leer , escribir e ioctl ), [2] y su aplicación se limitó a E/S de terminales y protocolos que proporcionan semántica de E/S tipo canalización.
Este sistema de E/S fue portado a System V Release 3 por Robert Israel, Gil McGrath, Dave Olander, Her-Daw Che y Maury Bach como parte de un marco más amplio destinado a admitir una variedad de protocolos de transporte, incluidos TCP, ISO Class 4 transporte, SNA LU 6.2 y el protocolo AT&T NPACK (utilizado en RFS ). [3] Se lanzó por primera vez con el paquete Network Support Utilities (NSU) de UNIX System V Release 3. [4] Este puerto agregó las llamadas al sistema putmsg , getmsg y poll , que son casi equivalentes en propósito a send , recv y seleccionar llamadas desde enchufes de Berkeley. el putmsgy las llamadas al sistema getmsg originalmente se llamaban send y recv , [5] pero se les cambió el nombre para evitar conflictos de espacio de nombres. [6] En la versión 4 de System V, STREAMS se amplió y usó para el marco de E/S del terminal y las canalizaciones, proporcionando una nueva funcionalidad útil, como canalizaciones bidireccionales y paso de descriptores de archivos . [3] También se produjo un puerto para Unicos . Eric S. Raymond cita a Ritchie diciendo sobre la complejidad de System V STREAMS en comparación con sus V8 Streams que "Streams significa algo diferente cuando se grita". [7]
Simultáneamente con el puerto System V Release 3, AT&T desarrolló pautas de paso de mensajes STREAMS independientes del protocolo para las capas de enlace , [8] red , [9] y transporte [10] del modelo OSI (capas 2-4). Debido al acoplamiento de implementación típicamente cercano de la red y los protocolos de transporte en una pila de protocolos dada , y la práctica típica de implementar las capas 5-7 fuera del kernel , solo las interfaces de servicio STREAMS de enlace [8] y capa de transporte [11] fueron luego estandarizado por X / Open. Junto con el modelo de paso de mensajes de transporte, se definió la interfaz de la capa de transporte (posteriormente adoptada como interfaz de transporte X/Open ) para proporcionar una API independiente del protocolo de transporte para el desarrollo de aplicaciones. Además, The Open Group definió una biblioteca compatible con las capas de sesión , presentación y aplicación [12] y luego la estandarizó . [13]
Se requería STREAMS para cumplir con las versiones 1 (UNIX 95) y 2 (UNIX 98) de Single UNIX Specification , pero como resultado de la negativa de los desarrolladores de BSD y Linux a proporcionar STREAMS, [ cita requerida ] se marcó como opcional para POSIX cumplimiento por parte de Austin Group en la versión 3 (UNIX 03). POSIX.1-2008 con TC1 (IEEE Std 1003.1, edición de 2013) ha designado a STREAMS como 'marcado como obsoleto' [14] [15], lo que significa que dicha funcionalidad puede eliminarse en una versión futura de la especificación. Sin embargo, la definición específica de 'obsolescente' utilizada [16] también dice que las aplicaciones POSIX estrictamente conformes 'no utilizarán funciones obsoletas'.