次に示す頻繁に寄せられる質問は、ToolTalk サービスに関する追加情報の役割も果たしています。
ToolTalk サービスを使用すれば、個々のアプリケーションは直接相手を知らなくても、互いに通信できます。アプリケーションは ToolTalk メッセージを作成して送信することにより、互いに通信します。ToolTalk サービスはこのメッセージを受信すると、受信側を判別し、適切なアプリケーションに配信します。
違います。ToolTalk サービスは、CORBA に準拠した Sun オブジェクト要求仲介 (ORB) ではありません。ToolTalk サービスは、オブジェクト管理グループ (OMG) の CORBA 仕様が定義される以前の 1991 年に設計出荷されました。
CORBA に準拠した Sun ORB は、分散オブジェクト管理機能 (DOMF) であり、これは Sun のプロジェクト DOE 製品の一部です。Sun は、DOMF が Solaris の一部として一般利用できるようになった時点で、DOMF 上で動作する ToolTalk API をサポートすると公約しています。現在 ToolTalk メッセージサービスを使用しているアプリケーションは、将来は分散オブジェクト環境に移行します。
ToolTalk ファイルは、/usr/openwin/bin、lib、include/desktop、および man ディレクトリの他に /usr/dt/bin、lib、および include/Tt ディレクトリにもあります。これには、過去のいきさつがあります。ToolTalk は、共通デスクトップ環境 (CDE) の前から存在していて、Solaris とともに /usr/openwin ディレクトリ構造で出荷されていました。CDE がリリースされると、ToolTalk は、シンボリックリンクを使って /usr/dt ディレクトリから見えるようになりましたが、実際には、依然として /usr/openwin にインストールされていました。CDE がインストールされた Solaris 2.6 オペレーティング環境およびその互換バージョンのシステムでは、ToolTalk の 2 つの完全版がインストールされています。1 つは /usr/dt に、もう 1 つは /usr/openwin にインストールされていますが、/usr/dt にインストールされているものだけが CDE で有効です。
表 D-1 にこれらのファイルを示します。
表 D-1 ToolTalk のファイル
ファイル名 |
説明 |
---|---|
ネットワーク上で通信してメッセージを配信する |
|
ToolTalk オブジェクト仕様や、ToolTalk メッセージで参照するファイル情報を格納し管理する |
|
標準オペレーティングシステムのシェルコマンド ToolTalk オブジェクトの入ったファイルや、ToolTalk メッセージのサブジェクトであるファイルがコピー、移動、または削除されると、これらのコマンドは ToolTalk サービスに連絡する |
|
tttrace, ttsnoop |
tttrace は、truss (1) に類似している。これにより、特定の ttsession で発生するメッセージパッシングとパターンマッチングをトレースできる。また、これを使用することにより、すべての呼び出しのプログラムごとのトレースを ToolTalk API に提供できる。ttnsoop は Motif をベースにしたプログラムで、tttrace のメッセージとパターントレース機能に、デバッグとチュータ機能として、メッセージを簡単に作成または送信したり、パターンを登録したりできる付加機能 |
ToolTalk データベースの検査と修復を行うツール |
|
ptype と otype のファイルをコンパイルし、ToolTalk 型データベースに自動的にインストールする |
|
ToolTalk 型データを、分類機構データベースフォーマットから XDR データベースフォーマットに変換する |
|
アプリケーションが使用してメッセージを送受信する ToolTalk 関数のアプリケーションプログラミングインタフェース (API) ライブラリとヘッダーファイル |
ttsession が 1 つも動作していない場合は、tt_open を最初に呼び出した時点で ttsession が自動的に起動されます。ただし、/usr/dt/bin/Xsession ファイルには下記のようなエントリがあり、それによって usr/dt/bin/dtlogin を使用している際に、ログイン時に自動的に ttsession を起動します。
# Start ttsession here. dtstart_ttsession="$DT_BINPATH/ttsession" |
/etc/inet/inetd.conf ファイルに、次のようなエントリが入っています。
# Sun ToolTalk Database Server 100083/1 tli rpc/tcp wait root /usr/dt/bin/rpc.ttdbserverd /usr/dt/binrpc.ttdbserverd |
ToolTalk 型データベースの場所は、環境変数 TTPATH
で ToolTalk サービスに教えます。この環境変数のフォーマットを次に示します。
userDB[:systemDB[:networkDB]] |
型ファイルは、TTPATH
に指定した順序と逆の順序で読み込まれます。
この環境変数は、データベースサーバーのリダイレクトファイルの場所も ToolTalk サービスに教えます。そのデフォルトの位置を表 D-2 に示します。
表 D-2 ToolTalk 型データベースのデフォルト位置
データベース |
位置 |
---|---|
ユーザー |
‾/.tt |
システム |
/etc/tt |
ネットワーク |
$OPENWINHOME/etc/tt または /usr/dt/appconfig/tttypes |
ToolTalk サービスは、メッセージの配信に X のメッセージやプロトコルを使用しません。ToolTalk サービスが X Window System と関連付けられるのは、X セッションを動作させた場合だけです。
X セッションを起動すると、そのセッション名が X サーバーのルートウィンドウ上にプロパティ (名称は TT_SESSION
) として表示されます。この X サーバーをディスプレイとして指定するすべてのプロセスは、その X セッションをデフォルトセッションとして取得します。X セッションは個々の X ディスプレイ上で表示を行うプロセスのグループとして定義されているため、定義に従えば X Window System を起動する必要がありますが、ToolTalk サービスから要求があるまで X Window System を起動する必要はありません。
動作中の X サーバーが 1 つもない (たとえば、ダム端末上で動作する文字モードアプリケーションだけのセッションを実行する) 場合は、「プロセスツリーセッション」を使用してください。プロセスツリーセッションを実行すると、そのセッション名は環境変数 TT_SESSION
に表示されます。プロセスツリーセッションは、プロセスツリー上で、自分より下のすべてのプロセスに対してデフォルトセッションになります。
使用できます。ただし、libtt.so ファイル用に、LD_LIBRARY_PATH
で /usr/dt/lib を指定しなければなりません。
この識別子を入手するには、次のコマンドを入力します。
xprop -root | grep TT_SESSION |
X セッションは、ルートウィンドウの TT_SESSION
プロパティ上にそのセッション ID を表示します。
内部的な初期設定を行なった後、tt_open は ttsession の検索を開始します。
tt_open は、環境変数 TT_SESSION
が設定されているか検査します。
設定されている場合は、その値を ttsession の ID として使用します。
設定されていない場合は、環境変数 DISPLAY
が設定されているか検査します。
設定されている場合は、その値を ttsession の ID として使用します。
設定されていない場合は、(そのディスプレイを実行しているマシンの) ルート X Window System 上の TT_SESSION
プロパティが設定されているか検査します。
以上の結果、これらの環境変数が 1 つも設定されていない場合は、tt_open は自分で ttsession を起動します。
tt_open は、ttsession が動作中か確認します。
tt_open は環境変数 TT_TOKEN
を検査し、そのクライアントが ptype の「Start」コマンドから起動されたかどうかを決定します。
ptype の「Start」コマンドから起動された場合、tt は procid を作成します。
tt_open は、ttsession が接続するクライアント側の TCP/IP ソケットを作成します。
ソケット上の動作は、関連付けられたファイル記述子で通知されます。ttsession はこのチャネルだけを使用して、着信メッセージをクライアントに通知します。
このファイル記述子には、tt_close を使用してください。close 関数をは使用しないでください。tt_fd が返すファイル記述子に close 関数を使用すると、後で tt_open や close を呼び出すたびに、ファイル記述子のカウント値が増えます。
tt_open は、データベースのホスト名リダイレクト用マップを読み取ります。
デフォルトセッションが X セッションであり、動作中の ttsession がない場合は、libtt がセッションを 1 つ起動します。そうでない場合は、セッション名を入手するために、ttsession を最初に起動しなければなりません。
終了しません。最初のセッションはまだ動作しています。
動作するマシンが異なるプロセス同士が ToolTalk サービスを使用して通信するには、次の 2 つの方法があります。
同一セッションに接続する。
それぞれのマシン上で NFS にファイルをマウントし、そのファイルを配信範囲とする。
複数のプロセスを同一セッションに接続するには、まずプロセス共通の処理対象 (セッション名など) を決定します。次に、それらの全プロセスにセッション名を伝達する方法を決定します。ToolTalk サービスには、セッションアドレスを配布する手段がありません (できるのは、X サーバールートウィンドウの TT_SESSION
プロパティにセッション ID を表示することだけです)。
セッション名を入手するには、次のコマンドを使用できます。
ttsession -p |
これはセッションを新規に生成し、標準出力にそのセッション名を出力します。また、次のコマンドも使用できます。
ttsession -c |
これは環境変数 $TT_SESSION
にセッション ID を設定します。
次に、他のプロセスが見つけられる場所に、セッション名を設定する必要があります。セッション名を設定する場所の例としては、次のものがあります。
共有ファイル
.plan ファイル
メールメッセージ
独自に設計した別の RPC 呼び出し
NIS
NFSTM 公開ファイルシステムで、公共ファイルを使用する場合の例を次に示します。
次のコマンドで ttsession を起動します。
ttsession -p >/home/foo/sessionaddress |
この /home/foo/sessionaddress ファイルに入っているセッションアドレスをクライアントで確実に使用するには、たとえば、次のようなシェルスクリプトでセッションアドレスを読み取り、_SUN_TT_SESSION
を設定してからクライアントを起動します。
#!/bin/csh setenv TT_SESSION `cat /home/foo/sessionaddress` exec client-program |
プロセスからこのセッションに接続するには、tt_default_session_set を呼び出す際にセッション名を指定します。
また、個々の X サーバーに関連付けられた ttsession からメッセージを送信すると、新規に作成した ttsession を表示できます。
ファイルが配信範囲になるのは、ファイルを配信範囲とするパターンをプロセスが登録したときです。登録したプロセスのセッション名は、登録したファイルに関連付けられた rpc.ttdbserverd のセッションリスト上に格納されます。ファイルを配信範囲とするメッセージが送信されると、ToolTalk サービスは、この該当ファイルのセッションリストを検索し、そのリスト上の各セッションにメッセージを配布します。
NFS にマウントしたファイルを配信範囲とするには、すべてのシステム上で 1 つのファイルシステムを NFS にマウントし、rpc.ttdbserverd を NFS サーバー上で実行する必要があります。
tt_default_session_set は、tt_open 呼び出しで接続する ttsession を指定します。
ToolTalk サービスと通信する際に使用されるデフォルト変数を表 D-3 に示します。
表 D-3 デフォルト変数
変数 |
説明 |
---|---|
tt_open が設定する。この変数により ttsession はクライアントを識別する |
|
tt_ptype_declare が設定する |
|
ファイルを結合すると設定される。メッセージ中にファイルが 1 つも設定されていない場合は、デフォルトファイルが設定される |
API 関数を使用して procid の取得と設定を行うと、アプリケーションから複数セッション間の切り替えができます。次に例を示します。
connect to session 1 store the default procid in filename connect to session 2, store the default procid filename restore associated default procid interact with particular_session |
デフォルトのファイルと ptype は、現在のデフォルト procid の一部です。デフォルトの procid を変更すると、デフォルトのファイルと ptype も、その procid に関連付けられたものに変更されます。
起動できません。ttsession のセッション ID は、ToolTalk サービスから入手しなければなりません。
セッション ID はたくさんのフィールドから構成されていますが、その中には次のものがあります。
アドレスフォーマットのバージョン
プロセスの UNIX pid
RPC 非常駐プログラム番号
未使用バージョン (互換性のために使用)
認証レベル
ユーザー ID
ホストの IP アドレス
RPC のバージョン
セッション ID のフォーマットは、公開されていないインタフェースです。セッション ID のフォーマットに依存するような ToolTalk クライアントを作成しないでください。
プロセスが新しくセッションに参加する際は、通知メッセージを送って、処理対象のプロセスに通知してください。また、プロセスが新しくセッションに参加した際に通知をもらいたいプロセスは、その通知メッセージを監視するためのパターンを登録しておく必要があります。
デスクトップサービスの「Started」メッセージは、このために開発されました。
送信した各メッセージを ttsession がどのように処理するかを監視するには、起動時に -t (トレースモード) を指定します。次のように USR1 シグナルを ttsession に送信すると、トレースモードのオンとオフを切り替えることができます。
kill -USR1 <ttsession_pid> |
また、ttsnoop ユーティリティ (または tttrace ユーティリティ) を使用すると、削除メッセージを監視できます。
メッセージフローには、次の 2 種類があります。
セッションを配信範囲とするもの
ファイルを配信範囲とするもの
セッションを配信範囲とするメッセージの基本的なフローは、次のとおりです。
クライアントが要求メッセージを作成し、tt_message_send を呼び出します。
ttsession がハンドラを見つけます。
ttsession はハンドラを起動する際に、環境変数 TT_TOKEN
を設定します。
ハンドラが動作を開始し、tt_open と tt_fd を呼び出して、ttsession への通信を確立します。
ハンドラは自分の ptype を ttsession に宣言します。
ttsession は ptype の静的パターンをすべて動的パターンに変更します。
この時点では、ハンドラがまだセッションに参加していないため、そのパターンは無効です。
ハンドラがセッションに参加して、パターンが有効になります。
ttsession は、メッセージが待ち行列に入っていることをハンドラに通知します。
ハンドラはファイル記述子で通知を受け、tt_message_receive を呼び出してそのメッセージを検索します。
tt_message_receive が返したメッセージ状態が TT_WRN_START_MESSAGE
の場合、ToolTalk サービスはすでにそのプロセスを起動してメッセージを配信済みです。この場合 ptype 用のメッセージは、プロセスがメッセージ (通知の場合でも) に対して応答、拒否、異常終了のいずれかの処理を行うか、tt_message_accept を呼び出すまでブロックされます。
ハンドラは要求された操作を実行します。
ハンドラは要求に対する応答を返します。
ttsession は、(応答) メッセージが待ち行列に入っていることをクライアントに通知します。
クライアントのファイル記述子が有効になります。
実際には、要求メッセージの状態が変化するたびに、クライアントはメッセージを受信します。
クライアントは tt_message_receive を呼び出し、結果を検索します。
ファイルを配信範囲とするメッセージの基本的なフローは、次のとおりです。
ファイルを配信範囲とするパターンが登録されます。
ファイルと、パターンを登録しようとしているセッションを、libtt がデータベースサーバーに通知します。
libtt はデータベースサーバーに照会して、指定されたファイルを処理対象として登録しているクライアントのセッションをすべて検索します。
通知の場合、libtt はこれらのセッションすべてと直接通信します。
要求の場合、libtt はメッセージと、関連する他のセッションリストをそのセッションに通知します。
これらのセッションは互いに通信し合い、ハンドラを探します。
アプリケーションにメッセージが到着すると、次のようになります。
ファイル記述子が有効になります。
Xt メインループが select から抜け出し、XtAppAddInput 呼び出しで登録してある関数を呼び出します。
この登録関数は、tt_message_receive を呼び出します。
メッセージが読み込まれ、メッセージに関連付けられているコールバックがすべて起動されます。
メッセージのコールバックから戻ります。
入力コールバックは他の処理を継続します。
たとえば、次のような入力コールバックに対して、
input_callback(...) { Tt_message m; printf ("input callback entered¥n"); m = tt_message_receive(); printf ("input callback exiting, message handle is %d¥n", (int)m); } |
メッセージコールバックが次のようになっている場合、
message_callback(...) { printf("message callback entered¥n"); return TT_CALLBACK_PROCESSED; } |
次のように出力されます。
input callback entered message callback entered input callback exiting, message handle is 0 |
メッセージの区別は、次のように行います。
動作中のすべての ttsession では、メッセージを一意に識別する識別子がメッセージごとに 1 つあります。
メッセージハンドルは同じです。たとえば、例 D-1 では、受信メッセージと送信メッセージが同じかどうかを調べています。
送信できます。プロセスは、自分で処理する要求を送信できます。このような要求は通常、次のように処理します。
{ ... tt_message_arg_val_set(m, 1, "answer"); tt_message_reply(m); tt_message_destroy(m); return TT_CALLBACK_PROCESSED; } |
しかし、ハンドラと送信者が同じプロセスの場合、(同じプロセスに) 応答が返って来た時点では、メッセージは既に削除されています。送信側がメッセージに添付したメッセージ (コールバックやユーザーデータなど) もすべて削除されています。これを防ぐには、メッセージを削除しないでください。次に例を示します。
{ ... if (0!=strcmp(tt_message_sender(m),tt_default_procid())) { tt_message_destroy(m); } |
tt_message_callback_add で登録した関数に自分自身のデータを渡すには、メッセージのユーザーデータセルを使用します。次に例を示します。
ユーザーデータは、送信先クライアントでしか見ることができません。
ToolTalk サービスには構造体を送信する方法が組み込まれていないため、送信できるのは文字列、整数、バイト配列だけです。構造体を送信するには、XDR ルーチンを使用して構造体をバイト配列に変換した後、メッセージに設定します。このシリアル化を解除するにも、同じ XDR ルーチンを使用します。
直接は転送できません。ただし、次のことは可能です。
ファイルデータをメッセージの引数に設定する。
ToolTalk サービスはメッセージデータを、アプリケーションからライブラリに、ライブラリから ttsession に、ttsession から受信側のライブラリへとコピーし、受信側が引数値を取得する際に、この受信側のライブラリから取り出します。データが大きいと、この方法では非常に遅くなり、使用するメモリーも膨大になります。
ファイル名をメッセージの引数に設定する。
この方法では、すべての受信側がファイルを同じ場所にマウントすることが前提です。
ファイル名を tt_message_file 属性に設定する。
この方法でもすべての受信側がファイルをマウントすることが前提ですが、マウント場所が異なる場合は、ToolTalk サービスがすべて解決します。
ToolTalk サービスでは、整数、文字列、バイト配列をメッセージに格納できます。XDR ルーチンにより、これらのデータ型はどのクライアントでも保証されています。これら 3 つの型以外のデータの場合は、メッセージに設定する前にシリアル化して、バイト配列にしなければなりません。
再使用できません。引数を変えて同じメッセージを複数回は送信できません。メッセージはそれぞれ、作成、送信、破棄のサイクルを繰り返さなければなりません。
メッセージを破棄する際、そのハンドルは破棄できますが、メッセージ本体は破棄できません。メッセージ本体は、ToolTalk がそのメッセージの処理を完了し、外部のハンドルがすべて破棄されたときにだけ破棄されます。たとえば、メッセージを送信した直後にそのハンドルを破棄しても、応答が返って来た時点で新しいハンドルが渡されます。
メッセージをいったん破棄してしまうと、二度とそのメッセージを見ることはできません。たとえば、自分が送信する要求を監視するパターンを登録し、パターンが一致した時点でそのメッセージを破棄すると、そのメッセージの状態が「handled」(応答) になってもそのメッセージを見ることはできません。
現在は処理できません。1 つのメッセージを複数のプロセスで処理したい場合は、通知を使用できます。また、メッセージの拒否を利用して ToolTalk サービスに、使用可能なハンドラすべてに要求を配信させることもできます。ただし、これらのハンドラはそれぞれ、実際には何らかの操作を処理する必要があります。
実行できます。ただし、ToolTalk サービスには負荷分散の概念がないため、ToolTalk はいくつかのハンドラから 1 つだけ選択し、一致するものであれば、その他のメッセージもそのハンドラだけに配信します。メッセージをその他のハンドラにも配信させるには、次のような方法があります。
メッセージを受信してもビジーなのでそのメッセージを処理したくないプロセスは、メッセージを拒否できます。この場合、ToolTalk サービスは使用可能な次のハンドラを探します。(登録されているハンドラがすべて拒否した場合は、処置オプションが適用されます。)
この方法では、tt_fd が有効になったら tt_message_receive を呼び出すというイベントループを、プロセスが実行中でなければなりません。ただし、プロセスが複雑な計算ループを実行していると、この方法ではうまくいきません。
ビジーになるようなメッセージの場合は、そのパターンを登録解除する。次に例を示します。
m = tt_message_receive(); if (m is the message that causes us to go busy) { tt_pattern_unregister(p); } |
ToolTalk サービスは、パターンが登録されていないと、一致するメッセージをプロセスに渡しません。プロセスでもう一度メッセージを受信したい場合は、パターンを再登録してください。
この方法を使用すると、競争条件が生じます。たとえば、tt_message_receive と tt_pattern_unregister 呼び出しの間に次のメッセージが送信され、このプロセスに渡される可能性があります。
方法 1 と方法 2 を組み合わせる。
方法 1 と方法 2 を組み合わせて、次のようにすることもできます。
get the message unregister the pattern loop, calling tt_message_receive until it returns 0; reject all the returned messages handle the message re-register the pattern repeat |
この方法では、プロセスで登録するパターンは 1 つであることが前提です。
メッセージの処置を指定すると、静的型定義に指定された処置の値を上書きできます。ハンドラに ptype を指定したメッセージが静的シグニチャに一致しないと、メッセージで指定した処置に従って処理されます。たとえば、メッセージの処置に TT_START
、ptype に開始文字列を指定すると、インスタンスが 1 つ起動されます。
ToolTalk サービスでは、message_status_string を使用しません。このメッセージ要素は、アプリケーションが使用するためのものです。ToolTalk サービスがこのメッセージ状態を設定するのは、メッセージの配信に問題が発生したときだけです。その他の場合、このメッセージ要素はアプリケーション独自の方法で設定または読み取りを行います。
アプリケーションがデータバッファとして受け取る内部記憶領域のスタックは、libtt が管理します。アプリケーションが ToolTalk API ルーチンから返される char * や void * はすべて、そのコピー領域を指していて、これらの領域はアプリケーションで解放する必要があります。
割り当てられたバッファは、マーク関数と解放関数を使用して、一連の操作で解放してください。ただし、解放関数を呼び出すと、対応するマーク関数を呼び出した以降に割り当てられたすべての領域が解放されます。ToolTalk サービスが返したデータを一部残しておきたい場合は、解放操作を実行する前にデータのコピーを取っておいてください。
ptype はツールの種類を指定する文字列で、プログラマが定義します。(「プロセス型」と呼ぶこともあります。) 各 ptype は一連のパターンに関連付けることができます。そのパターンには、ptype が処理対象とするメッセージと、その ptype のインスタンスを起動する際に ToolTalk サービスが使用する文字列を指定します。
ptype の主な目的は、ツールのインスタンスがメッセージの配信範囲で 1 つも動作していないときも、メッセージをツールの処理対象にできるようにすることです。メッセージが要求する操作を実行できる場合や、メッセージが送信された際に通知を受けたい場合は、ツールの ptype でその旨を指示しておくと、ToolTalk は必要に応じてそのツールを起動します。ptype データベースはシステム管理者やユーザーが変更できるため、現場やユーザーの好みに応じて、個々のメッセージを処理するツールを指定できます。
ttsession がデータベースタイプを読み込むのは、起動時、USR1 信号受信時、またはデータベースタイプが変更されたときに特別の ToolTalk メッセージによってその旨を通知されたときです。通常、手作業で ttsession を更新してファイルタイプをもう一度読み込む必要はありません。ただし、強制的に実行中の ttsession にデータベースタイプを再読み込みさせたいときは、下記のような USR2 信号を送信することによって実行できます。たとえば、次のように送信します。
kill -USR2 <ttsession pid> |
ToolTalk サービスは、すべてのメッセージに対して常に 1 つのハンドラと任意の数のオブザーバを探します。この場合、ToolTalk サービスは動作中のハンドラを 1 つ見つけても、メッセージに一致する任意の監視パターンを ptype の中から探します。一致する監視パターンの ptype が 1 つ存在するが、その ptype のプロセスが動作していない場合、ToolTalk サービスは (ptype パターンまたはメッセージの指定に従って) プロセスを新しく起動するか、メッセージを待ち行列に入れます。
変更できません。起動時の ptype へのメッセージは、ptype がそのメッセージに応答するか、tt_message_accept 呼び出しを発行するまでブロックされます。しかし ptype は、TT_WRN_START_MESSAGE
状態以外のすべての要求に対して、tt_message_reject を実行できます。したがって、その ptype を持つ動作中のすべてのインスタンスにすべての要求が配信され (そして拒否され) てから、インスタンスが新しく起動されます。この方法は、同時に動作している ptype が多い場合や、メッセージに大量のデータが入っている場合は遅くなります。また、tt_message_accept を使用することもできます。これは、ptype へのメッセージを基本的にはブロックしません。
ptype を宣言した時点では、静的パターンは ttsession のメモリーに存在します。アプリケーションが ptype を登録すると、ToolTalk サービスはその ptype を指定している otype をチェックし、otype の中のパターンも登録します。静的パターンを有効にするには、アプリケーションから適切な join 関数を呼び出す必要があります。
1 つのアプリケーションで同じ ptype を複数回宣言しても無視されます。
アプリケーションの起動を要求するメッセージを処理する際、ToolTalk サービスは、その子プロセスの _SUN_TT_TOKEN
環境変数を設定します。アプリケーションが動作を開始して tt_open を実行すると、この情報は ToolTalk サービスに戻され、メッセージを処理するのに起動、つまり任命されたのはそのアプリケーションであることを ToolTalk に知らせます。
パターンは、そのパターンを有効にしたいセッションに登録しなければなりません。パターンは (1 つの procid で) 2 つ以上のファイルに対して有効にできるため、パターンのファイル部はリストされたすべてのファイルに一致します。
コンテキストは配信範囲ではありません。コンテキストに結合してもファイルやセッションに結合していないパターンは、どのメッセージにも一致できません。
必要ありません。ただし、応答に一致するパターンを登録すると、その応答はイベントループに 2 度表われます。1 度目はパターンに一致したためで、2 度目はそれが応答であるためです。
パターンに一致し、しかもポイントツーポイント (つまり TT_HANDLER
) ではない要求メッセージは監視できます。監視パターンがどの要求にも一致しない場合は、ttsession をトレースモードで動作させれば原因が分かります。
ToolTalk の静的パターン (つまり、型データベース) 機構では、属性値でパターンと照合させることはできません。ファイルの配信範囲や引数の vtype で照合させることはできますが、ファイル名や引数値で照合させることはできません。
この制限は、静的パターンのコンテキストの照合にも当てはまります。
TT_HANDLER
にアドレス指定されたメッセージは、パターンと照合されないため、ワイルドカードでパターンを指定できません。
設定できません。ファイルを配信範囲とする際にファイル名を指定しないのは、すべてのファイルについてファイルを配信範囲とするメッセージと照合するよう指定するのと実質的には同じです。
ファイルを配信範囲とするパターンにセッション属性を設定して、セッション中のファイルを配信範囲とするようエミュレートしてもかまいません。ただし、配信範囲が TT_FILE
になっているパターンのセッション属性は、tt_session_join を呼び出しても更新されません。
違います。これらの配信範囲は使用目的が違います。
たとえば、すべてのセッションが同じ静的パターンを持ち、(アプリケーションが送信しようとしている) メッセージ M に一致するパターン P を少なくとも 1 つ持つとします。そして、ファイル foo.bar を処理対象とするクライアントのセッションが 1 つもないとします。
アプリケーションはセッション A に接続しており、ファイル foo.bar を配信範囲とするメッセージ M を発行します。このファイルを処理対象とするクライアントのセッションは 1 つもないため、このメッセージを受け取るファイルはセッション A だけです。(このメッセージは、セッション A の静的パターン P と一致します。) ptype が動作を開始すると、そのパターンは実際には (そのセッション中の) ファイルを配信範囲とするようになり、セッション A がすべて処理します。
セッションの静的パターンがすべて同じとは限らない場合は、結果は異なります。たとえばセッション B が、ファイル配信範囲指定でメッセージ M に一致する P' というパターンを持つことも考えられます。メッセージ M がセッション A に送信されると、ファイル foo.bar を処理対象にしたクライアントがセッション B に 1 つもない場合、dbserver はそのメッセージをセッション B に送信しません。しかし、セッション B のクライアントの 1 つがファイル foo.bar を処理対象としていれば、セッション B の少なくとも 1 つのクライアントがファイル foo.bar を処理対象としていることを知り、dbserver はセッション B にもそのメッセージを送信します。
barg_add と iarg_add の呼び出しも、基本的には一組の値が後ろに付いた arg_add 呼び出しです。
メッセージ引数の type や vtype (value type の短縮形) は、その引数値が意味を持つ領域を示し、アプリケーションが指定します。
vtype は C の typedef に似ています。すべての vtype は通常、その引数に設定できる 3 種類のデータ型のどれか 1 つに対応します。
vtype 機構を使用すれば、2 つの値を同じ型として宣言できます。たとえば、messageID と bufferID という 2 つの vtype を C の文字列と同様に、それぞれ異なる意味を持つように定義し、操作によって messageID にだけ有効、bufferID にだけ有効、または両方の vtype に有効とすることもできます。このパターン照合機構を使用すれば、bufferID 文字列を指定した要求は、messageID 文字列にだけ有効な操作のパターンには一致しません。
コンテキストは、照合を制限するのに使用できます。照合を制限するには、照合する確率を大きくするために、メッセージは同じコンテキスト、つまりコンテキストのスーパーセットを持たなければなりません。また、コンテキストスロット名がドル記号 ($) で始まり (たとえば $ISV)、そのメッセージによってアプリケーションが起動される場合、コンテキストスロットにどのような値が設定されていても、その値がアプリケーションの環境変数に設定されます。
ttsession が照合を検査するさまざまな方法を表 D-4 に示します。
表 D-4 ttsession の照合の検査方法
方法 |
説明 |
一致するか |
---|---|---|
|
このようなアドレス指定は「ポイントツーポイント」配信であり、メッセージは受信側に直接渡される。登録されたパターンは検査されないため、ポイントツーポイントのメッセージは監視できない |
照合は不要 |
|
操作 (op) の同じ静的シグニチャ (sig) のリストを検索し、オブザーバと見込みのあるハンドラのリストを収集する。 sig が引数もコンテキストも持たない場合 sig プロトタイプ (引数の個数、型、モード) の値が異なる場合 sig コンテキストがメッセージのコンテキストのサブセットである場合 待ち行列に入れる必要のあるすべての静的オブザーバ用情報を保存する。 動的パターンを検索し、オブザーバと使用可能なハンドラのリストに追加する。このリストを作成するのに、ttsession はまず操作付きのパターンを使用し、次に操作なしのパターンを使用する。 信頼性、状態、クラス、アドレス、ハンドラ、ハンドラの ptype、配信範囲、オブジェクト、otype、送信側、送信側の ptype、引数、コンテキストを検査する。 まずオブザーバに配信する (ハンドラは状態が変わる可能性があるため)。 最もよく一致したハンドラに配信する。2 つ以上のハンドラが等しく「最適」な場合は、任意に選択する。 |
=> 一致する => 一致しない => 一致する |
|
type 引数が設定されているかどうかを検査する。 sig が異なる otype を持つ場合 sig が otype を 1 つも持たず、配信範囲が異なる場合 その他の場合は、 |
=> 一致しない => 一致しない |
現在は、セッションとファイルの 2 種類だけです。
X セッションも 1 つの配信範囲と言われることがありますが、実際にはセッション配信範囲です。
ToolTalk 型データベースには、静的な ptype と otype の定義が入っています。これらの定義は、アプリケーションやオブジェクトが応答するメッセージを宣言しています。静的型定義を追加または変更すると、ToolTalk 型コンパイラがその型データベースを更新します。ttsession は起動時、これらの型ファイルを読み込みます。
TT_DB データベースは、rpc.ttdbserverd が作成します。tt_db ディレクトリには、このパーティション内のファイルと、そのファイルを処理対象とするパターンのセッションの関連付けが入っています。また、このパーティション内のファイルのオブジェクト仕様情報もすべて入っています。
tt_db データベースには現在、次の 10 個のファイルが入っています。
これらのファイルのアクセス権は、-rw-r--r-- に設定されています。
ToolTalk データベースサーバーのデーモンは、次の主な機能を実行します。
tt_file_join 呼び出しでファイルを結合したクライアントのセッション ID を格納する。
メッセージの処置が TT_QUEUED
で、しかもそのメッセージを処理できるハンドラがまだ起動されていないために待ち行列に入っているファイル配信範囲のメッセージを格納する。
ToolTalk のオブジェクト仕様を格納する。
ToolTalk ファイル名フレームマッピング API への要求に応答する。
通信しません。
小さなメッセージなら 1 秒あたり約 100 個です。性能は主に、各メッセージの受信側の数で決まります。つまり、どのパターンにも一致しない通知が最も安く、多くのオブザーバに一致するメッセージが最も高くなります。
制限はありません。ToolTalk メッセージのサイズや引数の個数に設計上の制限はありませんが、ToolTalk はメッセージデータを (クライアントのアドレス空間内の領域間、および RPC 接続を経由したサーバーとの間で) 何回かコピーします。たとえば、ToolTalk メッセージで 1M バイトのデータを送信すると、次のように少なくとも 4 回コピーされます。
アプリケーション領域から ToolTalk ライブラリ領域へ
ToolTalk ライブラリ領域から ToolTalk サーバーへ
ToolTalk サーバーから受信側のライブラリへ
受信側のライブラリから最終目的地へ
このメッセージを監視しているプロセスがあると、さらにコピー回数が増えます。また、ttsession プロセスはシングルスレッドであるため、コピー期間中は、このセッションに他のメッセージは配信されません。このため、非常に大きなデータを頻繁に送信する場合は、ToolTalk 以外の方法でデータを渡すよう検討する必要があります。
手続き的なメッセージで 1 つの受信者だけに一致させるより、直接処理する (つまり、TT_HANDLER
を使用してメッセージをアドレス指定する) 方が高速です。
ToolTalk サービスでは、ハードウェアによるブロードキャストやマルチキャストを使用しません。メッセージは、(ネットワークを経由するかどうかに関係なく) 該当セッションの ttsession プロセスに直接送信されます。パターンを登録すると、そのパターンも ttsession プロセスに直接送信されます。ttsession プロセスは、すべてのパターンに対してメッセージを照合し、メッセージに一致するパターンを登録してあるプロセスにだけメッセージを直接送信します。メッセージを処理対象とするプロセスがマシン上にない場合、そのマシンは起動されません。
使用しません。ToolTalk サービスは、負荷分散機構ではありません。同じパターンを持つプロセスを 2 つ登録してある場合、ToolTalk サービスはどちらか 1 つのプロセスを任意に選択して、一致するメッセージをすべてそのプロセスに配信します。プロセスがビジーの間はパターンを登録解除して、同時にパターンを登録解除する前に受信していた可能性のあるメッセージをすべて拒否すると、負荷を分散できます。
メッセージを処理するには、送信側クライアント、ttsession、受信側クライアントで約数百キロバイトのワーキングセットが必要です。クライアントがメッセージをタイムリに処理している限り、ToolTalk のメモリー条件は、時間が経過しても変わりません。
ttsession に障害が発生すると tt_fd が有効になり、ToolTalk API 呼び出しのほとんどが次のような TT_ERR_NOMP
エラーメッセージを返します。
No Message Passer |
このメッセージが返されると、ほとんどのアプリケーションは ttsession に何か問題が発生したものとして、ToolTalk メッセージの送受信を停止します。この状況から回復する方法を次に示します。
TT_ERR_NOMP
という状況を認識する。
tt_close を呼び出し、相手との接続を切断する。
ToolTalk サービスを再度初期設定する。
次の順序で呼び出す。
tt_open, tt_default_session_join, tt_fd
パターンをすべて再登録し、ptype を再度宣言する。
障害の発生した ttsession を再起動して障害発生箇所から継続する際、環境変数 TT_SESSION
の設定と、ルートの X Window System がある場合は TT_SESSION
プロパティ値を操作する必要がある場合があります。また、障害の発生したセッションの他の参加者も回復できるように、再起動したセッションと新しいセッションの ID を連絡する必要があります。
ttsession に障害が発生すると、次の項目は回復できません。
障害が発生したセッションの procid で登録したパターン
障害が発生したセッションの procid から出した要求で保留されているもの
障害が発生したセッションの procid で tt_message_send_on_exit 呼び出しに渡したメッセージ
セッションのプロパティ
セッションの待ち行列に入っているメッセージ
rpc.ttdbserverd が不意に終了すると、inetd は代わりに新しい rpc.ttdbserverd を起動します。データは一時的に使用できなくなりますが消失しません。ただし、API 呼び出しが TT_ERR_DBAVAIL
を返すことがあります。API 呼び出しが TT_OK
を返すと、dbserver は即座に、または障害回復記録を新しい dbserver が読んだ時点で、ToolTalk データベースを更新します。
ホストやリンクが停止したことを TCP が検知すると、TCP 接続は破棄されます。プロセスと ttsession の接続が破壊されると、ttsession はそのプロセスが終了したときと同じように動作します。パターンがすべて消去されるため、メッセージを送受信しようとすると、プロセスは TT_ERR_NOMP
というエラーメッセージを受信します。
tt_close を呼び出すと、ttsession は現在の procid だけを閉じます。現在の procid が最後の procid の場合は、tt_open 呼び出し以降に作成された ToolTalk の構造体をすべて消去します。tt_close は tt_fd が返したファイル記述子を使って呼び出さなければなりません。そうしないと、後で tt_open や close を呼び出すたびにファイル記述子のカウンタ値が増えます。
保証されます。メッセージは TCP/IP の RPC を使用して送信するため、配信の信頼性があります。
送信側と受信側の間では、メッセージの順序は決まっています。まず、プロセス A がメッセージ M1 を送り、その後でメッセージ M2 を送信し、これらのメッセージをプロセス B が受信する場合、プロセス B はメッセージ M2 を受信する前にメッセージ M1 を受信します。ただし、次の 2 つの例外があります。
プロセス B がメッセージ M1 を受信して拒否すると、メッセージ M1 は再度ディスパッチされてプロセス C に行きます。この間 (プロセス B がメッセージ M1 に対して応答するか拒否するかを決定している間)、ToolTalk サービスはメッセージの配信を継続します。このような場合は、後のメッセージが最初のメッセージを「追い越した」ように見えることがあります。
プロセス B へのメッセージが待ち行列に入っている場合、待ち行列に入る原因となったパターンの ptype をプロセス B が宣言した時点で、プロセス B 待ち行列に入っていたメッセージを受信します。しかし、プロセス B は実際は、プロセス A から次のメッセージをすべて受信するまで、待ち行列に入ったメッセージ (この場合はメッセージ M1 ) を受信しない場合があります。
これらは認証方法の種類です。
unix は、RPC 呼び出しでアプリケーションを呼び出しているエンティティの uid を教えます。dbserver は各 RPC 呼び出しに機密保護を実施し、デフォルト時はこの認証方法を使用します。
xauth はホームディレクトリ中の読み出し保護ファイルを使用して、X ディスプレイへのアクセスを制御します (これにより、ttsession へのアクセスも制御されます)。
できません。あるアプリケーションへのメッセージを他のアプリケーションが隠す機構を、ToolTalk サービスでは意図的に提供していません。
ありません。ToolTalk サービスの「プラグアンドプレイ」概念によれば、アプリケーションは個々のタスクに最適なツールを選択して、インストールしたりインストールを解除したりできます。プロトコル X に対して、アプリケーション A よりアプリケーション B の方が応答が良い場合、アプリケーション A のインストールを解除して、アプリケーション B をインストールできるようにプロトコル X を設計してください。
ファイルを配信範囲とするメッセージで待ち行列に入ったものは、配信範囲となるファイルと同じファイルシステム上のデータベースに格納されます。このデータベースを読むことができるのはスーパーユーザーだけであり、(ルートとして動作中の) ToolTalk データベースサーバーは、そのファイルの読み取り権を持つユーザーのプロセスだけにそのメッセージを渡します。
セッションを配信範囲とするメッセージで待ち行列に入ったものは、そのセッションを管理する ttsession のアドレス空間に格納されます。ttsession は、自分が動作している認証モードを満たすプロセスだけにそのメッセージを渡します。
保証されていません。
メッセージの行方を追跡するには、使用する ttsession のトレース出力をオンにしてください。これを行う最も簡単な方法は、関連する ttsession のトレース出力をオンにすることですが、次のコマンドを使って SIGUSR1 信号を ttsession の実行プロセスに送信する方法もあります。
kill -USR1 <unix_pid_of_the_ttsession_process> |
デバッグツールを隔離するには、「プロセスツリーセッション」モードを使用してください。このモードはセッション名を環境変数に設定して、該当する ttsession プロセスを見つけます。このモードを使用するには、次のように実行してください。
トレースモードをオンにして、プロセスツリーセッションを新しく起動します。
% ttsession -t -c $SHELL * * ttsession (version 1.3, library 1.3) * ttsession: starting % |
ttsession が動作を開始して該当する環境変数を設定し、指定されたコマンド ($SHELL) を生成します。この段階では、サブシェルを実行しています。このサブシェルから起動したコマンドはすべて、上記ので起動した ttsession を使用します。この新しい ttsession のセッション ID は、環境変数 TT_SESSION
に入っています。
サブシェルの中で次のテストプログラムを実行します。
% ./my_receiver & [1] 4532 % ./my_sender & .. and look at the output of the ttsession trace. |
テストが完了したら、サブシェルを終了します。
サブシェルの中で ToolTalk サービスを使用するツールを起動すると、X セッションの ttsession ではなく、プロセスツリーの ttsession が使用されるため未定義となります。
使用できます。ToolTalk API ヘッダーファイルは、C++ を扱えるようになっています。C++ を使用する際、tt_c.h はすべての API 呼び出しを extern C として宣言します。
ありません。ToolTalk サービスでは、パス名の明示的なホスト名修飾を許可していません。ファイル名の中にコロン (:) を使用すると、ToolTalk サービスはコロンの入ったファイル名を検索します。tt_message_file や tt_default_file を呼び出すと、使用中のマシンの画面に表示されるのと同じような形式で、指定したファイルの「実パス」が返されます。ToolTalk サービスでは、次のことを保証しています。
2 つのクライアントが、異なるマシン上にある同じ名前のファイルを配信範囲に指定した場合、各マシン上にファイルが実際にマウントされているかどうかにかかわらず、これらのクライアントは互いに交信できる。
ローカルで有効な、標準的なパス名が返される。
ToolTalk オブジェクトは、通常のオブジェクト指向言語によく出てくるオブジェクトとは少し異なっています。
otype と継承は実行専用です。2 つの仕様が同じ otype を持つことはできますが、プロパティが異なります。これらが共有するのは、otype の宣言のシグニチャで定義した操作だけです。otype の宣言の各シグニチャに対して、ptype を 1 つ指定しなければなりません。指定した ptype (プロセス型) は、この otype を持つオブジェクトに対する操作の「実行エンジン」です。仕様のファイル部は要求されたプロパティと同様、すべての仕様がファイル名を持たなければなりません。ただし、そのファイルが存在する必要はありません。仕様のファイル名部分にはいくつかの機能がありますが、その中には次のようなものがあります。
仕様を格納するホストやパーティションを指定する。
オブジェクトに対してグループ化機構を提供する。
あります。ToolTalk news グループは、alt.soft-sys.tooltalk です。共通デスクトップ環境 (CDE) は、新規のアプリケーションの統合やアプリケーションプログラムの起動時に ToolTalk を利用しているため、comp.unix.cde グループも役立つでしょう。