В компьютерных сетях STREAMS — это собственная платформа Unix System V для реализации драйверов символьных устройств , сетевых протоколов и межпроцессного взаимодействия . В этой среде поток — это цепочка сопрограмм , которые передают сообщения между программой и драйвером устройства (или между парой программ). ПОТОКИ возникли в версии 8 Research Unix как Streams (без заглавной буквы).
Конструкция STREAMS представляет собой модульную архитектуру для реализации полнодуплексного ввода -вывода между ядром и драйверами устройств. Чаще всего он использовался при разработке терминального ввода-вывода ( линейная дисциплина ) и сетевых подсистем. В System V Release 4 весь интерфейс терминала был переопределен с использованием STREAMS. [1] Важной концепцией STREAMS является возможность объединять драйверы — модули специального кода, которые могут изменять функциональность сетевого интерфейса или другого устройства — вместе, образуя стек. Некоторые из этих драйверов могут быть объединены в цепочку по порядку.
STREAMS был основан на подсистеме ввода-вывода Streams, представленной в восьмом издании Research Unix (V8) Деннисом Ритчи , где она использовалась для подсистемы терминального ввода-вывода и набора протоколов Интернета . Эта версия, еще не названная заглавными буквами STREAMS, соответствовала новой функциональности существующих системных вызовов ввода-вывода устройства ( open , close , read , write и ioctl ), [2] и ее применение ограничивалось терминальным вводом-выводом и протоколы, обеспечивающие канальную семантику ввода-вывода.
Эта система ввода-вывода была перенесена в System V Release 3 Робертом Израэлем, Гилом МакГратом, Дэйвом Оландером, Хер-Доу Че и Мори Бахом как часть более широкой структуры, предназначенной для поддержки различных транспортных протоколов, включая TCP, класс ISO. 4, SNA LU 6.2 и протокол AT&T NPACK (используется в RFS ). [3] Впервые он был выпущен вместе с пакетом Network Support Utilities (NSU) UNIX System V Release 3. [4] В этот порт добавлены системные вызовы putmsg , getmsg и poll , которые по своему назначению почти эквивалентны send , Recv . и выберите вызовы из сокетов Беркли. Системные вызовы putmsg и getmsg первоначально назывались send и Recv [5] , но были переименованы во избежание конфликта пространств имен . [6] В System V Release 4 технология STREAMS была расширена и использовалась для структуры терминального ввода-вывода и каналов, предоставляя новые полезные функции, такие как двунаправленные каналы и передача файловых дескрипторов . [3] Также был выпущен порт для UNICOS . Эрик С. Рэймонд цитирует слова Ричи о сложности System V STREAMS по сравнению с его V8 Streams: «Потоки означают нечто иное, когда их выкрикивают». [7]
Одновременно с портом System V Release 3 компания AT&T разработала независимые от протокола правила передачи сообщений STREAMS для канального , [8], сетевого , [9] и транспортного уровней [10] модели OSI (уровни 2–4). Из-за типично тесной реализации сетевых и транспортных протоколов в данном стеке протоколов , а также типичной практики реализации уровней 5-7 вне ядра , только канальный [8] и транспортный уровень [11] сервисные интерфейсы STREAMS были позже стандартизирован X/Open . В сочетании с моделью передачи транспортных сообщений был определен интерфейс транспортного уровня (позже принятый как X/Open Transport Interface ), обеспечивающий независимый от транспортного протокола API для разработки приложений. Также была определена и позже стандартизирована The Open Group библиотека, поддерживающая сеансовый , презентационный и прикладной уровни [12] . [13]
STREAMS требовался для соответствия Единой спецификации UNIX версий 1 (UNIX 95) и 2 (UNIX 98), но в результате отказа разработчиков BSD и Linux предоставлять STREAMS, [ необходима цитата ] была помечена как необязательная для POSIX. соответствие Austin Group в версии 3 (UNIX 03). POSIX.1-2008 с TC1 (IEEE Std 1003.1, издание 2013 г.) обозначил STREAMS как «отмеченный устаревшим» [14] [15], что означает, что указанная функциональность может быть удалена в будущей версии спецификации. Однако в используемом конкретном определении термина «устаревший» [16] также говорится, что приложения, строго соответствующие POSIX, «не должны использовать устаревшие функции».
В Unix версии 7 команда подключалась к терминалу (клавиатура и экран или клавиатура и принтер ) через механизм, называемый дисциплиной строки, который буферизировал одну строку ввода, т. е. ждал, пока пользователь нажмет клавишу Return. перед отправкой входных данных в программу для обработки; это позволило просто исправить ошибки. Потоки заменили это набором модулей обработки, организованных в линейную цепочку, которая обеспечивала двустороннюю связь между соседними модулями. Программы могли «вставить» новый модуль на один конец цепочки, чтобы изменить поведение терминала или другого символьного устройства. Ричи приводит пример цепочки терминального модуля, связанного с сетевым модулем Datakit , для обеспечения удаленного входа в систему по сети. [5] Помимо символов (байтов), передаваемых из программы в устройство и наоборот , потоки могут переносить управляющие сообщения, такие как «зависание» (разрыв соединения) и сообщения ioctl .
Потоки также можно использовать для межпроцессного взаимодействия , соединяя два процесса с псевдотерминалами . Эта функциональность была реализована в оконной системе mpx для графического терминала Blit , которая могла отображать несколько окон эмулятора терминала . Каждое окно представляло собой процесс, который взаимодействовал с оконной системой через псевдотерминал, на котором был установлен драйвер дисциплины линии, отправляя ему напечатанные символы и получая текст (и графику) для отображения. Сигналы управления обозначали желание пользователя переключиться между окнами или закрыть их. [17] [18] : 348–350
Фактические модули Streams находятся в пространстве ядра Unix и устанавливаются (загружаются) и удаляются (извлекаются) системным вызовом ioctl. Например, чтобы установить вышеупомянутую дисциплину строк в файловом дескрипторе fd , ссылающемся на терминальное устройство, можно было бы написать (на языке C ): [18] : 347.
ioctl ( fd , PUSH , TTYLD ); Для выполнения ввода/вывода в потоке можно либо использовать системные вызовы readи, writeкак в случае с обычными файловыми дескрипторами, либо набор функций, специфичных для ПОТОКОВ, для отправки управляющих сообщений. [19]
Ритчи признался, что сожалел о необходимости реализовать Streams в ядре, а не как процессы, но чувствовал себя обязанным сделать это из соображений эффективности. [5] В более поздней реализации Plan 9 модули были реализованы как процессы пользовательского уровня. [20]
STREAMS в основном использовался в мире System V Unix; однако существуют и другие реализации:
Linux не поддерживает функции STREAMS без сторонних надстроек. Кальдера «настоял» на включении STREAMS в Linux ок. 1998, для поддержки своего Netware для Linux, но он был категорически отвергнут разработчиками ядра Linux по техническим причинам (в основном производительность). [25] Уровни совместимости Linux с другими операционными системами преобразуют операции STREAMS в сокеты как можно раньше. [26] В Caldera использовалась реализация «LiS» компании GCOM; позже он участвовал в судебных тяжбах преемника Caldera, SCO Group , против Linux, при этом SCO утверждала, что Linux с STREAMS нарушил, по ее мнению, ее авторские права на System V. [25]