Loading article…
コンピュータネットワークにおいて、STREAMSはUnix System Vのネイティブフレームワークであり、キャラクタデバイスドライバ、ネットワークプロトコル、およびプロセス間通信を実装するためのものです。このフレームワークでは、ストリームとは、プログラムとデバイスドライバ間（または2つのプログラム間）でメッセージをやり取りするコルーチンの連鎖です。STREAMSは、バージョン8 Research UnixでStreams（小文字）として誕生しました。
STREAMS の設計は、カーネルとデバイスドライバ間の全二重I/O を実装するためのモジュール型アーキテクチャです。最も頻繁に使用されているのは、端末 I/O (ライン ディシプリン) およびネットワーク サブシステムの開発です。System V Release 4 では、端末インターフェイス全体が STREAMS を使用して再実装されました。[ 1 ] STREAMS の重要な概念は、ドライバ(ネットワーク インターフェイスやその他のデバイスの機能を変更できるカスタム コード モジュール) をまとめてスタックを形成する機能です。これらのドライバのいくつかを順番に連結できます。
STREAMS は、 Dennis Ritchieが第8 版 Research Unix (V8)で導入した Streams I/O サブシステムに基づいており、端末I/Oサブシステムとインターネット プロトコル スイートに使用されていました。このバージョンはまだ大文字の STREAMS とは呼ばれていませんでしたが、既存のデバイス I/O システム コール ( open、close、read、write、およびioctl )の下で新しい機能に適合し[ 2 ] 、その適用は端末 I/O とパイプのような I/O セマンティクスを提供するプロトコルに限定されていました。
この I/O システムは、TCP、ISO クラス 4 トランスポート、SNA LU 6.2、および AT&T NPACK プロトコル ( RFSで使用) など、さまざまなトランスポート プロトコルをサポートすることを目的としたより広いフレームワークの一部として、Robert Israel、Gil McGrath、Dave Olander、Her-Daw Che、および Maury Bach によって System V Release 3 に移植されました。 [ 3 ] これは、UNIX System V Release 3 の Network Support Utilities (NSU) パッケージで最初にリリースされました。[ 4 ] この移植により、Berkeley ソケットのsend、recv、およびselectコールと目的がほぼ同じputmsg、getmsg、およびpollシステム コールが追加されました。putmsgおよびgetmsgシステムコールは、元々はsendおよびrecvと呼ばれていましたが、[ 5 ]名前空間の競合を避けるために名前が変更されました。[ 6 ] System V Release 4 では、STREAMS が拡張され、端末 I/O フレームワークとパイプに使用され、双方向パイプやファイルディスクリプタの受け渡しなどの便利な新機能が提供されました。[ 3 ] UNICOS 用の移植版も作成されました。Eric S. Raymond は、Ritchie が System V STREAMS の複雑さについて、自身の V8 Streams と比較して「Streams は叫ぶと意味が違う」と述べたと引用しています。[ 7 ]
System V Release 3 の移植と同時に、AT&T はOSI モデル(レイヤ 2 ～ 4)のリンク層[ 8 ] 、ネットワーク層[ 9 ]、トランスポート層[ 10 ]向けのプロトコル非依存の STREAMS メッセージ パッシング ガイドラインを開発しました。特定のプロトコル スタックではネットワーク プロトコルとトランスポート プロトコルの実装が密接に結合していること、およびレイヤ 5 ～ 7 をカーネルの外で実装するのが一般的であることから、リンク層[ 8 ]とトランスポート層[ 11 ]の STREAMS サービス インターフェイスのみが後にX/Openによって標準化されました。トランスポート メッセージ パッシング モデルと連携して、トランスポート レイヤ インターフェイス(後にX/Open Transport Interfaceとして採用) が定義され、アプリケーション開発用のトランスポート プロトコル非依存の API が提供されました。また、セッション層、プレゼンテーション層、アプリケーション層[ 12 ]をサポートするライブラリが定義され、後にThe Open Groupによって標準化されました。[ 13 ]
STREAMS は、 Single UNIX Specificationバージョン 1 (UNIX 95) および 2 (UNIX 98)への準拠に必須でしたが、 BSDおよびLinux開発者が STREAMS の提供を拒否した結果、バージョン 3 (UNIX 03) ではAustin Groupによって POSIX 準拠のためのオプションとしてマークされました。POSIX.1-2008 with TC1 (IEEE Std 1003.1、2013 年版) では、STREAMS は「廃止予定」として指定されています[ 14 ] [ 15 ]。これは、この機能が仕様の将来のバージョンで削除される可能性があることを意味します。ただし、使用されている「廃止予定」の具体的な定義[ 16 ]では、厳密に準拠する POSIX アプリケーションは「廃止予定の機能を使用してはならない」とも述べています。
In Version 7 Unix, a command was connected to a terminal (keyboard and screen, or keyboard and printer) through a mechanism called the line discipline, which would buffer a single line of input, i.e., wait for the user to press the Return key before sending input to the program for processing; this allowed simple error correction. Streams replaced this with a set of processing modules organized in a linear chain that allowed bidirectional communication between neighboring modules. Programs could "push" a new module onto one end of the chain to change the behavior of a terminal or other character device. Ritchie gives the example chain of a terminal module chained with a Datakit network module to achieve remote login over a network.[5] Aside from characters (bytes) going from program to device and vice versa, Streams could carry control messages such as "hangup" (drop connection) and ioctl messages.
Streams could also be used for inter-process communication, by connecting two processes to pseudoterminals. This functionality was implemented in the mpx window system for the Blit graphics terminal, which could display multiple terminal emulator windows. Each window was a process that communicated with the window system through a pseudoterminal that had the line discipline driver installed, sending typed characters to it and receiving text (and graphics) to display. Control signals designated the user's wish to switch between windows or close them.[17][18]:348–350
The actual Streams modules live in kernel space on Unix, and are installed (pushed) and removed (popped) by the ioctl system call. For example, to install the aforementioned line discipline on a file descriptorfd referring to a terminal device, one would write (in C):[18]:347
ioctl(fd,PUSH,TTYLD);To perform input/output on a stream, one either uses the read and write system calls as with regular file descriptors, or a set of STREAMS-specific functions to send control messages.[19]
リッチーは、ストリームをプロセスとしてではなくカーネルに実装しなければならなかったことを後悔していると認めたが、効率上の理由からそうせざるを得なかったと感じた。[ 5 ]後のPlan 9 の実装では、モジュールをユーザーレベルのプロセスとして実装した。[ 20 ]
STREAMSは主にSystem V Unixの世界で使用されてきましたが、他の実装も存在します。
Linux にはサードパーティのアドオンなしでは STREAMS 機能は含まれていません。Calderaは、 Netware for Linuxをサポートするために、1998 年頃に Linux に STREAMS を含めるよう「働きかけ」ましたが、Linux カーネル開発者によって技術的な理由 (主にパフォーマンス) で完全に拒否されました。[ 25 ]他のオペレーティングシステム用の Linux の互換性レイヤーは、 STREAMS操作を可能な限り早い段階でソケットに変換します。[ 26 ] Caldera が使用した実装は、GCOM という会社による「LiS」でした。これは後に、Caldera の後継であるSCO Groupが Linux に対して起こした訴訟で取り上げられ、SCO は STREAMS を備えた Linux が System V の著作権を侵害していると主張しました。[ 25 ]