TRANSMISIONES

En redes informáticas , STREAMS es el marco de trabajo nativo de 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 corrutinas que transmiten mensajes entre un programa y un controlador de dispositivo (o entre un par de programas). STREAMS se originó en la versión 8 de Research Unix , como Streams (sin mayúscula inicial).

El diseño de STREAMS es una arquitectura modular para implementar E/S dúplex completo 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 de terminal se reimplementó usando STREAMS. ^{[ 1 ]} Un concepto importante en STREAMS es la capacidad de agrupar controladores ( módulos de código personalizado 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 de E/S Streams introducido en la Octava Edición de Research Unix (V8) por Dennis Ritchie , donde se utilizó para el subsistema de E/S de terminal y el conjunto de protocolos de Internet . Esta versión, que aún no se llamaba STREAMS en mayúsculas, se ajustaba a la nueva funcionalidad bajo las llamadas al sistema de E/S de dispositivos existentes ( open , close , read , write e ioctl ), ^{[ 2 ]} y su aplicación se limitaba a la E/S de terminal y a los protocolos que proporcionaban semántica de E/S tipo 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, transporte ISO Clase 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 Release 3. ^{[ 4 ]} Este puerto agregó las llamadas al sistema putmsg , getmsg y poll , que son casi equivalentes en propósito a las llamadas send , recv y select de los sockets de Berkeley. Las llamadas al sistema putmsg y getmsg se llamaban originalmente send y recv , ^{[ 5 ]} pero se renombraron para evitar conflictos de espacio de nombres. ^{[ 6 ]} En System V Release 4, STREAMS se extendió y se utilizó para el marco de E/S de terminal y tuberías, proporcionando nuevas funcionalidades útiles como tuberías bidireccionales y paso de descriptores de archivo . ^{[ 3 ]} También se produjo una versión para UNICOS . Eric S. Raymond cita a Ritchie diciendo acerca de la complejidad de System V STREAMS en comparación con su V8 ​​Streams que "Streams significa algo diferente cuando se grita". ^{[ 7 ]}

Simultáneamente con la adaptación de System V Release 3, AT&T desarrolló directrices 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 estrecho de los protocolos de red y transporte en una pila de protocolos dada , y la práctica típica de implementar las capas 5-7 fuera del núcleo , solo las interfaces de servicio STREAMS de las capas de enlace ^{[ 8 ]} y transporte ^{[ 11 ]} fueron estandarizadas posteriormente por X/Open . Junto con el modelo de paso de mensajes de transporte, se definió la Interfaz de Capa de Transporte (posteriormente adoptada como la Interfaz de Transporte de X/Open ) para proporcionar una API independiente del protocolo de transporte para el desarrollo de aplicaciones. Además, se definió una biblioteca que admite las capas de sesión , presentación y aplicación ^{[ 12 ]} y posteriormente fue estandarizada por The Open Group . ^{[ 13 ]}

STREAMS era necesario 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, el Grupo Austin lo marcó como opcional para el cumplimiento de POSIX en la versión 3 (UNIX 03). POSIX.1-2008 con TC1 (IEEE Std 1003.1, edición de 2013) ha designado STREAMS como "marcado como obsoleto" ^{[ 14 ] [ 15 ]} , lo que significa que dicha funcionalidad podría eliminarse en una versión futura de la especificación. Sin embargo, la definición específica de "obsoleto" utilizada ^{[ 16 ]} también establece que las aplicaciones POSIX que cumplan estrictamente con la especificación "no deben usar 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 en búfer una sola línea de entrada, es decir, esperaba a que el usuario presionara la tecla Intro antes de enviar la entrada al programa para su procesamiento; esto permitía una corrección de errores sencilla. 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 podían "enviar" un nuevo módulo a un extremo de la cadena para cambiar el comportamiento de una terminal u otro dispositivo de caracteres. Ritchie da el ejemplo de una cadena de un módulo de terminal encadenado con un módulo de red Datakit para lograr el inicio de sesión remoto a través de una red. ^{[ 5 ]} Además de los caracteres (bytes) que van del programa al dispositivo y viceversa , Streams podía transportar mensajes de control como "colgar" (caída de conexión) y mensajes ioctl .

También se podían usar flujos para la comunicación entre procesos , conectando dos procesos a pseudoterminales . Esta funcionalidad se implementó en el sistema de ventanas mpx para la terminal gráfica Blit , que podía mostrar múltiples ventanas de emulador de terminal . Cada ventana era un proceso que se comunicaba con el sistema de ventanas a través de una pseudoterminal con el controlador de disciplina de línea instalado, enviándole caracteres escritos y recibiendo texto (y gráficos) para mostrar. Las señales de control indicaban el deseo del usuario de cambiar entre ventanas o cerrarlas. ^{[ 17 ] [ 18 ] : 348–350}

Los módulos Streams propiamente dichos residen en el espacio del kernel en Unix, y se instalan (se agregan) y se eliminan (se eliminan) mediante la llamada al sistema ioctl. Por ejemplo, para instalar la disciplina de línea mencionada anteriormente en un descriptor de archivofd que hace referencia a un dispositivo terminal, se escribiría (en C ): ^{[ 18 ] : 347}

ioctl ( fd , PUSH , TTYLD );

Para realizar operaciones de entrada/salida en un flujo, se utilizan las llamadas readal writesistema como con los descriptores de archivo regulares, o un conjunto de funciones específicas de STREAMS para enviar mensajes de control. ^{[ 19 ]}

Ritchie admitió lamentar haber tenido que implementar Streams en el núcleo, en lugar de como procesos, pero se sintió obligado a hacerlo por razones de eficiencia. ^{[ 5 ]} Una implementación posterior de Plan 9 sí implementó módulos como procesos de nivel de usuario. ^{[ 20 ]}

STREAMS se ha utilizado principalmente en el mundo Unix System V; sin embargo, existen otras implementaciones:

• El Plan 9 originalmente utilizaba una variante multiprocesador de Streams de Research Unix. Durante la transición a la tercera edición del Plan 9, Streams se simplificó aún más a simples colas de E/S. ^{[ 20 ]}
• Una implementación desarrollada en Mentat se utilizó en Novell NetWare para su pila TCP/IP, y Apple la licenció para su uso en el sistema operativo Mac OS clásico a partir de la versión 7.5.2, como parte del sistema de red Open Transport . (En macOS , el Entorno Clásico utilizaba la arquitectura STREAMS, pero la arquitectura de red nativa utiliza la API de sockets de Berkeley y deriva del código de red BSD ).
• FreeBSD tiene soporte básico para llamadas al sistema relacionadas con STREAMS, como lo requiere la capa de compatibilidad binaria SVR4. ^{[ 21 ]}
• El kernel de Windows NT ofrecía una versión completa de STREAMS como el binario streams.sys. El DDK de NT incluso tenía un capítulo sobre STREAMS, que se extendió hasta NT4, aunque en el DDK de NT4 se declaró obsoleto. La pila TCP/IP original para Windows NT 3.1 fue implementada sobre STREAMS por Spider Systems y utilizó el binario streams.sys. A partir de NT 3.5, TCP/IP se rehizo por completo, ^{[ 22 ] [ 23 ]} adoptando la de Microsoft LAN Manager para OS/2 1.x.
• La capa de red AlphaTCP en AMOS, el sistema operativo para las computadoras Alpha Micro , también se basaba en SpiderStreams . ^{[ 24 ]}

Linux no incluye la funcionalidad STREAMS sin complementos de terceros. Caldera había presionado para que STREAMS se incluyera en Linux alrededor de 1998, para dar soporte a su Netware para Linux , pero fue rechazado de plano por los desarrolladores del kernel de Linux por razones técnicas (principalmente 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; posteriormente, figuró en las batallas legales del sucesor de Caldera, el Grupo SCO , contra Linux, con SCO alegando que Linux con STREAMS infringía lo que creía que eran sus derechos de autor sobre System V. ^{[ 25 ]}

• Goodheart, Berny; Cox, James (1994), El jardín mágico explicado: el funcionamiento interno de UNIX System V Release 4, un diseño de sistemas abiertos , Australia: Prentice Hall, ISBN 0-13-098138-9
• Open Group (1999), "Especificación de la interfaz del proveedor de transporte (TPI)", Especificación CAE de Open Group (Revisión 2.0.0, Borrador 2.ª  ed.), Berkshire, Reino Unido: Publicación de Open Group
• Open Group (septiembre de 1993), "ACSE/Presentation Services API (XAP)", Especificación X/Open CAE , vol.  XAP, Berkshire, Reino Unido: X/Open Company Limited, ISBN 1-872630-91-X
• Pajari, George (1992) [1991], Writing UNIX Device Drivers (2.ª impresión, 1.ª  ed.), Reading, MA: Addison-Wesley, ISBN 0-201-52374-4
• Ritchie, Dennis M. (octubre de 1984). "Un sistema de entrada-salida de flujo" . AT&T Bell Laboratories Technical Journal . 63 (8 Parte 2). AT&T: 1897–1910 . doi : 10.1002/j.1538-7305.1984.tb00071.x . S2CID 33497669. Recuperado el 13 de enero de 2018 . 
• Stevens, W. Richard (1993), Programación avanzada en el entorno UNIX (15.ª reimpresión, 1.ª  ed.), Reading, MA: Addison-Wesley, ISBN 0-201-56317-7
• Thomas, Rebecca; Rogers, Lawrence R.; Yates, Jean L. (1986), Guía avanzada para programadores del sistema UNIX V , Berkeley, CA: Osborne McGraw-Hill, ISBN 0-07-881211-9
• UNIX International (20 de agosto de 1991), Especificación de la interfaz del proveedor de enlace de datos (DLPI) (PDF) , Publicación de UNIX International (Revisión 2.0.0, Borrador 2.ª  ed.), Parsippany, NJ: UNIX International Press , consultado el 27 de julio de 2009.
• UNIX International (17 de agosto de 1992), Especificación de la interfaz del proveedor de red (NPI) (PDF) , Publicación de UNIX International (Revisión 2.0.0, Borrador 2.ª  ed.), Parsippany, NJ: UNIX International Press , consultado el 27 de julio de 2009.
• UNIX International (10 de diciembre de 1992), Especificación de la interfaz del proveedor de transporte (PDF) , Publicación de UNIX International (Revisión 1.5, Borrador 2.ª  ed.), Parsippany, NJ: UNIX International Press , consultado el 27 de julio de 2009.
• UNIX International (25 de octubre de 1990), Especificación de la interfaz de la biblioteca de presentaciones ACSE (APLI) , Publicación de UNIX International (  edición preliminar), Parisppany, NJ: UNIX International Press
• Waite Group (1987), Mitchel Waite (ed.), UNIX Papers (2.ª reimpresión, 1.ª  ed.), Indianápolis, IN: Howard W. Sams & Company, ISBN 0-672-22578-6
• Barr, Adam (19 de junio de 2001), "Microsoft, TCP/IP, código abierto y licencias" , Kuro5hin , consultado el 22 de febrero de 2013.
• Valentine, Mark (19 de junio de 2001). "Re: Consulta: ¿Cómo saber si Microsoft está usando código TCP/IP de BSD?" . freebsd-hackers (Lista de correo) . Recuperado el 22 de febrero de 2013 .

• El manual original de stream(4) de Unix 8.ª edición
• El marco STREAMS en Digital UNIX – de la Guía del programador de redes de Digital UNIX 
• Guía de programación de Oracle (anteriormente Sun) STREAMS