3    X/Open トランスポート・インタフェース

X/Open トランスポート・インタフェース (XTI) は,一連の関数からなるトランスポート層アプリケーション・インタフェースであり,使用する特定のトランスポート・プロバイダから独立するために開発されました。 このオペレーティング・システムでは,XPG3,XNS4.0 および XNS5.0 仕様に従って XTI をインプリメントしています。 XNS4.0 が省略時の設定です。 XPG3 は下位互換性のために提供されており,コンパイラ・スイッチを使用して有効にできますが,将来的にはサポートされなくなります。 XNS5.0 も,コンパイラ・スイッチを使用して有効にできます。 XPG3,XNS4.0 および XNS5.0 についての詳細は,それぞれ『X/Open Portability Guide Volume 7: Networking Services』,『X/Open CAE Specification: Networking Services, Issue 4』および『X/Open CAE Specification: Networking Services (XNS), Issue 5』を参照してください。 このオペレーティング・システムでの XTI のインプリメンテーションもスレッド・セーフです。

概念はバークレイ・ソケット・インタフェースと似ていますが,XTI は AT&T トランスポート層インタフェース (TLI) に基づいています。 一方,TLI は,開放型システム間相互接続 (OSI) モデルのトランスポート・サービス定義に基づいています。

注意

このオペレーティング・システムには,伝送制御プロトコル (TCP) およびユーザ・データグラム・プロトコル (UDP) のトランスポート・プロバイダが含まれています。 この章で説明する情報は,DECnet/OSI などこのオペレーティング・システムの XTI がサポートするすべてトランスポート・プロバイダに当てはまりますが,例は TCP および UDP に固有のものです。 XTI を TCP または UDP で使用する場合についての詳細は, xti_internet(7) を参照してください。 他のトランスポート・プロバイダ固有の例および情報については,それらのソフトウェアに添付されているドキュメントを参照してください。

この章では,次の事項について説明します。

図 3-1は,XTI,および XTI とオペレーティング・システムのインターネット・プロトコル群のインプリメンテーションの関係を強調表示しています。 また,XTI とインターネット・プロトコル群が,ネットワーク・プログラミング環境の他の部分に対し,どのように位置付けられているかも示しています。

図 3-1:  X/Open トランスポート・インタフェース

3.1    XTI の概要

XTI には,次の各エンティティ間のやりとりが含まれています。

トランスポート・ユーザは,トランスポート終端をトランスポート・アドレスにバインドすることによって,トランスポート終端をアクティブにします。 一度,トランスポート終端がアクティブになると,トランスポート・ユーザは,この終端を通してデータを送信できます。 トランスポート・プロバイダは,該当する対等ユーザ,または他のデスティネーションにデータの経路を指定します。

TCP などのコネクション指向型トランスポート・サービスを使用する場合には,トランスポート・ユーザはデータを送信する前に,アクティブな終端を指定して,t_connect 関数を呼び出すことにより,自分自身と対等トランスポート・ユーザの間に接続を確立しなければなりません。 トランスポート接続において,接続を開始するトランスポート・ユーザは, アクティブ・ユーザ,つまりクライアントです。 一方,接続要求に応答する対等トランスポート・ユーザは,パッシブ・ユーザ,つまりサーバです。 図 3-2 は,トランスポート・プロバイダ,トランスポート・ユーザ,およびトランスポート終端の関係を示しています。

図 3-2:  トランスポート終端

3.2    XTI の機能

XTI には,ライブラリ・コール,ヘッダ・ファイル,および,XTI プロセスの動作と対話処理の方法を記述する規則と制限があります。 この節では,ライブラリ・コールおよびヘッダ・ファイルについて説明するとともに,通信プロセス間のやりとりを制御する規則についても記述します。

3.2.1    サービス・モードと実行モード

トランスポート・ユーザは,さまざまなサービス・モードと実行モードを使用して,トランスポート・プロバイダとの間でデータを交換する方法を決定します。 次の 2 つの項で,XTI で利用できるサービス・モードと実行モードについて説明します。

3.2.1.1    コネクション指向型サービスおよびコネクションレス型サービス

XTI において,終端は,次のサービス・モードのうちの 1 つをサポートできます。

3.2.1.2    非同期実行および同期実行

実行モードにより,トランスポート・ユーザは,関数の完了およびイベントの受信を処理できます。 イベントとは,トランスポート・ユーザにとって意味のある出現事象または偶発事象です。 XTI は,次の 2 つの実行モードをサポートします。

省略時の値では,着信イベントを処理するすべての関数は同期モードで動作し,そのタスクが完了するまでブロックします。 非同期モードを選択する場合には,トランスポート・ユーザは,終端の作成時,または fcntl オペレーティング・システム・コールを使用して関数または関数のグループを実行する前に,t_open 関数で O_NONBLOCK フラグを指定します。

XTI がサポートする特定のイベントについての詳細は,3.2.3 項を参照してください。

3.2.2    XTI ライブラリ,TLI ライブラリ,およびヘッダ・ファイル

XTI 関数は,XTI ライブラリ libxti.a の一部としてインプリメントされています。 TLI 関数は,別の TLI ライブラリ libtli.a にインプリメントされています。 これらのライブラリのシェアード・バージョン libxti.so および libtli.so も提供されます。

XTI または TLI アプリケーションを XTI または TLI ライブラリにリンクするとき,省略時の設定によりシェアード・ライブラリ・サポートが提供されます。

次に 2 つの例を示します。 最初の例は,XTI アプリケーションのオブジェクト・ファイルを XTI シェアード・ライブラリに再リンクする方法を示しています。 2 番目の例は,TLI アプリケーションのオブジェクト・ファイルを TLI シェアード・ライブラリに再リンクする方法を示しています。

% cc -o XTIapp XTIappmain.o XTIapputil.o -lxti
 
% cc -o TLIapp TLIappmain.o TLIapputil.o -ltli
 

プログラムを XTI または TLI ライブラリに静的にリンクするには,cc コマンドで non_shared オプションを使用します。 次の例は,XTI アプリケーションのオブジェクト・ファイルを XTI ライブラリに静的にリンクする方法を示しています。

% cc -non_shared -o XTIapp XTIappmain.o XTIapputil.o -lxti
 

詳細は cc(1) を参照してください。

プログラムをスレッド・セーフにするためには,POSIX スレッド pthreads ルーチンでプログラムを構築します。 詳細については,『Guide to the POSIX Threads Library』を参照してください。

XTI と TLI にはほとんど違いがありません。 両者の相違点については3.5.2 項で説明します。 また3.5.2 項では,コンパイル時にプログラムを正しいライブラリとリンクする方法についても説明しています。

3.2.2.1    XTI および TLI ヘッダ・ファイル

XTI および TLI ヘッダ・ファイルには,XTI および TLI ライブラリ・コールが使用する,データ定義,構造体,定数,マクロ,およびオプションが入っています。 アプリケーション・プログラムでは,特定の XTI または TLI ライブラリ・コールが必要とする構造体や他の情報を使用するために,適切なヘッダ・ファイルをインクルードしなければなりません。 表 3-1 は,XTI および TLI ヘッダ・ファイルの一覧です。

表 3-1:  XTI および TLI のヘッダ・ファイル

ファイル名 説明
<tiuser.h> TLI アプリケーション用のデータ定義および構造体が入っている。 TLI アプリケーションにはすべて,このファイルをインクルードしなければならない。
<xti.h> XTI アプリケーション用のデータ定義および構造体が入っている。 XTI アプリケーションにはすべて,このファイルをインクルードしなければならない。
<xti_inet.h> XTI アプリケーション用のインターネット・データ定義および構造体が入っている。 XTI アプリケーションにはすべて,このファイルをインクルードしなければならない。
<xti_osi.h> XTI アプリケーション用の ISO OSI データ定義および構造体が入っている。 XTI アプリケーションにはすべて,このファイルをインクルードしなければならない。
<fcntl.h> t_open 関数の実行モード用フラグを定義する。 すべての XTI アプリケーションおよび TLI アプリケーションには,このファイルをインクルードしなければならない。

注意

一般的に,ヘッダ・ファイル名は山カッコ (< >) で囲まれます。 ヘッダ・ファイルの絶対パスは,山カッコ内の情報の前に /usr/include/ を付けたものです。 たとえば,tiuser.h ヘッダ・ファイルの絶対パスは /usr/include/tiuser.h です。

3.2.2.2    XTI ライブラリ・コール

XTI ライブラリ・コールの中には,コネクション指向型トランスポート (COTS) に適用されるもの,コネクションレス型トランスポート (CLTS) に適用されるもの, 正常解放機能とともに使用される場合にコネクション指向型トランスポートに適用されるもの (COTS_ORD),およびすべてのサービス・モードに適用されるものがあります。 一部の XTI ライブラリ・コールはユーティリティ関数であり,特定のサービス・モードには適用されません。 表 3-2 に,各 XTI ライブラリ・コールの名前,説明,およびサービス・モードの一覧を示します。 各ライブラリ・コールについて,同じ名前のリファレンス・ページがあります。

オペレーティング・システムでは,XTI のリファレンス・ページだけを提供し,TLI のリファレンス・ページは提供していません。 TLI および TLI のリファレンス・ページについての詳細は,『UNIX System V Programmer's Guide: Networking Interfaces』を参照してください。 これは,UNIX システムラボラトリーズ社から発行されています。 オペレーティング・システムでは,それぞれの関数のリファレンス・ページを提供してします。 詳細は,『X/Open CAE Specification: Networking Services』を参照してください。

表 3-2:  XTI ライブラリ・コール

呼び出し名 説明 サービス・モード
t_accept 接続要求を受け入れる。 COTS, COTS_ORD
t_alloc ライブラリ構造体のメモリを割り当てる。 すべて
t_bind アドレスをトランスポート終端にバインドする。 すべて
t_close トランスポート終端をクローズする。 すべて
t_connect 別のトランスポート・ユーザとの接続を確立する。 COTS, COTS_ORD
t_error エラー・メッセージを出す。 すべて
t_free 以前にライブラリ構造体に割り当てられたメモリを解放する。 すべて
t_getinfo プロトコル固有の情報を返す。 すべて
t_getprotaddr [脚注 1] プロトコル・アドレスを返す。 すべて
t_getstate トランスポート終端に現在の状態を返す。 すべて
t_listen 接続要求をリッスンする。 COTS, COTS_ORD
t_look トランスポート終端上の現在のイベントを返す。 すべて
t_open トランスポート終端を設定する。 すべて
t_optmgmt プロトコル・オプションの検出,確認,折衝のいずれかを行う。 すべて
t_rcv 接続を通して,データまたは優先データを受信する。 COTS, COTS_ORD
t_rcvconnect 接続要求から確認を受信する。 COTS, COTS_ORD
t_rcvdis 切断の原因を識別し,切断にともなって送信された情報を検出する。 COTS, COTS_ORD
t_rcvrel [脚注 2] 正常解放指示の受信に肯定応答する。 COTS_ORD
t_rcvreldata [脚注 3] ユーザ・データがある正常解放指示または正常解放確認を受信する。 COTS_ORD
t_rcvv [脚注 3] 接続を通してデータまたは優先データを受信し,バッファに格納する。 COTS, COTS_ORD
t_rcvvudata [脚注 3] データ・ユニットをバッファに受信する。 CLTS
t_rcvudata データ・ユニットを受信する。 CLTS
t_rcvuderr データ・ユニットに関連するエラーについての情報を受信する。 CLTS
t_snd 接続を通して,データまたは優先データを送信する。 COTS, COTS_ORD
t_snddis 確立された接続で解放を開始するか,または接続要求をリジェクトする。 COTS, COTS_ORD
t_sndrel [脚注 2] 正常解放を開始する。 COTS_ORD
t_sndreldata [脚注 3] ユーザ・データがある正常解放の開始または応答を行う。 COTS_ORD
t_sndudata データ・ユニットを送信する。 CLTS
t_sndv [脚注 3] 接続を通してデータまたは優先データを送信する。 COTS, COTS_ORD
t_sndvudata [脚注 3] データ・ユニットを送信する。 CLTS
t_strerror [脚注 1] エラー・メッセージ文字列を作成する。 すべて
t_sync トランスポート・ライブラリのデータ構造体の同期をとる。 すべて
t_sysconf [脚注 3] 構成可能な XTI 変数を取り出す。 すべて
t_unbind トランスポート終端を使用不能にする。 すべて

XTI は,正常解放機能 (t_sndrel および t_rcvrel 関数) をサポートしています (詳細は表 3-2 を参照)。 ただし,アプリケーションが,ISO トランスポート層に対して移植可能にしなければならない場合には,この機能は使用しないようにしてください。

最後に,XTI ヘッダ・ファイルは,サービス・モードを識別する次の定数を定義します。

これらのサービス・モードは,ユーザが t_open 関数を使用して終端を作成したときに,トランスポート・プロバイダによって,info 構造体の servtype フィールドに返されます。

3.2.3    イベントおよび状態

各トランスポート・プロバイダには,トランスポート・ユーザから見た場合,関連付けられた特定の状態があります。 トランスポート・プロバイダの状態,および次に起こり得る状態への遷移は,発信および着信のイベントによって制御され,指定されたユーザ・レベルのトランスポート関数の正常復帰に対応します。 発信イベントは,トランスポート・プロバイダに要求または応答を送信する関数に対応します。 一方,着信イベントは,トランスポート・プロバイダからデータまたはイベント情報を検出する関数に対応しています。

この項では,トランスポート・プロバイダが取り得る状態,生じる可能性のある発信および着信のイベント,および関数の呼び出し可能な順序について説明します。

3.2.3.1    XTI イベント

XTI アプリケーションは,非同期イベントを管理しなければなりません。 非同期イベントは,XTI ヘッダ・ファイルに定数として定義されているニーモニックによって識別されます。 表 3-3 は,XTI における非同期イベントのイベント名,説明,およびサービス・モードの一覧です。

表 3-3:  非同期 XTI イベント

イベント名 説明 サービス・モード
T_CONNECT トランスポート・プロバイダが接続応答を受信した。 このイベントは,通常,トランスポート・ユーザが t_connect 関数を発行した後に発生する。 COTS, COTS_ORD
T_DATA トランスポート・プロバイダが通常データを受信した。 通常データとは,トランスポート・サービス・データ・ユニット (TSDU) のすべてまたは一部である。 COTS, CLTS, COTS_ORD
T_DISCONNECT トランスポート・プロバイダが切断要求を受信した。 このイベントは,通常,トランスポート・ユーザが,データ転送関数,t_accept 関数,t_snddis 関数のいずれかを発行した後に発生する。 COTS, COTS_ORD
T_EXDATA トランスポート・プロバイダが優先データを受信した。 COTS, COTS_ORD
T_GODATA 通常データのフローに関するフロー制御制約が解除された。 トランスポート・ユーザは,通常データを再度送信できる。 COTS, CLTS, COTS_ORD
T_GOEXDATA 優先データのフローに関するフロー制御制約が解除された。 トランスポート・ユーザは,優先データを再度送信できる。 COTS, COTS_ORD
T_LISTEN トランスポート・プロバイダがリモート・ユーザから接続要求を受信した。 このイベントは,ファイル記述子が有効なアドレスにバインドされており,トランスポート接続が確立されていない場合にだけ発生する。 COTS, COTS_ORD
T_ORDREL トランスポート・プロバイダが正常解放の要求を受信した。 COTS_ORD
T_UDERR 以前に送信されたデータグラムでエラーが検出された。 このイベントは,通常,トランスポート・ユーザが t_rcvudata 関数または t_unbind 関数を発行した後に発生する。 CLTS

XTI は,トランスポート終端で発生するすべてのイベントを格納します。

同期実行モードを使用している場合,トランスポート・ユーザは,実行していた関数から --1 の値を指定して戻ると,t_errno の TLOOK 値をチェックし,t_look 関数を使用してイベントを検出します。 非同期実行モードでは,トランスポート・ユーザは作業を継続し,定期的に新しいイベントをチェックします。

トランスポート終端で発生する各イベントは,特定の XTI 関数によって消費されるか,または未処理のまま残ります。 例外は T_GODATA イベントおよび T_GOEXDATA イベントであり,これは,t_look を使用して検出されるとクリアされます。 このように,一度トランスポート・ユーザが,関数から TLOOK エラーを受け取ると,そのトランスポート・ユーザがそのイベントを消費するまで,同じ関数または別の関数への後続の呼び出しで TLOOK エラーが返されます。 表 3-4 に,各非同期イベントの消費関数の一覧を示します。

表 3-4:  非同期イベントおよび消費関数

イベント t_look によるクリア 消費関数
T_CONNECT No t_connect, t_rcvconnect
T_DATA No t_rcv, t_rcvudata
T_DISCONNECT No t_rcvdis
T_EXDATA No t_rcv
T_GODATA Yes t_snd, t_sndudata
T_GOEXDATA Yes t_snd
T_LISTEN No t_listen
T_ORDREL No t_rcvrel
T_ORDRELDATA [脚注 4] No t_rcvreldata
T_UDERR No t_rcvuderr

表 3-5 は,特定の XTI 関数に TLOOK エラーを返させるイベントの一覧です。 これは,XTI アプリケーションにイベント・チェック機能を構築する場合に役立ちます。

表 3-5:  TLOOK を返す XTI 関数

関数 TLOOK の原因となるイベント
t_accept T_DISCONNECT, T_LISTEN
t_connect T_DISCONNECT, T_LISTEN [脚注 5]
t_listen T_DISCONNECT [脚注 6]
t_rcv T_DISCONNECT, T_ORDREL [脚注 7]
t_rcvconnect T_DISCONNECT
t_rcvrel T_DISCONNECT
t_rcvreldata T_DISCONNECT
t_rcvudata T_UDERR
t_rcvv T_DISCONNECT, T_ORDREL
t_rcvvudata T_UDERR
t_snd T_DISCONNECT, T_ORDREL
t_sndv T_DISCONNECT, T_ORDREL
t_snddis T_DISCONNECT
t_sndrel T_DISCONNECT
t_sndreldata T_DISCONNECT
t_sndudata T_UDERR
t_sndvudata T_UDERR
t_unbind T_LISTEN, T_DATA [脚注 8]

各 XTI 関数は,一度に 1 つのトランスポート終端を管理します。 一度に複数のソース,特に複数のトランスポート接続から,複数のイベントを待つことはできません。 XTI のこのインプリメンテーションでは,トランスポート・ユーザは poll 関数を使用して, 複数のファイル記述子における着信と発信を監視することができます。 詳細は, poll(2) を参照してください。

3.2.3.2    XTI の状態

XTI は,任意の時点でプログラムが実行する呼び出しの正当性を制御します。 XTI は,8 つの状態を使用して,トランスポート終端を通した通信を管理します。 アクティブ・ユーザおよびパッシブ・ユーザはどちらも,処理中の関数を反映する固有の状態を持っています。

表 3-6 で,各 XTI の状態の意味について説明します。 サービス・モードの COTS は,正常サービスがインプリメントされているかどうかに関係なく,その状態が生じることを示します。 サービス・モードの COTS_ORD は,正常サービスがインプリメントされている場合にだけ,その状態が生じることを示します。

表 3-6:  XTI の状態

状態 説明 サービス・モード
T_UNINIT 初期化されていない。 インタフェースの最初と最後の状態。 トランスポート終端を設定するには,ユーザは t_open を発行しなければならない。 COTS, CLTS, COTS_ORD
T_UNBIND バインドされていない。 ユーザはアドレスをトランスポート終端にバインドしたり,トランスポート終端をクローズしたりできる。 COTS, CLTS, COTS_ORD
T_IDLE アイドル。 アクティブ・ユーザは,パッシブ・ユーザとの間に接続を確立したり (COTS),トランスポート終端を使用不能にしたり (COTS,CLTS),データ・ユニットを送受信したり (CLTS) できる。 パッシブ・ユーザは,接続要求をリッスンできる (COTS)。 COTS, CLTS, COTS_ORD
T_OUTCON 発信接続の保留。 アクティブ・ユーザは,接続要求の確認を受信できる。 COTS, COTS_ORD
T_INCON 着信接続の保留。 パッシブ・ユーザは,接続要求を受け入れることができる。 COTS, COTS_ORD
T_DATAXFER データ転送。 アクティブ・ユーザは,パッシブ・ユーザとデータの送受信ができる。 パッシブ・ユーザは,アクティブ・ユーザとデータの送受信ができる。 COTS, COTS_ORD
T_OUTREL 正常解放の発信。 ユーザは,正常解放指示に応答できる。 COTS_ORD
T_INREL 正常解放の着信。 ユーザは,正常解放指示を送信できる。 COTS_ORD

コネクション指向型アプリケーションを作成する場合,接続確立状態またはデータ転送状態の間は,いつでもプログラムで接続を解放できます。

3.2.4    XTI イベントのトラッキング

XTI ライブラリでは,発信イベントと着信イベントを追跡できるので,トランスポート終端の正当な状態を管理できます。 これ以降の項では,この発信イベントおよび着信イベントについて説明します。

3.2.4.1    発信イベント

発信イベントは,要求または応答をトランスポート・プロバイダに送信する XTI 関数によって引き起こされます。 発信イベントは,その関数が正常に戻ると発生します。 このような関数の中には,次の値に応じて,異なるイベントを生じるものがあります。

ocnt 未処理の接続指示の数 (トランスポート・ユーザに引き渡されたが,受け入れもリジェクトもされていないもの)。 この数は,現在のトランスポート終端 (fd) のみで意味を持つ。
fd 現在のトランスポート終端のファイル記述子。
resfd 接続が受け入れられる終端のファイル記述子。

表 3-7は, XTI で使用できる発信イベントの一覧です。 サービス・モードの COTS は,正常サービスがインプリメントされているかどうかに関係なく,そのイベントがコネクション指向型サービスに対して発生することを示します。 サービス・モードの COTS_ORD は,正常サービスがインプリメントされている場合にだけ,そのイベントが発生することを示します。

表 3-7:  発信 XTI イベント

イベント 説明 サービス・モード
opened t_open 関数の正常な戻り。 COTS, CLTS, COTS_ORD
bind t_bind 関数の正常な戻り。 COTS, CLTS, COTS_ORD
optmgmt t_optmgmt 関数の正常な戻り。 COTS, CLTS, COTS_ORD
unbind t_unbind 関数の正常な戻り。 COTS, CLTS, COTS_ORD
closed t_close 関数の正常な戻り。 COTS, CLTS, COTS_ORD
connect1 同期実行モードでの t_connect 関数の正常な戻り。 COTS, COTS_ORD
connect2 t_connect 関数が非同期モードにおいて TNODATA エラーを返したか,またはトランスポート終端に切断指示が到着したために TLOOK エラーを返した。 COTS, COTS_ORD
accept1 t_accept 関数の正常な戻り。 (ocnt == 1 かつ fd == resfd の場合) COTS, COTS_ORD
accept2 t_accept 関数の正常な戻り。 (ocnt == 1 かつ fd != resfd の場合) COTS, COTS_ORD
accept3 t_accept 関数の正常な戻り。 (ocnt > 1 の場合) COTS
snd t_snd 関数の正常な戻り。 COTS
snddis1 t_snddis 関数の正常な戻り。 (ocnt <= 1 の場合) COTS, COTS_ORD
snddis2 t_snddis 関数の正常な戻り。 (ocnt > 1 の場合) COTS, COTS_ORD
sndrel t_sndrel 関数の正常な戻り。 COTS_ORD
sndudata t_sndudata 関数の正常な戻り。 CLTS

3.2.4.2    着信イベント

着信イベントは,トランスポート・プロバイダからデータまたはイベントを検出する XTI 関数によって引き起こされます。 着信イベントは,その関数が正常に戻ると発生します。 このような関数の中には,ocnt 変数の値に応じて,異なるイベントを生じるものがあります。 この変数は,未処理の接続指示 (トランスポート・ユーザに引き渡されたが,受け入れもリジェクトもされていないもの) の数です。 この数は,現在のトランスポート終端 (fd) のみで意味を持ちます。

pass_conn 着信イベントは,指定した終端で関数が正常に戻ったこととは,直接は関係しません。 pass_conn イベントは,現在の終端から接続が引き渡されている終端においてのみ発生します。 pass_conn イベントが発生する終端では関数は発生しません。

表 3-8 は,XTI で使用できる着信イベントの一覧です。 サービス・モードの COTS は,正常サービスがインプリメントされているかどうかに関係なく,そのイベントが発生することを示します。 サービス・モードの COTS_ORD は,正常サービスがインプリメントされている場合にだけ,そのイベントが発生することを示します。

表 3-8:  着信 XTI イベント

イベント 説明 サービス・モード
listen t_listen 関数の正常な戻り。 COTS, COTS_ORD
rcvconnect t_rcvconnect 関数の正常な戻り。 COTS, COTS_ORD
rcv t_rcv 関数の正常な戻り。 COTS, COTS_ORD
rcvdis1 t_rcvdis 関数の正常な戻り。 (ocnt == 0 の場合) COTS, COTS_ORD
rcvdis2 t_rcvdis 関数の正常な戻り。 (ocnt == 1 の場合) COTS, COTS_ORD
rcvdis3 t_rcvdis 関数の正常な戻り。 (ocnt > 1 の場合) COTS, COTS_ORD
rcvrel t_rcvrel 関数の正常な戻り。 COTS_ORD
rcvudata t_rcvudata 関数の正常な戻り。 CLTS
rcvuderr t_rcvuderr 関数の正常な戻り。 CLTS
pass_conn 別のトランスポート終端から引き渡された接続を正常に受け取った。 COTS, COTS_ORD

3.2.5    XTI 関数,イベント,および状態のマップ

この項では,XTI 関数,発信イベントと着信イベント,および状態の関係について説明します。 XTI では,状態遷移に関する規則が厳密に定義されているので,現在の状態および最新の受信イベントによって次に起こり得る状態を知ることができます。 この項では,現在のイベントおよび状態を,次に起こり得る状態にマップする詳細な表を示します。

この項の状態遷移の説明では,t_getstate 関数,t_getinfo 関数,t_alloc 関数,t_free 関数,t_look 関数,t_sync 関数,およびt_error 関数については触れません。 これらのユーティリティ関数は,トランスポート・インタフェースの状態には影響しないため,未初期化 (T_UNINIT) 状態以外のすべての状態から発行できます。

表 3-9表 3-10,および表 3-11 を使用して,現在の着信イベントまたは発信イベントに一致する行と,現在の状態に一致する列を探してください。 その行と列が交わる欄に示されている状態が,次に起こり得る状態です。 交わる欄にダッシュ (--) が記述されている場合は,イベントと状態の組み合わせが無効であることを示しています。 状態遷移の中には,右肩に英字が付いているものもあります。 この英字は,トランスポート・ユーザが行わなければならないアクションを示しています。 英字とその意味は,該当する表の脚注に記載されています。

表 3-9 は,初期化関数および初期化解除関数,つまりコネクション指向型とコネクションレス型の両方のサービス・モードに共通した関数の状態遷移を示しています。 たとえば,現在のイベントと状態がそれぞれ bind と T_UNBND の場合,次に起こり得る状態は T_IDLE です。 また,英字 a が示されているので,トランスポート・ユーザは,未処理の接続指示の数にゼロを設定しなければなりません。

表 3-9:  コネクション指向型またはコネクションレス型トランスポート・サービスの初期化における状態遷移

イベント T_UNINIT 状態 T_UNBND 状態 T_IDLE 状態
opened T_UNBND -- --
bind -- T_IDLE [脚注 9] --
unbind -- -- T_UNBND
closed -- T_UNINIT T_UNINIT

表 3-10 は,コネクションレス型トランスポート・サービスにおけるデータ転送関数の状態遷移を示しています。

表 3-10:  コネクションレス型トランスポート・サービスにおける状態遷移

イベント T_IDLE 状態
sndudata T_IDLE
rcvudata T_IDLE
rcvuderr T_IDLE

表 3-11表 3-12 は,着信イベントおよび発信イベントについて,コネクション指向型トランスポート・サービスにおける接続,解放,およびデータ転送の関数の遷移を示しています。 たとえば,現在のイベントと状態がそれぞれ accept2 と T_INCON の場合,次に起こり得る状態は T_IDLE です。 このとき,トランスポート・ユーザは,未処理の接続指示の数を減少させて,接続を別のトランスポート終端に引き渡します。

表 3-11:  コネクション指向型トランスポート・サービスにおける状態遷移:パート 1

イベント T_IDLE 状態 T_OUTCON 状態 T_INCON 状態 T_DATAXFER 状態
connect1 T_DATAXFER -- -- --
connect2 T_OUTCON -- -- --
rcvconnect -- T_DATAXFER -- --
listen T_INCON [脚注 10] -- T_INCON [脚注 10] --
accept1 -- -- T_DATAXFER [脚注 10] [脚注 11] --
accept2 -- -- T_IDLE [脚注 11] [脚注 12] --
accept3 -- -- T_INCON --
snd -- -- -- T_DATAXFER
rcv -- -- -- T_DATAXFER
snddis1 -- T_IDLE T_IDLE [脚注 11] T_IDLE
snddis2 -- -- T_INCON [脚注 11] --
rcvdis1 -- T_IDLE -- T_IDLE
rcvdis2 -- -- T_IDLE [脚注 11] --
rcvdis3 -- -- T_INCON [脚注 11] --
sndrel -- -- -- T_OUTREL
rcvrel -- -- -- T_INREL
pass_conn T_DATAXFER -- -- --
optmgmt T_IDLE T_OUTCON T_INCON T_DATAXFER
closed T_UNINIT T_UNINIT T_UNINIT T_UNINIT

表 3-12:  コネクション指向型トランスポート・サービスにおける状態遷移:パート 2

イベント T_OUTREL 状態 T_INREL 状態 T_UNBND 状態
connect1 -- -- --
connect2 -- -- --
rcvconnect -- -- --
listen -- -- --
accept1 -- -- --
accept2 -- -- --
accept3 -- -- --
snd -- T_INREL --
rcv T_OUTREL -- --
snddis1 T_IDLE T_IDLE --
snddis2 -- -- --
rcvdis1 T_IDLE T_IDLE --
rcvdis2 -- -- --
rcvdis3 -- -- --
sndrel -- T_IDLE --
rcvrel T_IDLE -- --
pass_conn -- -- T_DATAXFER
optmgmt T_OUTREL T_INREL T_UNBND
closed T_UNINIT T_UNINIT --

3.2.6    複数のプロセスおよび終端の同期

一般に,複数のプロセスを使用する場合には,注意深くプロセスの同期をとって,インタフェースの状態違反を避ける必要があります。

トランスポート・プロバイダは,1 つのトランスポート終端のすべてのトランスポート・ユーザを単一ユーザとして処理しますが,次の状況が可能になります。

単一プロセスが同期実行モードにおいて複数の終端を管理する場合,そのプロセスは,各終端におけるアクションを並列にではなく直列に管理しなければなりません。 またオプションで,サーバを作成して,複数の終端を一度に管理することができます。 たとえば,プロセスは,1 つの終端で着信接続指示をリッスンし,別の終端で接続を受け入れることができるので,着信接続はブロックされません。 このため,アプリケーションは,子プロセスをフォークして,新しい接続からの要求に対してサービスを行うことができます。

複数のプロセスが単一の終端を共用する場合には,アクションを調整して,インタフェースの状態違反を避けなければなりません。 これを行うため,各プロセスは,他の関数を呼び出す前に,t_sync 関数を呼び出すことによって,トランスポート・プロバイダの現在の状態を検出します。 すべてのプロセスをこのように調整しておかなければ,別のプロセスまたは着信イベントが,インタフェースの状態を変更する可能性があります。

同様に,複数の終端で同じプロトコル・アドレスを共用できますが,着信接続をリッスンできるのは 1 つの終端だけです。 プロトコル・アドレスを共用している他の終端は,競合することなくデータ転送状態や接続確立状態になることができます。 つまり,1 つのアドレスはサーバを 1 つしか持てませんが,複数の終端は同じアドレスを同時に呼び出すことができます。

3.3    XTI の使用

この節では,まず,関数の呼び出し順序,状態管理,および XTI のオプションの使用についてのガイドラインを示します。 次に,XTI に合わせたコネクション指向型プログラムおよびコネクションレス型プログラムの作成に必要な手順について説明します。

3.3.1    関数の呼び出し順序のガイドライン

図 3-3 は,非ブロッキング・モードのコネクション指向型トランスポート・サービスを使用して通信しているアクティブ・ユーザおよびパッシブ・ユーザについて,一般的な関数の呼び出し順序および状態遷移を示しています。 図中の実線は,アクティブ・ユーザの状態遷移を示し,破線は,パッシブ・ユーザの状態遷移を示しています。 各線は,関数の呼び出しを表し,各楕円は,結果の状態を表します。 この例には,オプションの正常解放機能は含まれていません。

図 3-3:  コネクション指向型トランスポート・サービスの状態遷移

図 3-4 は,コネクションレス型トランスポート・サービスを使用して通信している2 人のユーザについて,一般的な関数の呼び出し順序および状態遷移を示しています。 図中の各線は,関数の呼び出しを表し,各楕円は,結果の状態を表します。 両方のユーザは,実線で表されています。

図 3-4:  コネクションレス型トランスポート・サービスの状態遷移

3.3.2    トランスポート・プロバイダによる状態の管理

すべてのトランスポート・プロバイダは,状態に関して次のアクションを行わなければなりません。

未初期化状態 (T_UNINIT) には,次の 2 つの意味があります。

3.3.3    コネクション指向型アプリケーションの作成

この項では,コネクション・モードのアプリケーションの作成に必要な手順について説明します。

  1. 終端の初期化

  2. 接続の確立

  3. データの転送

  4. 接続の解放

  5. 終端の初期化解除

3.3.3.1    終端の初期化

終端を初期化するには,次の手順に従ってください。

  1. 終端をオープンする。

  2. アドレスを終端にバインドする。

  3. プロトコル・オプションを折衝する。

ここでは,コネクション指向型サービス用に終端を初期化する手順について説明します。 この手順は,コネクションレス型サービスの場合も同じです。

トランスポート終端のオープン

コネクション指向型とコネクションレス型のどちらのアプリケーションも,t_open 関数を使用して,トランスポート終端をオープンしなければなりません。

関数の構文,パラメータ,エラーについては, t_open(3) を参照してください。 XTI のエラーの概要の説明については,3.7 節 を参照してください。

この XTI のインプリメンテーションは,デバイス・スぺシャル・ファイルへのパス名を使用して,トランスポート・プロバイダを識別します。 これは AT&T の TLI と同じ方法です。 TCP または UDP のトランスポート・プロバイダとデータのやりとりをするデバイス・スぺシャル・ファイルは,/dev/streams/xtiso ディレクトリにあります。 異なるトランスポート・プロバイダを使用する場合には,そのマニュアルを参照して,適切なデバイス名を指定してください。

注意

XTI/TLI 以外の方式での特殊デバイスの使用 (たとえば,openreadwrite などの直接呼び出しなど) は違法であり,定義されていない結果が生じます。

XTI の仕様では,O_RDONLY または O_WRONLY を使用して,終端を読み取り専用または書き込み専用にすることを禁止しています。

プロトコルに依存しないプログラムを作成する場合は,t_open 関数が返す t_info 構造体の情報にアクセスすることによって,データ・バッファ・サイズを決定できます。 トランスポート・ユーザが,許容されているデータ・サイズを超えた場合には,エラーが返されます。 代わりに,t_alloc 関数を使用して,データ・バッファを割り当てることもできます。

次は,TCP トランスポート・プロバイダ (XNS4.0) 用の t_open 関数の例です。

if ( (newfd = t_open( "/dev/streams/xtiso/tcp+" , O_RDWR , NULL) ) == -1 )
    {
      (void) t_error("could not open tcp transport");
      exit (1);
    }
 

終端へのアドレスのバインド

一度,終端をオープンすると,t_bind 関数を使用してプロトコル・アドレスをその終端にバインドする必要があります。 アドレスをバインドすることによって,終端をアクティブにします。 コネクション・モードでは,トランスポート・プロバイダに,接続指示の受け入れ,またはトランスポート終端上での接続要求のサービスを開始するように指示することもできます。 t_listen 関数を発行して,トランスポート・プロバイダが接続指示を受け入れたかどうかを確認することができます。 コネクションレス・モードでは,一度,アドレスをバインドすると,トランスポート終端を通してデータ・ユニットの送受信ができます。

関数の構文,パラメータ,エラーについては, t_bind(3) を参照してください。 XTI のエラーの概要の説明については,3.7 節 を参照してください。

トランスポート・プロバイダがアドレスを生成するかどうかを判断するには,t_bind 関数でアドレスを指定しません (req に空ポインタを設定します)。 トランスポート・プロバイダがアドレスを生成する場合,この関数は,割り当てられたアドレスを ret フィールドに返します。 トランスポート・プロバイダがアドレスを生成しない場合には,TNOADDR エラーを返します。

接続指示のリッスンに使用する終端上で接続を受け入れる場合,バインドされたアドレスは,接続中はビジーになります。 最初のリッスンに使用した終端が,データをアクティブに送信しているか,または T_IDLE 状態のときは,リッスン用に他の終端を同じアドレスにバインドすることはできません。

TCP または UDP のいずれかが基礎となるトランスポート・プロバイダの場合には,4.2.3.2 項で説明する gethostbyname ルーチンを使用して,ホスト情報を取得することができます。

gethostbyname ルーチン以外の方法を使用してホスト情報を検索する場合には,次の点に考慮してください。

3.3.3.2    XTI のオプションの使用

XPG3,XNS4.0 および XNS5.0 では,オプション管理のインプリメント方法が異なります。

XPG3 では,オプション管理は t_optmgmt 関数だけが取り扱えます。 XNS4.0 および XNS5.0 では,いくつかの関数が引数 opt を持ち,この引数を使用してトランスポート・ユーザとトランスポート・プロバイダとの間でオプションをやりとりできます。

詳細は,3.6.7 項を参照してください。

3.3.3.3    接続の確立

一般には,次の手順で接続を確立します。

  1. パッシブ・ユーザ,つまりサーバが接続要求をリッスンする。

  2. アクティブ・ユーザ,つまりクライアントが接続を開始する。

  3. パッシブ・ユーザ,つまりサーバが,接続要求を受け入れて,接続指示が受信される。

これらの手順について,次の各項で説明します。

接続指示のリッスン

パッシブ・ユーザは,t_listen 関数を発行して,キューに入っている接続指示を検索します。 t_listen 関数が,キューの先頭で接続指示を見つけた場合は,接続指示に関する詳細な情報,およびその指示を識別するローカル・シーケンス番号を返します。 キューにいれることが可能な未処理の接続指示の数は,t_bind 関数の発行時にトランスポート・プロバイダが受け入れた,qlen パラメータの値によって制限されます。

省略時には,t_listen 関数は同期モードで実行され,接続指示が到着するのを待ってから制御をユーザに戻します。 t_open 関数または fcntl 関数の O_NONBLOCK フラグを設定して非同期モードを指定している場合には,t_listen 関数は,接続指示があるかどうかをチェックして,接続指示がなければ TNODATA エラーを返します。

関数の構文,パラメータ,エラーについては, t_listen(3) を参照してください。 XTIのエラーの概要の説明については,3.7 節 を参照してください。

接続の開始

接続は,同期または非同期のいずれかのモードで開始されます。 同期モードでは,アクティブ・ユーザが t_connect 関数を発行すると,この呼び出しは,パッシブ・ユーザの応答を待ってから,アクティブ・ユーザに制御を戻します。 非同期モードでは,t_connect は接続を開始しますが,接続に対する応答が到着する前に,アクティブ・ユーザに制御を戻します。 このとき,アクティブ・ユーザは,t_rcvconnect 関数を発行して,接続要求の状態を判別することができます。 パッシブ・ユーザが要求を受け入れた場合,t_rcvconnect 関数は正常に戻り,接続確立フェーズが完了します。 応答をまだ受信していない場合は,TNODATA エラーを返します。 アクティブ・ユーザは,後で t_rcvconnect 関数を再度発行する必要があります。

関数の構文,パラメータ,エラーについては, t_connect(3) を参照してください。 XTI のエラーの概要の説明については,3.7 節 を参照してください。

t_connect 関数は,正常終了すると 0 を返します。 それ以外の場合は --1 を返し,変数 t_errno に,3.7 節に示されている値の 1 つが設定されます (マルチスレッド・アプリケーションの場合,t_errno はスレッド固有です)。

接続の受け入れ

パッシブ・ユーザが接続指示を受け入れると,同じ終端 (t_listen を使用してリッスンしていた終端),または別の終端で t_accept 関数を発行できます。

パッシブ・ユーザが同じ終端で受け入れると,その終端はそれ以上は着信接続指示を受信することも,キューにいれることもできなくなります。 その終端にバインドされたプロトコル・アドレスは,終端がアクティブな間はビジーのままです。 リッスンに使用している終端と同じプロトコル・アドレスに,トランスポート終端をバインドすることはできません。 つまり,パッシブ・ユーザが t_unbind 関数を発行するまで,他の終端はバインドできません。 さらに,同じ終端で接続を受け入れるためには,パッシブ・ユーザは,(t_accept 関数または t_snddis 関数のいずれかを使用して) 以前に受信したすべての接続指示に応答しなければなりません。 それ以外の場合,t_accept は,TBADF エラーを返します。

パッシブ・ユーザが別の終端で接続を受け入れた場合には,リッスンに使用している終端は,引き続き着信接続要求を受信してキューにいれることができます。 別の終端は,前もってプロトコル・アドレスにバインドして,T_IDLE 状態になっていなければなりません。 プロトコル・アドレスが,接続指示を受信した終端と同じ場合には,qlen パラメータにゼロ (0) を設定しなければなりません。

どちらの終端を使用する場合にも,受信を待っている接続指示または切断指示があるときには,t_accept 関数は失敗し,TLOOK エラーを返します。

関数の構文,パラメータ,エラーについては, t_accept(3) を参照してください。 XTI のエラーの概要の説明については,3.7 節 を参照してください。

3.3.3.4    データの転送

2 つの終端間に一度接続が確立されると,アクティブ・ユーザとパッシブ・ユーザは,その接続を通して全二重方式でデータを転送できます。 コネクション指向型サービスのこのフェーズは,データ転送フェーズといいます。 これ以降の項では,データ転送フェーズでデータの送受信を行う方法について説明します。

データの送信

トランスポート・ユーザは,t_snd 関数を使用して,通常データまた優先データのいずれかを接続を通して送信できます。 通常では,トランスポート・プロバイダがすべてのデータをただちに受け入れることができる場合,t_snd は正常に送信して,受け入れられたバイト数を返します。 データがただちに受け入れられない場合,t_snd の結果は,同期モードまたは非同期モードのどちらで実行していたかによって異なります。

省略時には,t_snd 関数は同期モードで実行され,フロー制御条件によってトランスポート・プロバイダがデータを受け入れることができない場合は待ちます。 この関数は,次の条件の 1 つが真になるまでブロックします。

終端の作成時に O_NONBLOCK フラグがセットされていれば,t_snd は非同期モードで実行され,フロー制御制限がある場合はすぐに失敗します。 場合によっては,データの一部だけがトランスポート・プロバイダに受け入れられ,t_snd は,送信要求したバイト数より少ない値を返すことがあります。 このときには,ユーザは次のうちの 1 つを行います。

関数の構文,パラメータ,エラーについては, t_snd(3) を参照してください。 XTI のエラーの概要の説明については,3.7 節 を参照してください。

データの受信

トランスポート・ユーザは,t_rcv 関数を使用して,通常データまたは優先データのいずれかを接続を通して受信できます。 通常では,データが受信できる場合,t_rcv はデータを返します。 接続が切断されている場合は,t_rcv は,ただちにエラーを指定して戻ります。 データは受信できないが,接続が存在している場合には,t_rcv の動作は,実行モードに応じて異なります。

関数の構文,パラメータ,エラーについては, t_rcv(3) を参照してください。 XTI のエラーの概要の説明については,3.7 節 を参照してください。

3.3.3.5    接続の解放

XTI では,2 つの接続の解放方法をサポートしています。 つまり,打ち切りによる解放と正常解放です。 すべてのトランスポート・プロバイダは,打ち切りによる解放をサポートします。 正常解放は,XTI ではオプション機能であるため,トランスポート・プロバイダの中には,これを提供しないものがあります。 たとえば,OSI トランスポートは打ち切りによる解放だけをサポートしますが,TCP は打ち切りによる解放と,オプションとして正常解放をサポートします。

打ち切りによる解放

打ち切りによる解放は,トランスポート・ユーザまたはトランスポート・プロバイダから要求でき,接続をただちに打ち切ります。 打ち切りによる解放は折衝できないため,一度打ち切りによる解放を要求すると,ユーザ・データが引き渡される保証はありません。

トランスポート・ユーザは,接続確立フェーズまたはデータ転送フェーズのいずれかで,打ち切りによる解放を要求できます。 接続確立フェーズでは,トランスポート・ユーザは,打ち切りによる解放を使用して接続要求をリジェクトすることができます。 データ転送フェーズでは,どちらかのユーザがいつでも接続を解放できます。 トランスポート・プロバイダが打ち切りによる解放を要求すると,接続がもう存在しないことが両方のユーザに通知されます。

関数の構文,パラメータ,エラーについては, t_snddis(3) を参照してください。 XTI のエラーの概要の説明については,3.7 節 を参照してください。

トランスポート・ユーザは,T_DISCONNECT イベントを通じて,打ち切りによる解放について通知されます。 プログラムが T_DISCONNECT イベントを受信した場合には,t_rcvdis 関数を発行して,切断に関する情報を検索し,T_DISCONNECT イベントを消費しなければなりません。

関数の構文,パラメータ,エラーについては, t_rcvdis(3) を参照してください。 XTI のエラーの概要の説明については,3.7 節 を参照してください。

正常解放

正常解放を使用すると,データを損失することなく接続を解放することができます。 正常解放はすべてのトランスポート・プロバイダが提供している機能ではありません。 トランスポート・プロバイダが,t_open 関数または t_getinfo 関数で T_COTS_ORD のサービス・タイプを返す場合には,正常解放がサポートされます。 トランスポート・ユーザは,データ転送フェーズで正常解放を要求できます。 正常解放の一般的な手順は次のとおりです。

  1. アクティブ・ユーザが t_sndrel 関数を発行して,接続の正常解放を要求する。

  2. パッシブ・ユーザは,アクティブ・ユーザからの正常解放要求を示す T_ORDREL イベントを受信すると,t_rcvrel 関数を発行して,要求を受信したことを示し,T_ORDREL イベントを消費する。

  3. 切断の準備ができたら,パッシブ・ユーザは,t_sndrel 関数を発行する。

  4. アクティブ・ユーザは,t_rcvrel 関数を発行して応答する。

トランスポート・ユーザは t_sndrel 関数を発行した後に,その接続を通してそれ以上データを送信することはできません。 ただし,正常解放指示 (T_ORDREL イベント) を受信するまで,データの受信を継続することはできます。

関数の構文,パラメータ,エラーについては, t_sndrel(3) を参照してください。 XTI のエラーの概要の説明については,3.7 節 を参照してください。

正常解放指示の受信に肯定応答するには,t_rcvrel 関数を発行します。

トランスポート・ユーザは,正常解放指示 (T_ORDREL) を受信した後に,それ以上データを受信できません。 トランスポート・ユーザがデータを受信しようとすると,その関数は無期限にブロックします。 ただし,トランスポート・ユーザは,t_sndrel 関数を発行するまで,データの送信を継続することができます。

関数の構文,パラメータ,エラーについては, t_rcvrel(3) を参照してください。 XTI のエラーの概要の説明については,3.7 節 を参照してください。

3.3.3.6    終端の初期化解除

終端の使用が終了したら,t_unbind および t_close 関数を使用して,終端をアンバインドし,クローズすることにより,その終端の初期化を解除します。 ここでは,コネクション指向型サービスを使用して終端の初期化を解除する手順について説明しますが,コネクションレス型サービスの場合も手順は同じです。

終端をアンバインドしたら,終端は使用不能になり,トランスポート・プロバイダはそれ以上要求を受け入れません。

関数の構文,パラメータ,エラーについては, t_unbind(3) を参照してください。 XTI のエラーの概要の説明については,3.7 節 を参照してください。

終端をクローズすることによって,トランスポート・プロバイダにその終端の使用が終了したことを通知し,その終端に関連するライブラリ・リソースをすべて解放します。

終端が T_UNBND 状態の場合は,t_close を呼び出さなければなりません。 ただし,この関数は状態情報をチェックしないので,どの状態からでも呼び出して,トランスポート終端をクローズすることができます。

T_UNBND 状態ではない終端をクローズすると,その終端に関連するライブラリ・リソースが自動的に解放されて,その終端に関連するファイルがクローズされます。 そのプロセスまたはその終端を参照するプロセスに他の記述子がない場合,トランスポート接続は切断されます。

関数の構文,パラメータ,エラーについては, t_close(3) を参照してください。 XTI のエラーの概要の説明については,3.7 節 を参照してください。

3.3.4    コネクションレス型アプリケーションの作成

この項では,コネクションレス・モードのアプリケーションを作成するために必要な手順について説明します。

  1. 終端の初期化

  2. データの転送

  3. 終端の初期化解除

3.3.4.1    終端の初期化

コネクションレス型アプリケーションのために終端を初期化する手順は,コネクション指向型アプリケーションの場合と同じです。 コネクションレス型アプリケーションのために終端を初期化する方法についての詳細は,3.3.3.1 項を参照してください。

3.3.4.2    データの転送

コネクションレス型サービスのデータ転送フェーズは,次の操作から構成されています。

コネクションレス型サービスについては,次のことに注意してください。

データの送信

t_sndudata 関数は,同期モードまたは非同期モードで実行できます。 同期モードで実行している場合,t_sndudata は,トランスポート・プロバイダが別のデータグラムを受け入れることができるときに,制御をユーザに戻します。 場合によっては,この状態になるまで少しの間,この関数はブロックします。 非同期モードでは,フロー制御制限が存在する場合,トランスポート・プロバイダは,新しいデータグラムの送信を拒否します。 この場合,t_sndudata 関数は TFLOW エラーを返します。 したがって,ユーザは,後でこの呼び出しを再試行するか,または t_look 関数を発行して,フロー制御制限が解除されたかどうかを確かめなければなりません。 フロー制御制限の解除は,T_GODATA または T_GOEXDATA のイベントによって示されます。

t_bind 関数を使用して終端をアクティブにする前に,データ・ユニットを送信しようとすると,トランスポート・プロバイダはそのデータを破棄します。

関数の構文,パラメータエラーについては, t_sndudata(3) を参照してください。 XTIのエラーの概要の説明は,3.7 節

データの受信

t_rcvudata 関数を呼び出しデータが受信できる場合,t_rcvudata は,受信オクテット数を示して,すぐに戻ります。 データを受信できない場合の t_rcvudata の動作は,実行モードに応じて次のように異なります。

関数の構文,パラメータ,エラーについては, t_rcvudata(3) を参照してください。 XTL のエラーの概要の説明は,3.7 節 を参照してください。

エラー情報の検索

t_look を発行して T_UDERR イベントを受信した場合は,以前に送信したデータでエラーが生じています。 エラーをクリアして T_UDERR イベントを消費するには,t_rcvuderr 関数を発行する必要があります。 この関数はまた,エラーを生じたデータとエラーの性質に関する情報も返します (ただしこれは指定した場合のみです)。

データ・ユニットに関するエラー情報を受信するには,t_rcvuderr 関数を発行します。

関数の構文,パラメータ,エラーについては, t_rcvuderr(3) を参照してください。 XTI のエラーの概要の説明については,3.7 節 を参照してください。

3.3.4.3    終端の初期化解除

コネクションレス型アプリケーションのために終端の初期化を解除する手順は,コネクション指向型アプリケーションの場合と同じです。 コネクションレス型アプリケーションのために終端の初期化を解除する方法についての詳細は,3.3.3.6 項を参照してください。

3.4    フェーズに依存しない関数

XTI は,コネクション指向型サービスまたはコネクションレス型サービスの任意のフェーズ (初期化されていない状態を除く) で発行できる関数を,多数提供しています。 これらの関数は,インタフェースの状態には影響を与えません。 このような関数の一覧と簡単な説明を,表 3-13に示します。

表 3-13:  フェーズ独立関数

関数 説明
t_getinfo 終端に関連するトランスポート・プロバイダの特性に関する情報を返す。
t_getprotaddr [脚注 13] プロトコル・アドレスを返す。
t_getstate 終端の現在の状態を返す。
t_strerror [脚注 13] エラー・メッセージ文字列を作成する。
t_sync トランスポート・プロバイダからの情報と,トランスポート・ライブラリによって管理されるデータ構造体の同期をとる。
t_sysconf [脚注 14] 構成可能な XTI 限界値またはオプションの現在値を返す。
t_alloc 指定されたデータ構造体用にストレージを割り当てる。
t_free 以前に t_alloc によって割り当てられたデータ構造体用のストレージを解放する。
t_error XTI 関数によって返された最新のエラーを記述するメッセージを出力する。 (オプション)
t_look 終端に関連する現在のイベントを返す。

t_getinfo 関数および t_getstate 関数は,重要な情報の検索に役立ちます。 t_getinfo 関数は,t_open と同様にトランスポート・プロバイダに関する情報を返します。 t_open が初期化フェーズだけで呼び出すことができるのに対して,t_getinfo は,通信のどのフェーズでも呼び出すことができます。 関数が TOUTSTATE エラーを返して,終端が適切な状態にないことを示している場合には,t_getstate を発行して現在の状態を検出し,その状態に対して適切なアクションをとることができます。

t_sync 関数は,次のことを実行できます。

t_alloc 関数および t_free 関数は,メモリの割り当ておよび解放に便利です。 これらの関数では,サイズに関する情報ではなく XTI 構造体の名前を指定できます。 t_alloc および t_free を使用して XTI 構造体のメモリを管理していれば,XTI 構造体が将来のリリースにおいて変更された場合でも,プログラムを変更する必要がありません。

t_error を使用すると,t_errno の内容に加えて,ユーザ指定のメッセージ (説明) を標準出力にプリントできます。

t_look は,終端に関連する現在の未処理のイベントを検出する,重要な関数です。 一般に,XTI 関数がエラーとして TLOOK を返して,重要な非同期イベントが発生したことを示すと,トランスポート・ユーザは,t_look 関数を発行してそのイベントを検出します。 イベントについての詳細は,3.2.3 項を参照してください。

3.5    XTI へのポート

この節では,次の事柄について説明します。

3.5.1    プロトコル独立およびポータビリティ

XTI は,使用する特定のトランスポート・プロトコルに依存しないインタフェースを提供するために設計されました。 基礎となるトランスポート・プロバイダがサポートする XTI の関数および機能の任意のサブセットに応じて,動作を変更できるアプリケーションを作成できます。

プロバイダは,XTI の機能をすべて備えていなくてもかまいません。 したがって,アプリケーション・プログラマは,次のガイドラインに従って,XTI アプリケーションを作成する必要があります。

以降の項で,異なるトランスポート・レベルのプログラミング・インタフェースから XTI にアプリケーションをポートする方法について説明します。 特に,最も一般に使用される 2 つのトランスポート・レベルのプログラミング・インタフェースからポートする方法について説明します。 この 2 つのインタフェースとは,多数の UNIX System V アプリケーションで使用されているトランスポート層インタフェース (TLI),および多数のバークレイ版 UNIX アプリケーションで使用されている 4.3BSD ソケット・インタフェースです。

以降の項で示される情報は,ユーザが,TLI またはソケットを使用したプログラミングに習熟していること,および基本的な XTI の概念および構文を理解していることを前提としています。

3.5.2    XTI と TLI の互換性

この項では,TLI プログラムを再コンパイルする前に考慮すべき事項について説明するとともに,再コンパイルの方法について説明します。 長期的な観点から考えた場合は,TLI インタフェースではなく XTI インタフェースを使用することをお勧めします。 XTI を使用するアプリケーションおよびトランスポート・プロバイダが多くなるにつれ,その利点が明らかになります。

XTI と TLI は同じ関数,状態,およびサービス・モードをサポートします。 XTI または TLI アプリケーションを XTI または TLI ライブラリとリンクする場合には,シェアード・ライブラリ・サポートが省略時の設定です。 シェアード・ライブラリ・サポートの詳細については,3.2.2 項を参照してください。

TLI プログラムを再コンパイルする前に,次のようなイベント管理について,プログラムの現在のインプリメンテーションを検討する必要があります。 つまり,System V UNIX オペレーティング・システムは,イベント管理用のツールとして,poll 関数を提供します。 Tru64 UNIX の XTI インプリメンテーションは,poll 関数をサポートしているので,アプリケーションでこの関数を使用している場合は,再コンパイルできます。 プログラムが,独自のイベント管理機構を使用している場合は,そのイベント管理機構を Tru64 UNIX にポートするか,または Tru64 UNIX が提供するポーリング機構に変更する必要があります。

Tru64 UNIX の TLI のインプリメンテーションは,AT&T の TLI とソース・レベルで互換性があるため,Tru64 UNIX の TLI ライブラリを使用して TLI プログラムを再コンパイルすることができます。 次の手順に従ってください。

  1. TLI ヘッダ・ファイルがソース・コードにインクルードされていることを確認する。

    #include <tli/tiuser.h>
     
    

  2. 次のコマンド構文を使用して,アプリケーションを再コンパイルする。

    cc -o name name.c -ltli

TLI アプリケーションを XTI アプリケーションに変更する場合には,次に示す TLI と XTI のわずかな相違を認識しておく必要があります。

TLI アプリケーションを真の XTI アプリケーションにするには,次のことを行います。

  1. TLI ヘッダ・ファイルの代わりに XTI ヘッダ・ファイルをソース・コードにインクルードする。

    #include <xti.h>
     
    

  2. TLI と XTI の相違から必要となる,すべての変更または拡張をプログラムに加える。

  3. 次のコマンドを使用して,アプリケーションを再コンパイルする。

    cc -o name name.c -lxti

3.5.3    ソケット・アプリケーションから XTI 使用アプリケーションへの書き換え

この項では,ソケット・インタフェースと XTI との相違について説明します。 ここでは,アプリケーションが標準 4.3 BSD ソケット・インタフェースを使用していることを前提としており,ソケット・インタフェースに加えた拡張や変更は考慮していません。 ソケットと XTI のサーバおよびクライアントの例については,付録 B を参照してください。

XTI には,ソケット・インタフェースと共通の関数が多数あります。 ただし,XTI を使用できるようにアプリケーションを書き換える場合には,XTI と現在のソケット・インタフェースとのあらゆる相違を認識しておく必要があります。

XTI では,30 個の関数を提供しています。 ソケット関数に対応する XTI 関数は 14 個ありますが,そのうち 6 個の関数にはわずかな相違があります。 表 3-14 は,各 XTI 関数と,それに対応するソケット関数 (存在する場合),およびその 2 つの関数が同じ意味を持つかどうかを示した一覧です。 一般に,ソケット関数はパラメータを値で渡しますが,ほとんどの XTI 関数は,入出力パラメータの構造体を指し示すポインタを渡します。

表 3-14:  XTI 関数とソケット関数の比較

XTI 関数 ソケット関数 意味
t_accept accept 異なる
t_alloc -- --
t_bind bind 異なる
t_close close 同じ
t_connect connect 同じ
t_error -- --
t_free -- --
t_getinfo -- --
t_getstate -- --
t_listen listen, accept 同じ [脚注 15]
t_look select 異なる
t_open socket 同じ
t_optmgmt setsockopt, getsockopt 異なる
t_rcv recv 同じ
t_rcvconnect -- --
t_rcvdis -- --
t_rcvrel -- --
t_rcvreldata -- --
t_rcvudata recvfrom 同じ
t_rcvuderr -- --
t_rcvv recv 同じ
t_rcvvudata recv 同じ
t_snd send 同じ
t_snddis shutdown 異なる
t_sndrel -- --
t_sndreldata -- --
t_sndudata sendto 同じ
t_sndv send 同じ
t_sndvudata send 同じ
t_sync -- --
t_sysconf -- --
t_unbind -- --

対応するソケット関数と意味が異なる XTI 関数は,次の点で異なっています。

t_accept

t_accept 関数は,ユーザ指定の resfd 引数をとり,リモート終端との接続を確立する。 一方,ソケットからの accept 呼び出しは,接続が確立されるファイル記述子の選択をシステムに命じる。 また t_accept 関数は,接続指示が受信されている場合に発行される。 したがって,この関数はブロックしない。 逆に,accept 呼び出しは接続要求を見越して発行されるため,接続要求が発生するまでブロックすることがある。

t_bind

XTI は,1 つのプロトコル・アドレスを複数の終端にバインドできるが,ソケット・インタフェースでは,1 つのアドレスは 1 つのソケットにしかバインドできない。

t_look

t_look 関数は,現在のイベントを返す。 現在のイベントは,T_LISTEN,T_CONNECT,T_DATA,T_EXDATA,T_DISCONNECT,T_UDERR,T_ORDREL,T_GODATA,および T_GOEXDATA のいずれかである。 poll 関数は,トランスポート終端で着信イベントを監視するときに使用できる。 select 呼び出しは,単一の記述子が読み取り用または書き込み用に準備できているかどうか,または例外条件が保留中かどうかを調べる場合に使用できる。

t_snddis

t_snddis 関数は, 確立された接続での打ち切りによる解放を開始するか,または接続要求をリジェクトする。 XTI プログラムは t_snddis 関数を発行した後も,t_listen 関数を使用して要求のリッスンを継続したり,t_connect 関数を使用して接続を再確立することができる。 ソケットでは,shutdown 呼び出しおよび close 呼び出しを使用して接続を一度シャットダウンすると,この接続に割り当てられたすべてのローカル・リソースが自動的に解放される。 したがって,接続のリッスンを継続したり,接続を確立するために,プログラムは,socket 呼び出しと bind 呼び出しを再発行する必要がある。

XTI およびソケットはどちらも一連の状態を使用して,適切な呼び出しの順序を制御しますが,各々が使用する状態は異なります。 XTI の状態とソケットの状態が持つ意味は同じではありません。 たとえば,XTI の状態は相互に排他的ですが,ソケットの状態は排他的ではありません。

ほとんどのエラー・メッセージは,ソケットと XTI で異なります。 表 3-15 に,XTI エラー・メッセージに対応するソケット・エラー・メッセージの一覧を示します。

表 3-15:  ソケットと XTI のメッセージの対応

ソケット・エラー XTI エラー 説明
EBADF TBADF 無効なファイル記述子を指定した。
EOPNOTSUPP TNOTSUPPORT 基礎となるトランスポート・プロバイダがサポートしていない関数を発行した。
EADDRINUSE TADDRBUSY すでに使用されているアドレスを指定した。
EACCES TACCES 指定したアドレスを使用する許可がない。

注意

XTI および TLI は,STREAMS を使用してインプリメントされます。 STREAMS ファイル記述子に関しては,select 呼び出しではなく,poll 関数を使用してください。

3.6    XPG3,XNS4.0,XNS5.0 の相違点

この節では,XPG3,XNS4.0,XNS5.0 の XTI のインプリメントの相違点について説明します。

これまでのバージョンの Tru64 UNIX では,XTI のインプリメントは X/Open の XPG3 仕様に準拠していました。 現在のインプリメントは,X/Open の XNS4.0 および XNS5.0 の XTI 仕様に準拠しています。 XNS4.0 が省略時の設定です。

これらの仕様には,プログラマが知っておかなければならない変更がいくつかあります。 この節では,そのような相違点と,関連するプログラミング上の問題について概説します。

Tru64 UNIX は,XPG3,XNS4.0,および XNS5.0 の XTI を 1 つのサブセットに集約してインプリメントしていることに注意してください。 この節では,該当するレベルの機能の使用についての詳細も記述します。

本書では,XNS4.0 または XNS4.0 XTI という用語は,Tru64 UNIX の本バージョンでの XTI の省略時のインプリメントを指して使用します。 XNS5.0 または XNS5.0 XTI という用語は,X/Open の XNS5.0 仕様に準拠する XTI のインプリメントを指して使用します。 XPG3 の XTI という用語は,X/Open の XPG3 仕様に準拠する XTI のインプリメントを指して使用します。 XPG3 の XTI は,Tru64 UNIX の現在のバージョンでも,バイナリの互換性やソース移行の機能のために使用できます。

3.6.1    XPG3 と XNS4.0 の主な相違点

2 つの仕様の間の変更点のほとんどには,上位互換性があります。 しかし t_optmgmt 関数はこれに当てはまりません。

次に,XTI の XPG3 から XNS4.0 への変更についての基本事項を簡単にまとめます。

t_optmgmt 関数の変更は非常に大きく,XPG3 仕様とは互換性がありません。 一般に,XPG3 のインプリメントの t_optmgmt 関数を使用しているアプリケーションは,XNS4.0 または XNS5.0 仕様が実行されているシステムの t_optmgmt 関数を使用できません。 ソースにいくらかの修正が必要です。

3.6.2    XNS4.0 と XNS5.0 の主な相違点

2 つの仕様間の変更点のほとんどには,上位互換性があります。 XNS4.0 の XTI に対する XNS5.0 の XTI の基本的な変更点の概要を,次に示します。

3.6.3    ソース・コードの移行

XPG3 の XTI 用に開発したアプリケーションがある場合,オペレーティング・システムの現在のバージョンでそのアプリケーションをサポートするときには,次のいずれかを選択します。

どの方法を選択するかは,ユーザの状況によって異なります。 次の各節では,そのような状況について詳細に説明します。

3.6.3.1    アプリケーションの古いバイナリ・ファイルを使用する場合

アプリケーションのソースと機能を変化を変更しない場合は,この方法を選択します。 以前のリリースのまま製品を継続して機能させることができる点が便利です。

3.6.3.2    ソースを変更しないで再コンパイルする場合

小さな問題点を修正するためにわずかな変更を行う場合は,この方法を選択します。 したがって,アプリケーションの構成や機能は変更しません。 XPG3 の開発環境と同じ方法でソースをコンパイルしたい場合は,-DXPG3 コンパイラ・スイッチでコンパイルします。 そうすれば,ヘッダが自動的に以前の機能を定義します。

3.6.3.3    XNS4.0 に準拠させる場合

XNS4.0 の XTI がサポートする新しい機能を使用する必要がある場合は,ソース・コードに変更を加えなければなりません。 XPG3 と XNS4.0 の XTI の機能を組み合わせることはできません。 したがって,複数のファイルからなる大きいアプリケーションの場合は,変更を行った一部のファイルだけではなく,すべてのファイルを新しい機能とともに再コンパイルする必要があります。

ソース・コードをコンパイルするには,-DXOPEN_SOURCE コンパイラ・スイッチを付ける必要があります。 さらに,トランスポート・プロトコルの名前 (/dev/streams/xtiso/tcp といったストリームのデバイス特殊ファイルとして与えられるもの) は,XNS4.0 の XTI で使用されている命名規則に合わせて更新しなければなりません。 たとえば,TCP と UDP の名前は,/dev/streams/xtiso/tcp+/dev/streams/xtiso/udp+ になります。 その他のプロトコルの名前については,それぞれのリファレンス・マニュアルで確認してください。

3.6.3.4    XNS5.0 に準拠させる場合

XNS5.0 の XTI がサポートする新しい機能を使用する必要がある場合は,ソース・コードに変更を加えなければなりません。 XPG3 と XNS5.0 の XTI の機能を組み合わせることはできません。 したがって,複数のファイルからなる大きいアプリケーションの場合は,変更を行った一部のファイルだけではなく,すべてのファイルを新しい機能とともに再コンパイルする必要があります。

ソース・コードをコンパイルするには,-DXOPEN_SOURCE=500 コンパイラ・スイッチを付ける必要があります。 さらに,トランスポート・プロトコルの名前 (/dev/streams/xtiso/tcp といったストリームのデバイス特殊ファイルとして与えられるもの) は,XNS5.0 の XTI で使用されている命名規則に合わせて更新しなければなりません。 たとえば,TCP と UDP の名前は,/dev/streams/xtiso/tcp5/dev/streams/xtiso/udp5 になります。 その他のプロトコルの名前については,それぞれのリファレンス・マニュアルで確認してください。

3.6.4    バイナリの互換性

XPG3 の XTI を使用して開発されたアプリケーションのバイナリ・ファイルを実行する際には,いくつかの注意が必要です。

正常でない状況では,XPG3 を使用するプログラムの中のエラーが,プログラムまたはライブラリをコンパイルおよびリンクする方法によってマスクされてしまうことがあります。 こうした場合に,新しいインプリメントによってエラーのフラグがセットされることがあります。 明らかになるエラーはアプリケーションのプログラム上のエラーなので,プログラマが修正します。 通常,このようなエラーが発生するのは,プログラム上のポインタのオーバランや変数の初期化忘れです。

もう 1 つ考慮が必要な点は,STREAMS 特殊ファイルを介して XNS4.0 の機能が使用できることです。 これが重要になるのは,アプリケーションがコマンド行からのトランスポート・プロトコルの入力や,何らかの構成ファイルからのプロトコル名の取り込みを受け付ける場合です。 XTI を組み込んで構成したシステムは,XNS4.0 に準拠したプロトコルのためのファイル名を持ちます。 したがって,バイナリの互換モードで実行しているアプリケーションでは,こうした特別な名前を使用しないようにユーザやシステム管理者に警告しておくことが大切です。 使用した場合の結果は,定義されていません。

古いアプリケーションを再コンパイルせずに実行する場合は,バイナリの互換性をチェックして,こうした問題が起こらないようにしてください。

3.6.5    パッケージ

オペレーティング・システムの現在のバージョンが実行されていて,XTI を組み込んで構成されているシステムは,XPG3 準拠,XNS4.0 準拠,および XNS5.0 準拠の機能をサポートしています。 XPG3,XNS4.0,および XNS5.0 の機能を分けて実行することはできません。 したがって,XTI のサブシステムが構成に組み込まれていることだけを確認する必要があります。

3.6.6    相互運用性

XPG3,XNS4.0,および XNS5.0 の XTI を 1 つのネットワーク上で使用できます。 アプリケーションの,互換性のあるバージョンを使用する場合は,動作の違いはユーザからはわかりません。

アプリケーションを簡単な手順で変換して,ある部分は XPG3 の XTI に互換で,ある部分は XNS4.0 の XTI に互換で,ある部分は XNS5.0 の XTI に互換にすることができます。 必ず守らなければならないのは,アプリケーション・レベルのプロトコルを同じに保つことだけです。 この他には,それぞれの構成要素の相互運用性について問題はありません。 したがって,アプリケーションにクライアンとサーバがあれば,サーバを XNS4.0 または XNS5.0 準拠にアップグレードして,クライアントはそのままバイナリ互換のモードで動作させておくことができます。 後で,サーバの機能のアップグレードが完了したら,クライアントをアップグレードすることもできます。

3.6.7    XTI のオプションの使用

この節では,XNS4.0,XNS5.0,および XPG3 の XTI のオプションの使用について説明します。

3.6.7.1    XNS4.0 および XNS5.0 の XTI のオプションの使用

この節では,XTI のオプションを使用する上での,次の事柄について説明します。

全般的な説明

次の各関数は,入出力パラメータとして struct netbuf 型の引数 opt を持っています。 この引数は,トランスポート・ユーザとトランスポート・プロバイダの間でオプションをやりとりするために使用します。

オプションの内容についての一般的な規定はありません。 オプションには,XTI 全般で使用するものと,それぞれのトランスポート・プロバイダに固有のものとがあります。 オプションのいくつかは,ユーザの通信上の必要に応えるためのものです。 たとえば,高いスループットや短い遅延を要求するようなものです。 その他のオプションには,プロトコルの動作を微調整して,特殊な特性の通信を,より効率的に処理できるようにするためのものもあります。 また,デバッグを目的としたオプションもあります。

すべてのオプションには,省略時の値があります。 値は,それぞれが適用されるプロトコル・レベルで意味を持ち,定義されています。 しかし,トランスポート・ユーザが値を折衝できます。 これには,トランスポート・ユーザが値の使用を強制できる場合などの単純なケースも含まれます。 多くの場合は,トランスポート・プロバイダ,またはリモートのトランスポート・ユーザまでもが,値を折衝して,提案されたものよりも低い品質の値にする権限を持っています。 つまり,遅延が長くなったり,スループットが低くなったりすることがあります。

オプションを,関連付けに関するものとそうでないものとに区別すると役に立ちます。 関連付けに関するとは,通信するトランスポート・ユーザのペアに関することを意味します。 関連付けに関するオプションは,特定のトランスポート接続やデータグラム転送に密接に関係しています。 呼び出し側ユーザがこのようなオプションを指定すると,ほとんどの場合はネットワークを介して何らかの補助的な情報がやりとりされます。 この情報の解釈およびその後の処理は,プロトコルによって変わります。 たとえば,ISO のコネクション指向型の通信では,呼び出し側ユーザは,接続の確立でサービス品質パラメータを指定できます。 このパラメータは,最初にローカルのトランスポート・プロバイダで処理されて,おそらくは低下され,そしてリモートのトランスポート・プロバイダに送られ,さらに低下されます。 最後に,呼び出された側のユーザに渡されて最終の選択が行われ,選択された値が呼び出し側に返されます。

関連付けに関したものでないオプションは,リモートのトランスポート・ユーザに送る情報を持ちません。 デバッグを行うためのオプションのように,まったくローカルでだけ意味を持つものがあれば,IP の time-to-live フィールドや,TCP_NODELAY を設定するオプションのように,転送に影響を与えるものもあります ( xti_internet(7) を参照)。 ローカルのオプションの折衝は,トランスポート・ユーザとトランスポート・プロバイダの間でだけ行われます。 こうした関連付けについての 2 つの分類のオプションの区別は,XTI の次の各点において見られます。 出力では,t_listen および t_rcvudata 関数は関連付けに関するオプションだけを返します。 t_rcvconnect および t_rcvuderr 関数はどちらの分類のオプションも返します。 入力では,t_accept および t_sndudata 関数はどちらの分類のオプションも指定できます。 t_connect および t_optmgmt 関数はどちらの分類のオプションも処理して返します。

トランスポート・プロバイダは,サポートするそれぞれのオプションに対して,省略時の値を持っています。 大部分の通信は省略時の値で十分です。 したがって,トランスポート・ユーザは,作業を行うのに実際に必要なオプションだけを要求して,その他はすべて省略時の値にするようにしてください。

この項では,オプションの使用についての全般的なフレームワークを説明しています。 このフレームワークは,トランスポート・プロバイダに必須なものです。 XTI の一般的なオプションについては,t_optmgmt リファレンス・ページで説明しています。 TCP および UDP のトランスポート・プロバイダで有効な固有のオプションについては,xti_internet リファレンス・ページで説明しています。

オプションの形式

オプションは,struct netbuf の引数 opt で受け渡します。 指定されたバッファ内のそれぞれのオプションは,struct t_opthdr 型の形式をしていて,通常はオプションの値が後に続きます。

トランスポート・プロバイダはプロトコル・スタックを形成しています。 struct t_opthdrlevel フィールドは,XTI レベル,または TCP や ISO 8073:1986 といったトランスポート・プロバイダのプロトコルを指定します。 name フィールドは,そのレベル内のオプションを指定し,len フィールドは全体の長さ,つまりオプションのヘッダ t_opthdr にオプションの値部分を合わせた長さを収めています。 status フィールドは,XTI レベルまたはトランスポート・プロバイダが使用して,折衝の成功あるいは失敗を示します。

複数のオプションを連結することもできます。 ただし,それぞれのオプションは必ずロング・ワード単位の境界で始まらなければなりません。 XNS4.0 では OPT_NEXTHDR(pbuf,buflen,poptons) マクロ,XNS5.0 では T_OPT_NEXTHDR(pbuf,buflen,poptons) マクロを使用すると,ロング・ワード単位の境界で始めることができます。 パラメータ pbuf はオプション・バッファ opt.buf へのポインタを示し,buflen はバッファの長さを示します。 パラメータ poption は,オプション・バッファ内の現在のオプションを指します。 OPT_NEXTHDR および T_OPT_NEXTHDR は,次のオプションの位置へのポインタを返すか,またはオプション・バッファを使い切った場合に NULL ポインタを返します。 これらのマクロは,オプションのリストを読み書きするときに便利です。

折衝の各要素

この項では,オプションの受け渡しと取り出しに対する一般的な規則,および起こり得るエラーについて説明します。 明示的な制約がない限り,これらの規則はオプションの交換が可能なすべての関数に適用されます。

複数のオプションの指定とオプション・レベル

入力のオプション・バッファで複数のオプションを指定した場合は,呼び出す関数によって,指定するレベルに対して違った規則が適用されます。 t_optmgmt に入力で指定する複数のオプションは,同じオプション・レベルに向けたものでなければなりません。 t_connectt_accept,および t_sndudata に入力で指定するオプションは,違ったレベルに向けたものでも構いません。

違反オプション

折衝できるのは,規則に従っているオプションだけです。 違反オプションは障害を起こす可能性があります。 オプションが違反になるのは,次のいずれかの場合です。

違反オプションを XTI に渡した場合は,次のようになります。

トランスポート・ユーザが 1 つの呼び出しで複数のオプションを渡した場合に,オプションの 1 つが違反していると,呼び出しは前述のように失敗します。 ただし,渡した違反していないオプションの一部分,または場合によってはすべてが正常に折衝されることもあります。 トランスポート・ユーザは,t_optmgmt 関数を T_CURRENT フラグをセットして呼び出すことで,現在の状態を確認できます。 t_optmgmt(3) および xti_internet(7) を参照してください。

オプション・レベルが選択したプロトコルに対して未知,またはそのプロトコルがサポートしていないオプション・レベルを指定した場合は,失敗になりません。 このオプションは,t_connectt_accept,または t_sndudata 関数の呼び出しでは破棄されます。 t_optmgmt 関数では,オプションの level フィールドで T_NOTSULPORT を返します。

オプション折衝の開始

T_NEGOTIATE フラグ付きの t_optmgmtt_connect,または t_sndudata 関数を呼び出すとき,トランスポート・ユーザがオプション折衝を開始します。

これらの関数の折衝についての規則は,オプション要求が絶対必要条件かどうかによって変わります。 絶対必要条件か否は,それぞれのオプションで明示的に定義されています。 t_optmgmt(3) および xti_internet(7) を参照してください。 たとえば,ISO トランスポート・プロバイダの場合は,優先データの使用を要求するオプションは絶対必要条件ではありません。 一方,保護を要求するオプションは,絶対必要条件である場合があります。

注意

絶対必要条件という用語は,本来は ISO 8072:1986 仕様のサービス品質パラメータについてのものです。 ここでは,すべてのオプションに対して使用しています。

提案したオプション値が絶対必要条件の場合は,次の 3 つの結果が考えられます。

提案したオプション値が絶対必要条件でない場合は,次の結果が考えられます。

オプションがサポートされていないために,関数が失敗したり,接続が打ち切られることはありません。 これは,ベンダによって,違ったサブセットのオプションをインプリメントしているためです。 さらに,XTI の将来の拡張で,トランスポート・プロバイダのこれまでのインプリメントでは未知のオプションも含められる可能性があります。 オプションがサポートされていない場合の通信を受け入れるかどうかの判断は,トランスポート・ユーザに任されています。

トランスポート・プロバイダは,同じオプションの (おそらくは違った値を持つ) 重複した発生をチェックしません。 単にオプションをオプション・バッファから順番に処理します。 ただし,ユーザは処理の順番について何も知ることができません。

オプションは,互いに独立していないものもあります。 要求したオプション値が,同じ呼び出しで指定している別のオプション値や,現在有効な別のオプション値と矛盾することがあります。 詳細は,「トランスポート終端のオプション管理」の項を参照してください。 こうした矛盾はすぐには検出されなくても,後になって予測しない結果につながることがあります。 折衝時に検出された場合は,これらの矛盾は前述の規則で解決されます。 したがって,結果は,矛盾にかかわる要求が絶対的な要求かどうかによって大きく変わります。

通常接続が確立されるか,またはデータグラムが送信されるときに,矛盾は検出されます。 オプションが t_optmgmt 関数で折衝される場合は通常,矛盾はこのときには検出されません。 これは,要求されたオプションを独立して処理するので,一時的な不一致が許されるためです。

t_connect および t_sndudata 関数を呼び出した場合は,関連付けに関するすべてのオプションに対して,この項の規則に従って折衝が開始されます。 関数呼び出し自体では明示的に指定していないオプションは,以前の折衝の値を収めた内部のオプション・バッファから取り出されます。 詳細は,「トランスポート終端のオプション管理」の項を参照してください。

折衝の提案への応答

コネクション指向型の通信では,対等トランスポート・ユーザが,確立するトランスポート接続の特性を折衝できます。 これは,関連付けに関するオプションの場合です。 接続指示に対して,呼び出された側のユーザは (t_listen 関数を介して),その接続で有効にするオプションの値についての提案を受け取ります。 呼び出された側のユーザは,この提案を受け入れるか,またはこれよりも低い質の値を選んで低くする (たとえば,提案よりも遅延を長くする) ことができます。 当然,呼び出された側のユーザが接続の確立を拒否することもできます。

呼び出された側のユーザは,t_accept 関数を使用して折衝の提案に応答します。 呼び出された側のトランスポート・ユーザが,提案よりも高い質のオプションを折衝しようとした場合の結果は,オプションが適用されるプロトコルによって変わります。 プロトコルはオプションを拒否したり,プロトコル固有のリファレンス・ページに記述されているような他の適当な動作を行ったりします。 オプションがリジェクトされた場合は,接続が失敗して T_DISCONNECT イベントが発生します。 この場合,t_accept 関数がそれでも正常終了するか,または TLOOK エラーで失敗するかは,タイミングとインプリメントの条件によって決まります。

複数のオプションを t_accept 関数に渡して,その内の 1 つがリジェクトされた場合は,接続は前述のようにして失敗します。 エラーになるオプションの処理の前に正常に折衝されたオプションは,折衝された値を保ちます。 ロールバックの機構はありません。 詳細は,「トランスポート終端のオプション管理」の項を参照してください。

応答するオプションは,t_accept 呼び出しで指定するか,または t_accept 呼び出しの前に t_optmgmt 呼び出し (T_NEGOTIATEアクション) の中の応答する終端 (リッスンする終端ではありません) resfd に渡すかのどちらかができます。 詳細は,「トランスポート終端のオプション管理」の項を参照してください。 なお,折衝の提案への応答が起動されるのは,t_accept 関数が呼び出されたときです。 t_optmgmt 関数の呼び出しが前述のようなエラーになるオプション値を持つ場合は,正常終了します。 接続が打ち切られるのは,t_accept 関数が呼び出されたときです。

選択されたオプションが矛盾につながる場合も,接続は失敗します。

t_accept 関数は,オプションの指定の重複をチェックしません。 「オプション折衝の開始」の項を参照してください。 サポートしていないオプションは無視されます。

オプション情報の取り出し

この項では,トランスポート・ユーザがオプションに関する情報を取り出す方法について説明します。

トランスポート・ユーザは,次のことができなければなりません。

このために,次の各関数は struct netbuf 型の引数 opt を持っています。

トランスポート・ユーザは,オプションを書き込むためのバッファを用意しなければなりません。 opt.buf パラメータでこのバッファを指し示し,opt.maxlen パラメータにバッファのサイズを収めます。 トランスポート・ユーザは,opt.maxlen パラメータをゼロに設定して,取り出すオプションがないことを示すことができます。

どのオプションが返されるかは,次のように各関数によって違います。

特権オプションおよび読み取り専用オプション

特権オプションとその値は,特権ユーザだけが要求できます。 ここでの特権の意味はインプリメントで定義されます。

読み取り専用オプションは,参照のためだけに使用します。 トランスポート・ユーザはオプションの値を読み出すことはできますが,変更はできません。 たとえばプロトコル・タイマや,プロトコル・データ・ユニットの最大長の選択は非常に微妙なので,トランスポート・ユーザには任せられないことがありますが,その値を知る必要はあります。 オプションは,すべてのユーザまたは特権のないユーザだけに対して読み出し専用にできます。 特権オプションは,特権のないユーザに対してアクセス不可または読み出し専用にできます。

オプションは,XTI の状態によって折衝可能であったり,読み出し専用であったりすることがあります。 たとえば,ISO のサービス品質オプションは,T_IDLE および T_INCON 状態では折衝可能で,その他のすべての状態 (T_UNINIT を除きます) では読み出し専用です。

トランスポート・ユーザが読み出し専用オプションの折衝を要求するか,または特権のないユーザが特権オプションに不法にアクセスした場合は,次のような結果になります。

複数のオプションを t_connectt_accept,または t_sndudata 関数に渡して,読み出し専用オプションが拒否された場合は,接続またはデータグラム転送は前述のようにして失敗します。 エラーになるオプションが処理される前に正常に折衝されたオプションは,折衝された値を保ちます。 ロールバックの機構はありません。 詳細は,「トランスポート終端のオプション管理」の項を参照してください。

トランスポート終端のオプション管理

この項では,トランスポート終端の存在期間中にオプション管理がどのように行われるかについて説明します。

それぞれのトランスポート終端は,内部のオプション・バッファと (論理的に) 結び付いています。 トランスポート終端が作成されると,このバッファに,サポートされているそれぞれのオプションの省略時のシステム設定値が入ります。 オプションによって,省略時の設定値は,OPTION ENABLED,OPTION DISABLED,またはタイム・スパンを示すものやその他の値になります。 たいていの操作では,省略時のこれらの設定は適切です。 オプションの折衝を通してオプションの値が変更されると,必ず修正後の値が以前の値を上書きしてこのバッファに書き込まれます。 バッファは,常にすべてのオプションに対して,そのトランスポート終端で現在有効な値を収めています。

t_optmgmt 関数を T_CURRENT フラグをセットして呼び出すことにより,オプションの現在の値はいつでも取り出せます。 t_optmgmt 関数を T_DEFAULT フラグをセットして呼び出すと,指定したオプションの省略時のシステム設定が返されます。

t_optmgmt 関数を T_NEGOTIATEフラグ をセットして呼び出すことで,トランスポート・ユーザはオプションの新しい値を折衝できます。 折衝は,「折衝の各要素」の項で説明した規則に従います。

オプションによっては,特定の XTI 状態でだけ変更できたり,他の XTI 状態で読み出し専用になったりするものがあります。 たとえば,関連付けに関するオプションの多くは,T_DATAXFER 状態では変更できず,変更しようとすると失敗します。 「特権オプションおよび読み出し専用オプション」の項を参照してください。 それぞれのオプションの状態についての規則は,その定義の中で指定されています。

関連付けに関するオプションは通常,接続の確立時またはデータグラムの転送の時に有効になります。 これはオプションが,ネットワークを介して転送される情報を含んでいる場合や,特定の転送特性を決める場合です。 このようなオプションを t_optmgmt 関数の呼び出しで変更する場合には,トランスポート・プロバイダは,オプションをサポートしているかどうかを確認して,値を現在の情報に従って折衝します。 折衝した値は,内部のオプション・バッファに書き込みます。

最終的な折衝は,接続が確立されるか,またはデータグラムが転送されると起こります。 この結果,オプションの値が低下されたり,または折衝が失敗したりすることさえあります。 折衝された値は,内部のオプション・バッファに書き込まれます。

T_DATAXFER 状態でも変更できるオプションがあります。 たとえば,バッファ・サイズを指定するオプションです。 このような変更は転送の特性に影響し,予測できない副作用を起こすことがあります。 たとえば,バッファ・サイズを短くするとデータを失う可能性があります。

t_connectt_accept,または t_sndudata 関数を呼び出す場合は,トランスポート・ユーザは関連付けについての両方の分類のオプションを,入力で明示的に指定できます。 オプションは,最初にローカルで1つ1つ折衝され,結果の値が内部のオプション・バッファに書き込まれます。 この後,ネットワークを介した折衝段階がさらに必要な場合は,変更されたオプション・バッファが使用されます。 たとえば,コネクション指向型の ISO の通信がそうです。 その後,新たに折衝された値が,内部のオプション・バッファに書き込まれます。

どの段階でも,折衝が失敗すると転送が打ち切られます。 転送が打ち切られると,オプション・バッファは,失敗が起こった時点の内容を保ちます。 XTI 呼び出しが失敗しても成功しても,エラーが発生する前に折衝されたオプションはオプション・バッファに書き込まれます。

t_connectt_accept,または t_sndudata 関数を呼び出すときに,どのオプションを明示的に指定するかを決めるのは,トランスポート・ユーザです。 トランスポート・ユーザは,関数の入力引数 optlen フィールドをゼロ (0) に設定すれば,オプションをまったく渡さなくてもかまいません。 この場合,内部のオプション・バッファの現在の内容が,変更なしに折衝に使用されます。

t_connectt_accept,または t_sndudata 呼び出しのときのオプションの折衝プロシージャは,常に「オプション折衝の開始」の項の規則に従います。 オプションが呼び出しで明示的に指定されたか,内部のオプション・バッファから暗黙に取られたかには関係ありません。

折衝でオプションが処理される順番については,トランスポート・ユーザは何も知ることができません。

オプション・バッファの値が変更されるのは,オプションが正常に折衝された結果による場合だけです。 特に,接続の解放では変更されません。 ヒストリの機構はなく,データグラム転送や接続の確立以前に存在していたバッファの状態はリストアできません。 トランスポート・ユーザは,(オプションが,最初に省略時の値に初期化されていた場合でも) 接続の確立またはデータグラム転送が内部のオプション・バッファを変更することがあることを知っておかなければなりません。

オプション値 T_UNSPEC

オプションの中には,常に完全に決まった値を持っているとは限らないものがあります。 たとえば,複数のプロトコル・クラスをサポートする ISO トランスポート・プロバイダは,接続の確立を開始するまでは,優先クラスを選択していない場合があります。 接続要求の時点で,トランスポート・プロバイダが,宛先のアドレス,サービス品質パラメータ,およびその他のローカルの情報からどの優先クラスを使用するかを決めます。 トランスポート・ユーザが,T_IDLE 状態で優先クラスのオプションの省略時の値を要求すると,T_UNSPEC の値を得ます。 この値は,トランスポート・プロバイダがまだ値を選択していないことを示します。 トランスポート・ユーザは,T_CLASS2 といった別の値を優先クラスの値として折衝することはできます。 この場合は,トランスポート・プロバイダは,クラス 2 を優先クラスとして接続要求を開始するよう強制されます。

XTI のインプリメントによっては,オプションの値に現在アクセスできないときに T_UNSPEC 値を返すこともあります。 これは,プロトコル・スタックがホストではなく別のコントローラ・カード上に位置するシステムで,T_UNBND 状態において起こることがあります。 オプションがサポートされていない場合に,このようなインプリメントが T_UNSPEC を返すことはありません。

T_UNSPEC は,これが有効な値であるオプションでは,入力でも使用できます。 適切な値の選択をプロバイダに任せることを指定するために使用します。 ISO のスループットのように,オプション値が内部で構造体を持つような複雑なオプションで特に役に立ちます。 この値を選択することで,トランスポート・ユーザはフィールドのいくつかを指定しないままにしておくことができます。 ユーザが T_UNSPEC を指定すると,トランスポート・プロバイダが適切な値を自由に選択します。 この結果は,省略時の値になることも,明示的にその他の値になることも,または T_UNSPEC になることもあります。

それぞれのオプションについて,折衝に対して T_UNSPEC が有効な値かどうかが指定されています。

引数 info

t_open および t_getinfo 関数は,引数 info でトランスポート・プロバイダの特性を表す値を返します。 info->options の値は,t_alloc 関数が使用します。 t_alloc 関数は,XTI 呼び出しで使用するオプション・バッファの記憶割当てにこの値を使用します。 この値は,すべての用途に十分な大きさです。

一般に,info->options には,特権オプションのサイズも含まれています。 特権オプションが,特権のないユーザに対して読み出し専用でない場合でも同じです。 あるいはインプリメントによっては,info->options で,特権ユーザと非特権ユーザに関して別の値を返すようにすることもあります。

info->etsduinfo->connect,および info->discon の値は,T_DATAXFER 状態に入ると通常小さくなります。 t_optmgmt 関数を呼び出してもこれらの値には影響ありません。 詳細は, t_optmgmt(3) を参照してください。

移植性の問題

XTI プログラムを作成するアプリケーション・プログラマは,次の各点にわたる移植性に関する問題に注意してください。

オプションは,本質的に特定のプロトコルまたはプロトコル・プロファイルと結び付いています。 したがって,オプションを明示的に使用すると,複数のプロトコル・プロファイルにわたる移植性が低下します。

異なるベンダは,異なるオプションをサポートするトランスポート・プロバイダを提供します。 これは,インプリメントや製品のポリシがそれぞれ違うためです。 t_optmgmt(3) リファレンス・ページおよびプロトコル固有のリファレンス・ページにあるオプションのリストは最大限のものですが,必ずしも一般的なインプリメントの慣例に従っているとは限りません。 各ベンダは,それぞれの要件に合ったサブセットをインプリメントしています。 したがって,オプションを不用意に使用すると,それぞれのシステムのプラットフォーム間の移植性が低くなります。

XTI でアクセス可能なプロトコル・プロファイルのどのインプリメントのオプションも,省略時の設定ではすべて使用できます。 アプリケーションは,したがって,オプションをまったく気にしないで作成することもできます。

アプリケーション・プログラムが,XTI 関数で取り出したオプションを処理する場合は,未知のオプションを破棄するようにしてください。 これにより,それぞれのシステム・プラットフォームからの依存性,およびサポートするオプションが増える予定の将来の XTI リリースからの依存性を軽減できます。

3.6.7.2    XPG3 でのプロトコル・オプションの折衝

Tru64 UNIX による XTI の XPG3 のインプリメントは,オプションの関数 t_optmgmt を提供します。 この関数はトランスポート・プロバイダとの間でプロトコル・オプションの取り出し,確認,および折衝を行います。 終端を t_open で作成してアドレスをバインドすると,トランスポート・プロバイダとの間でオプションを確認または折衝できます。

注意

他のトランスポート・プロバイダには t_optmgmt 関数をサポートしているものもありますが,このオペレーティング・システムで提供されている TCP トランスポート・プロバイダはサポートしていません。 オプション管理については,トランスポート・プロバイダのドキュメントを参照してください。

関数の構文,パラメータ,エラーについては, t_optmgmt(3) を参照してください。 XTI のエラーの概要の説明は,3.7 節 を参照してください。

t_optmgmt 関数は,正常終了すると 0 を返します。 それ以外の場合は -1 を返し,t_errno に,3.7 節に示されている値の 1 つが設定されます (マルチスレッド・アプリケーションの場合,t_errno はスレッド固有です)。

3.7    XTI エラー

XTI は,ライブラリ・エラーおよびシステム・エラーを返します。 XTI 関数はエラーを検出すると --1 を返し,次のいずれかの処理を行うことができます。

<xti.h> ヘッダ・ファイルは,次のように t_errno 変数をマクロとして定義します。

#define t_errno (*(_terrno()))
 

エラーについての詳細は,それぞれの XTI リファレンス・ページを参照してください。

3.8    XTI トランスポート・プロバイダの構成

XTI トランスポート・プロバイダを構成するためには,xtiso カーネル構成オプションを使用します。 xtiso オプションは,インストレーション時にシステムに構成することも,また,doconfig コマンドを使用してシステムに追加することもできます。 詳細は『インストレーション・ガイド』を参照してください。

doconfig コマンドは,次のいずれかの方法で使用できます。

オプションを指定せずに doconfig コマンドを使用する場合は,次の手順に従ってください。

  1. スーパユーザ・プロンプト (#) から /usr/sbin/doconfig コマンドを入力する。

  2. カーネル構成ファイルの名前を入力する。

    ファイル名は大文字のシステム名であり,通常は省略時の設定として,大カッコ ([]) の中に表示されます。 次に例を示します。

    Enter a name for the kernel configuration file. [HOST1]: [RETURN]
     
    

  3. システム構成ファイルを置き換えるかどうかを尋ねられたら,y を入力する。

    次に例を示します。

    A configuration file with the name 'HOST1' already exists.
    Do you want to replace it? (y/n) [n]: y
     
    Saving /sys/conf/HOST1 as /sys/conf/HOST1.bck
     
    *** KERNEL CONFIGURATION AND BUILD PROCEDURE ***
     
    

  4. カーネル・オプション選択メニューから X/Open Transport Interface (XTISO, TIMOD, TIRDWR) を選択する。 システムが確認を求めるので,選択の確認を行う。

    次に例を示します。

    *** KERNEL OPTION SELECTION ***
     
        Selection   Kernel Option
    --------------------------------------------------------------
            1       System V Devices
            2       NTP V3 Kernel Phase Lock Loop (NTP_TIME)
            3       Kernel Breakpoint Debugger (KDEBUG)
            4       Packetfilter driver (PACKETFILTER)
            5       Point-to-Point Protocol (PPP)
            6       STREAMS pckt module (PCKT)
            7       X/Open Transport Interface (XTISO, TIMOD, TIRDWR)
            8       File on File File System (FFM)
            9       ISO 9660 Compact Disc File System (CDFS)
            10      Audit Subsystem
            11      ACL Subsystem
            12      Logical Storage Manager (LSM)
            13      Advanced File System (ADVFS)
            14      All of the above
            15      None of the above
            16      Help
    --------------------------------------------------------------
     
    Enter the selection number for each kernel option you want.
    For example, 1 3 [15]: 7
     
    Enter the selection number for each kernel option you want.
    For example, 1 3 : 7
     
    You selected the following kernel options:
     
            X/Open Transport Interface (XTISO, TIMOD, TIRDWR)
    Is that correct? (y/n) [y]: y
     
    Configuration file complete.
     
    

  5. 構成ファイルを編集するかどうかを尋ねられるので,n を入力する。

    doconfig コマンドは,デバイス特殊ファイルを作成し,作成したファイルのログをいれる場所を示して,新しいカーネルを構築します。 新しいカーネルが構築されたら,カーネルを doconfig が置いたディレクトリからルート・ディレクトリ (/) に移動して,システムをリブートしなければなりません。

    リブートすると,strsetup -i コマンドが自動的に実行され,新しい STREAMS モジュールに対してデバイス特殊ファイルが作成されます。

  6. strsetup -c コマンドを実行して,デバイスが正しく構成されたことを確認する。

    strsetup -c コマンドからの出力例を次に示します。

    # /usr/sbin/strsetup -c
     
    

    STREAMS Configuration Information...Fri Nov  3 14:23:36 1995
     
               Name       Type   Major  Module ID
               ----       ----   -----  ---------
              clone                 32          0
                dlb     device      52       5010
              kinfo     device      53       5020
                log     device      54         44
               nuls     device      55       5001
               echo     device      56       5000
                sad     device      57         45
               pipe     device      58       5304
           xtisoUDP     device      59       5010
           xtisoTCP     device      60       5010
          xtisoUDP+     device      61       5010
          xtisoTCP+     device      62       5010
                ptm     device      63       7609
                pts     device       6       7608
                bba     device      64      24880
                lat     device       5          5
              pppif     module               6002
           pppasync     module               6000
            pppcomp     module               6001
           bufcall     module                  0
               null     module               5002
               pass     module               5003
               errm     module               5003
               ptem     module               5003
              spass     module               5007
             rspass     module               5008
            pipemod     module               5303
              timod     module               5006
             tirdwr     module                  0
              ldtty     module               7701
     
            Configured devices = 15, modules = 14
     
    

doconfig -c コマンドを使用して XTISO オプションをカーネル構成ファイルに追加する場合は,次の手順に従ってください。

  1. スーパユーザ・プロンプト (#) から doconfig -c HOSTNAME コマンドを入力する。

    HOSTNAME は大文字のシステム名です。 たとえば,host1 というシステムの場合には,次のように入力します。

    # doconfig -c HOST1
     
    

  2. XTISO をカーネル構成ファイルのオプション・セクションに追加する。 カーネル構成ファイルを編集するかどうかを尋ねられるので,y を入力する。

    doconfig コマンドを実行すると,ed エディタを使用して構成ファイルを編集できます。 ed エディタの使用方法については, ed(1) を参照してください。

    次の例は,ed 編集セッションで,host1 用のカーネル構成ファイルに XTISO オプションを追加する方法を示しています。 新しい行を追加する行番号は,カーネル構成ファイルによって異なる場合があります。

    *** KERNEL CONFIGURATION AND BUILD PROCEDURE ***
     
    Saving /sys/conf/HOST1 as /sys/conf/HOST1.bck
     
    Do you want to edit the configuration file? (y/n) [n]: y
     
    Using ed to edit the configuration file.  Press return when ready,
    or type 'quit' to skip the editing session: 
    2153
     
    48a
    options         XTISO
    .
    1,$w
    2185
    q
     
    *** PERFORMING KERNEL BUILD ***
     
    

  3. 新しいカーネルが構成されたら,doconfig が置いたディレクトリからルート・ディレクトリ (/) へそのカーネルを移動して,システムをリブートする。

    リブートすると,strsetup -i コマンドが自動的に実行され,新しい STREAMS モジュールに対してデバイス特殊ファイルが作成されます。

  4. strsetup -c コマンドを実行して,デバイスが正しく構成されていることを確認する。

    次は,strsetup -c コマンドからの出力例です。

    # /usr/sbin/strsetup -c
     
    

    STREAMS Configuration Information...Fri Nov  3 14:23:36 1995
     
               Name       Type   Major  Module ID
               ----       ----   -----  ---------
              clone                 32          0
                dlb     device      52       5010
              kinfo     device      53       5020
                log     device      54         44
               nuls     device      55       5001
               echo     device      56       5000
                sad     device      57         45
               pipe     device      58       5304
           xtisoUDP     device      59       5010
           xtisoTCP     device      60       5010
          xtisoUDP+     device      61       5010
          xtisoTCP+     device      62       5010
                ptm     device      63       7609
                pts     device       6       7608
                bba     device      64      24880
                lat     device       5          5
              pppif     module               6002
           pppasync     module               6000
            pppcomp     module               6001
           bufcall     module                  0
               null     module               5002
               pass     module               5003
               errm     module               5003
               ptem     module               5003
              spass     module               5007
             rspass     module               5008
            pipemod     module               5303
              timod     module               5006
             tirdwr     module                  0
              ldtty     module               7701
     
            Configured devices = 15, modules = 14
     
    

    カーネルの再構成および doconfig コマンドについての詳細は,『システム管理ガイド』を参照してください。