ПОТОКИ - STREAMS

В компьютерная сеть, ПОТОКИ это родная структура в Unix System V для реализации символьное устройство драйверы, сетевые протоколы и межпроцессного взаимодействия. В этой структуре поток представляет собой цепочку сопрограммы это передавать сообщения между программой и драйвером устройства (или между парой программ). ПОТОКИ возникли в версии 8 Исследование Unix, как потоки (без заглавных букв).

STREAMS представляет собой модульную архитектуру для реализации полнодуплексного режима. Ввод / вывод между ядром и драйверами устройств. Чаще всего его использовали при разработке терминального ввода-вывода (линейная дисциплина ) и сетевые подсистемы. В System V Release 4 весь интерфейс терминала был повторно реализован с использованием STREAMS.[1] Важной концепцией STREAMS является возможность объединять драйверы - модули пользовательского кода, которые могут изменять функциональность сетевого интерфейса или другого устройства - вместе для формирования стека. Некоторые из этих драйверов можно связать вместе по порядку.

История

STREAMS был основан на подсистеме Streams I / O, представленной в Восьмое издание Research Unix (V8) пользователя Деннис Ричи, где он использовался для терминала Ввод / вывод подсистема и Набор интернет-протоколов. Эта версия, еще не названная ПОТОКОВ заглавными буквами, соответствует новой функциональности в рамках существующих системных вызовов ввода-вывода устройств (открыто, близко, читать, записывать, и 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, и голосование системные вызовы, которые по назначению почти эквивалентны Отправить, получить, и Выбрать звонки из розеток Беркли. В putmsg и getmsg системные вызовы изначально назывались Отправить и получить,[5] но были переименованы, чтобы избежать конфликта пространств имен.[6] В System V Release 4 STREAMS был расширен и использовался для инфраструктуры и каналов ввода-вывода терминала, обеспечивая полезные новые функции, такие как двунаправленные каналы и дескриптор файла прохождение.[3] Порт для Unicos также был произведен. Эрик С. Раймонд цитирует слова Ричи о сложности ПОТОКОВ System V по сравнению с его потоками V8, что «потоки означают нечто иное, когда их кричат».[7]

Одновременно с портом System V Release 3, AT&T разработали протокол-независимые инструкции по передаче сообщений STREAMS для ссылка на сайт,[8] сеть,[9] и транспортные уровни[10] из Модель OSI (слои 2-4). Из-за типичной тесной связи реализации сетевых и транспортных протоколов в данном стек протоколов, и типичная практика реализации слоев 5-7 вне ядро, только ссылка на сайт[8] и транспортный уровень[11] Сервисные интерфейсы STREAMS позже были стандартизированы X / Открыть. В сочетании с моделью передачи транспортных сообщений Интерфейс транспортного уровня (позже принят как X / открытый транспортный интерфейс ) был определен для предоставления независимого от транспортного протокола API для разработки приложений. Кроме того, библиотека, поддерживающая сессия, презентация и прикладные слои[12] был определен и позже стандартизирован Открытая группа.[13]

STREAMS требовалось для соответствия Единая спецификация UNIX версии 1 (UNIX 95) и 2 (UNIX 98), но в результате отказа от BSD и Linux разработчиков для предоставления ПОТОКОВ,[нужна цитата ] был отмечен как необязательный для соответствия POSIX группой Austin Group в версии 3 (UNIX 03). POSIX.1-2008 с TC1 (IEEE Std 1003.1, издание 2013 г.) обозначил STREAMS как «устаревшие»[14][15] означает, что указанная функциональность может будет удален в будущей версии спецификации. Однако использовалось конкретное определение «устаревший».[16] также говорит, что строго соответствующие POSIX приложения «не должны использовать устаревшие функции».

Технический обзор

Пример использования Streams для реализации удаленного выполнения команд по сети после (Ричи 1984 )

В Версия 7 Unix, команда была подключена к терминалу (клавиатуре и экрану, или клавиатура и принтер ) через механизм, называемый дисциплиной линии, который будет буферизовать одну строку ввода, то есть ждать, пока пользователь нажмет Ключ возврата перед отправкой ввода в программу для обработки; это позволило простое исправление ошибок. Streams заменил это набором модулей обработки, организованных в линейную цепочку, которая обеспечивала двунаправленную связь между соседними модулями. Программы могут «протолкнуть» новый модуль на один конец цепочки, чтобы изменить поведение терминала или другого символьного устройства. Ричи приводит пример цепочки оконечного модуля, соединенного с Датакит сетевой модуль для удаленного входа в систему по сети.[5] Помимо символов (байтов), передаваемых от программы к устройству и наоборот, Потоки могут нести управляющие сообщения, такие как "зависание" (разрыв соединения) и ioctl Сообщения.

Потоки также можно использовать для межпроцессного взаимодействия, подключив два процесса к псевдотерминалы. Эта функция была реализована в mpx оконная система для Блит графический терминал, который может отображать несколько эмулятор терминала окна. Каждое окно представляло собой процесс, который взаимодействовал с оконной системой через псевдотерминал, на котором был установлен драйвер линейной дисциплины, отправляя ему набранные символы и получая текст (и графику) для отображения. Управляющие сигналы обозначают желание пользователя переключаться между окнами или закрывать их.[17][18]:348–350

Фактические модули Streams находятся в пространство ядра в Unix и устанавливаются (отправляются) и удаляются (выталкиваются) системным вызовом ioctl. Например, чтобы установить вышеупомянутую линейную дисциплину на дескриптор файла fd ссылаясь на оконечное устройство, можно было бы написать (в C ):[18]:347

ioctl(fd, ОТ СЕБЯ, TTYLD);

Для выполнения ввода / вывода в потоке используется либо читать и записывать системные вызовы, как с обычными файловыми дескрипторами, или набор специфичных для STREAMS функций для отправки управляющих сообщений.[19]

Ричи признался, что сожалеет о том, что ему пришлось реализовывать потоки в ядре, а не как процессы, но чувствовал себя вынужденным сделать это из соображений эффективности.[5] Позже План 9 реализация реализовала модули как процессы уровня пользователя.[20]

Реализации

ПОТОКИ в основном использовались в мире System V Unix; однако существуют и другие реализации:

  • План 9 изначально использовал многопроцессорный вариант Research Unix's Streams. При переходе к третьей редакции Plan 9 потоки были дополнительно упрощены до простых очередей ввода-вывода.[20]
  • Реализация, написанная на Ментат был использован в Novell NetWare для своего стека TCP / IP и лицензирован яблоко для использования в классическая Mac OS начиная с версии 7.5.2, как часть Открытый транспорт сетевая система. (В macOS, то Классическая среда использовали архитектуру STREAMS, но собственная сетевая архитектура использует Розетки Berkeley API и является производным от BSD сетевой код.)
  • FreeBSD имеет базовую поддержку системных вызовов, связанных с STREAMS, в соответствии с требованиями уровня двоичной совместимости SVR4.
  • В Windows NT ядро предлагало полный порт STREAMS в виде двоичного файла streams.sys. В NT DDK даже была глава о STREAMS, вплоть до NT4, хотя в NT4 DDK она была объявлена ​​устаревшей. Исходный стек TCP / IP для Windows NT 3.1 был реализован поверх STREAMS компанией Системы пауков, и использовал двоичный файл streams.sys. Начиная с NT 3.5, TCP / IP был полностью переделан,[21][22] приняв решение Microsoft LAN менеджер для OS / 2 1.x.[нужна цитата ]

Linux не включает функции ПОТОКОВ без сторонних надстроек. Кальдера «подтолкнул» к включению ПОТОКОВ в Linux ок. 1998 г., чтобы поддержать Netware для Linux, но он был категорически отвергнут разработчиками ядра Linux по техническим причинам (в основном из-за производительности).[23] В уровни совместимости в Linux для других операционных систем преобразуйте операции ПОТОКОВ в сокеты как можно раньше.[24] В Caldera использовалась реализация LiS, созданная компанией GCOM; позже это фигурировало в юридические баталии преемником Кальдеры, Группа ШОС против Linux, при этом SCO заявила, что Linux с STREAMS нарушает то, что, по ее мнению, является ее авторскими правами на System V.[23]

Заметки

  1. ^ (Гудхарт 1994, стр. 51–53,403–527)
  2. ^ (Гудхарт 1994, стр. 52–53).
  3. ^ а б (Гудхарт 1994, п. 17)
  4. ^ (Гудхарт 1994, п. 51)
  5. ^ а б c (Ричи 1984 )
  6. ^ (Гудхарт 1994 )
  7. ^ Эрик С. Раймонд (2003). «Глава 7. Мультипрограммирование». Искусство программирования под Unix. Эддисон-Уэсли.
  8. ^ а б (DLPI и 2.0.0 )
  9. ^ (NPI и 2.0.0 )
  10. ^ (TPI & 1.5 )
  11. ^ (TPI и 2.0.0 )
  12. ^ (APLI 1990 )
  13. ^ (XAP 1993 )
  14. ^ «Базовые спецификации, выпуск 7, издание 2013 г., раздел B.2.6 ПОТОКИ». Открытая группа. Получено 9 марта 2015.
  15. ^ "Группа по пересмотру общих стандартов Остина". Открытая группа. Получено 9 марта 2015.
  16. ^ «Базовые спецификации Open Group, выпуск 7, коды». Открытая группа. Получено 9 марта 2015.
  17. ^ Пайк, Роб (1984). "Блит: мультиплексный графический терминал". Технический журнал AT&T Bell Laboratories. 63 (8): 1607–1631.
  18. ^ а б Бах, Морис Дж. (1986). Дизайн операционной системы UNIX. Прентис Холл.
  19. ^ Увидеть: putmsg - Справочник по системным интерфейсам, Единая спецификация UNIX, Выпуск 6 из Открытая группа, и getmsg - Справочник по системным интерфейсам, Единая спецификация UNIX, Выпуск 6 из Открытая группа.
  20. ^ а б Пресотто, Дэвид Л. (1990). Многопроцессорные потоки для Plan 9. Proc. Летняя конференция UKUUG. CiteSeerX  10.1.1.42.1172.
  21. ^ (Барр 2001 )
  22. ^ (Валентина 2001 )
  23. ^ а б «STREAMS, LiS и Netware Caldera для Linux - Обновлено». Groklaw. 3 июля 2006 г.. Получено 27 декабря 2014.
  24. ^ Алан Кокс, Потоки и Linux, Список рассылки ядра Linux, 28 июня 1998 г.

использованная литература

внешние ссылки