STREAMS - Enciclopedia

En la red de computadoras, STREAMS es el marco nativo en el Sistema V de Unix 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 cooperativas que pasan mensajes entre un programa y un controlador de dispositivo (o entre un par de programas). STREAMS tuvo su origen en la Versión 8 del Research Unix, como Streams (sin mayúsculas).

El diseño de STREAMS es una arquitectura modular para implementar E/S de doble sentido entre el núcleo y los controladores de dispositivo. Sus usos más comunes han sido en el desarrollo de E/S de terminal (disciplina de línea) y subsistemas de red. En el Sistema V Release 4, toda la interfaz de terminal fue reimplementada utilizando STREAMS. Un concepto importante en STREAMS es la capacidad de empujar controladores – módulos de código personalizados que pueden modificar la funcionalidad de una interfaz de red u otro dispositivo – juntos para formar una pila. Se pueden encadenar varios de estos controladores para formar una pila.

Historia
STREAMS se basó en el subsistema de E/S de Streams introducido en la Octava Edición del 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 ajustó a la nueva funcionalidad bajo las llamadas de sistema de E/S de dispositivo existentes (open, close, read, write y ioctl), y su aplicación se limitó a la E/S de terminal y protocolos que proporcionan semántica de E/S de tubería. Este sistema de E/S se portó al Sistema 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 soportar una variedad de protocolos de transporte, incluyendo TCP, ISO Class 4 transport, SNA LU 6.2 y el protocolo NPACK de AT&T (usado en RFS). Se lanzó por primera vez con el paquete de Utilidades de Soporte de Red (NSU) del Sistema V Release 3. Esta portación agregó las llamadas de sistema putmsg, getmsg y poll, que son casi equivalentes en propósito a las llamadas send, recv y select de Berkeley sockets. Las llamadas de sistema putmsg y getmsg originalmente se llamaban send y recv, pero se renombraron para evitar conflictos de espacio de nombres. En el Sistema 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. También se produjo una portación para UNICOS. Eric S. Raymond cita a Ritchie diciendo sobre la complejidad de System V STREAMS en comparación con su V8 Streams que "Streams significa algo diferente cuando se grita".

Concurrente con la portación del Sistema V Release 3, AT&T desarrolló directrices de paso de mensajes de Streams independientes del protocolo para las capas de enlace, red y transporte del modelo OSI (capas 2-4). Debido a la implementación típicamente cercana del enlace 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 núcleo, solo las interfaces de servicio de Streams de las capas de enlace y transporte se estandarizaron más tarde por X/Open. En conjunction con el modelo de paso de mensajes de la capa de transporte, se definió la Interfaz de Capa de Transporte (más tarde 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 soportaba las capas de sesión, presentación y aplicación y más tarde se estandarizó por The Open Group.

STREAMS era obligatorio para la conformidad con las versiones 1 (UNIX 95) y 2 (UNIX 98) de la Single UNIX Specification, pero como resultado de la negativa de los desarrolladores de BSD y Linux a proporcionar STREAMS, el Austin Group lo marcó como opcional para la conformidad con POSIX 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', lo que significa que dicha funcionalidad puede eliminarse en una futura versión de la especificación. Sin embargo, la definición específica de 'obsoleto' utilizada también dice que las aplicaciones estrictamente conformes a POSIX 'no deben usar características obsoletas'.

Resumen técnico

En la Versión 7 de Unix, un comando se conectaba a una terminal (teclado y pantalla, o teclado y impresora) a través de un mecanismo llamado disciplina de línea, que almacenaba una única línea de entrada, es decir, esperaba a que el usuario presionara la tecla Return antes de enviar la entrada al programa para su procesamiento; esto permitía la corrección de errores simple. 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 adyacentes. Los programas podí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 da el ejemplo de una cadena de un módulo de terminal enlazada con un módulo de red Datakit para lograr el inicio de sesión remoto a través de una red. Además de los caracteres (bytes) que van del programa al dispositivo y viceversa, Streams podía llevar mensajes de control como "hangup" (desconectar conexión) y mensajes ioctl.

Streams también podía utilizarse 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 de emulador de terminal. Cada ventana era un proceso que comunicaba con el sistema de ventanas a través de una pseudoterminal que tenía instalado el controlador de disciplina de línea, enviándole caracteres tecleados y recibiendo texto (y gráficos) para mostrar. Las señales de control designaban el deseo del usuario de cambiar entre ventanas o cerrarlas.

Los módulos de Streams realmente viven en el espacio del núcleo en Unix y se instalan (empujan) y se eliminan (sacan) mediante la llamada de sistema ioctl. Por ejemplo, para instalar la disciplina de línea mencionada en un descripto de archivo fd que se refiere a un dispositivo de terminal, se escribiría (en C):

Para realizar E/S en un flujo, se utilizan las llamadas de sistema read y write como con descriptores de archivo regulares, o un conjunto de funciones específicas de Streams para enviar mensajes de control.

Ritchie admitió que lamentaba tener que implementar Streams en el núcleo en lugar de como procesos, pero sintió la necesidad de hacerlo por razones de eficiencia. Una implementación posterior de Plan 9 implementó los módulos como procesos a nivel de usuario.

Implementaciones
STREAMS se ha utilizado principalmente en el mundo del Sistema V de Unix; sin embargo, existen otras implementaciones:

Plan 9 originalmente utilizó una variante de multiprocesador de los Streams del Research Unix. Durante la transición a la tercera edición de Plan 9, los Streams se simplificaron aún más a colas de E/S simples.
Una implementación escrita en Mentat se utilizó en Novell NetWare para su pila de TCP/IP, y licenciada por Apple para su uso en el classic Mac OS a partir de la versión 7.5.2, como parte del sistema de red Open Transport. (En macOS, el Entorno Clásico utilizó la arquitectura de Streams, pero la arquitectura de red nativa utiliza la API de sockets de Berkeley y se deriva del código de red de BSD).
FreeBSD tiene soporte básico para las llamadas de sistema relacionadas con Streams, según sea necesario para la compatibilidad binaria de SVR4.
El núcleo de Windows NT ofreció una portación completa de Streams como el binario streams.sys. NT DDK incluso tenía un capítulo sobre Streams, hasta NT4, aunque en el NT4 DDK se declaró obsoleto. La pila de TCP/IP original para Windows NT 3.1 se implementó sobre Streams por Spider Systems y utilizó el binario streams.sys. A partir de NT 3.5, TCP/IP se remodeló completamente, adoptando la del Microsoft LAN Manager para OS/2 1.x.
La capa de red AlphaTCP en AMOS, el sistema operativo para computadoras Alpha Micro, también se basó en SpiderStreams.
Linux no incluye la funcionalidad de Streams sin complementos de terceros. Caldera había abogado por incluir Streams en Linux alrededor de 1998, para soportar su Netware for Linux, pero fue rechazado de plano por los desarrolladores del núcleo Linux por razones técnicas (principalmente rendimiento). Las capas de compatibilidad de Linux para otros sistemas operativos convierten las operaciones de Streams en sockets tan pronto como sea posible. La implementación utilizada por Caldera fue "LiS", de una empresa llamada GCOM; más tarde figuró en las batallas legales por parte del sucesor de Caldera, la SCO Group, contra Linux, con SCO alegando que Linux con Streams infringía lo que creía ser sus derechos de autor sobre System V.

Notas


Referencias
Goodheart, Berny; Cox, James (1994), The magic garden explained: the internals of UNIX System V Release 4, an open-systems design, Australia: Prentice Hall, ISBN 0-13-098138-9
Open Group (1999), "Transport Provider Interface (TPI) Specification", Open Group CAE Specification (Revision 2.0.0, Draft 2 ed.), Berkshire, UK: Open Group Publication
Open Group (September 1993), "ACSE/Presentation Services API (XAP)", X/Open CAE Specification, vol. XAP, no. c303, Berkshire, UK: X/Open Company Limited, ISBN 1-872630-91-X
Pajari, George (1992) [1991], Writing UNIX Device Drivers (2nd Printing, 1st ed.), Reading, MA: Addison-Wesley, ISBN 0-201-52374-4
Ritchie, Dennis M. (October 1984). "A Stream Input-Output System". AT&T Bell Laboratories Technical Journal. 63 (8 Part 2). AT&T: 1897–1910. doi:10.1002/j.1538-7305.1984.tb00071.x. S2CID 33497669. Retrieved 2018-01-13.
Stevens, W. Richard (1993), Advanced Programming in the UNIX Environment (15th Printing, 1st ed.), Reading, MA: Addison-Wesley, ISBN 0-201-56317-7
Thomas, Rebecca; Rogers, Lawrence R.; Yates, Jean L. (1986), Advanced Programmers Guide to UNIX System V, Berkeley, CA: Osborne McGraw-Hill, ISBN 0-07-881211-9
UNIX International (August 20, 1991), Data Link Provider Interface (DLPI) Specification (PDF), UNIX International Publication (Revision 2.0.0, Draft 2 ed.), Parsippany, N.J.: UNIX International Press, retrieved 2009-07-27
UNIX International (August 17, 1992), Network Provider Interface (NPI) Specification (PDF), UNIX International Publication (Revision 2.0.0, Draft 2 ed.), Parsippany, N.J.: UNIX International Press, retrieved 2009-07-27
UNIX International (December 10, 1992), Transport Provider Interface Specification (PDF), UNIX International Publication (Revision 1.5, Draft 2 ed.), Parsippany, N.J.: UNIX International Press, retrieved 2009-07-27
UNIX International (October 25, 1990), ACSE/Presentation Library Interface (APLI) Specification, UNIX International Publication (Draft ed.), Parisppany, N.J.: UNIX International Press
Waite Group (1987), Mitchel Waite (ed.), UNIX Papers (2nd Printing, 1st ed.), Indianapolis, IN: Howard W. Sams & Company, ISBN 0-672-22578-6
Barr, Adam (June 19, 2001), "Microsoft, TCP/IP, Open Source, and Licensing", Kuro5hin, retrieved February 22, 2013
Valentine, Mark (June 19, 2001). "Re: Query: How to tell if Microsoft is using BSD TCP/IP code?". freebsd-hackers (Mailing list). Retrieved February 22, 2013.


Enlaces externos
El manual original de stream(4) de la octava edición de Unix
El marco de Streams en Digital UNIX – de la Guía del Programador de Red de Digital UNIX
Oracle (anteriormente Sun) Guía de Programación de Streams