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)
この章では,次の事項について説明します。
XTI の概要
XTI の機能
XTI の使用方法
アプリケーションの XTI へのポート方法
XPG3,XNS4.0,XNS5.0 の相違点
XTI エラーおよびエラー・メッセージ
トランポート・プロバイダを組み込んだ構成の方法
図 3-1は,XTI,および XTI とオペレーティング・システムのインターネット・プロトコル群のインプリメンテーションの関係を強調表示しています。
また,XTI とインターネット・プロトコル群が,ネットワーク・プログラミング環境の他の部分に対し,どのように位置付けられているかも示しています。
図 3-1: X/Open トランスポート・インタフェース
XTI には,次の各エンティティ間のやりとりが含まれています。
トランスポート・プロバイダ
トランスポート・プロバイダは,トランスポート層サービスを提供する, TCP や UDP などのトランスポート・プロトコルです。
トランスポート・ユーザ
トランスポート・ユーザは,別のプログラムとの間でデータを送受信するときに,トランスポート・プロバイダのサービスを必要とするアプリケーション・プログラムです。 トランスポート・ユーザは,トランスポート終端によって識別される通信パスを通して,トランスポート・プロバイダと通信します。
トランスポート終端
アプリケーションが
t_open
ライブラリ・コールを発行すると,トランスポート終端は作成されます。
トランスポート・ユーザからトランスポート・プロバイダへの要求はすべて,そのプロバイダに関連付けられた終端を経由します。
トランスポート・ユーザは,トランスポート終端をトランスポート・アドレスにバインドすることによって,トランスポート終端をアクティブにします。 一度,トランスポート終端がアクティブになると,トランスポート・ユーザは,この終端を通してデータを送信できます。 トランスポート・プロバイダは,該当する対等ユーザ,または他のデスティネーションにデータの経路を指定します。
TCP などのコネクション指向型トランスポート・サービスを使用する場合には,トランスポート・ユーザはデータを送信する前に,アクティブな終端を指定して,t_connect
関数を呼び出すことにより,自分自身と対等トランスポート・ユーザの間に接続を確立しなければなりません。
トランスポート接続において,接続を開始するトランスポート・ユーザは,
アクティブ・ユーザ,つまりクライアントです。
一方,接続要求に応答する対等トランスポート・ユーザは,パッシブ・ユーザ,つまりサーバです。
図 3-2
は,トランスポート・プロバイダ,トランスポート・ユーザ,およびトランスポート終端の関係を示しています。
図 3-2: トランスポート終端
XTI には,ライブラリ・コール,ヘッダ・ファイル,および,XTI プロセスの動作と対話処理の方法を記述する規則と制限があります。
この節では,ライブラリ・コールおよびヘッダ・ファイルについて説明するとともに,通信プロセス間のやりとりを制御する規則についても記述します。
3.2.1 サービス・モードと実行モード
トランスポート・ユーザは,さまざまなサービス・モードと実行モードを使用して,トランスポート・プロバイダとの間でデータを交換する方法を決定します。
次の 2 つの項で,XTI で利用できるサービス・モードと実行モードについて説明します。
3.2.1.1 コネクション指向型サービスおよびコネクションレス型サービス
XTI において,終端は,次のサービス・モードのうちの 1 つをサポートできます。
回線指向型サービス。 確立された接続を通して,信頼性が高い方法でデータの順次転送を行います。
コネクション指向型トランスポートは,時間が長く,順序に依存し,信頼性が高いストリーム指向型のやりとりを必要とするアプリケーションに適しています。 コネクション指向型トランスポートを使用すると, トランスポート・ユーザおよびプロバイダは,データ転送を制御するパラメータおよびオプションを折衝できます。 さらに,接続により両者は識別可能になるので,トランスポート・ユーザは,データ転送中のアドレスの伝送と解析によるオーバヘッドを回避できます。 また,連続するデータ・ユニットを論理的に関連付けるコンテキストも提供されます。
メッセージ指向型サービス。 データを自己完結型ユニットまたはデータグラムとして転送します。 データ間の論理的連続はありません。
コネクションレス型トランスポートは,次のような特徴を持つアプリケーションに最適です。
短時間の要求と応答のやりとり
複数の終端に対する接続の動的な再構成
データの順次引き渡しの保証が不必要
各データ・ユニットは自己完結型であり,直前または後続のデータ・ユニットとの関係がないので,トランスポート・プロバイダは独立して経路を指定できます。
実行モードにより,トランスポート・ユーザは,関数の完了およびイベントの受信を処理できます。 イベントとは,トランスポート・ユーザにとって意味のある出現事象または偶発事象です。 XTI は,次の 2 つの実行モードをサポートします。
トランスポート・プリミティブが完了してから,制御がトランスポート・ユーザに戻ります。 ブロッキング・モードともいいます。
同期モードは,関数の完了までの待機,または単一のトランスポート接続だけの維持を必要とするアプリケーションに適しています。
同期モードでは,関数が完了するのを待つ間,トランスポート・ユーザは他のタスクを実行することはできません。
たとえば,トランスポート・ユーザが同期モードで
t_rcv
関数を発行した場合,t_rcv
はデータを受信してから,制御をトランスポート・ユーザに戻します。
同期モードの使用中でも,イベント通知を受け取ることができます。 これは,通常ではトランスポート・ユーザは受け取らないものです。 このような非同期イベントは,特殊エラーの TLOOK を通してユーザに返されます。
関数の実行中に非同期イベントが発生した場合,その関数は TLOOK エラーを返します。
この場合,トランスポート・ユーザは,t_look
関数を発行してイベントを検出できます。
トランスポート・プリミティブが完了する前に,制御をトランスポート・ユーザに戻します。 非ブロッキング・モードともいいます。
非同期モードは,関数が完了してから他のタスクを実行するまでの間に,長い遅延があるアプリケーションに適しています。
また,このモードは,複数の接続を同時に処理するアプリケーションにも適しています。
非同期モードでは,特定のネットワーキング関数が完了するのを待っている間に有用な作業を実行できるので,多くのアプリケーションは,非同期モードでネットワーキング関数を処理します。
たとえば,トランスポート・ユーザが,非同期モードで
t_rcv
関数呼び出しを発行すると,この関数は,データを入手できなければ,制御をただちにユーザに戻します。
ユーザは,データが到着するまで,定期的にデータをポールします。
省略時の値では,着信イベントを処理するすべての関数は同期モードで動作し,そのタスクが完了するまでブロックします。
非同期モードを選択する場合には,トランスポート・ユーザは,終端の作成時,または
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
です。
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_COTS - コネクション指向型トランスポート・サービス (たとえば,OSI トランスポート)
T_CLTS - コネクションレス型トランスポート・サービス (たとえば,UDP)
T_COTS_ORD - 正常解放機能がインプリメントされているコネクション指向型トランスポート・サービス (たとえば,TCP)
これらのサービス・モードは,ユーザが
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 イベント
着信イベントは,トランスポート・プロバイダからデータまたはイベントを検出する 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 |
この項では,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 | -- |
一般に,複数のプロセスを使用する場合には,注意深くプロセスの同期をとって,インタフェースの状態違反を避ける必要があります。
トランスポート・プロバイダは,1 つのトランスポート終端のすべてのトランスポート・ユーザを単一ユーザとして処理しますが,次の状況が可能になります。
1 つのプロセスで,複数のトランスポート終端を同時に作成できる。
複数のプロセスが,単一の終端を同時に共用できる。
単一プロセスが同期実行モードにおいて複数の終端を管理する場合,そのプロセスは,各終端におけるアクションを並列にではなく直列に管理しなければなりません。 またオプションで,サーバを作成して,複数の終端を一度に管理することができます。 たとえば,プロセスは,1 つの終端で着信接続指示をリッスンし,別の終端で接続を受け入れることができるので,着信接続はブロックされません。 このため,アプリケーションは,子プロセスをフォークして,新しい接続からの要求に対してサービスを行うことができます。
複数のプロセスが単一の終端を共用する場合には,アクションを調整して,インタフェースの状態違反を避けなければなりません。
これを行うため,各プロセスは,他の関数を呼び出す前に,t_sync
関数を呼び出すことによって,トランスポート・プロバイダの現在の状態を検出します。
すべてのプロセスをこのように調整しておかなければ,別のプロセスまたは着信イベントが,インタフェースの状態を変更する可能性があります。
同様に,複数の終端で同じプロトコル・アドレスを共用できますが,着信接続をリッスンできるのは 1 つの終端だけです。
プロトコル・アドレスを共用している他の終端は,競合することなくデータ転送状態や接続確立状態になることができます。
つまり,1 つのアドレスはサーバを 1 つしか持てませんが,複数の終端は同じアドレスを同時に呼び出すことができます。
3.3 XTI の使用
この節では,まず,関数の呼び出し順序,状態管理,および XTI のオプションの使用についてのガイドラインを示します。
次に,XTI に合わせたコネクション指向型プログラムおよびコネクションレス型プログラムの作成に必要な手順について説明します。
3.3.1 関数の呼び出し順序のガイドライン
図 3-3
は,非ブロッキング・モードのコネクション指向型トランスポート・サービスを使用して通信しているアクティブ・ユーザおよびパッシブ・ユーザについて,一般的な関数の呼び出し順序および状態遷移を示しています。
図中の実線は,アクティブ・ユーザの状態遷移を示し,破線は,パッシブ・ユーザの状態遷移を示しています。
各線は,関数の呼び出しを表し,各楕円は,結果の状態を表します。
この例には,オプションの正常解放機能は含まれていません。
図 3-3: コネクション指向型トランスポート・サービスの状態遷移
図 3-4
は,コネクションレス型トランスポート・サービスを使用して通信している2 人のユーザについて,一般的な関数の呼び出し順序および状態遷移を示しています。
図中の各線は,関数の呼び出しを表し,各楕円は,結果の状態を表します。
両方のユーザは,実線で表されています。
図 3-4: コネクションレス型トランスポート・サービスの状態遷移
すべてのトランスポート・プロバイダは,状態に関して次のアクションを行わなければなりません。
トランスポート・ユーザから見たインタフェースの状態を記録する。
インタフェースが状態の範囲外になるような要求や応答をリジェクトして,エラーを返す。
この場合,状態は変更されません。 たとえば,ユーザが関数を使用してデータを引き渡したとき,インタフェースが T_DATAXFER 状態でない場合,トランスポート・プロバイダは,データの受け入れまたは転送を行いません。
未初期化状態 (T_UNINIT) には,次の 2 つの意味があります。
トランスポート終端の最初の状態
トランスポート・プロバイダがトランスポート終端をアクティブと見なすためには,その前に,トランスポート・ユーザがその終端を初期化してバインドしておかなければなりません。
トランスポート終端の最後の状態
トランスポート・プロバイダは,この状態の終端を未使用と見なさなければなりません。
トランスポート・ユーザが
t_close
関数を発行すると,トランスポート・プロバイダはクローズされ,トランスポート・ライブラリに関連するリソースは,別の終端が使用できるように解放されます。
この項では,コネクション・モードのアプリケーションの作成に必要な手順について説明します。
終端の初期化
接続の確立
データの転送
接続の解放
終端の初期化解除
終端をオープンする。
アドレスを終端にバインドする。
プロトコル・オプションを折衝する。
ここでは,コネクション指向型サービス用に終端を初期化する手順について説明します。
この手順は,コネクションレス型サービスの場合も同じです。
トランスポート終端のオープン
コネクション指向型とコネクションレス型のどちらのアプリケーションも,t_open
関数を使用して,トランスポート終端をオープンしなければなりません。
関数の構文,パラメータ,エラーについては,
t_open
(3)
この XTI のインプリメンテーションは,デバイス・スぺシャル・ファイルへのパス名を使用して,トランスポート・プロバイダを識別します。
これは AT&T の TLI と同じ方法です。
TCP または UDP のトランスポート・プロバイダとデータのやりとりをするデバイス・スぺシャル・ファイルは,/dev/streams/xtiso
ディレクトリにあります。
異なるトランスポート・プロバイダを使用する場合には,そのマニュアルを参照して,適切なデバイス名を指定してください。
注意
XTI/TLI 以外の方式での特殊デバイスの使用 (たとえば,
open
,read
,write
などの直接呼び出しなど) は違法であり,定義されていない結果が生じます。
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)
トランスポート・プロバイダがアドレスを生成するかどうかを判断するには,t_bind
関数でアドレスを指定しません (req
に空ポインタを設定します)。
トランスポート・プロバイダがアドレスを生成する場合,この関数は,割り当てられたアドレスを
ret
フィールドに返します。
トランスポート・プロバイダがアドレスを生成しない場合には,TNOADDR エラーを返します。
接続指示のリッスンに使用する終端上で接続を受け入れる場合,バインドされたアドレスは,接続中はビジーになります。 最初のリッスンに使用した終端が,データをアクティブに送信しているか,または T_IDLE 状態のときは,リッスン用に他の終端を同じアドレスにバインドすることはできません。
TCP または UDP のいずれかが基礎となるトランスポート・プロバイダの場合には,4.2.3.2 項で説明する
gethostbyname
ルーチンを使用して,ホスト情報を取得することができます。
gethostbyname
ルーチン以外の方法を使用してホスト情報を検索する場合には,次の点に考慮してください。
アプリケーションは,トランスポート・プロバイダが指定するフォーマットでソケット・アドレスを XTI 関数に引き渡さなければならない。
TCP/IP 上の XTI の場合には,指定のアドレス・フォーマットは
sockaddr_in
構造体です。
アプリケーションは,XTI 関数にトランスポート・プロバイダ識別子も引き渡さなければならない。
オペレーティング・システムは,この識別子がトランスポート・プロバイダ用のデバイス特殊ファイルへのパス名のフォーマットになっていると考えます。
XPG3,XNS4.0 および XNS5.0 では,オプション管理のインプリメント方法が異なります。
XPG3 では,オプション管理は
t_optmgmt
関数だけが取り扱えます。
XNS4.0 および XNS5.0 では,いくつかの関数が引数
opt
を持ち,この引数を使用してトランスポート・ユーザとトランスポート・プロバイダとの間でオプションをやりとりできます。
詳細は,3.6.7 項を参照してください。
3.3.3.3 接続の確立
パッシブ・ユーザ,つまりサーバが接続要求をリッスンする。
アクティブ・ユーザ,つまりクライアントが接続を開始する。
パッシブ・ユーザ,つまりサーバが,接続要求を受け入れて,接続指示が受信される。
これらの手順について,次の各項で説明します。
接続指示のリッスン
パッシブ・ユーザは,t_listen
関数を発行して,キューに入っている接続指示を検索します。
t_listen
関数が,キューの先頭で接続指示を見つけた場合は,接続指示に関する詳細な情報,およびその指示を識別するローカル・シーケンス番号を返します。
キューにいれることが可能な未処理の接続指示の数は,t_bind
関数の発行時にトランスポート・プロバイダが受け入れた,qlen
パラメータの値によって制限されます。
省略時には,t_listen
関数は同期モードで実行され,接続指示が到着するのを待ってから制御をユーザに戻します。
t_open
関数または
fcntl
関数の O_NONBLOCK フラグを設定して非同期モードを指定している場合には,t_listen
関数は,接続指示があるかどうかをチェックして,接続指示がなければ TNODATA エラーを返します。
関数の構文,パラメータ,エラーについては,
t_listen
(3)接続の開始
接続は,同期または非同期のいずれかのモードで開始されます。
同期モードでは,アクティブ・ユーザが
t_connect
関数を発行すると,この呼び出しは,パッシブ・ユーザの応答を待ってから,アクティブ・ユーザに制御を戻します。
非同期モードでは,t_connect
は接続を開始しますが,接続に対する応答が到着する前に,アクティブ・ユーザに制御を戻します。
このとき,アクティブ・ユーザは,t_rcvconnect
関数を発行して,接続要求の状態を判別することができます。
パッシブ・ユーザが要求を受け入れた場合,t_rcvconnect
関数は正常に戻り,接続確立フェーズが完了します。
応答をまだ受信していない場合は,TNODATA エラーを返します。
アクティブ・ユーザは,後で
t_rcvconnect
関数を再度発行する必要があります。
関数の構文,パラメータ,エラーについては,
t_connect
(3)
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)3.3.3.4 データの転送
2 つの終端間に一度接続が確立されると,アクティブ・ユーザとパッシブ・ユーザは,その接続を通して全二重方式でデータを転送できます。
コネクション指向型サービスのこのフェーズは,データ転送フェーズといいます。
これ以降の項では,データ転送フェーズでデータの送受信を行う方法について説明します。
データの送信
トランスポート・ユーザは,t_snd
関数を使用して,通常データまた優先データのいずれかを接続を通して送信できます。
通常では,トランスポート・プロバイダがすべてのデータをただちに受け入れることができる場合,t_snd
は正常に送信して,受け入れられたバイト数を返します。
データがただちに受け入れられない場合,t_snd
の結果は,同期モードまたは非同期モードのどちらで実行していたかによって異なります。
省略時には,t_snd
関数は同期モードで実行され,フロー制御条件によってトランスポート・プロバイダがデータを受け入れることができない場合は待ちます。
この関数は,次の条件の 1 つが真になるまでブロックします。
フロー制御条件がクリアであり,トランスポート・プロバイダは新しいデータ・ユニットを受け入れることができる。
この場合,t_snd
関数は正常に戻ります。
切断指示が受信された。
t_snd
関数は,TLOOK エラーを指定して戻ります。
t_look
関数を呼び出すと,T_DISCONNECT イベントが返されます。
転送中のデータはすべて失われます。
内部問題が発生した。
t_snd
関数は,TSYSERR エラーを指定して戻ります。
転送中のデータはすべて失われます。
終端の作成時に O_NONBLOCK フラグがセットされていれば,t_snd
は非同期モードで実行され,フロー制御制限がある場合はすぐに失敗します。
場合によっては,データの一部だけがトランスポート・プロバイダに受け入れられ,t_snd
は,送信要求したバイト数より少ない値を返すことがあります。
このときには,ユーザは次のうちの 1 つを行います。
残りのデータを指定して,t_snd
をもう一度発行する。
t_look
関数を使用して,フロー制御制限が解除されたかどうかをチェックしてから,データを再送信する。
t_look
関数については,この章の最後で説明します。
関数の構文,パラメータ,エラーについては,
t_snd
(3)データの受信
トランスポート・ユーザは,t_rcv
関数を使用して,通常データまたは優先データのいずれかを接続を通して受信できます。
通常では,データが受信できる場合,t_rcv
はデータを返します。
接続が切断されている場合は,t_rcv
は,ただちにエラーを指定して戻ります。
データは受信できないが,接続が存在している場合には,t_rcv
の動作は,実行モードに応じて異なります。
省略時には,t_rcv
は同期モードで実行され次のうちの 1 つが到着するのを待つ。
データ
切断指示
シグナル
t_rcv
を発行して待つ代わりに,t_look
関数を発行して,T_DATA または T_EXDATA イベントをチェックすることができます。
O_NONBLOCK フラグをセットした場合,t_rcv
は非同期モードで実行される。
<PARA>データが受信できない場合は,TNODATA エラーを返して失敗します。
その場合には,t_rcv
関数または
t_look
関数を発行することによって,データのポールを継続する必要があります。
関数の構文,パラメータ,エラーについては,
t_rcv
(3)3.3.3.5 接続の解放
XTI では,2 つの接続の解放方法をサポートしています。
つまり,打ち切りによる解放と正常解放です。
すべてのトランスポート・プロバイダは,打ち切りによる解放をサポートします。
正常解放は,XTI ではオプション機能であるため,トランスポート・プロバイダの中には,これを提供しないものがあります。
たとえば,OSI トランスポートは打ち切りによる解放だけをサポートしますが,TCP は打ち切りによる解放と,オプションとして正常解放をサポートします。
打ち切りによる解放
打ち切りによる解放は,トランスポート・ユーザまたはトランスポート・プロバイダから要求でき,接続をただちに打ち切ります。 打ち切りによる解放は折衝できないため,一度打ち切りによる解放を要求すると,ユーザ・データが引き渡される保証はありません。
トランスポート・ユーザは,接続確立フェーズまたはデータ転送フェーズのいずれかで,打ち切りによる解放を要求できます。 接続確立フェーズでは,トランスポート・ユーザは,打ち切りによる解放を使用して接続要求をリジェクトすることができます。 データ転送フェーズでは,どちらかのユーザがいつでも接続を解放できます。 トランスポート・プロバイダが打ち切りによる解放を要求すると,接続がもう存在しないことが両方のユーザに通知されます。
関数の構文,パラメータ,エラーについては,
t_snddis
(3)
トランスポート・ユーザは,T_DISCONNECT イベントを通じて,打ち切りによる解放について通知されます。
プログラムが T_DISCONNECT イベントを受信した場合には,t_rcvdis
関数を発行して,切断に関する情報を検索し,T_DISCONNECT イベントを消費しなければなりません。
関数の構文,パラメータ,エラーについては,
t_rcvdis
(3)正常解放
正常解放を使用すると,データを損失することなく接続を解放することができます。
正常解放はすべてのトランスポート・プロバイダが提供している機能ではありません。
トランスポート・プロバイダが,t_open
関数または
t_getinfo
関数で T_COTS_ORD のサービス・タイプを返す場合には,正常解放がサポートされます。
トランスポート・ユーザは,データ転送フェーズで正常解放を要求できます。
正常解放の一般的な手順は次のとおりです。
パッシブ・ユーザは,アクティブ・ユーザからの正常解放要求を示す T_ORDREL イベントを受信すると,t_rcvrel
関数を発行して,要求を受信したことを示し,T_ORDREL イベントを消費する。
切断の準備ができたら,パッシブ・ユーザは,t_sndrel
関数を発行する。
アクティブ・ユーザは,t_rcvrel
関数を発行して応答する。
トランスポート・ユーザは
t_sndrel
関数を発行した後に,その接続を通してそれ以上データを送信することはできません。
ただし,正常解放指示 (T_ORDREL イベント) を受信するまで,データの受信を継続することはできます。
関数の構文,パラメータ,エラーについては,
t_sndrel
(3)
正常解放指示の受信に肯定応答するには,t_rcvrel
関数を発行します。
トランスポート・ユーザは,正常解放指示 (T_ORDREL) を受信した後に,それ以上データを受信できません。
トランスポート・ユーザがデータを受信しようとすると,その関数は無期限にブロックします。
ただし,トランスポート・ユーザは,t_sndrel
関数を発行するまで,データの送信を継続することができます。
関数の構文,パラメータ,エラーについては,
t_rcvrel
(3)3.3.3.6 終端の初期化解除
終端の使用が終了したら,t_unbind
および
t_close
関数を使用して,終端をアンバインドし,クローズすることにより,その終端の初期化を解除します。
ここでは,コネクション指向型サービスを使用して終端の初期化を解除する手順について説明しますが,コネクションレス型サービスの場合も手順は同じです。
終端をアンバインドしたら,終端は使用不能になり,トランスポート・プロバイダはそれ以上要求を受け入れません。
関数の構文,パラメータ,エラーについては,
t_unbind
(3)
終端をクローズすることによって,トランスポート・プロバイダにその終端の使用が終了したことを通知し,その終端に関連するライブラリ・リソースをすべて解放します。
終端が T_UNBND 状態の場合は,t_close
を呼び出さなければなりません。
ただし,この関数は状態情報をチェックしないので,どの状態からでも呼び出して,トランスポート終端をクローズすることができます。
T_UNBND 状態ではない終端をクローズすると,その終端に関連するライブラリ・リソースが自動的に解放されて,その終端に関連するファイルがクローズされます。 そのプロセスまたはその終端を参照するプロセスに他の記述子がない場合,トランスポート接続は切断されます。
関数の構文,パラメータ,エラーについては,
t_close
(3)3.3.4 コネクションレス型アプリケーションの作成
この項では,コネクションレス・モードのアプリケーションを作成するために必要な手順について説明します。
終端の初期化
データの転送
終端の初期化解除
コネクションレス型アプリケーションのために終端を初期化する手順は,コネクション指向型アプリケーションの場合と同じです。
コネクションレス型アプリケーションのために終端を初期化する方法についての詳細は,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)データの受信
t_rcvudata
関数を呼び出しデータが受信できる場合,t_rcvudata
は,受信オクテット数を示して,すぐに戻ります。
データを受信できない場合の
t_rcvudata
の動作は,実行モードに応じて次のように異なります。
同期モード
t_rcvudata
関数は,データグラム,エラー,またはシグナルのいずれか 1 つを受信するまでブロックします。
t_rcvudata
が戻るのを待つ代わりに,t_look
関数を定期的に発行して T_GODATA イベントを確かめた後,t_rcvudata
を発行してデータを受信することもできます。
非同期モード
t_rcvudata
は,エラーを指定してただちに戻ります。
この場合,ユーザはこの関数を定期的に再試行するか,または
t_look
関数を使用して着信データをポールしなければなりません。
関数の構文,パラメータ,エラーについては,
t_rcvudata
(3)エラー情報の検索
t_look
を発行して T_UDERR イベントを受信した場合は,以前に送信したデータでエラーが生じています。
エラーをクリアして T_UDERR イベントを消費するには,t_rcvuderr
関数を発行する必要があります。
この関数はまた,エラーを生じたデータとエラーの性質に関する情報も返します (ただしこれは指定した場合のみです)。
データ・ユニットに関するエラー情報を受信するには,t_rcvuderr
関数を発行します。
関数の構文,パラメータ,エラーについては,
t_rcvuderr
(3)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
を発行して現在の状態を検出し,その状態に対して適切なアクションをとることができます。
基礎となるトランスポート・プロバイダからの情報とトランスポート・ライブラリによって管理されるデータ構造体の同期をとる。
共同して動作している 2 つのプロセスが,トランスポート・プロバイダとのやりとりの同期をとることを許可する。
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 へのポート
XTI に合わせたプログラムを作成するときのガイドライン
XTI と TLI の互換性に関する情報
ソケット・アプリケーションから XTI 使用アプリケーションへの書き換えに関する情報
XTI は,使用する特定のトランスポート・プロトコルに依存しないインタフェースを提供するために設計されました。 基礎となるトランスポート・プロバイダがサポートする XTI の関数および機能の任意のサブセットに応じて,動作を変更できるアプリケーションを作成できます。
プロバイダは,XTI の機能をすべて備えていなくてもかまいません。 したがって,アプリケーション・プログラマは,次のガイドラインに従って,XTI アプリケーションを作成する必要があります。
XTI の必須機能の関数だけを使用する。
すべてのトランスポート・プロバイダで備えていない機能をアプリケーションで使用すると,トランスポート・プロバイダや XTI のインプリメンテーションによっては,その機能を使用できない場合があります。
たとえば,正常解放機能 (t_sndrel
および
t_rcvrel
関数) は,すべてのコネクション指向型のトランスポート・プロトコルがサポートしているとは限りません。
特に,ISO プロトコルはサポートしていません。
複数のプロトコルを使用する環境でアプリケーションを実行する場合には,正常解放機能は使用しないでください。
一般的にサポートされていない機能も使用する場合には,各トランスポート・プロバイダがサポートする XTI 関数のサブセットに応じて動作を変更するように,アプリケーションを作成してください。
論理データ境界が接続を通しても保存されていると想定しない。
TCP など,トランスポート・プロバイダによっては,TSDU の概念をサポートしていないものがあるります。
そのためそのトランスポート・プロバイダで関数
t_snd
,t_sndudata
,t_rcv
,および
t_rcvudata
を使用する場合,T_MORE フラグは無視されます。
t_open
関数および
t_getinfo
関数によって返される,プロトコル固有のサービス制限を超えないようにする。
アプリケーションで,データを転送する前にこれらの制限を検索し,通信プロセス全体を通してこれらの制限を厳守していることを確認してください。
プロトコル固有のオプションに依存しない。
t_optmgmt
関数を使用すると,アプリケーションはトランスポート・プロバイダから省略時のプロトコル・オプションにアクセスし,これらのオプションを引数として接続確立関数に引き渡すことができます。
ただしアプリケーションでそのオプションを調べたり,特定のオプションに依存したりしないようにしてください。
t_rcvdis
関数に関連する理由コードや
t_rcvuderr
関数に関連するエラー・コードを解釈しない。
これらのコードは基礎となるプロトコルに依存しているので,プロトコル独立を実現するためには,アプリケーションでこれらのコードを解釈しないようにしてください。
t_open
関数によって返されるファイル記述子に対しては,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 プログラムを再コンパイルすることができます。 次の手順に従ってください。
TLI ヘッダ・ファイルがソース・コードにインクルードされていることを確認する。
#include <tli/tiuser.h>
次のコマンド構文を使用して,アプリケーションを再コンパイルする。
cc -o
name name.c
-ltli
TLI アプリケーションを XTI アプリケーションに変更する場合には,次に示す TLI と XTI のわずかな相違を認識しておく必要があります。
t_error
は,XTI では整数値 (正常終了時は 0,異常時は --1) を返す
int
型の関数であり,TLI では
void
型のプロシージャである。
XTI では,t_look
は,(TLI とは異なり) T_ERROR イベントをサポートしない。
T_ERROR イベントの代わりに,--1 および
t_errno
を返す。
t_open
関数の
oflag
パラメータで,TLI の O_NDELAY 値は,XTI では O_NONBLOCK 値として認識される。
XTI は,読み取り書き込みアクセス許可を持つ終端をオープンする。
これは,ほとんどの関数がトランスポート・プロバイダに対して読み取り書き込みアクセスを必要とするからです。
TLI は,読み取り専用,書き込み専用,読み取り書き込みのいずれかのアクセス許可でオープンします。
特に,t_open
関数においては,XTI は,oflag
パラメータの値として,O_RDWR および O_NONBLOCK のビット単位の論理和を使用します。
一方,TLI は,O_NDELAY と,O_RDONLY,O_WRONLY,O_RDWR のいずれか 1 つとのビット単位の論理和を使用します。
O_RDONLY および O_WRONLY の値は,XTI では使用できません。
XTI では,O_RDWR が,終端のアクセス用として唯一の有効な値です。
TLI では,トランスポート・プロバイダに自動アドレス生成機能があると想定されているが,XTI では想定されていない。
トランスポート・プロバイダに自動アドレス生成機能がない場合には,競合する要求が発行されると,XTI は適切なエラー・メッセージを返すことができます。
XTI は,TCP/IP プロトコルおよび OSI プロトコルに対して,プロトコル固有の情報を定義する。
Tru64 UNIX の XTI インプリメンテーションでは,STREAMS ベースのプロトコルに対して,プロトコル固有のオプションもサポートしていますが,TLI は,そのような情報は提供しません。
XTI は,フロー制御を管理するために,T_GODATA や T_GOEXDATA などの追加のイベントを提供するが,TLI では,正常終了するまで送信を続行する。
XTI は,より正確なエラー情報をアプリケーションに伝えるために,追加のエラー・メッセージを提供する。
終端の状態を変更するすべての関数は,TOUTSTATE エラーを使用して,終端の状態が正しくないときに関数が呼び出されたことを示します。
XTI 関数の中には,TLOOK エラーを返して,緊急の非同期イベントが発生したことを示すものがあります。
TLI では,多少面倒ですが,呼び出しの前に明示的に
t_look
関数を呼び出すか,または TLOOK イベント用にシグナルをセットしなければなりません。
キューに入っている接続要求がない場合には,TBADQLEN エラーが返されて,アプリケーションが
t_listen
関数を発行した後に永遠に待ち続けることを防ぎます。
エラー・メッセージについては,XTI のリファレンス・ページを参照してください。
TLI アプリケーションを真の XTI アプリケーションにするには,次のことを行います。
TLI ヘッダ・ファイルの代わりに XTI ヘッダ・ファイルをソース・コードにインクルードする。
#include <xti.h>
TLI と XTI の相違から必要となる,すべての変更または拡張をプログラムに加える。
次のコマンドを使用して,アプリケーションを再コンパイルする。
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
関数を使用してください。
この節では,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 への変更についての基本事項を簡単にまとめます。
オプションだった関数が必須になった。 Tru64 UNIX は XPG3 の XTI でオプションの関数をすべてインプリメントしているので,Tru64 UNIX の XTI のインプリメントでは何の影響もない。
XPG3 仕様の多数の点が明瞭になり,XTI のアプリケーションの移植が容易になった。
新しくエラー・コードがいくつか追加され,プログラムの性能が向上した。
オプションおよびその管理構造が見直され,通信の各種の面に対する制御性が高まった。
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 の基本的な変更点の概要を,次に示します。
7 つの新しい関数 (t_rcvreldata
,t_rcvv
,t_rcvvudata
,t_sndreldata
,t_sndv
,t_sndvudata
,t_sysconf
) が追加された。
XPG3 の XTI 用に開発したアプリケーションがある場合,オペレーティング・システムの現在のバージョンでそのアプリケーションをサポートするときには,次のいずれかを選択します。
アプリケーションの古いバイナリ・ファイルを使用する。 3.6.4 項を参照。
ソースを変更しないで再コンパイルする。
必要であれば,ソースを変更して XNS4.0 の XTI に準拠させる。
必要であれば,ソースを変更して XNS5.0 の 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
を持っています。
この引数は,トランスポート・ユーザとトランスポート・プロバイダの間でオプションをやりとりするために使用します。
t_accept
t_connect
t_listen
t_optmgmt
t_rcvconnect
t_rcvudata
t_rcvuderr
t_sndudata
オプションの内容についての一般的な規定はありません。 オプションには,XTI 全般で使用するものと,それぞれのトランスポート・プロバイダに固有のものとがあります。 オプションのいくつかは,ユーザの通信上の必要に応えるためのものです。 たとえば,高いスループットや短い遅延を要求するようなものです。 その他のオプションには,プロトコルの動作を微調整して,特殊な特性の通信を,より効率的に処理できるようにするためのものもあります。 また,デバッグを目的としたオプションもあります。
すべてのオプションには,省略時の値があります。 値は,それぞれが適用されるプロトコル・レベルで意味を持ち,定義されています。 しかし,トランスポート・ユーザが値を折衝できます。 これには,トランスポート・ユーザが値の使用を強制できる場合などの単純なケースも含まれます。 多くの場合は,トランスポート・プロバイダ,またはリモートのトランスポート・ユーザまでもが,値を折衝して,提案されたものよりも低い品質の値にする権限を持っています。 つまり,遅延が長くなったり,スループットが低くなったりすることがあります。
オプションを,関連付けに関するものとそうでないものとに区別すると役に立ちます。 関連付けに関するとは,通信するトランスポート・ユーザのペアに関することを意味します。 関連付けに関するオプションは,特定のトランスポート接続やデータグラム転送に密接に関係しています。 呼び出し側ユーザがこのようなオプションを指定すると,ほとんどの場合はネットワークを介して何らかの補助的な情報がやりとりされます。 この情報の解釈およびその後の処理は,プロトコルによって変わります。 たとえば,ISO のコネクション指向型の通信では,呼び出し側ユーザは,接続の確立でサービス品質パラメータを指定できます。 このパラメータは,最初にローカルのトランスポート・プロバイダで処理されて,おそらくは低下され,そしてリモートのトランスポート・プロバイダに送られ,さらに低下されます。 最後に,呼び出された側のユーザに渡されて最終の選択が行われ,選択された値が呼び出し側に返されます。
関連付けに関したものでないオプションは,リモートのトランスポート・ユーザに送る情報を持ちません。
デバッグを行うためのオプションのように,まったくローカルでだけ意味を持つものがあれば,IP の
time-to-live
フィールドや,TCP_NODELAY を設定するオプションのように,転送に影響を与えるものもあります
(
xti_internet
(7)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_opthdr
の
level
フィールドは,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_connect
,t_accept
,および
t_sndudata
に入力で指定するオプションは,違ったレベルに向けたものでも構いません。
違反オプション
折衝できるのは,規則に従っているオプションだけです。 違反オプションは障害を起こす可能性があります。 オプションが違反になるのは,次のいずれかの場合です。
t_opthdr.len パラメータに指定した長さが,(オプションの先頭から数えて) オプション・バッファの末尾までのサイズを超えている。
オプションの値が違反している。
それぞれのオプションには,規則に従って値が定義されている。
詳細は
t_optmgmt
(3)xti_internet
(7)
違反オプションを XTI に渡した場合は,次のようになります。
t_optmgmt
関数の呼び出しは,TBADOPT エラーで失敗する。
t_accept
または
t_connect
関数は,TBADOPT エラーで失敗するか,または接続の確立が打ち切られる。
どちらになるかは,インプリメント,および違反オプションが検出されるタイミングにより異なる。
接続が打ち切られる場合は,T_DISCONNECT イベントが発生し,t_connect
の同期呼び出しは TLOOK エラーで失敗します。
t_accept
関数の場合は,接続が打ち切られると,それでも正常に終了するか,または TLOOK エラーで失敗します。
どちらになるかは,インプリメントおよびタイミングにより異なります。
t_sndudata
関数の呼び出しは,TBADOPT エラーで失敗するか,または正常に戻る。
ただし,T_UDERR イベントが発生して,データグラムが送信されなかったことを示します。
トランスポート・ユーザが 1 つの呼び出しで複数のオプションを渡した場合に,オプションの 1 つが違反していると,呼び出しは前述のように失敗します。
ただし,渡した違反していないオプションの一部分,または場合によってはすべてが正常に折衝されることもあります。
トランスポート・ユーザは,t_optmgmt
関数を T_CURRENT フラグをセットして呼び出すことで,現在の状態を確認できます。
t_optmgmt
(3)xti_internet
(7)
オプション・レベルが選択したプロトコルに対して未知,またはそのプロトコルがサポートしていないオプション・レベルを指定した場合は,失敗になりません。
このオプションは,t_connect
,t_accept
,または
t_sndudata
関数の呼び出しでは破棄されます。
t_optmgmt
関数では,オプションの
level
フィールドで T_NOTSULPORT を返します。
オプション折衝の開始
T_NEGOTIATE フラグ付きの
t_optmgmt
,t_connect
,または
t_sndudata
関数を呼び出すとき,トランスポート・ユーザがオプション折衝を開始します。
これらの関数の折衝についての規則は,オプション要求が絶対必要条件かどうかによって変わります。
絶対必要条件か否は,それぞれのオプションで明示的に定義されています。
t_optmgmt
(3)xti_internet
(7)
注意
絶対必要条件という用語は,本来は ISO 8072:1986 仕様のサービス品質パラメータについてのものです。 ここでは,すべてのオプションに対して使用しています。
提案したオプション値が絶対必要条件の場合は,次の 3 つの結果が考えられます。
折衝された値が提案した値と同一になる。
折衝の結果を取り出すと,t_opthdr
の
status
フィールドが T_SUCCESS に設定されている。
オプションがサポートされていても提案した値が折衝できない場合は,折衝が拒否される。 この結果,次のようになる。
t_optmgmt
関数は,正常に戻る。
しかし,返される値の
status
フィールドは T_FAILURE に設定されている。
接続を確立する試みは,すべて打ち切られる。
T_DISCONNECT イベントが発生し,t_connect
関数の同期呼び出しは TLOOK エラーで失敗する。
t_sndudata
関数は,TLOOK エラーで失敗するか,または正常に戻る。
ただし,T_UDERR イベントが発生して,データグラムが送信されなかったことを示す。
1 つの呼び出しで複数のオプションを送り,その内の 1 つがリジェクトされた場合は,XTI は上述のように動作します。 接続の確立またはデータグラムの転送は失敗しますが,いずれかのオプションがリジェクトされる前に正常に折衝されたオプションは,折衝された値を保持します。 ロールバックの機構はありません。 詳細は,「トランスポート終端のオプション管理」の項を参照してください。
t_optmgmt
関数は,それぞれのオプションを折衝しようと試みます。
返されるオプションの
status
フィールドは,成功 (T_SUCCESS) または失敗 (T_FAILURE) を示します。
ローカルのトランスポート・プロバイダが,そのオプションをサポートしていない場合は,t_optmgmt
関数は
status
フィールドで T_NOTSULPORT を報告します。
t_connect
および
t_sndudata
関数は,このオプションを無視します。
提案したオプション値が絶対必要条件でない場合は,次の結果が考えられます。
折衝された値が,提案した値以下の質になる (たとえば,遅延が長くなるなど)。
折衝の結果を取り出すと,折衝された値が提案した値に等しい場合は,t_opthdr
の
status
フィールドが T_SUCCESS に設定されます。
等しくない場合は,T_PARTSUCCESS に設定されます。
ローカルのトランスポート・プロバイダが,そのオプションをサポートしていない場合は,t_optmgmt
は
status
フィールドで T_NOTSULPORT を報告する。
t_connect
および
t_sndudata
関数はこのオプションを無視します。
オプションがサポートされていないために,関数が失敗したり,接続が打ち切られることはありません。 これは,ベンダによって,違ったサブセットのオプションをインプリメントしているためです。 さらに,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
関数は,オプションの指定の重複をチェックしません。
「オプション折衝の開始」の項を参照してください。
サポートしていないオプションは無視されます。
オプション情報の取り出し
この項では,トランスポート・ユーザがオプションに関する情報を取り出す方法について説明します。
トランスポート・ユーザは,次のことができなければなりません。
折衝の結果を知る。 たとえば,接続確立の後の時点でなど。
接続確立の中で折衝に提案されたオプションの値を知る。
リモートのトランスポート・ユーザが,通知のためだけに送ってきたオプションの値を取り出す。 たとえば,IPオプション。
トランスポート終端の,現在有効なオプションの値を確認する。
このために,次の各関数は
struct netbuf
型の引数
opt
を持っています。
t_connect
t_listen
t_optmgmt
t_rcvconnect
t_rcvudata
t_rcvuderr
トランスポート・ユーザは,オプションを書き込むためのバッファを用意しなければなりません。 opt.buf パラメータでこのバッファを指し示し,opt.maxlen パラメータにバッファのサイズを収めます。 トランスポート・ユーザは,opt.maxlen パラメータをゼロに設定して,取り出すオプションがないことを示すことができます。
どのオプションが返されるかは,次のように各関数によって違います。
同期モードの
t_connect
および
t_rcvconnect
関数が返すのは,接続の応答で受け取った,関連付けに関するオプションの値,および入力で指定した,関連付けに関しないオプションの折衝された値です。
ただし,t_connect
呼び出しの入力で指定したオプションがサポートされていなかったり,未知のオプション・レベルを参照していたりする場合は,このオプションは破棄されて出力に返されません。
t_connect
および
t_rcvconnect
関数のそれぞれのオプションの
status
フィールドは,折衝された値が,提案した値 (T_SUCCESS) か,低下された値 (T_PARTSUCCESS) かを示します。
折衝の対象にならない,受け取った補助的な情報 (たとえば IP オプション) の
status
フィールドは,常に T_SUCCESS に設定されます。
t_listen
関連付けに関する受け取るオプションは,着信接続 (シーケンス番号で識別されます) についてのもので,リッスンしている終端についてのものではありません。
ただし,リッスンしている終端で現在有効なオプション値が,t_listen
関数で取り出す値に影響することはあります。
これは,トランスポート・プロバイダも折衝処理に関わることがあるためです。
したがって,T_CURRENT アクションの
t_optmgmt
関数の呼び出しで同じオプションを指定すると,通常同じ値が返されます。
受け取るオプションの数は,後に続く接続指示の数によって変わります。 関連付けに関するオプションの多くは,(たとえば,IP オプションや,ISO 8072:1986 のスループットのように) 呼び出し側ユーザの明示的な要求によってだけ転送されるためです。 オプションがまったく返されない場合もあります。
status フィールドは無関係です。
t_rcvudata
関連付けに関する受け取るオプションは,着信データグラムについてのもので,トランスポート終端
fd
についてのものではありません。
したがって,T_CURRENT アクションの
t_optmgmt
関数の呼び出しで同じオプションを指定すると,通常同じ値は返されません。
受け取るオプションの数は,呼び出しによって変わります。
status フィールドは無関係です。
t_rcvuderr
返されるオプションは,前の,エラーを発生した
t_sndudata
呼び出しの入力オプションについてのものです。
どのオプションが返されてどのような値を持っているかは,それぞれのエラー状況によって変わります。
status
フィールドは無関係です。
t_optmgmt
この呼び出しは,関連付けについての両方の分類のオプションを処理して返すことができます。
扱うオプションは,指定したトランスポート終端についてのもので,接続指示や着信データグラムについてのものではありません。
詳細は,
t_optmagmt
(3)
特権オプションとその値は,特権ユーザだけが要求できます。 ここでの特権の意味はインプリメントで定義されます。
読み取り専用オプションは,参照のためだけに使用します。 トランスポート・ユーザはオプションの値を読み出すことはできますが,変更はできません。 たとえばプロトコル・タイマや,プロトコル・データ・ユニットの最大長の選択は非常に微妙なので,トランスポート・ユーザには任せられないことがありますが,その値を知る必要はあります。 オプションは,すべてのユーザまたは特権のないユーザだけに対して読み出し専用にできます。 特権オプションは,特権のないユーザに対してアクセス不可または読み出し専用にできます。
オプションは,XTI の状態によって折衝可能であったり,読み出し専用であったりすることがあります。 たとえば,ISO のサービス品質オプションは,T_IDLE および T_INCON 状態では折衝可能で,その他のすべての状態 (T_UNINIT を除きます) では読み出し専用です。
トランスポート・ユーザが読み出し専用オプションの折衝を要求するか,または特権のないユーザが特権オプションに不法にアクセスした場合は,次のような結果になります。
t_optmgmt
関数は正常に戻るが,返されたオプションの
status
フィールドは,特権オプションを不法にアクセスした場合は T_NOTSULPORT に,読み出し専用オプションの変更を要求した場合は T_READONLY に設定される。
読み出し専用オプションの折衝を要求すると,
t_accept
または
t_connect
関数は TACCES で失敗するか,または接続の確立が打ち切られて T_DISCONNECT イベントが発生する。
接続が打ち切られた場合は,t_connect
の同期呼び出しはTLOOKで失敗する。
特権オプションを不法に要求した場合は,オプションが単に無視される。
特権のないユーザは,特権オプションやサポートされていないオプションは選択できない。
t_accept
呼び出しが正常に終了するか,または TLOOK で失敗するかは,タイミングとインプリメントの条件で決まる。
読み出し専用オプションの折衝を要求すると,t_sndudata
関数は TLOOK を返すか,または正常に返す。
しかし,T_UDERR イベントが発生して,データグラムが送信されなかったことを示す。
特権オプションを不法に要求した場合は,単に無視される。
特権のないユーザは,特権オプションやサポートされていないオプションは選択できない。
複数のオプションを
t_connect
,t_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_connect
,t_accept
,または
t_sndudata
関数を呼び出す場合は,トランスポート・ユーザは関連付けについての両方の分類のオプションを,入力で明示的に指定できます。
オプションは,最初にローカルで1つ1つ折衝され,結果の値が内部のオプション・バッファに書き込まれます。
この後,ネットワークを介した折衝段階がさらに必要な場合は,変更されたオプション・バッファが使用されます。
たとえば,コネクション指向型の ISO の通信がそうです。
その後,新たに折衝された値が,内部のオプション・バッファに書き込まれます。
どの段階でも,折衝が失敗すると転送が打ち切られます。 転送が打ち切られると,オプション・バッファは,失敗が起こった時点の内容を保ちます。 XTI 呼び出しが失敗しても成功しても,エラーが発生する前に折衝されたオプションはオプション・バッファに書き込まれます。
t_connect
,t_accept
,または
t_sndudata
関数を呼び出すときに,どのオプションを明示的に指定するかを決めるのは,トランスポート・ユーザです。
トランスポート・ユーザは,関数の入力引数
opt
の
len
フィールドをゼロ (0) に設定すれば,オプションをまったく渡さなくてもかまいません。
この場合,内部のオプション・バッファの現在の内容が,変更なしに折衝に使用されます。
t_connect
,t_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->etsdu,info->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)
t_optmgmt
関数は,正常終了すると 0 を返します。
それ以外の場合は -1 を返し,t_errno
に,3.7 節に示されている値の 1 つが設定されます
(マルチスレッド・アプリケーションの場合,t_errno
はスレッド固有です)。
3.7 XTI エラー
XTI は,ライブラリ・エラーおよびシステム・エラーを返します。 XTI 関数はエラーを検出すると --1 を返し,次のいずれかの処理を行うことができます。
外部変数 t_errno をチェックして,特定のエラーを取得する。 マルチスレッド・アプリケーションに対しては,t_errno はスレッドに固有。
t_error
関数を呼び出して,t_errno
に格納されたエラーに関連するメッセージ・テキストをプリントする。
t_getstate
関数を使用して,トランスポート終端の状態をチェックする。
エラーによっては,終端の状態が変更される。
注意
XTI 関数の呼び出しが正常終了しても,t_errno の内容はクリアされないので,エラーが発生した後だけ t_errno をチェックしてください。
<xti.h>
ヘッダ・ファイルは,次のように
t_errno
変数をマクロとして定義します。
#define t_errno (*(_terrno()))
エラーについての詳細は,それぞれの XTI リファレンス・ページを参照してください。
3.8 XTI トランスポート・プロバイダの構成
XTI トランスポート・プロバイダを構成するためには,xtiso
カーネル構成オプションを使用します。
xtiso
オプションは,インストレーション時にシステムに構成することも,また,doconfig
コマンドを使用してシステムに追加することもできます。
詳細は『インストレーション・ガイド』を参照してください。
doconfig
コマンドは,次のいずれかの方法で使用できます。
カーネルをカスタマイズしていない場合は,オプションを指定せずに
doconfig
コマンドを使用する。
オプションを指定しない場合,doconfig
コマンドは,システム用に新しいカーネル構成ファイルを作成する。
カーネルをカスタマイズしてあり,再度カスタマイズをしたくない場合は,doconfig -c
コマンドを使用する。
doconfig -c
コマンドを使用すると,既存のカーネル構成ファイルに,情報を追加できる。
オプションを指定せずに
doconfig
コマンドを使用する場合は,次の手順に従ってください。
スーパユーザ・プロンプト (#) から
/usr/sbin/doconfig
コマンドを入力する。
カーネル構成ファイルの名前を入力する。
ファイル名は大文字のシステム名であり,通常は省略時の設定として,大カッコ ([]) の中に表示されます。 次に例を示します。
Enter a name for the kernel configuration file. [HOST1]: [RETURN]
システム構成ファイルを置き換えるかどうかを尋ねられたら,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 ***
カーネル・オプション選択メニューから
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.
構成ファイルを編集するかどうかを尋ねられるので,n
を入力する。
doconfig
コマンドは,デバイス特殊ファイルを作成し,作成したファイルのログをいれる場所を示して,新しいカーネルを構築します。
新しいカーネルが構築されたら,カーネルを
doconfig
が置いたディレクトリからルート・ディレクトリ (/) に移動して,システムをリブートしなければなりません。
リブートすると,strsetup -i
コマンドが自動的に実行され,新しい STREAMS モジュールに対してデバイス特殊ファイルが作成されます。
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 オプションをカーネル構成ファイルに追加する場合は,次の手順に従ってください。
スーパユーザ・プロンプト (#) から
doconfig -c
HOSTNAME
コマンドを入力する。
HOSTNAME
は大文字のシステム名です。
たとえば,host1
というシステムの場合には,次のように入力します。
# doconfig -c HOST1
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 ***
新しいカーネルが構成されたら,doconfig
が置いたディレクトリからルート・ディレクトリ (/) へそのカーネルを移動して,システムをリブートする。
リブートすると,strsetup -i
コマンドが自動的に実行され,新しい STREAMS モジュールに対してデバイス特殊ファイルが作成されます。
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
コマンドについての詳細は,『システム管理ガイド』を参照してください。