En redes de computadoras , 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, una secuencia es una cadena de corrutinas 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úscula).
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 el desarrollo de E/S de terminales ( disciplina de línea ) y subsistemas de redes. En System V Release 4, toda la interfaz del terminal se reimplementó 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 en orden.
STREAMS se basó en el subsistema Streams I/O introducido en la octava edición Research Unix (V8) por Dennis Ritchie , donde se utilizó para el subsistema de E/S del terminal y el conjunto de protocolos de Internet . Esta versión, aún no llamada STREAMS en mayúsculas, se ajusta a la nueva funcionalidad bajo las llamadas al sistema de E/S del dispositivo existente ( open , close , read , write e ioctl ), [2] y su aplicación se limitaba a E/S de terminal y protocolos que proporcionan semántica de E/S similar a una tubería.
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, 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 versión 3. [4] Este puerto agregó las llamadas al sistema putmsg , getmsg y poll , que son casi equivalentes en propósito a send , recv. y seleccione llamadas de sockets de Berkeley. Las llamadas al sistema putmsg y getmsg originalmente se llamaban send y recv , [5] pero se les cambió el nombre para evitar conflictos de espacios de nombres. [6] En System V Versión 4, STREAMS se amplió y utilizó para el marco de E/S del terminal y las canalizaciones, proporcionando nuevas funciones útiles 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 acerca de 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 estrecho acoplamiento de implementación típico de los protocolos de red y de transporte en una pila de protocolos determinada , y a la práctica típica de implementar las capas 5 a 7 fuera del núcleo , solo se utilizaron las interfaces de servicio STREAMS de enlace [8] y capa de transporte [11]. posteriormente estandarizado por X/Open . Junto con el modelo de paso de mensajes de transporte, se definió la interfaz de capa de transporte (posteriormente adoptada como X/Open Transport Interface ) para proporcionar una API independiente del protocolo de transporte para el desarrollo de aplicaciones. Además, The Open Group definió y luego estandarizó una biblioteca que soporta las capas de sesión , presentación y aplicación [12] . [13]
Se requería STREAMS para cumplir con las versiones 1 (UNIX 95) y 2 (UNIX 98) de la especificación única de UNIX , pero como resultado de la negativa de los desarrolladores de BSD y Linux a proporcionar STREAMS, [ cita necesaria ] se marcó como opcional para POSIX Cumplimiento por parte del Grupo Austin en la versión 3 (UNIX 03). POSIX.1-2008 con TC1 (IEEE Std 1003.1, edición 2013) ha designado STREAMS como 'marcado 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 características obsoletas".
En la versión 7 de Unix , un comando se conectaba a una terminal (teclado y pantalla, o teclado e impresora ) a través de un mecanismo llamado disciplina de línea, que almacenaba una sola línea de entrada, es decir, esperaba a que el usuario presionara la tecla Retorno. antes de enviar la entrada al programa para su procesamiento; esto permitió una simple corrección de errores. Streams reemplazó esto con un conjunto de módulos de procesamiento organizados en una cadena lineal que permitía la comunicación bidireccional entre módulos vecinos. Los programas podrían "empujar" un nuevo módulo a un extremo de la cadena para cambiar el comportamiento de una terminal u otro dispositivo de caracteres. Ritchie ofrece el ejemplo de cadena de un módulo terminal encadenado con un módulo de red Datakit para lograr un inicio de sesión remoto a través de una red. [5] Aparte de los caracteres (bytes) que van del programa al dispositivo y viceversa , Streams podría transportar mensajes de control como "colgar" (interrumpir la conexión) y mensajes ioctl .
Los flujos también podrían usarse para la comunicación entre procesos , conectando dos procesos a pseudoterminales . Esta funcionalidad se implementó en el sistema de ventanas mpx para la terminal de gráficos Blit , que podía mostrar múltiples ventanas del emulador de terminal . Cada ventana era un proceso que se comunicaba con el sistema de ventanas a través de un pseudoterminal que tenía instalado el controlador de disciplina de línea, enviándole caracteres escritos y recibiendo texto (y gráficos) para mostrar. Las señales de control designaban el deseo del usuario de cambiar entre ventanas o cerrarlas. [17] [18] : 348–350
Los módulos Streams reales viven en el espacio del kernel en Unix y son instalados (empujados) y eliminados (extraídos) mediante la llamada al sistema ioctl. Por ejemplo, para instalar la disciplina de línea antes mencionada en un descriptor de archivo fd que hace referencia a un dispositivo terminal, se escribiría (en C ): [18] : 347
ioctl ( fd , PUSH , TTYLD ); Para realizar entrada/salida en una secuencia, se utilizan las llamadas al sistema ready writecomo con los descriptores de archivos normales, o un conjunto de funciones específicas de STREAMS para enviar mensajes de control. [19]
Ritchie admitió que lamentaba tener que implementar Streams en el kernel, en lugar de como procesos, pero se sintió obligado a hacerlo por razones de eficiencia. [5] Una implementación posterior del Plan 9 implementó módulos como procesos a nivel de usuario. [20]
STREAMS se ha utilizado principalmente en el mundo System V Unix; sin embargo, existen otras implementaciones:
Linux no incluye la funcionalidad STREAMS sin complementos de terceros. Caldera había "presionado" para que STREAMS se incluyera en Linux ca. 1998, para soportar su Netware para Linux, pero fue rechazado rotundamente por los desarrolladores del kernel de Linux por motivos técnicos (principalmente de rendimiento). [25] Las capas de compatibilidad en Linux para otros sistemas operativos convierten las operaciones STREAMS en sockets lo antes posible. [26] La implementación utilizada por Caldera fue "LiS", de una empresa llamada GCOM; Más tarde figuró en las batallas legales del sucesor de Caldera, el Grupo SCO , contra Linux, con SCO afirmando que Linux con STREAMS infringió lo que creía que eran sus derechos de autor sobre System V. [25]