STREAMS

Введение

UNIX System V framework В компьютерных сетях STREAMS - это собственная структура в Unix System V для реализации драйверов устройств символов, сетевых протоколов и межпроцессной связи. В этой структуре поток представляет собой цепочку коррутинов, которые передают сообщения между программой и драйвером устройства (или между парой программ). STREAMS появился в версии 8 Research Unix, как Streams (не заглавная буква). Конструкция STREAMS представляет собой модульную архитектуру для реализации полной дуплексной вводы и вывода между ядром и драйверами устройств. Его наиболее частое использование заключается в разработке подсистем I/O (линейная дисциплина) и сетевых подсистем. В System V Release 4 весь интерфейс терминала был переделан с использованием STREAMS. Важной концепцией в STREAMS является возможность вставлять в драйверы модули пользовательского кода, которые могут изменять функциональность сетевого интерфейса или другого устройства вместе, чтобы сформировать стек. Несколько из этих драйверов можно приковать вместе в цепи.

История

STREAMS был основан на подсистеме Streams I/O, введенной в исследовательском Unix восьмого издания (V8) Деннисом Ричи, где он использовался для подсистемы I/O терминалов и пакета интернет-протоколов. Эта версия, еще не называемая STREAMS, соответствовала новой функциональности в рамках существующих системных вызовов ввода-вывода устройств (открытие, закрытие, чтение, запись и ioctl), и ее применение было ограничено терминальными вводами-выводами и протоколами, обеспечивающими семантику ввода-вывода. Эта система ввода-вывода была перенесена в System V Release 3 Робертом Израилем, Гилом Макгратом, Дэйвом Оландером, Хер Доу Че и Мори Бахом в рамках более широкой структуры, предназначенной для поддержки различных транспортных протоколов, включая TCP, ISO Class 4 transport, SNA LU 6.2 и протокол AT&T NPACK (используемый в RFS). Впервые он был выпущен с пакетом Network Support Utilities (NSU) UNIX System V Release 3. Этот порт добавил вызовы системы putmsg, getmsg и poll, которые почти эквивалентны по назначению вызовам отправки, восстановления и выбора из сокетов Беркли. Системные вызовы putmsg и getmsg первоначально назывались send и recv. В System V Release 4 STREAMS был расширен и использован для терминальной структуры ввода-вывода и труб, обеспечивая полезные новые функции, такие как двунаправленные трубы и передача файлового дескриптора. Одновременно с портом System V Release 3 AT&T разработала протокольные независимые STREAMS-руководства по передаче сообщений для связки, сети и транспортных уровней модели OSI (слои 2 и 4). Из-за типично тесной связи сетевых и транспортных протоколов в стеке протоколов и типичной практики реализации уровней 5 7 вне ядра, только интерфейсы услуг STREAMS были позже стандартизированы X/Open. В сочетании с моделью передачи транспортных сообщений был определен интерфейс транспортного уровня (позже принятый как X / Open Transport Interface), чтобы обеспечить независимый от транспортного протокола API для разработки приложений. Кроме того, библиотека, поддерживающая уровни сеанса, презентации и приложений, была определена и позже стандартизирована The Open Group. STREAMS был необходим для соответствия версиям Single UNIX Specification 1 (UNIX 95) и 2 (UNIX 98), но в результате отказа разработчиков BSD и Linux предоставить STREAMS, был помечен как необязательный для соответствия POSIX группой Остина в версии 3 (UNIX 03). POSIX.1 2008 с TC1 (IEEE Std 1003.1, 2013 издание) обозначил STREAMS как "обозначенный устаревшим", что означает, что указанная функциональность может быть удалена в будущей версии спецификации. Однако в конкретном определении "устаревшего" также говорится, что строго соответствующие POSIX-приложения "не должны использовать устаревшие функции".

STREAMS was based on the Streams I/O subsystem introduced in the Eighth Edition Research Unix (V8) by Dennis Ritchie, where it was used for the terminal I/O subsystem and the Internet protocol suite. This version, not yet called STREAMS in capitals, fit the new functionality under the existing device I/O system calls (open, close, read, write, and ioctl), and its application was limited to terminal I/O and protocols providing pipe like I/O semantics. This I/O system was ported to System V Release 3 by Robert Israel, Gil McGrath, Dave Olander, Her Daw Che, and Maury Bach as part of a wider framework intended to support a variety of transport protocols, including TCP, ISO Class 4 transport, SNA LU 6.2, and the AT&T NPACK protocol (used in RFS). It was first released with the Network Support Utilities (NSU) package of UNIX System V Release 3. This port added the putmsg, getmsg, and poll system calls, which are nearly equivalent in purpose to the send, recv, and select calls from Berkeley sockets. The putmsg and getmsg system calls were originally called send and recv, In System V Release 4, STREAMS was extended and used for the terminal I/O framework and pipes, providing useful new functionality like bidirectional pipes and file descriptor passing. Concurrent with the System V Release 3 port, AT&T developed protocol independent STREAMS message passing guidelines for the link, network, and transport layers of the OSI model (layers 2 4). Due to the typically close implementation coupling of the network and transport protocols in a given protocol stack, and the typical practice of implementing layers 5 7 outside of the kernel, only the link STREAMS service interfaces were later standardized by X/Open. In conjunction with the transport message passing model, the Transport Layer Interface (later adopted as the X/Open Transport Interface) was defined to provide a transport protocol independent API for application development. Also, a library supporting the session, presentation and application layers was defined and later standardized by The Open Group. STREAMS was required for conformance with the Single UNIX Specification versions 1 (UNIX 95) and 2 (UNIX 98), but as a result of the refusal of the BSD and Linux developers to provide STREAMS, was marked as optional for POSIX compliance by the Austin Group in version 3 (UNIX 03). POSIX.1 2008 with TC1 (IEEE Std 1003.1, 2013 edition) has designated STREAMS as 'marked obsolescent' meaning that said functionality may be removed in a future version of the specification. However, the specific definition of 'obsolescent' used also says that strictly conforming POSIX applications 'shall not use obsolescent features'.