Войти
В компьютерных сетях, ПОТОКИ - это собственная среда в Unix System V для реализации символьных устройств драйверов, сетевых протоколов и межпроцессного взаимодействия. В этой структуре поток представляет собой цепочку сопрограмм, которые передают сообщения между программой и драйвером устройства (или между парой программ). ПОТОКИ возникли в Версии 8 Research Unix как потоки (без заглавных букв).
STREAMS представляет собой модульную архитектуру для реализации полнодуплексного ввода-вывода между ядром и драйверами устройств. Чаще всего он использовался при разработке терминального ввода-вывода (линейная дисциплина ) и сетевых подсистем. В System V Release 4 весь интерфейс терминала был повторно реализован с использованием STREAMS. Важной концепцией STREAMS является возможность объединять драйверы - модули пользовательского кода, которые могут изменять функциональность сетевого интерфейса или другого устройства - вместе для формирования стека. Некоторые из этих драйверов можно связать вместе по порядку.
ПОТОКИ были основаны на подсистема Streams I / O, представленная в Eighth Edition Research Unix (V8) Деннисом Ритчи, где она использовалась для подсистемы терминала I / O и пакет Интернет-протокола. Эта версия, еще не названная STREAMS в заглавных буквах, соответствовала новой функциональности в рамках существующих системных вызовов ввода-вывода устройств (открытие, закрытие, чтение, запись и ioctl), и ее применение было ограничено вводом-выводом терминала и протоколами, обеспечивающими канал. -подобная семантика ввода-вывода.
Эта система ввода-вывода была перенесена на System V Release 3 Робертом Израэлем, Гилом МакГратом, Дэйвом Оландером, Хер-Доу Че и Мори Бахом как часть более широкой структуры, предназначенной для поддержки различных транспортных протоколов., включая TCP, транспорт ISO класса 4, SNA LU 6.2 и протокол ATT NPACK (используется в RFS ). Впервые он был выпущен с пакетом Network Support Utilities (NSU) для UNIX System V Release 3. Этот порт добавил системные вызовы putmsg, getmsg и poll , которые по назначению почти эквивалентны send, recv, и выберите вызовы из сокетов Беркли. Системные вызовы putmsg и getmsg изначально назывались send и recv, но были переименованы, чтобы избежать конфликта пространств имен. В System V Release 4 STREAMS был расширен и использовался для инфраструктуры ввода-вывода терминала и каналов, обеспечивая полезные новые функции, такие как двунаправленные каналы и передача файлового дескриптора. Также был создан порт для Unicos. Эрик С. Реймонд цитирует слова Ричи о сложности ПОТОКОВ System V по сравнению с его потоками V8, что «потоки означают нечто иное, когда кричат».
Одновременно с System V Release 3 порт, ATT разработала протокол-независимые инструкции по передаче сообщений STREAMS для link, network и транспортных уровней OSI. модель (слои 2-4). Из-за типичной тесной связи реализации сетевых и транспортных протоколов в данном стеке протоколов и типичной практики реализации уровней 5-7 вне ядра только link и транспортный уровень Сервисные интерфейсы STREAMS были позже стандартизированы в X / Open. В сочетании с моделью передачи транспортных сообщений был определен интерфейс транспортного уровня (позже принятый как X / Открытый транспортный интерфейс ) для обеспечения независимого от транспортного протокола API для разработки приложений. Кроме того, была определена библиотека, поддерживающая сеанс, презентация и прикладные уровни, а затем стандартизованная . Open Group.
STREAMS была необходима для соответствия с единой спецификацией UNIX версий 1 (UNIX 95) и 2 (UNIX 98), но в результате отказа разработчиков BSD и Linux provide STREAMS, был помечен Austin Group как необязательный для соответствия POSIX в версии 3 (UNIX 03). POSIX.1-2008 с TC1 (IEEE Std 1003.1, издание 2013 г.) обозначил STREAMS как «помеченные как устаревшие», что означает, что указанные функциональные возможности могут быть удалены в будущей версии спецификации. Однако используемое конкретное определение «устаревшего» также гласит, что строго соответствующие приложения POSIX «не должны использовать устаревшие функции».
Пример использования потоков для реализации удаленного выполнения команд по сети, после (Ritchie 1984)В версии 7 Unix команда была подключена к терминал (клавиатура и экран или клавиатура и принтер ) через механизм, называемый дисциплиной линии, который будет буферизовать одну строку ввода, то есть ждать, пока пользователь нажмет клавишу возврата перед отправкой входных данных в программу для обработки; это позволило простое исправление ошибок. Потоки заменили это набором модулей обработки, организованных в линейную цепочку, которая обеспечивала двунаправленную связь между соседними модулями. Программы могли «протолкнуть» новый модуль на один конец цепочки для изменения поведения терминала или другого символьного устройства. Ричи приводит пример цепочки терминального модуля, соединенного с сетевым модулем Datakit для удаленного входа в систему по сети. Помимо символов (байтов) переходя от программы к устройству и наоборот, Streams может ry управляющие сообщения, такие как «зависание» (разрыв соединения) и сообщения ioctl.
Потоки также можно использовать для межпроцессного взаимодействия, подключив два процесса к псевдотерминалам. Эта функциональность была реализована в оконной системе mpx для графического терминала Blit, который мог отображать несколько окон эмулятора терминала. Каждое окно представляло собой процесс, который взаимодействовал с оконной системой через псевдотерминал, на котором был установлен драйвер линейной дисциплины, отправляя ему набранные символы и получая текст (и графику) для отображения. Управляющие сигналы обозначают желание пользователя переключаться между окнами или закрывать их.
Фактические модули Streams находятся в пространстве ядра в Unix и устанавливаются (вставляются) и удаляются (выталкиваются) Системный вызов ioctl. Например, чтобы установить вышеупомянутую линейную дисциплину на файловый дескриптор fd, относящийся к оконечному устройству, нужно написать (в C ):
ioctl (fd, PUSH, TTYLD);
Для выполнения ввода / вывода в потоке используются системные вызовы readи write, как с обычными файловыми дескрипторами, или набор специфичных для STREAMS функций для отправки управляющих сообщений.
Ричи признался, что сожалеет о том, что ему пришлось реализовывать потоки в ядре, а не как процессы, но чувствовал себя вынужденным сделать это по соображениям эффективности. В более поздней реализации Плана 9 модули были реализованы как процессы уровня пользователя.
STREAMS в основном использовались в мире System V Unix; однако существуют и другие реализации:
Linux не включает Функциональность ПОТОКОВ без сторонних надстроек. Caldera «подтолкнула» к включению ПОТОКОВ в Linux ок. 1998 г., чтобы поддержать его, но разработчики ядра Linux категорически отвергли его по техническим причинам (в основном из-за производительности). Уровни совместимости в Linux для других операционных систем преобразуют операции STREAMS в сокеты как можно раньше. В Caldera использовалась реализация LiS, созданная компанией GCOM; позже он фигурировал в юридических баталиях преемника Caldera, SCO Group, против Linux, когда SCO утверждала, что Linux с STREAMS нарушает то, что, по ее мнению, является ее авторскими правами на System V.
