(57)【特許請求の範囲】
【請求項１】
予め特定タイプのメッセージの受信を申し込んだ購読アプリケーションを有するコンピュータベースの出版／購読システムにおいて、出版アプリケーションと購読アプリケーションとの間で保証付メッセージセッションを確立するためのコンピュータ実行方法であって、当該コンピュータ実行方法は下記を備えている：
出版アプリケーションにおいて、購読アプリケーションを特定する購読者名と、購読アプリケーションがメッセージを受信するアドレスと、保証付メッセージセッションを確立すべき前記特定タイプのメッセージに関連付けられこれを特定する主題名とを含む保証付メッセージ購読要求を受信する、
保証付メッセージ購読要求を受信して、出版アプリケーションにおいて、購読者名を台帳に追加することにより購読アプリケーションと保証付メッセージセッションを確立し、保証付メッセージセッションの確立を確認する確認メッセージを購読アプリケーションに通信し、
手順番号を保証付メッセージに割り当てることにより、保証付メッセージセッションにしたがって特定タイプの保証付メッセージの配送を試み、保証付メッセージに購読アプリケーションがメッセージを受信するアドレスを付け、出版アプリケーションからの保証付メッセージを購読アプリケーションに通信し、保証付メッセージ配送の試みを台帳に記録し、少なくとも出版アプリケーションが購読アプリケーションにおける保証付メッセージの受信を確認する確認メッセージを購読アプリケーションから受信するまで保証付メッセージを台帳に保持する。
【請求項２】
請求項１のコンピュータ実行方法において、
出版アプリケーションにおいて、手順番号によって特定された保証付メッセージが購読アプリケーションにて受信されたことを確認する確認メッセージを受信すると、手順番号によって特定された保証付メッセージが購読アプリケーションによって受信されたことを追加するように出版アプリケーションが台帳を更新することをさらに備えたもの。
【請求項３】
請求項１のコンピュータ実行方法において、
出版アプリケーションにおいて、手順番号によって特定された保証付メッセージが購読アプリケーションにて受信されたことを確認する確認メッセージを受信すると、出版アプリケーションが手順番号によって特定された保証付きメッセージを台帳から削除することをさらに備えたもの。
【請求項４】
請求項１のコンピュータ実行方法において、
出版アプリケーションにおいて、手順番号によって特定された保証付メッセージが購読アプリケーションにて受信されたことを確認する確認メッセージを受信すると、手順番号によって特定された保証付メッセージが送信された全ての購読アプリケーションが、手順番号によって特定された保証付メッセージの受信を確認したことを台帳が示していれば、出版アプリケーションが手順番号によって特定された保証付きメッセージを台帳から削除することをさらに備えたもの。
【請求項５】
請求項１のコンピュータ実行方法において、
出版アプリケーションが、手順番号によって特定された保証付メッセージの配送を試みた後、所定の時間内に購読アプリケーションから確認メッセージを受け取っていなければ、出版アプリケーションかから購読アプリケーションに対して、購読アプリケーションに手順番号によって特定された保証付メッセージの受信の確認を要求する確認要求を通信することをさらに備えたもの。
【請求項６】
請求項１のコンピュータ実行方法において、
台帳はファイルベースの台帳であり、出版アプリケーションおよび／または購読アプリケーションの終了と再スタートを超越して保証付きメッセージセッションが繰り返されることを特徴とするもの。
【請求項７】
請求項１のコンピュータ実行方法において、
購読アプリケーションとの保証付きメッセージセッションの確立前に、当該購読アプリケーションにより予め特定タイプのメッセージの申し込みを行われた出版アプリケーションは、当該出版アプリケーションが購読アプリケーションの存在を知ることなく、購読アプリケーションに通信されるメッセージを出版することを特徴とするもの。
【請求項８】
予め特定タイプのメッセージの受信を申し込んだ購読アプリケーションを有するコンピュータベースの出版／購読システムにおいて、出版アプリケーションと購読アプリケーションとの間で保証付メッセージセッションを確立するためのコンピュータ実行方法であって、当該コンピュータ実行方法は下記を備えている：
購読アプリケーションを特定する購読者名と、購読アプリケーションがメッセージを受信するアドレスと、保証付メッセージセッションを確立すべき前記特定タイプのメッセージに関連付けられこれを特定する主題名とを含む、購読アプリケーションからの保証付きメッセージ購読要求を出版アプリケーションに通信し、
購読アプリケーションにおいて、出版アプリケーションからの、保証付きメッセージセッションの確立を確認する確認メッセージを受信し、
購読アプリケーションにおいて、保証付きメッセージセッションにしたがって、手順番号によって特定される出版アプリケーションからの保証付きメッセージを受信し、
購読アプリケーションにおいて、手順番号によって特定される出版アプリケーションからの保証付きメッセージを受信すると、手順番号によって特定される保証付きメッセージの受信を示すため購読アプリケーションにより台帳を更新し、手順番号によって特定される保証付きメッセージが購読アプリケーションに受信されたことを確認する確認メッセージを出版アプリケーションに通信する。
【請求項９】
請求項８のコンピュータ実行方法において、
確認メッセージを出版アプリケーションに通信した後、特定の手順番号を有する保証付きメッセージの受信を確認するため、購読アプリケーションからの確認メッセージを要求する確認要求を出版アプリケーションから受信し、
台帳において特定の手順番号を有する保証付きメッセージが購読アプリケーションに受信されたかを確認し、もしそうなら、特定の手順番号を有する保証付きメッセージが購読アプリケーションにおいて受信されたことを確認する第２の確認メッセージを出版アプリケーションに通信することをさらに備えたもの。
【請求項１０】
請求項８のコンピュータ実行方法において、
出版アプリケーションへの確認メッセージの通信後、先の確認メッセージが出版アプリケーションから送信されたが購読アプリケーションが受信しなかった旨を示す手順番号を有する第２の確認メッセージを受信し、
購読アプリケーションにおいて先に受信されたことが台帳に示されている保証付きメッセージに関連付けられた手順番号を含む確認メッセージ要求を出版アプリケーションに通信することをさらに備えたもの。
【請求項１１】
請求項８のコンピュータ実行方法において、
台帳はファイルベースの台帳であり、出版アプリケーションおよび／または購読アプリケーションの終了と再スタートを超越して保証付きメッセージセッションが繰り返されることを特徴とするもの。
【請求項１２】
出版アプリケーションと購読アプリケーションが匿名出版／購読コンピュータシステムの一部を構築しており、保証付きメッセージセッションによって保証付きメッセージを購読アプリケーションに通信するための出版アプリケーションであって、当該出版アプリケーションは下記を備えている：
購読アプリケーションを特定する購読者名と、購読アプリケーションがメッセージを受信するアドレスと、保証付メッセージセッションを確立すべき前記特定タイプのメッセージに関連付けられこれを特定する主題名と含む保証付きメッセージ購読要求を受信する処理、
保証付きメッセージ購読要求の受信に対応して、出版アプリケーションによりメッセージ台帳に購読者名を追加することにより、購読アプリケーションと保証付きメッセージセッションを確立し、保証付きメッセージセッションの確立を確認する確認メッセージを購読アプリケーションに通信する処理、
保証付きメッセージセッションにしたがって、保証付きメッセージに手順番号を付与し、保証付きメッセージに購読アプリケーションがメッセージを受信するアドレスを付し、出版アプリケーションから購読アプリケーションに対して保証付きメッセージを通信し、保証付きメッセージの配送の試みを台帳に記録し、保証付きメッセージが購読アプリケーションにおいて受信されたことを確認する確認メッセージを出版アプリケーションが購読アプリケーションから少なくとも受信するまで保証付きメッセージを台帳に保持することにより特定タイプの保証付きメッセージの配送を試みる保証付き配送処理、
手順番号によって特定される保証付きメッセージが購読アプリケーションによって受信されたことを確認する確認メッセージを受信すると、出版アプリケーションは、手順番号によって特定される保証付きメッセージが購読アプリケーションによって受信されたことを示すために出版アプリケーションの台帳を更新する。
【請求項１３】
請求項１２の出版アプリケーションにおいて、出版アプリケーションにおいて、手順番号によって特定される確認メッセージを出版アプリケーションが受信すると、保証付き配送処理は、手順番号によって特定される確認メッセージを出版アプリケーションの台帳から削除することを特徴とするもの。
【請求項１４】
請求項１２の出版アプリケーションにおいて、出版アプリケーションにおいて、手順番号によって特定される確認メッセージを出版アプリケーションが受信すると、手順番号によって特定された保証付メッセージが送信された全ての購読アプリケーションが、手順番号によって特定された保証付メッセージの受信を確認したことを台帳が示していれば、手順番号によって特定された保証付きメッセージを出版アプリケーションの台帳から削除することを特徴とするもの。
【請求項１５】
請求項１２の出版アプリケーションにおいて、出版アプリケーションが、手順番号によって特定された保証付メッセージの配送を試みた後、所定の時間内に購読アプリケーションから確認メッセージを受け取っていなければ、保証付き配送処理が購読アプリケーションに、手順番号によって特定された保証付メッセージの受信の確認を要求する確認要求を通信することを特徴とするもの。
【請求項１６】
請求項１２の出版アプリケーションにおいて、
台帳はファイルベースの台帳であり、出版アプリケーションおよび／または購読アプリケーションの終了と再スタートにより保証付きメッセージセッションは繰り返されることを特徴とするもの。
【請求項１７】
請求項１２の出版アプリケーションにおいて、
特定の主題名を有するメッセージの受信を申し込んだ購読アプリケーションに、出版アプリケーションが購読アプリケーションの存在を知ることなく通信されるメッセージの内容に関連付けられた主題名とともにメッセージを出版するメッセージング処理をさらに備えたもの。
【請求項１８】
出版アプリケーションと購読アプリケーションが匿名出版／購読コンピュータシステムの一部を構築しており、保証付きメッセージセッションにより、保証付きメッセージを出版アプリケーションから受信するための購読アプリケーションにおいて、当該購読アプリケーションは下記を備えている：
購読アプリケーションを特定する購読者名と、購読アプリケーションがメッセージを受信するアドレスと、保証付メッセージセッションを確立すべき前記特定タイプのメッセージに関連付けられこれを特定する主題名とを含む保証付きメッセージ購読要求を、購読アプリケーションから出版アプリケーションに対し通信する処理、
購読アプリケーションにおいて、保証付きメッセージセッションの確立を確認する確認メッセージを出版アプリケーションから受信する処理、
購読アプリケーションにおいて、保証付きメッセージセッションにしたがって出版アプリケーションから、手順番号によって特定される保証付きメッセージを受信し、手順番号によって特定された保証付きメッセージを受信すると、手順番号によって特定される保証付きメッセージが受信されたことを示すために購読アプリケーションにおいて台帳を更新し、保証付きメッセージが購読アプリケーションにおいて受信されたことを確認する確認メッセージを出版アプリケーションに通信するための保証付き配送処理。
【請求項１９】
請求項１８の購読アプリケーションにおいて、確認メッセージを出版アプリケーションに通信した後、確認メッセージ処理は、特定の手順番号を有する保証付きメッセージを受信したことを確認する確認メッセージを購読アプリケションに要求する確認要求を出版アプリケーションから受信し、確認メッセージ処理は、特定の手順番号を有する保証付きメッセージが購読アプリケーションにおいて受信されたことが台帳に示されているかを確認し、もしそうなら、特定の手順番号を有する保証付きメッセージが購読アプリケーションにおいて受信されたことを確認する第２の確認メッセージを出版アプリケーションに通信することを特徴とするもの。
【請求項２０】
請求項１８の購読アプリケーションにおいて、確認メッセージを出版アプリケーションに通信した後、確認メッセージ処理は、先の確認メッセージが出版アプリケーションから送信されたが購読アプリケーションによって受信されなかったことを示す手順番号を有する第２の確認メッセージを受信し、確認メッセージ処理は、購読アプリケーションにおいて先に受信されたことが台帳に示されている保証付きメッセージに関連付けられた手順番号を含む確認メッセージ要求を出版アプリケーションに通信する
【請求項２１】
請求項１８の購読アプリケーションにおいて、
台帳はファイルベースの台帳であり、出版アプリケーションおよび／または購読アプリケーションの終了と再スタートを超越して保証付きメッセージセッションが繰り返されることを特徴とするもの。
【発明の詳細な説明】
【０００１】
【発明の背景】
【０００２】
【発明の技術分野】
本発明は、マルチポイントパブリッシュ／サブスクライブ通信に関し、より詳細には、マルチポイントコンピュータベースのパブリッシャとサブスクライバアプリケーションとの間の証明付メッセージの配送とキュー操作に関する。
【０００３】
【背景】
米国特許第５，５５７，７９８号、５，３３９，３９２号、５，２５７，３６９号、および５，１８７，７８７号に記載されているような代表的な匿名のパブリッシュ／サブスクライブ技術において、パブリッシャアプリケーションは、情報を、要求アプリケーションすなわちサブスクライバアプリケーションに対し、そのようなサブスクライバアプリケーションの番号、アイデンティティ、またはアドレスの、何れの情報も持たせることなく発行する。実際には、サブスクライバアプリケーションがなくてもよい。サブスクライバについて知る代わりに、パブリッシャは、単にコンテクストまたはサブジェクト「ラベル」を発行メッセージに添付して情報を発行するだけである。サブスクライバは次いで、コンテンツラベルにより所望メッセージを識別し、所望コンテンツに関連するそれらのメッセージだけを受信する。
【０００４】
このようなパブリッシュ／サブスクライブ、コンテンツベースのアドレス指定方式の利点は周知であり、それら利点には、サブスクライバとパブリッシャを相互に切り離す能力が含まれる。この非干渉化によって、パブリッシャとサブスクライバは、アイデンティティ、ロケーションまたはアドレスの情報、あるいは互いの通信プロトコルの情報をいずれも用いることなく操作できる。これによって提供される柔軟性は極めて高いので、このようなコンテンツ／サブジェクトベースのアドレス指定通信環境が、次第に普及してきている。
【０００５】
残念なことに、これらのシステムのまさしくその利点（匿名の非干渉性等）が、ＴＣＰ等の従来の信頼できるメッセージ送信プロトコルの利用を妨げている。ＴＣＰおよび他の信頼できるメッセージ送信プロトコルは、ポイントツーポイント（point - to - point）タイプの通信にだけ適用する。これらのポイントツーポイント通信では、メッセージ送信者および受信者は、相互に直接リンクされており、従って、互いのアドレスおよびロケーションを知っている。
【０００６】
残念なことに、これらの信頼できるメッセージ送信プロトコル（メッセージの到着と到着順序を保証するプロトコル）は、アプリケーション間での事前情報を必要とする。従って、それらは、普通のパブリッシュ／サブスクライブ環境に適用できない。
【０００７】
更に、このような信頼できる、あるいは証明付のメッセージ配送は、極めて重要である。例えば、証明付配送は、送信アプリケーションが、送信した各メッセージに対する個々の配送確認を必要とする場合に適切である。例えば、移動している営業マンは、売上高をラップトップコンピュータで計算し、オフィスにいるスーパーバイザーにそれらを送信する。ユーザーは、データが到着して、それがスーパーバイザーの販売報告書に入れられたことを確実に知っていなければならない。
【０００８】
証明付配送はまた、受信アプリケーションに余裕がなくて何れのメッセージも失ってしまう場合にも好適である。例えば、在庫品の売買注文を処理するアプリケーションでは、各注文は重要である。何れかの注文が脱けてしまうと、在庫記録は不正確になる。
【０００９】
加えて、証明付配送は、特定のサブジェクトに関する各メッセージが、そのサブジェクトを持つ前回のメッセージにおける情報を基にしている場合に適切である。例えば、送信プログラムは、受信データベースを更新して、レコード内のデータの一部を寄稿するが、データの他の部分を変えずに残す。データベースは、全ての更新が、それらの送信順序で到着する場合にのみ正しい。
【００１０】
更に、証明付配送は、例えばいくつかのモバイルラップトップコンピュータが相互に通信しなければならないアプリケーション等、不連続ネットワーク接続のような断続的な物理的コネクティビティの状況において適切である。モバイルユニット間の接続は、散発的なものであり、適切な接続が回復するまで、メッセージの信頼性の高い記憶装置を必要とする。
【００１１】
従って、証明付メッセージ送信の利点、およびコンテンツベースで匿名のパブリッシュ／サブスクライブ環境の利点の両方を備えることに対する極めて現実的なニーズが存在する。
【００１２】
【発明の概要】
要約すると、本発明によれば、パブリッシャは、多数の未知のサブスクライバにメッセージを発行する。本明細書中で用いる「パブリッシャ」と「送信者」は同義で用いられ、「サブスクライバ」と「リスナ」も同義で用いられることに留意されたい。
【００１３】
メッセージは、サブジェクトまたはコンテンツを示し、代表的なコンテンツベースのパブリッシュ／サブスクライブプロトコルを用いて発行される。所定のコンテンツに関する情報の受信に関心を持つサブスクライバは、パブリッシャを知ることなくメッセージを受信する。このように、パブリッシャ情報は、サブスクライバに透過的なまま保たれる。
【００１４】
証明付メッセージ送信が必要とされる環境で、本発明はメッセージ配送トラッキングセッションの確立を提供する。このセッションは、トラッキングに使用される名前および台帳を含む。
【００１５】
これらの機能を用いることによって、システムは、メッセージが配送されない場合、メッセージの配送を追跡し、パブリッシャ／送信者に通知することができる。本発明のひとつの実施の形態では、配送試行は、予め設定された時間（または配送試行数）の間繰り返されて、配送を確実にするか、または確実にしようとする。
【００１６】
本発明はまた、証明付配送のためのキュー操作メッセージまで拡張する。この拡張は、証明付配送が、ｎ人の見込まれる受信者グループのひとつに対して必要とされる場合に発生する。システムは、ひとつの（そして全てではない）グループがメッセージを受信することを確実にする。これは、グループのメンバにそれらの可用性または許容量を示させ、システムに最も高い可用性を持つサブスクライバ（リスナ）までメッセージのルートを決めさせることによって達成される。
【００１７】
このコンセプトの拡張は、それぞれがタスクを達成することができる、ｎ人の見込まれるタスク実行者に対するタスクのスケジューリングである。各タスク実行者は、タスクを達成する可用性／能力をシステムに通知する。タスクは次いで、その可用性に基づく評価に従い各タスク実行者のために送信／キュー操作される。
【００１８】
【発明の利点】
本発明は多くの利点を有する。例えば、それは以下を提供する：
確実性
証明付配送は、送信された順序で、全てのメッセージが、それぞれ意図した受信者に到達することをアプリケーションプログラムに保証する。配送できない場合、送信者と、任意ではあるがリスナの両方は、各未配送メッセージに関する明確な情報を受信する。
利便性
一旦、プログラムが証明付メッセージを送信すると、システムは、配送が成功するまで、または、メッセージの期限が切れるまで、配送試行を続ける。
管理
アプリケーションプログラムは、各メッセージに対する明確な期限を決定する。送信アプリケーションは、特定のリスニングセッションに対して証明付配送を却下することができる。
詳細
システムはまた、アドバイザリーメッセージを付与して、アプリケーションプログラムへ、配送に関するすべての重要イベントを通知することができる。
【００１９】
プロセスベース、またはファイルベースの記録
システムはまた、各メッセージの状態を台帳に記録することができる。アプリケーションプロセスの間だけ証明を必要とするアプリケーションは、プロセスベースの台帳を選択できる。プロセス終了および再起動を超越する証明を必要とするアプリケーションは、ファイルベースの台帳を選択できる。
【００２０】
本発明を、添付図面を参照して以下詳細に説明する。
【００２１】
【詳細な説明】
概要
図１に、パブリッシャアプリケーション（送信者）１０と、複数のサブスクライバーアプリケーション（リスナ）２０、２０’および２０’’を示す。本発明の好ましい実施の形態では、パブリッシャとサブスクライバ（単数または複数）は、アプリケーション間のデータ経路を備えるネットワーク３０により相互接続されるひとつ以上のコンピュータに基づくソフトウェアアプリケーションである。パブリッシャ１０とサブスクライバ２０（単数または複数）は、コンテンツベースの通信プロトコルを実装するのが好ましく、それによってパブリッシャは、メッセージのコンテンツのみを示すメッセージを、サブスクライバ２０が使用するアイデンティティまたはプロトコルを知ることなく発行する。これらのアプリケーション間通信は、（パブリッシャ／送信者に関する）通信デーモン１２および（サブスクライバ／リスナ２０、２０’および２０’’に関する）通信デーモン２２、２２’および２２’’によって確立される。この図に示す編成
（構成）は、周知であり、先に引用した特許を含めて多くの出版物に記載されている。
【００２２】
より詳細に以下記載するように、リスナ２０は、特定のパブリッシャ１０に登録して、証明付メッセージを受信することができる。この通信は、サブスクライバの名前、その「受信トレイ」アドレス、および必要とする情報があるメッセージのサブジェクト／コンテンツを含む。従って、パブリッシャ１０は、証明付メッセージの受信を望む全てのサブスクライバに関するサブスクライバ名および受信トレイのリストを有する（しかし、サブスクライバに関する他の情報は何も知らない）。従って、パブリッシャ／送信者１０は、それが送信する各メッセージの受信通知を予期し；その受信通知は、サブスクライバ／リスナ２０、２０’および／または２０’’から受信する。重要なことには、パブリッシャ／送信者１０が受信通知を受信しない場合、通常、所定の時間または「送信」回数の間、受信通知要求メッセージを送信する。
【００２３】
サブスクライバが保証されたメッセージ配送を持つことを望む場合、パブリッシャは、サブスクライバ受信の受信通知が発生するまで、ディスク（または他の記憶装置）にメッセージを保存できる。このように、メッセージが時間切れになるまで、サブスクライバは、後日、パブリッシャと交信することによってメッセージを受信することができる。これは通常、メッセージが、それらのシーケンスに大きく左右されるか、または、前回のメッセージを基にする場合に生じる。これらの環境では、紛失／未受信メッセージは、大きな損害であり得る。また、これらでは（そして、本発明の最良な証明付メッセージ送信アプリケーションでは）、各証明付メッセージは、トラッキング番号を割り当てられる。これは、送信者およびリスナ／サブスクライバの両者が、メッセージの受信および／または紛失をモニタすることを許可する。
【００２４】
多くのアプリケーションにおいて、データ通信は非常に信頼できるが、ある状況では、アプリケーションはより一層強力な配送保証を必要とする。証明付配送の特長は、プロセスおよびそれらのネットワーク接続が不安定である状況においてでさえも、より高い配送の確実性を提供することである。
【００２５】
証明付メッセージ送信
配送トラッキングセッションのイネーブル化
証明付配送へ向かう第１のステップは、配送トラッキングセッションを可能にすることである。配送トラッキングセッションは、通常の匿名パブリッシュ／サブスクライブセッションとして開始し；セッションに情報を追加することを可能にし、その結果、証明付配送プロトコルに関与できるようにする。追加情報は、名前および台帳を含む。
【００２６】
配送トラッキングセッションは、通常のセッションができるように、メッセージを送受信することができる。加えて、配送トラッキングセッションは、証明付配送コール（すなわち、ｒｖｃｍライブラリ層におけるコール）に関与することができ；通常のセッションは、これらのコールに関与することができない。（非対称性に留意されたい。配送トラッキングセッションは、通常のコールに関与できるが、通常のセッションは、証明付配送コールに関与できない。）
名前
各配送トラッキングセッションは、再使用可能、または再使用不可能としてもよい名前を有する。名前は、他の配送トラッキングセッションに対するセッションを識別し、セッションからアウトバウンドメッセージを識別するラベルの一部である。
【００２７】
名前は、プログラムがそれを明示的にイネーブルコールに対して供給する場合に再使用可能である。再使用可能名でのセッションが、ファイルベースの台帳を有する場合、それは、セッション終了およびプログラム再起動を超越して証明付配送の継続を許可する継続的な通信者の実例として動作する。
【００２８】
２つの配送トラッキングセッションは、同じ再使用可能名をバインドしてはならず、すなわち、あらゆる時点において、それぞれ再使用可能名は、一意的でなければならない。セッションは、連続的に名前を再使用してもよいが、同時に再使用してはならない。このルールに違反することは、証明付配送を著しく妨げ得る。普通、セション名は、サブジェクト名と同じシンタックスを有する。
【００２９】
プログラムは、コールがセッションに対して一意的で使用不可能な名前を作成する場合、イネーブルコールにおいて名前を省略してもよい。何れのコンピュータ上の他のセッションも、決して同じ名前を持つことができない。結果として、再使用不可能名でのセッションは、一時的な通信者として動作し、どの後続のセッションも、セッションの証明付配送動作を続けることができない。
【００３０】
配送トラッキングセッションのイネーブル化は、それに対する台帳を作成する。証明付配送ソフトウェアは、すべての未決着アウトバウンド証明付メッセージ、このセッションが受信する（インバウンド）証明付メッセージに対するすべてのサブジェクト、および他の協働配送トラッキングセッションに関する情報を記録する台帳を使用する。
【００３１】
プログラムは、台帳を台帳ファイル内に記憶していてもよく、または実行プログラム内部のプロセスベースの記憶装置内に記憶していてもよい。（セッションが台帳ファイルを使用する場合でさえも、それは効率のために時々プロセスベースの記憶装置内に台帳の一部を複製してもよい；しかし、プログラマはこの複製に依存することはできない。）
台帳ファイルは、一意的でなければならない。すなわち、２つのセッションは、（並行して）同じ台帳ファイルを使用してはならない。オペレーティングシステムがローディスクデバイス（また、ローパーティションとも称する）をサポートする場合、デバイスを台帳ファイルとして指定することができる。
【００３２】
ファイルベースの台帳および再使用可能名でのセッションは、セッションの終了を超越して拡張できる証明付配送動作を有する継続的な通信者としての資格を得る。
【００３３】
ラベル付メッセージ
ラベル付きメッセージは、それが補足情報を含むことを除いて、通常のメッセージに類似しており、それを、配送トラッキングセッションが、証明付メッセージ配送のために使用できる：
メッセージを送信した配送トラッキングセッション名。
【００３４】
送信セッションによって割り当てられたシーケンス番号。
【００３５】
ラベル付メッセージの送信
何れの配送トラッキングセッションも、証明付メッセージ配送ライブラリ層における送信コールを使用することにより、ラベル付メッセージを送信できる。このような配送トラッキング送信コールの実施例を以下の表に示す：
【表１】
0003860966.tif 000002
ラベル付メッセージの受信
明確にするため、２種類のリスニングエンドポイントを区別する。通常のリスナは、Ｃファンクションの rv_ListenInbox() または rv_ListenSubject() 等の通常のリスニングコールを用いて作成されるリスナである。配送トラッキングリスナは、Ｃファンクションの rvcm_ListenInbox() または rvcm_ListenSubject() 等の配送トラッキングリスニングコールを用いて作成されるリスナである。
【００３６】
リスニングエンドポイントのいずれのタイプもラベル付メッセージを受信することができ、それは、通常のリスナと同様に、証明付配送ライブラリによって作成される配送トラッキングリスナである。
【００３７】
通常のリスナがラベル付メッセージを受信する場合、それは、通常のメッセージであるかのように、適切なコールバックファンクションにそれを付与する。すなわち、それは、ラベル付メッセージを区別する補足情報を無視する。
【００３８】
配送トラッキングリスナがラベル付メッセージを受信する場合、その動作はコンテクストに依存する：
配送トラッキングリスナが証明付配送に登録されると、それは補足情報をコールバックファンクションに付与する。
【００３９】
配送トラッキングリスナが証明付配送に登録されないと、それは、ゼロのシーケンス番号を用いて、「空(null)」の送信者名をコールバックファンクションに付与する。
【００４０】
加えて、適切であれば、証明付配送ライブラリは、送信者がリスナを証明付配送に登録することを自動的に要求する。
【００４１】
証明付配送の発見および登録
発見
配送トラッキングリスナが、ラベル付メッセージを、リスナの台帳に記載されていない配送トラッキング送信者から受信する場合、リスナは、メッセージのサブジェクトで送信者を「発見する」。
【００４２】
３つのイベントが、発見をフォローする：
証明付配送ソフトウェアは、サブジェクトに関するメッセージのソースとして、送信者の名前をリスナの台帳に加える。
【００４３】
リスニングプログラムにおける証明付配送ソフトウェアは、送信プログラムと交信して、サブジェクトの証明付配送に対する登録と合意に関する情報を要求する。
【００４４】
証明付配送ソフトウェアは、ＲＥＧＩＳＴＲＡＴＩＯＮ．ＤＩＳＣＯＶＥＲＹアドバイザリをリスニングプログラムに付与する。
登録
配送トラッキング送信者が、登録要求を配送トラッキングリスナから受信する場合、送信者は、自動的に要求を受け入れる。承認は、これら４つのイベントから構成されている：
証明付配送ソフトウェアは、リスナをサブジェクトの証明付配送に登録し、その事実を送信者の台帳に記録する。
【００４５】
送信プログラムにおける証明付配送ソフトウェアは、要求された登録が受け入れられたことをリスナーセッションに通知し、送信者は、サブジェクトに関する証明付配送の責務を受け入れる。
【００４６】
証明付配送ソフトウェアは、ＲＥＧＩＳＴＲＡＴＩＯＮ．ＲＥＱＵＥＳＴアドバイザリを送信者セッションに付与し、それに新規登録リスナを通知する。
【００４７】
リスニングプログラムにおける証明付配送ソフトウェアが、承認返答を受信する場合、それはＲＥＧＩＳＴＲＡＴＩＯＮ  ＣＥＲＴＩＦＩＥＤアドバイザリをリスナーセッションに付与する。
【００４８】
証明付配送合意
登録および承認に続き、送信者およびリスナは、サブジェクトに関する証明付配送合意を有する。
【００４９】
送信者は、リスナから配送確認を受信するまで（または、メッセージの期限が切れるまで）そのサブジェクトに関する各アウトバウンドメッセージの記録、およびその台帳にメッセージを保持することに対して責任を負う。
【００５０】
返信では、リスナは、各メッセージの配送確認、および、メッセージがシーケンスから外れて到着する場合の再送要求に対する責任を負う。
【００５１】
システムは、自動的にこのアカウンティングの全てを整える。送信およびリスニングプログラムは、これらのプロトコルに直接関与せず、証明付配送ライブラリコールを用いて送信およびリスニングすることにより、間接的にのみ関与する。
【００５２】
証明付配送合意は、一方向のみ、つまり送信者からリスナへ適用することに留意されたい。双方向会話は、別々の２つの証明付配送合意を必要とする。
【００５３】
本発明者は、証明済送信者と証明済リスナとして証明付配送合意における２名の参加者について言及し、それらの間で流通するラベル付メッセージが証明付メッセージであることを言及する。用語において、証明付配送合意を確立する前では、参加者は、配送トラッキング送信者およびリスナであり；その後では、それらは証明済送信者およびリスナであるという、微妙な相違に留意されたい。ラベル付メッセージは、送信者および受信者が証明付配送合意を保守する場合、証明付メッセージだけである。
【００５４】
証明付メッセージの配送
一旦、配送合意が適当となれば、（証明済送信者から証明済リスナへの）サブジェクトに関する全ての後続メッセージは、証明付メッセージである。各証明付メッセージは、一連のプロトコルイベントを作成する：
システムが証明付メッセージをリスニングコールバックファンクションに付与する場合、それは、送信ソフトウェアによって（自動的に）割り当てられるシーケンス番号と発行者名を含む。
【００５５】
コールバックファンクションが戻る場合、証明付配送ソフトウェアは、自動的に送信者への配送を確認し、確認を台帳に記録する。（プログラムは、この動作を無効にでき、明示的に配送を確認できる。）
確認が送信プログラムに到達する場合、証明付配送ソフトウェアは、配送を送信者の台帳に記録し、ＤＥＬＩＶＥＲＹ．ＣＯＮＦＩＲＭアドバイザリを送信者セッションに付与する。
【００５６】
確認がこのメッセージに対するすべての証明済リスナから到着した場合、証明付配送ソフトウェアは、メッセージを送信者の台帳から削除し、ＤＥＬＩＶＥＲＹ．ＣＯＭＰＬＥＴＥアドバイザリを送信者セッションに付与する。
【００５７】
配送の自動確認
証明済リスナのデフォルト動作は、データコールバックファンクションからの返信により自動的にメッセージ配送を確認することである。プログラムは、特定のリスニングエンドポイントに対して（他のリスニングエンドポイントに影響を及ぼすことなく）選択的にこの動作を無効にできる。
【００５８】
自動確認を無効にすることによって、リスナは、各インバウンド証明付メッセージを明示的に確認する責任を負う。
【００５９】
インバウンドメッセージの処理が、他のスレッドにおける計算、データベースクエリー、または追加のネットワーク通信等の非同期アクティビティを伴う場合、自動確認を無効にすると考えられたい。
【００６０】
確認の要求
証明済送信者が（例えば、ネットワーク不具合のため）即座に配送確認を証明済リスナから受信しない場合、送信プログラムにおけるシステムは、自動的に確認を要求する。各要求の後、それはＤＥＬＩＶＥＲＹ．ＮＯ＿ＲＥＳＰＯＮＳＥアドバイザリを送信セッションへ付与する。
【００６１】
リスナが確認に対する要求を受信する場合、それは、その台帳をチェックし、既に確認したメッセージの受信を再確認する。（この動作は、プログラムが自動確認を使用するか、それを無効にするかにかかわらず一致する）
【００６２】
シーケンスおよび再送信
配送トラッキング送信者は、各アウトバウンドサブジェクトに対して連続的にシーケンス番号を割り当てるので、シーケンス番号は、特定のサブジェクトに関する送信者からのメッセージの順序を反映する。
【００６３】
証明付配送ソフトウェアが、証明付メッセージを証明済リスナに付与する場合、それは、送信者が送信したシーケンスを保存する。メッセージがシーケンスから外れて到着する場合、リスナにおける証明付配送ソフトウェアは、先行メッセージの全てが利用可能となるまで、それをコールバックファンクションに付与しない。
【００６４】
例えば、証明済リスナは、サブジェクトＦＯＯに関する証明付配送をＢＡＺという名前の送信者から受信している。受信し、メッセージ番号３２を付与した後、到着する次のメッセージは、メッセージ３５である。証明付配送ソフトウェアは、それが最初にメッセージ３３および３４を付与できるまで、メッセージ３５を保持する。
【００６５】
一方、ＦＯＯでの証明付配送ソフトウェアは、Ｂａｚからのメッセージ３３および３４の再送信を要求する。それらのメッセージに関する期限が切れる場合、そのため、ＢＡＺがもはやそれらをその台帳に持っていない場合、証明付配送ソフトウェアは、ＤＥＬＩＶＥＲＹ．ＵＮＡＶＡＩＬＡＢＬＥアドバイザリをリスナに付与して、メッセージ３３および３４がもはや利用可能でないことを示す。次いで、それはメッセージ３５をデータコールバックファンクションに付与する。
【００６６】
継続的な通信者
本発明者は、（１４４）ページ、名前セクションに継続的な通信者のコンセプトを導入した。再使用可能な名前およびファイルベースの台帳によって、継続的な通信者は、セッションまたはプロセスの終了および再起動を超越して証明付配送を継続できる。
【００６７】
実施例
実施例としてのアプリケーションシステムを考えられたい。ここで、アプリケーションプログラムＪＯＥは、重要情報を生成して、サブジェクトＲＥＭＥＭＢＥＲ．ＴＨＩＳに関する証明付メッセージでそれをアプリケーションプログラムＳＵＥに送信する。受信により、ＳＵＥは情報をデータベースに記憶する。
【００６８】
ＪＯＥまたはＳＵＥの何れかが不意に終了する場合、証明付メッセージがデータベースへのエントリのためにその後も到着することが非常に重要である。この結果を確実にするために、両プログラムは継続的な通信者を表わさねばならず、すなわち、両プログラムは、再使用可能な名前（ＪＯＥ＿ＰＣおよびＳＵＥ＿ＰＣ）でセッションを可能にし、各プログラムはファイルベースの台帳を保持する。加えて、ＳＵＥは、それがセッションＳＵＥ＿ＰＣを可能にする場合、旧いメッセージを必要とする。
【００６９】
操作の間、ＪＯＥはサブジェクトＲＥＭＥＭＢＥＲ．ＴＨＩＳに関するメッセージ番号５７を送信するが、メッセージ５３〜５６に対する配送確認をそれまでに受信していない。ＳＵＥは、ハードウエアの故障が突然起こって、終了するときに、メッセージ５３を処理している。一方、ＪＯＥはメッセージ５８〜７７を送信し続ける。
【００７０】
コンピュータが再起動し、ＳＵＥが再起動する。ＳＵＥ＿ＰＣ用の台帳ファイルは、メッセージ５２が受信され、ＪＯＥ＿ＰＣと同じ所定のパブリッシャに対し、サブジェクトＲＥＭＥＭＢＥＲ．ＴＨＩＳに関して確認されたことを示す。再起動において、ＳＵＥ＿ＰＣは、ＪＯＥ＿ＰＣと交信し、それらの証明付配送合意を復旧する。ＪＯＥが承認する場合、ＪＯＥ＿ＰＣは、そのサブジェクトに関する記憶済メッセージ５３〜７７を再送信する。
【００７１】
上記のシナリオにおいて、以下に注意することが重要である：
ＳＵＥは、いかなるＲＥＭＥＭＢＥＲ．ＴＨＩＳメッセージも紛失していない。しかし、新規ＳＵＥは、旧いＳＵＥによるメッセージ５３の部分的な処理により生じた何れの困難も上品に修正しなければならない。
【００７２】
ＪＯＥおよびＳＵＥは、ブロードキャストサブジェクト名を使用して通信しており、受信トレイ名は使用していない。受信トレイ名は一意的なので、それらが、セッション終了および再起動を超越して継続することはできない。
【００７３】
リスナの予期
ある状況では、配送トラッキング送信者は、それまでリスニングを開始しなかった継続的な通信者からの証明付配送に対する要求を予期できる。
【００７４】
データベースプログラム（ＤＢ）がサブジェクトＳＴＯＲＥ．ＴＨＩＳを有する全てのメッセージを記録する実施例について考えられたい。プログラムＤＢは、ＤＢ＿ＰＣという名の継続的な通信者のインスタンスを生成するセッションを可能にする。サブジェクトＳＴＯＲＥ．ＴＨＩＳを有するメッセージを送信する全てのプログラムは、この記憶メカニズムに依存する。
【００７５】
そのような送信プログラムのひとつは、ＪＡＮである。ＪＡＮが起動するときはいつでも、ＤＢ＿ＰＣがサブジェクトＳＴＯＲＥ＿ＴＨＩＳの証明付配送を要求することを、予期できる。ＪＡＮは起動するが、ＤＢは実行しておらず、またはネットワーク切断がＪＡＮをＤＢから切り離していると仮定する。最終的にはＤＢ＿ＰＣからＳＴＯＲＥ．ＴＨＩＳに対する登録要求を受信することを予期して、ＪＡＮは、追加リスナーコールを行う。ＪＡＮ内部のソフトウェアが、まるでサブジェクトＳＴＯＲＥ．ＴＨＩＳに対するＤＢ＿ＰＣとの証明付配送合意を有するように機能するという効果がある。それは、（そのサブジェクトに関する）アウトバウンドメッセージをその台帳内に記憶する。ＤＢが再起動するか、またはネットワークが再接続する場合、ＪＡＮは、自動的に全ての記憶済メッセージをＤＢに再送信する。
【００７６】
証明付配送のキャンセル
リスナおよび送信者の両方は、証明付配送合意をキャンセルすることができる。
【００７７】
リスナは、以下に一覧にするコールを使用して、リスニングエンドポイントを閉じることによりキャンセルする。閉じたエンドポイントとの証明付配送合意を有する送信者は、ＲＥＧＩＳＴＲＡＴＩＯＮ．ＣＬＯＳＥＤアドバイザリを受信する。ＨＯＳＴ．ＬＩＳＴＥＮ．ＳＴＯＰアドバイザリは、他のアプリケーションに変更を通知する。
【００７８】
送信者は、特定のリスナへの特定のサブジェクトの証明付配送をキャンセルすることができる。送信者プログラムは、その台帳からリスナへのサブジェクトの配信に関する全ての情報を削除する。送信プログラムは、ＲＥＧＩＳＴＲＡＴＩＯＮ．ＣＬＯＳＥＤアドバイザリを受信する。リスニング通信者が、利用可能（実行中および到達可能）である場合、それは、ＲＥＯＩＳＴＲＡＴＩＯＮ．ＮＯＴ＿ＣＥＲＴＩＦＩＥＤアドバイザリを受信する。（リスナーコールの却下とは異なり、これらのコールは、後続の登録要求の拒否の原因にはならない。）
【００７９】
証明付配送の却下
前述のように、送信者は全ての登録要求を自動的に承認する。これは、送信プログラムがリスニングセッションに対する証明付配送を明示的に却下する場合を除いて、真実である。リスナを却下するコールは、（全てのサブジェクトに関する）リスナーセッションとの既存の証明付配送合意をキャンセルし、証明付配送ソフトウェアにリスナーセッションからの後続の登録要求を自動的に拒否させる。
【００８０】
送信者がリスナを却下した場合、登録と接続するイベントは発生しない。代わりに、送信者における証明付配送ソフトウェアは、リスナーセッションに要求が却下された旨を通知する。リスニングプログラムにおける証明付配送ソフトウェアが拒否通知を受信する場合、それはＲＥＯＩＳＴＲＡＴＩＯＮ．ＮＯＴ＿ＣＥＲＴＩＦＩＥＤアドバイザリをリスニングセッションに付与する。
【００８１】
リスナーコールの許可は、それより前のリスナーコール却下の効果に取って代わり、リスナーセッションからの後続の登録要求が成功することを可能にする。
【００８２】
登録要求に対する無応答
登録要求が配送トラッキング送信者に全く到達しない、または、承認通知がリスニングプログラムに全く到達しないことは（例えば、ネットワーク不具合または送信プログラムの終了のため）あり得る。送信者から応答なく、登録への繰返しの試行の後、リスニングプログラムにおける証明付配送ソフトウェアは、ＲＥＧＩＳＴＲＡＴＩＯＮ．ＮＯ＿ＲＥＳＰＯＮＳＥアドバイザリをリスニングセッションに付与する。応答のない登録への数回の試行の後、リスナは要求を送信するのを中止する。
【００８３】
再使用可能名
継続的な通信者を表すセッションは、再使用可能な名前を必要とする。再使用可能名は、サブジェクト名に対するシンタックスに従わなければならない。再使用可能名は、ワイルドカード文字を含んではならない。再使用可能名は、予約エレメント（＿ＩＮＢＯＸ、＿ＲＶまたは＿ＬＯＣＡＬ等）で開始してはならない。最高のパフォーマンスのために、再使用可能名は、２、３文字だけの、普通３つか４つのエレメント未満で、合計５０文字未満の、短いものにすべきである。
【００８４】
台帳記憶モード
各配送トラッキングセッションは、台帳に情報を記録し、それはアプリケーションプロセス内部の記憶空間を占有する。また、継続的な通信者を表すセッションは、ファイルに台帳の複製を保持しなければならない。ファイルベースの台帳は、セッション（またはプロセス）の終了および再起動を超越して証明付配送情報を保存する。
【００８５】
この特長は、２つの関連コストを有する：
台帳ファイルは、ディスクスペースを消費する。
【００８６】
アプリケーションプログラムは、各重要イベントで台帳ファイルを更新するために一時中断する。
【００８７】
一時的な通信者は、これらのコスト（それらが台帳ファイルを使用しないから）を払う必要はない。しかし、プロセスベースの記憶装置での台帳保持は、プロセスメモリを消費する。
【００８８】
台帳サイズ
台帳のサイズは、いくつかの要因に依存し、最も重要なものは、記憶データの保存率である。すなわち、台帳は、不完全に配信されたメッセージの累積的な長さに応じて早く厚くなってしまう。
【００８９】
プログラム開発者は、台帳の予想サイズを見積ることができ、プロセスが充分なメモリを割り当てて、それを含むことができるよう確保しなければならない。ファイルベースの台帳に対しては、プロセスアプリケーション用の必要メモリがファイルベースの台帳を利用する場合に変化するため、充分なディスクスペースが同様に利用可能であるよう確保すること。
【００９０】
イベントマネージャ
システムの証明付配送は、タイマーおよびＩ／Ｏイベントに対するイベントマネージャに依存する。アプリケーションが配送トラッキングセッションを可能にする場合、そのセッションはイベント管理セッションでなければならない。
【００９１】
非同期セッション
同期セッションは証明付配送コールに効力がなく、全ての配送トラッキングセッションは、非同期のイベント管理セッションでなければならない。
【００９２】
分散キュー
システムはまた、ｎのうちのひとつの証明付配送のための分散キューの使用も提供する。特に、システムは、「ｎのうちのひとつ」配送メカニズムにおける証明付／保証付配送に加えて、メッセージの分散キュー操作を備える。この配送メカニズムを、図２に示し、単一のパブリッシャ２０２が、３人の登録サブスクライバ２０４、２０６および２０８それぞれにメッセージを発行している。サブスクライバのうちのひとつ、２０６は、ｎ人のサブスクライバの大きなグループである。
【００９３】
分散キュー操作は、登録サブスクライバ２０６内のすべてのｎ人のサブスクライバが、パブリッシャ２０２によって発行されるすべてのメッセージを得るという望ましくない問題を扱う。例えば、グループ２０６内のｎ人のサブスクライバのそれぞれが、処置を取るので、望ましくないだろう。加えて、各サブスクライバがメッセージを受信する（そして、おそらく、それに応答する）ことになっていると、これは、更なるネットワーク帯域幅を消費する。
【００９４】
それにもかかわらず、グループ２０６内のｎ人のサブスクライバのうちの少なくとも一人にとって、メッセージを受信することが、絶対に必要である（それ故、証明付／保証付配送が必要である）。すなわち、理想的に、システムは、メッセージをｎ人のサブスクライバ２０６のうちの一人だけに配送しなければならない。この種の状況は、大人数ｎのサブスクライバ２０６が、フォールトトレランスおよび／または負荷平衡化の所望レベルを備えることを必要とされる場合に生じる。フォールトトレランスは、アプリケーションが不安定であるか、メッセージ配送が絶対的に重大である状況において重要である。
【００９５】
本発明のシステムでは、グループ２０６内の各サブスクライバアプリケーションは、そのウエイトを示すスケジューラとしての役割を果たして、メッセージをグループ２０６内の別のｎ人のサブスクライバに送信することで動作する。スケジューラは次いで、メッセージをグループ内の特定のサブスクライバに最も重いウエイトで送信することによって応答する。これがどのように達成されるかに関するより詳しい詳細は、これ以降に従う。
【００９６】
よって、サブスクライブデータベースサーバ２０６の分散キューは、タスクを表す証明付メッセージ（更新およびクエリー）を受け入れることができる。システムは各タスクを正確にサーバのうちのひとつだけに割り当てる一方、サーバグループおよびタスクの分散は、クライアントプロセスに対して完全に透過的なままである。
【００９７】
キューメンバ
分散キューのメンバセッションのすべては、それらが、その名前を有するキューメンバであることを示す同一の再使用可能な通信者名を共有する。分散キューの各メンバは、同一サブジェクトに対して接続待機しており、さらに、ｎ人のメンバが接続待機している場合でさえ、各インバウンドメッセージ（またはタスク）に対して、１人のメンバだけが、メッセージを処理する。
【００９８】
メンバの役割−ワーカーおよびスケジューラ
キュー操作する配送およびキュー操作された配送に関して本明細書中で使用されているように、用語「リスナ」および「ワーカー」は置き換え可能で用いられる。各分散キューメンバセッションは、ワーカーとして、そして、ポテンシャルスケジューラとしての２つの明白な役割を有することができる。
【００９９】
リスナまたはワーカーの役割では、キューメンバセッションは、証明付配送コールの限定サブセットをサポートし；メンバは、サブジェクトに接続待機し、自動的に配信確認を無効にし、配送を確認することができる。キューメンバセッションは、他のいかなる証明付配送コール（特に、証明付メッセージの送信と関連するコール）もサポートしない。しかし、それらは、全ての標準コール（例えば、通常のメッセージ送信）をサポートする。
【０１００】
システムは、各キュー内に正確に１つのアクティブスケジューラを維持するフォールトトレランスソフトウェアを含み；スケジューラプロセスが終了する場合、別のメンバはスケジューラの役割を負う。スケジューラ役割におけるキューメンバセッションは、キュー内にリスナへのインバウンドタスクを割り当てる。（スケジューラは、それ自身のリスナーコンポーネントにタスクを割り当てることができるが、これは、他の全てのリスナがビジーの場合だけである。）
【０１０１】
フォルトトレラントコンポーネントとしてのスケジューラ
何れのキューメンバもスケジューラとなるポテンシャルを有するが、フォールトトレランスソフトウェアは、常時、正確にひとつのスケジューラを保守する。フォールトトレランスパラメータは、スケジューラとして最適なメンバを選択するようソフトウェアを導く。
【０１０２】
スケジューラウエイトは、同じキューの他のメンバに関するスケジューラの役割を果たすメンバセッションの能力、すなわち最高可用性または未使用のメンバーリソースを表す。キューメンバは、相対スケジューラウエイト値を使用して、スケジューラとしてひとつのメンバを選出し；より高いスケジューラウエイトを有するメンバが、優先する。
【０１０３】
アクティブスケジューラは、ユーザーによって指定されるインターバルでハートビートメッセージを送信する。ハートビートメッセージは、メンバがスケジューラとして作動していることを他のメンバに通知する。キュー内の全てのセッションは、同じスケジューラハートビートインターバルを指定しなければならない。
【０１０４】
加えて、キュー内の全てのセッションは、同じスケジューラ起動インターバルを指定しなければならない。スケジューラからのハートビート信号が、このインターバルの間音信不通であった場合、最も重いスケジューラウエイトを有するキューメンバが、新規スケジューラとして開始する。
【０１０５】
ワーカーへのタスクの割り当て
スケジューラは、各タスクをワーカーまたはリスナ（別のキューメンバセッション）に割り当てる。リスナまたはそのワーカーは、単独でデータコールバックファンクション内のタスクメッセージを処理する。
【０１０６】
ワーカーウエイト
相対ワーカーまたはリスナーウェイトは、タスクの割り当てにおいてスケジューラを補助する。スケジューラがタスクを受信する場合、それはタスクを最も重いワーカーまたはリスナーウェイトを有する可用ワーカーまたはリスナに割り当てる。
【０１０７】
キューメンバとしてセッションを可能にすることは、暗黙のうちにそのワーカーまたはリスナーウェイトパラメータを１にセットする。すなわち、全てのメンバは、プログラムコードが明示的にワーカーまたはリスナーウェイトを変更しない限り、同じワーカーまたはリスナーウェイトを暗に有する。
【０１０８】
可用性
スケジューラがタスクを受信する場合、それはタスクを最も重いワーカーリスナーウェイトを有する可用ワーカーリスナに割り当てる。
【０１０９】
ワーカーリスナは、これらの条件のいずれかが真でない限り、利用可能であると見なされる：
ワーカーまたはリスナに割り当てられる未処理のタスクは、そのタスク許容量を超える。
【０１１０】
ワーカーまたはリスナーセッションは、スケジューラである。（他の全てのワーカーまたはリスナがビジーの場合、スケジューラはそれ自身のワーカーまたはリスナにタスクを割り当てる。）
【０１１１】
タスク許容量
タスク許容量は、ワーカーまたはリスナが受け入れることのできるタスクの最大数である。承認タスク数が、この最大数に到達する場合、ワーカーまたはリスナは、それがひとつ以上のタスクを完了するまで、更なるタスクを受け入れることができない。
【０１１２】
スケジューラがタスクを受信する場合、それは、最も重いワーカーまたはリスナーウェイトを有するワーカーまたはリスナに、そのワーカーまたはリスナに割り当てた未処理のタスクがそのタスク許容量を超えない限り、タスクを割り当てる。優先ワーカーまたはリスナが、あまりに多くのタスクを有する場合、スケジューラは新しいインバウンドタスクを、次に重いワーカーまたはリスナーウェイトを有するワーカーまたはリスナへ割り当てる。
【０１１３】
キューメンバとしてセッションを可能にすることは、暗黙のうちにそのワーカーまたはリスナータスク許容量を１にセットする。プログラマは、２つの要因に基づいてタスク許容量を調整することができる：
マルチプロセッシングハードウエア上のマルチタスクプログラム
マルチプロセッシングコンピュータにおいて、インバウンドタスクにｎ個のスレッドおよびｎ個のプロセッサを当てるマルチスレッドプログラムは、タスク許容量ｎを有する。
【０１１４】
通信タイムラグ
大部分の分散キューアプリケーションでは、通信時間は、タスクターンアラウンド時間のうちの取るに足らない端数である。すなわち、タスクおよびそれを完了させる信号を割り当てるのに必要とされる時間は、タスク自体を処理するのに必要とされる時間と比較して極めて少ない。例えば、平均タスクターンアラウンド時間が２０００ミリ秒で、そのうち通信時間が合計１０ミリ秒だけを要するとすると、タスク許容量はプロセッサまたはスレッドの数と同じである。
【０１１５】
しかし、ある状況では、通信時間は著しいものとなり得るが、例えば、キューメンバがＷＡＮによって接続されている遠隔サイトに分散されている場合に著しいものになり得る。通信時間が著しい場合、タスク許容量の意味は変化し；リスナが並列処理できるタスク数を示す代わりに、通信タイムラグにもかかわらずリスナの許容量を満たすことのできるタスク数を示す。例えば、平均タスクターンアラウンド時間が１５００ミリ秒で、そのうち平均タスク処理時間が合計１０００ミリ秒を要するとすると、タスク許容量を３に設定することにより、タスク間のリスナのアイドル時間を最小にする。通信時間ラグを補正するためにタスク許容量を調整する場合、平衡化が重要である。リスナに（そのタスク許容量を非常に少なく設定することにより）負荷をかけなければ、リスナをアイドル状態のままにすることができる一方で、スケジュールにその次のタスクを割り当てるのを待機させる。逆に、リスナに（そのタスク許容量を非常に多く設定することにより）過負担をかければ、いくつかの割り当てられたタスクを待機させることができる一方、それらのタスクを受け入れたであろう他のリスナをアイドル状態のままする。
【０１１６】
タスクスケジューリング
本発明の更なるアプリケーションでは、分散キュー操作の幅広いコンセプトを、アプリケーションを実行する異なるタスクのためのスケジューリングタスクに適用することができる。このアプリケーションでは、アプリケーションは、スケジューラかワーカーのいずれか、または両方であり得る。各ワーカーは、作業実行に対するその能力を示すウエイト、つまり通常それが同時に実行できるタスク数を割り当てられる。普通、ワーカーは、それら自身のウエイトを割り当てる。
【０１１７】
グループのひとつのアプリケーション／メンバは、スケジューラになる。一旦、これが発生すると、他の全てのアプリケーションは、指定のワーカーだけになる。スケジューラは、ワーカーおよびスケジューラの両方になる。
【０１１８】
タスクがグループ（スケジューラ）によって受信される場合、それは、最も高い「ウエイト」またはタスクを実行する能力を有するワーカーにタスクを割り当てる。ワーカーは次いで、タスクを受け入れるスケジューラにコールバックし、完了時に、このファクトを示すスケジューラにコールを返す。特定の実例では、スケジューラに対するコールバックは、承認およびタスク完了の通知の両方を含む。
【０１１９】
２つの付属書ＡおよびＢを添付する。これらの付属書は、証明付メッセージ送信用およびメッセージキュー操作用の詳細なＣコーディング情報をそれぞれ含む。
【０１２０】
本明細書で言及した全ての出版物および特許出願は、それぞれ個々の出版物または特許出願が引用して組み込まれて、具体的かつ個々に示しているように、同じ範囲で本明細書中に引用して組み込む。
【０１２１】
本発明はここで完全に説明され、当該技術に精通する者にとって、多くの変更および修正が、その精神または適用範囲から逸脱することなく、それらに対して行うことができることは明白である。
【０１２２】
付属書Ａ：証明付メッセージ配送（Cプログラマ用プログラミング詳細）
先に示したように、いくつかの通信が、非常に信頼できるとしても、特定のアプリケーションは、さらに強固な配送の保証を必要とする。証明付配送の特長は、プロセスおよびそれらのネットワーク接続が不安定である状況においてでさえも、より高い配送の確実性を提供する。
【０１２３】
本付属書Ａは、証明付メッセージ配送の実装を望むＣプログラマのためのプログラミング詳細を提供する。本付属書は、表Ａ１で、証明付メッセージ配送データ型および関数の概要一覧を提供する。次いで、各データ型または関数を、関連するデータ型または関数に対するクロスリファレンスを用いて更に詳細に説明する。
【０１２４】
証明付メッセージ送信 CAPI
下記表は、証明付メッセージ配送CAPIにおけるデータ型および関数を要約する。
【０１２５】
表Ａ１：証明付メッセージ配送：データ型および関数
【表２】
0003860966.tif 000003
rvcm_Enable()
関数
宣言
rvcm_Error rvcm_Enable (
rv_Session session,
rv_Name name,
rv_Name reserved,
char* ledgerFile,
rv_Boolean requireOldMsgs
目的
配送トラッキング用既存セッションをイネーブル化する。
注釈
他の全ての rvcm 関数は、引数としてイネーブル化されたセッションを必要とする。プログラムは、証明付配送に関する他の何れの呼出し前に rvcm_Enable ( ) を呼び出さねばならない。
【０１２６】
ユーザーは、両証明付および非証明付通信のためのイネーブル化されたセッションを使用できる。例えば、イネーブル化されたセッションは、rvcm_Send () および rv_Send () への呼出しをサポートする。
【０１２７】
一旦、セッションが証明付配送のためにイネーブル化されると、それは、 rv_Term() により終了されるまで、イネーブル化状態のままである。その後、ユーザーは、セッションの証明付配送パラメータを変更することができない。
名前
rvcm_Enable () は、そのセッション引数を配送トラッキングセッションへ進める。
【０１２８】
名前が NULL であれば、 rvcm_Enable () は、このセッションのためのユニークで再使用不能な名前を生成する。
【０１２９】
名前が NULL でなければ、セッションはその名前をバインドする。通信者は、それが再使用可能な名前とファイルベースの台帳とを有する場合にのみ、セッション終了を超えて存続できる。
【０１３０】
台帳ファイル
すべての配送トラッキングセッションは、台帳にその証明付通信の状態を記憶し、台帳は、プロセスに関連するメモリ内に記憶される。
【０１３１】
ledgerFile が NULL であれば、このセッションは、プロセスベースの台帳だけを使用する。セッションまたはプロセスが終了すると、台帳内の全ての情報が失なわれる。
【０１３２】
ledgerFile が、有効なファイル名を指定するなら、このセッションは、台帳保存用ファイルを使用する。セッションまたはプロセスが、不完全な証明付通信とともに終了する場合、台帳ファイルはその状態を記録する。新規セッションが同じ再使用可能な名前をバインドする場合、それは、台帳ファイルを読み込み、ファイル内に記憶されている状態から、証明付通信を継続する。
【０１３３】
セッションが台帳ファイルを使用するとしても、それは効率のために時々プロセスベースの記憶に台帳の一部を複製してもよい。しかし、プログラマはこの複製に依存することはできない。
【０１３４】
オペレーティングシステムがローストレージデバイス（また、ローパーティションとも称する）をサポートする場合、ユーザーは、そのようなデバイスを台帳ファイルとして指定することができる。
【０１３５】
任意のプレフィックスは、台帳ファイルに対する書込みが同期動作であるかどうかを決定する。すなわち：
・同期書込み（デフォルト）を指定するには、通常のファイル名を与えるか、文字列 sync* をファイル名にプリペンドする；例えば、 "myLedger" （暗黙的）または "sync*/ local/ myLedger" （明示的）。台帳項目が書き込まれるたびに、データがファイルシステム内に安全に記憶されるまで、呼出しは返らない。
【０１３６】
・非同期書込みを指定するには、文字列 nosync* をファイル名にプリペンドする；例えば、 "nosync*/ local/ myLedger"。台帳ファイルは、ハードウエアまたはオペレーティングシステムカーネル障害の場合、正確にプログラム状態を反映しないであろう。
【０１３７】
非同期台帳ファイルを使用するプログラムは、以下に説明する rvcm_SyncLedgerFile() を呼出すことによって、明示的にそれを同期させることができる。
【０１３８】
パラメータ
【表３】
0003860966.tif 000004
エラー
【表４】
0003860966.tif 000005
コーディング例
cm_err = rvcm_Enable(sess, "CM_EXAMPLE", NULL,
"my_ledger_file", RV_TRUE)；
if (cm_err != RVCM_OK)
{
fprintf(stderr, 'Can't enable CM session--%s＼n',
rvcm_ErrorText (sess, cm_err))；
exit (-1)；
}
参照
下記 rvcm_SyncLedgerFile()
rvcm_ListenSubject()
関数
宣言
rvcm_Error rvcm_ListenSubject (
rv_Session session,
rvcm_LisCenId * listenid,
rv_Name subject,
rvcm_Callback dataCallbackFn,
rv_Opaque closureArg)
目的
サブジェクトに一致するメッセージに対して接続待機を開始し、利用可能であればいつでも証明付配送を要求する。メッセージが到着するときはいつでも、コールバック関数はそれを受け取る。
注釈
この関数は rv_ListenSubject() に対して並列であり、エンドポイントを作成して、一致するサブジェクトを持つメッセージを受け取る。エンドポイントは、ラベル付メッセージおよび通常メッセージの両方を受け取る。
【０１３９】
ラベル付メッセージが未知の配送トラッキングセッションから到着する場合、受信セッションは、サブジェクトに対する証明付配送を要求する。送信セッションが要求を承認すれば、２つのセッションは協働して、このサブジェクトを持つ後続メッセージの配送を証明する。
【０１４０】
通常のリスニングエンドポイントとは異なり、ユーザーは、サブジェクト当たりひとつを超える配送トラッキングリスニングエンドポイントを維持することができない。ひとつのエンドポイントがすでにオープンしている場合、同じサブジェクトを持つ rvcm_ListenSubject() に対する後続の呼出しはエラーを返す。（この制限は、各配送トラッキングセッションに適用する；しかし、いくつかの配送トラッキングセッションを用いるプログラムは、同一のサブジェクトを持つ独立した配送トラッキングリスナをオープンできる。）
rv_ListenSubject() とは異なり、ユーザーは、 rvcm_ListenSubject() を使用して、ワイルドカードサブジェクトに接続待機することができない。
【０１４１】
データコールバック関数が返される場合、ソフトウェアは自動的にメッセージ配送を確認する。
【０１４２】
パラメータ
【表５】
0003860966.tif 000006
エラー
【表６】
0003860966.tif 000007
コーディング例
cm_err = rvcm_ListenSubject(sess, &listenId, subject、
CM_callback, myClosure)；
if (cm_err != RVCM OK)
fprintf(stderr, "error %s listening to ＼"%s＼"＼n"、
rvcm_ErrorText (sess, cm_err), subject)；
参照
rvcm_Callback；
rvcm_ListenId；
rvcm_ListenInbox()；
rvcm_Close()、全て以下に説明する。
【０１４３】
rvcm_ListenInbox()
関数
rvcm_Error rvcm_ListenInbox (
rv_Session session,
rvcm_ListenId * listenid,
rv_Name inbox,
rv_Size inboxLimit,
rvcm_Callback dataCallbackFn,
rv_Opaque closureArg)
目的
受信トレイをオープンし、それにアドレス指定されるポイントツーポイントメッセージへ接続待機を開始する。利用可能であればいつでも証明付配送を要求する。メッセージが到着するときはいつでも、コールバック関数にそれを渡す。
注釈
この関数は rv_ListenInbox() に対して並列であり、受信ボックスを作成して、ポイントツーポイントメッセージを受け取る。受信ボックスは、ラベル付メッセージおよび通常メッセージの両方を受け取る。
【０１４４】
ラベル付メッセージが未知の配送トラッキングセッションから到着する場合、受信セッションは、受信トレイ名に対する証明付配送を要求する。送信セッションが要求を承認すれば、２つのセッションは協働して、この受信トレイに対する後続メッセージの配送を証明する。
【０１４５】
受信トレイに対する証明付配送は、受信トレイの持続時間に制限される。一旦、ユーザーが、受信トレイをクローズするか、またはそのセッションを終了すると、受信トレイおよびその名前は、廃止されたものになり；ユーザーは、二度と同じ名前を持つ別の受信トレイをオープンすることができない。システムは、廃止された受信トレイにアドレス指定されたメッセージの配送を決して完了できないので、それは、受信トレイが廃止されたものになったことを検出する場合、記憶されたメッセージを自動的に削除する。
【０１４６】
データコールバック関数が返される場合、システムは自動的にメッセージ配送を確認する。
【０１４７】
パラメータ
【表７】
0003860966.tif 000008
エラー
【表８】
0003860966.tif 000009
コーディング例
char inboxName [RV_MAX_INBOX_NAME]；
cm_err = rvcm_ListenInbox(sess, &listenId, inboxName, sizeof(inboxName),
CM_callback, myClosure)；
if (cm_err != RVCM_OK)
fprintf(stderr, "error %s listening to certified inbox.＼n", rvcm_ErrorText(sess, cm_err))；
参照
下記 rvcm_Callback
下記 rvcm_ListenId
上記 rvcm_ListenSubject()
下記 rvcm_Close()。
【０１４８】
rvcm_Callback
データ型
宣言
void* rvcm_Callback (
rv_Session session、
rv_Name subject、
rv_Name replyName
rvmsg_Type msgType、
rvmsg_Size msgSize、
rvmsgData msg、
rvcm_Seq sequenceNum、
rv_Name senderName、
rv_Opaque closureArg)
目的
rvcm_Callback は、配送トラッキングリスナに対するデータコールバック関数の関数型である。アプリケーションは、この型の関数を定義して、インバウンドメッセージを受信し、適切な動作をとる。
注釈
この関数型は、 rv_Callback に対して並列である。その関数の署名が、インバウンドメッセージにラベルを付けるトラッキングデータを受信するため、２つの追加パラメータ、 senderName と sequenceNum とを含むことに留意されたい。アプリケーションプログラムは、テストおよび監査のためにこれらの引数を使用できる。
【０１４９】
データコールバック関数が戻る場合、システムは自動的にメッセージ配送を確認する。
【０１５０】
ユーザーは、いくつかのコールバック関数を書き込んで、アプリケーションが受信することを期待する各種メッセージを処理することができる。ユーザーは、同じコールバック関数を使用して、いくつかのエンドポイントでメッセージを処理することができる。コールバック関数は、以下の制限を除き、メッセージの処理においていかなる動作もとることができる：
・コールバック関数は、いかなる方法によっても、データ（パラメータ msg、subject、 reillyName および senderName の値）の変更を試みてはならない。コールバック関数は、ポインタを介してデータを受け取る：実際のデータは、アプリケーションに属さないメモリに常駐する。データポインタは、コールバック関数が返るまで有効のままである。
【０１５１】
・データコールバック関数は、迅速に戻らなければならない。
【０１５２】
パラメータ
【表９】
0003860966.tif 000010
コーディング例
このコード例は、証明付配送を有するメッセージを受信するためのデータコールバック関数を示す。
【０１５３】
void
CM-callback (
rv_Session session、
rv_Name subject、
rv_Name replyName、
rvmsg_Type msgType、
rvmsg_Size msgSize、
rvmsg_Data msg、
rvcm_Seq seqNumber、
rv_Name sender、
rv_Opaque myClosureArg)
{
printf("Received: subject=%s, reply=%s, message=",
subject, (replyName!=NULL ? replyName : "<none>"))；
rvmsg_PrintItem(session, msgType, msgSize, msg, NULL)；
printf("＼n")；
printf("sequence number=%ld, sender=%s＼n",
seqNumber, (sender!=NULL ? sender: "<none>"))；
fflush(stderr)；
}
参照
下記、 rvcm_ListenId； rvcm_Seq； and rvcm_Close()。
【０１５４】
rvcm_ListenId
データ型
宣言
typedef void* rvcm_ListenId；
目的
rvcm_ListenSubject() および rvcm_ListenInbox() 関数は、型 rvcm_ListenId のハンドルを返す。対応する情報への接続待機を中止するには、このハンドルを rvcm_Close() へ渡す。
注釈
rvcm_ListenId は、それが作成されたセッションの外側では重要ではない。各 rvcm_ListenId は、サブジェクトとコールバック関数との間の関連を表すユニークなハンドルである。 rvcm_ListenId をリスニング関数のうちのひとつから受信するローカルプログラム範囲内だけでそれを使用し、それを不透過として扱う。
【０１５５】
rvcm_Seq
データ型
宣言
typedef unsigned long rvcm_Seq；
目的
ラベル付メッセージのシーケンス番号。
注釈
シーケンス番号は、全てのプラットホームに関して３２ビットに（６４ビット整数をサポートするプラットホームであっても）制限される。
【０１５６】
rvcm_Close()
関数
宣言
rvcm_Error rvcm_Close (
rv_Session session、
rvcm_ListenId listenid
目的
配送トラッキングエンドポイントをクローズし；それに関するメッセージへの接続待機を中止する。
注釈
この関数は、 rv_Close () に対して並列である。
【０１５７】
協働する送信者は、配送トラッキング合意がすでに効力を持たないことを示す REGISTRATION.CLOSED アドバイザリを受信する。送信者は、クローズされたエンドポイントへの各未配送メッセージのための DELIVERY.FAILED アドバイザリを受信し、システムは、送信者の台帳から未配送メッセージを削除する。
【０１５８】
システムは、クローズされたサブジェクトに対応するリスナの台帳項目を削除する。
【０１５９】
rvcm_Close() が、エンドポイントをクローズする場合、それは、 HOST.LISTEN.STOP アドバイザリーメッセージを生成して、このアプリケーションがサブジェクトへの接続待機を中止した旨を他のアプリケーションへ通知する。
【０１６０】
継続的なリスナは、もはや対応するサブジェクトの証明付配送を必要としない時、およびその場合だけ、配送トラッキングエンドポイントをクローズすることが重要である。オープンなエンドポイントは、証明済送信者に、送信者からの配信確認を待機している間、メッセージを台帳に記憶させる原因となる。送信者の観点から、そのリスニングエンドポイントをクローズせずに終了する継続的リスナは、異常終了するリスナと同じもののように見え；送信者は、リスナプロセスの戻りを待機しながら、メッセージを記憶し続ける。一旦、エンドポイントがクローズされると、送信者は、そのリスナに対する証明付メッセージを記憶せず、同じ通信者名を持つ連続的なリスナプロセスは、その合間に送信されたメッセージの証明付配送を受信しない。
【０１６１】
コーディング例
アプリケーションがデータの受信を完了した場合、エンドポイントをクローズする。エンドポイントのクローズは、 TiB/Rendezvous ソフトウェアに関連ストレージリソースを再利用させる。エンドポイントのクローズ後、それに対する全てのリファレンスを削除して、それを二回クローズすることから守る。
【０１６２】
二回以上同じエンドポイントをクローズすることは違法である。あるプラットホーム上では、エラー RVCM_ERR_NONEXISTENT_ID が生じる；他のプラットホーム上では、結果は致命的エラーの恐れがある（解放された動的割当てメモリを参照するため）。
【０１６３】
このコードフラグメントは、エンドポイントをクローズするための推奨イディオムを示す：
if(foo->listenId != NULL)
(rvclm_Close(foo->listenId)；
foo->listenId = NULL; }
パラメータ
【表１０】
0003860966.tif 000011
エラー
【表１１】
0003860966.tif 000012
参照
上記 rvcm_ListenId。
【０１６４】
rvcm_Send()
関数
宣言
rvcm_Error rvcm_Send (
rv_Session session、
rv_Name subject、
rvmsg_Type msgType、
rvmsg_Size msgSize、
rvmsg_Data msg,
unsigned long timeLimit、
rvcm_Seq * sequenceNum)
目的
ラベル付メッセージを送信し、協働リスナへの配送を追跡する。
注釈
この関数は、 rv_Send ( ) に対して並列である。その署名が、2つの追加パラメータ、 timeLimit と SequenceNum とを含むことに留意されたい。
【０１６５】
timeLimit をメッセージの持続時間（秒）を指定するのに使用すること。システムは、全ての協働リスナから配信確認を受け取るまでか、または timeLimit が期限切れになるまでのいずれかまで、その台帳にメッセージを保持する。配送が終了する前に、期限が切れる場合、システムは、台帳からメッセージを削除し、メッセージの配送を確認しなかった協働リスナを一覧した DELIVERY.FAILED アドバイザリーメッセージを生成する。
【０１６６】
本発明者は、６０秒を超える timeLimit 値を推奨するが、理由は、ドメインが６０秒間メッセージを保持するからである。
【０１６７】
rvcm_Send () は、配送トラッキングセッション名およびシーケンス番号を用いてメッセージへラベルを付ける。rvcm_Send () は、その sequenceNum パラメータ内の呼出し元にシーケンス番号を返して渡す（ユーザーはこの番号を監査のために使用できる）。
【０１６８】
各送信セッションは、それが送信する各サブジェクトに対して別々のシーケンスを維持する。その結果として、受信者は、3つのデータコールバック引数、 subject、senderName、および sequenceNum によって各ラベル付メッセージをユニークに識別できる。
【０１６９】
msg が自明長さを有する場合、ユーザーは、 msgSize に対してゼロを与えてもよい（システムは、自動的に実サイズを計算する）。自明のサイズを持つ型は、 RVMSG_RVMSG、RVMSG_STRING （文字列が NULL で終わる場合）、および RVMSG_ENCRYPTED である。他の全ての型は、この呼出し内に明示的サイズの引数を必要とする。
【０１７０】
rvcm_Send ()
rvcm_Send () は、その引数をコピーする。rvcm_Send () が返された後、ユーザーは、記憶（例えば、メッセージバッファ）を解放するか、または再利用してもよい。
警告
メッセージをワイルドカードサブジェクト名へ送信することは違法である。rvcm_Send () は、ユーザーがワイルドカードサブジェクトに違法に送信することを妨げないが、結果は予測不可能である。
【０１７１】
パラメータ
【表１２】
0003860966.tif 000013
エラー
【表１３】
0003860966.tif 000014
コーディング例
int time_limit = 600; /* 600sec = 1 10min ／
cm_err = rvcm_Send(sess, subject, type, sizeof(msg), msg,
time_limit, &seq_no)；
if (cm_err = RVCM_OK)
fprintf(stderr, "Sent sequence num %d\n', seq_no)；
else
fprintf(stderr, "Error while sending certified message: %s＼n",
rvcm_ErrorText (sess, cm_err))；
参照
上記 rvcm_Seq
下記 rvcm_SendWithReply()。
【０１７２】
rvcm_SendWithReply()
関数
宣言
rvcm_Error rvcm_SendWithReply (
rv_Session session、
rv_Name subject、
rv_Name replyName、
rvmsg_Type msgType、
rvmsg_Size msgSize、
rvmsg_Data msg、
unsigned long timeLimit、
rvcm_Seq * sequenceNum
目的
ラベル付リクエストメッセージを送信し、協働リスナへの配送を追跡する。リクエストメッセージは、応答メッセージに対する復帰アドレスとしての返答名を含む。
注釈
この関数は、rv_SendWithReply () に対して並列である。その署名が、2つの追加パラメータ、timeLimit と SequenceNum とを含むことに留意されたい。
【０１７３】
返答名は、オープンなリスニングエンドポイント（ブロードキャストまたは受信トレイのいずれか）のサブジェクト名でなければならない。アプリケーションは、リクエストメッセージに対して、ゼロ、1またはいくつかの応答を受け取ってもよい。ユーザーが rvcm_SendWithReply () を呼び出す前に、ユーザーは、適切なアプリケーションコンポーネントが返答名に接続待機していることを確実にしなければならない。
【０１７４】
rvcm_SendWithReply () は、ノンブロッキング関数である。それは直ちに返され、コールバック関数は、何れの返答も非同期で受け取る。返答は保証されていない（例えば、受信者が何れの返答も送信しない場合等）。
【０１７５】
timeLimit を、メッセージの持続時間を指定するのに使用すること。システムは、全ての協働リスナから配信確認を受け取るまでか、または timeLimit が期限切れになるまでのいずれかまで、その台帳にメッセージを保持する。配送が終了する前に、期限が切れる場合、システムは、台帳からメッセージを削除し、メッセージの配送を確認しなかった協働リスナを一覧にする DELIVERY.FAILED アドバイザリーメッセージを生成する。
【０１７６】
６０秒を超える timeLimit 値が推奨されるが、理由は、ドメインが６０秒間メッセージを保持するからである。
【０１７７】
rvcrn_SendWithReply ()
rvcm_SendWithReply() は、配送トラッキングセッション名およびシーケンス番号を用いてメッセージにラベルを付ける。rvcm_SendWithReply() は、その sequenceNum パラメータ内の呼出し元にシーケンス番号を返して渡す（ユーザーはこの番号を監査のための使用できる）。
【０１７８】
各送信セッションは、それが送信する各サブジェクトに対して別々のシーケンスを維持する。その結果として、受信者は、３つのデータコールバック引数、 subject、 senderName、および sequenceNum によって各ラベル付メッセージをユニークに識別できる。
【０１７９】
msg が自明長さを有する場合、ユーザーは、msgSize に対してゼロを与えてもよい（システムは、自動的に実サイズを計算する）。自明のサイズを持つ型は、RVMSG_RVMSG、 RVMSG_STRING  （文字列が NULL で終わる場合）、および RVMSG_ENNCRYPTED である。他の全ての型は、この呼出し内に明示的サイズの引数を必要とする。
【０１８０】
rvcm_SendWithReply() は、その引数をコピーする。rvcm_SendWithReply() が戻された後、ユーザーは、記憶（例えば、メッセージバッファ）を解放するか、または再利用してもよい。
警告
メッセージをワイルドカードサブジェクト名へ送信することは違法である。関数rvcm_SendWithReply() は、ユーザーがワイルドカードサブジェクトへ違法に送信することを妨げないが、結果は予測不能である。
【０１８１】
パラメータ
【表１４】
0003860966.tif 000015
エラー
【表１５】
0003860966.tif 000016
0003860966.tif 000017
【０１８２】
rvcm_AddListener()
関数
宣言
rvcm_Error rvcm_AddListener (
rv_Session      session,
rv_Name       name,
rv_Name       subject)
目的
予想されるリスナを予備登録する。
注釈
いくつかの送信アプリケーションは、リスニングアプリケーションが実行を開始する前であっても、証明付配送に対する要求を予想できる。このような状況で、送信者がリスナを予備登録できるので、システムは、送信者の台帳にアウトバウンドメッセージの記憶を開始する；リスナ要求が配送を証明した場合、それは未執行のメッセージを受け取る。
【０１８３】
この名前を持つ通信者が、この送信者セッションからこのサブジェクトの証明付配送をすでに受信していると、rvcm_AddListener() は何の効果もない。
【０１８４】
この名前を持つ通信者が却下されると、rvcm_AddListener() はエラーを戻す。ユーザーは、rvcm_AllowListener() を呼び出して、rvcm_DisallowListener() に対する前の呼出しの効果を破棄することができ；その後、再び rvcm_AddListener() を呼び出す。
【０１８５】
パラメータ
【表１６】
0003860966.tif 000018
rvcm_AddListener()
エラー
【表１７】
0003860966.tif 000019
【０１８６】
0003860966.tif 000020
【０１８７】
rvcm_RemoveListener()
関数
宣言
rvcm_Error rvcm_RemoveListener (
rv_Session        session,
rv_Name         name,/* listening correspondent name*/
rv_Name         subject)
目的
特定の通信者における特定のリスナを未登録にし、送信者の台帳内の関連記憶を解放する。
注釈
この関数は、この名前を持つ通信者への特定のサブジェクトの証明付配送をキャンセルする。リスニング通信者は、次いで、サブジェクトの証明付配送のために再登録してもよい。（対照的に、rvcm_DisallowListener() は、通信者に対する全サブジェクトの証明付配送をキャンセルし、再登録を禁止する。）
リスニング通信者用の台帳項目が非常に大きくなった場合、送信者は通常、この関数を呼び出す。このような増加は、リスナが配送を確認しておらず、終了してもよいことを示す。リスナの削除は、リスナのために記憶されるメッセージを削除することにより台帳サイズを小さくする。
【０１８８】
送信プログラムがこの関数を呼び出す場合、送信者における証明付配送ソフトウェアは、まるでリスナがサブジェクトに対するエンドポイントをクローズしたように機能する。送信者プログラムは、その台帳からこの名前を持つリスナへのサブジェクトの配信に関する全ての情報を削除する。送信プログラムは、REGISTRATION.CLOSED アドバイザリを受け取って、アドバイザリに対するコールバック関数内の何の動作もトリガーする。
【０１８９】
リスニング通信者が利用可能（実行および到達可能）な場合、送信者が、もはやサブジェクトの配送を証明しないことを通知するREGISTRATION.NOT_CERTIFIEDアドバイザリを受け取る。
【０１９０】
この名前を持つ通信者が、サブジェクトの証明付配送をこの送信者セッションから受信しなければ、rvcm_RemoveListener() は、RVCM_ERR_BAD_SUBJECT を戻す。
【０１９１】
パラメータ
【表１８】
0003860966.tif 000021
エラー
【表１９】
0003860966.tif 000022
【０１９２】
0003860966.tif 000023
【０１９３】
rvcm_DisallowListener()
関数
宣言
rvcm_Error rvcm_DisallowListener (
rv_Session
session,
rv_Name
name)
目的
特定の通信者における全てのリスナへの証明付配送をキャンセルする。それらリスナからの後続の証明付配送登録要求を拒否する。
注釈
却下されたリスナは、この送信者から後続のメッセージをその後も受け取るが、配送は証明されていない。すなわち：
・リスナは、送信者が全サブジェクトの証明付配送をキャンセルしたことを通知する REGISTRATION.NOT_CERTIFIED アドバイザリを受け取る。
【０１９４】
・送信者の台帳が、（このリスナが配送を確認しなかったために）却下されたリスナに送信されるメッセージを含んでいれば、システムは、それらの台帳項目を削除し、それらのメッセージの再送を試みない。
【０１９５】
・システムは、（キャンセルした送信者からの）後続のメッセージをシーケンス番号ゼロを用いてリスナに付与して、配送が証明されていないことを示す。
【０１９６】
送信者は、REGISTRATION.REQUEST アドバイザリを処理するコールバック関数内の rvcm_DisallowListener() を呼び出すことによって、証明付配送の承認を直ちに無効にできる。  この関数は、名前により通信者を却下する。通信者が終了し、（同じ再使用可能な名前を持つ）別のプロセスインスタンスが生じる場合、新規プロセスは、この送信者によりその後も却下される。
【０１９７】
rvcm_DisallowListener() の効果を破棄するには、rvcm_AllowListener() を呼び出す。
【０１９８】
パラメータ
【表２０】
0003860966.tif 000024
エラー
【表２１】
0003860966.tif 000025
0003860966.tif 000026
rvcm_AllowListener()
関数
宣言
rvcm_Error rvcm_AllowListener (
rv_Session        session,
rv_Name         name)
目的
指名した受信者に、rvcm_DisallowListener() に対する何れの旧呼出しの効果も破棄して、そのリスナに対する証明付配送の復帰を求める。
注釈
証明付配送の復帰に対する送信勧誘を受信すると即座に、リスニングプログラムにおけるシステムは、新規登録要求を自動的に送信する。送信プログラムは、これらの要求を承認し、証明付配送を復元する。
【０１９９】
パラメータ
【表２２】
0003860966.tif 000027
エラー
【表２３】
0003860966.tif 000028
0003860966.tif 000029
rvcm_NoAutoConfirm()
関数
宣言
rvcm_NoAutoConfirm(
rv_Session        session,
rvcm_ListenId    listenid)；
目的
このリスニングエンドポイントに対する自動配信確認を無効にする。
注釈
証明済リスナのデフォルト動作は、データコールバック関数からの復帰により自動的にメッセージ配送を確認することである（上記 rvcm_Callback 参照）。この呼出しは、この特定のリスニングエンドポイントに対するこの動作を選択的に無効にする。（この呼出しは、他のリスニングエンドポイントに影響を及ぼさない）
自動確認を無効にすることによって、リスナは、rvcm_Confirm() の呼出しによって各インバウンド証明付メッセージを明示的に確認することに対する責務を負う。
【０２００】
インバウンドメッセージの処理が、他のスレッドにおける計算、データベースクエリー、または追加のネットワーク通信等の非同期アクティビティを伴う場合、自動確認を無効にすることを考慮されたい。
【０２０１】
この関数の効果を逆転させて、デフォルト動作を復元するいかなる方法も存在しない。
【０２０２】
パラメータ
【表２４】
0003860966.tif 000030
エラー
【表２５】
0003860966.tif 000031
参照
上記 rvcm_Callback、および、
下記 rvcm_Confirm()。
【０２０３】
rvcm_Confirm()
関数
宣言
rvcm_Confirm()
rv_Session      session,
rvcm_ListenId listenerId,
rv_Name       senderName,        rvcm_Seq      sequenceNumber)
目的  証明付メッセージの配送を確認する。  注釈  自動確認を無効にするプログラムのみにおいてこの関数を使用する。
【０２０４】
サブジェクト名、送信者、およびシーケンス番号のトリプレットは、ユニークに各証明付メッセージを識別する。サブジェクト名は、リスニングエンドポイントにおいてすでに記憶されている。他の2つのコンポーネント、送信者およびシーケンス番号は、この関数の明示的パラメータである。
【０２０５】
パラメータ
【表２６】
0003860966.tif 000032
エラー
【表２７】
0003860966.tif 000033
参照
rvcm_Callback；および、上記rvcm_NoAutoConfirm()。
【０２０６】
rvcm_ReviewLedger()
関数
宣言
rvcm_Error rvcm_ReviewLedger
rv_Session              session,
rv_Name               subject,
rvcm_ReviewCallback   reviewCallbackFn
rv_Opaque             closureArg)；
目的
台帳内のメッセージの配送状態を要約する、
注釈
コールバック関数は、台帳内に記憶されている各一致サブジェクトに対するひとつのメッセージを受け取る。例えば、rvcm_ReviewLedger() が、そのサブジェクト引数としてFOO.* を受け取る場合、それは、これらの一致サブジェクトに対して別々に（FOO.BAR に対して一度、FOO.BAZ に対して一度、そして FOO.BOXに対して一度）コールバック関数を呼び出す。
【０２０７】
しかし、コールバック関数が非NULLを返す場合、rvcm_ReviewLedger() は直ちに復帰する。
【０２０８】
台帳が何れの一致項目も含んでいない場合、rvcm_ReviewLedger()  は、コールバック関数を呼び出さずに普通に復帰する。
【０２０９】
コールバックメッセージのコンテンツおよび書式に関する情報については、下記のrvcm_ReviewCallback を参照のこと。
【０２１０】
パラメータ
【表２８】
0003860966.tif 000034
エラー
【表２９】
0003860966.tif 000035
0003860966.tif 000036
【０２１１】
rvcm_ReviewCallback
データ型
宣言
void* rvcm_ReviewCallback (
rv_Session        session,
rv_Name         subject,
rvmsg_Msg       msg,
rv_Opaque        closureArg)
目的
rvcm_ReviewCallback は、台帳を検討するためのコールバック関数の関数型である。
【０２１２】
アプリケーションは、この型の関数を定義して、rvcm_ReviewLedger() からの要約メッセージを処理する。
注釈
rvcm_ReviewLedger()  は、台帳内の各一致サブジェクトにつき一回、このコールバックを呼び出す。
【０２１３】
台帳の検討を継続するには、このコールバック関数からNULLを返す。台帳の検討を中止するには、このコールバック関数から非NULLを返す；rvcm_ReviewLedger()  は、直ちに復帰する。
【０２１４】
パラメータ
【表３０】
0003860966.tif 000037
メッセージコンテンツ
【表３１】
0003860966.tif 000038
0003860966.tif 000039
【０２１５】
if(*count)  {  (*count)--；  if((*count )>0)；  {  /* カウントがゼロに達したら中止。rvcm_ReviewLedger() から復帰。*/  return((void*)sess)；  }  }  return(NULL)；/* それ以外は、次の項目に継続。*/  参照  rvcm_ReviewCallback  上記 rvcm_ReviewLedger()。
【０２１６】
rvcm_SyncLedgerFile()
関数
宣言
rvcm_Error rvcm SyncLedgerFile (rv_Session session)；
目的
台帳ファイルをその記憶媒体に同期させる。
注釈
この関数が復帰する場合、セッションの現在の状態は、台帳ファイル内に安全に記憶される。同期台帳ファイルを使用する配送トラッキングセッションは、この関数を呼び出す必要がないが、それは、現在の状態が、復帰する前に、自動的にファイルシステムへ書き込まれるからである。
【０２１７】
パラメータ
【表３２】
0003860966.tif 000040
エラー
【表３３】
0003860966.tif 000041
参照
上記 rvcm_Enable ()。
【０２１８】
rvcm_Error
データ型
rvcm_Error は、エラーコード用の技術列挙型である。表A2は、可能なrvcm_Error値の一覧である。ユーザーは、関数 rvcm_ErrorText() を使用して、rvcm_Error メッセージコードを説明文に変換することができる。詳細は、244ページの rvcm_ErrorText() を参照のこと。
【０２１９】
表A2：rvcm_Errorの列挙値
【表３４】
0003860966.tif 000042
0003860966.tif 000043
参照
下記 rvcm_ErrorText()
【０２２０】
付属書Ｂ：分散キュー（Cプログラマ用プログラミング詳細）
【０２２１】
アプリケーションはn人のリスナのうちの1人への証明付配送のための分散キューを使用できる（キューメンバセッション）。これらの分散キュー関数は普通、証明付メッセージ配送と組み合わせて使用される。
【０２２２】
分散キューCAPI
以下の表ＢＡは、分散キュー CAPI におけるデータ型および関数を要約する。
【０２２３】
表B1：分散キュー：データタイプ(dataty yes)および関数
【表３５】
0003860966.tif 000044
rvcm_EnableQueue()
関数
宣言
rvcm_Error rvcm_EnableQueue (
rv_Session      session
rv_Name       name,
unsigned long schedulerWeight,
unsigned long schedulerHeartbeat,
unsigned long schedulerActivation)；
目的
nのうちのひとつの証明付配送のための分散キューの一部として、証明付メッセージ配送のためのセッションを可能にする。
注釈
分散キューの各メンバは、同一サブジェクトに対して接続待機しており、さらに、n人のメンバが接続待機している場合であっても、各インバウンドメッセージ（またはタスク）に対して、正確に1人のメンバだけがメッセージを処理する。
【０２２４】
プログラムは、分散キューまたは証明済接続待機に関する他のいずれの呼出し前にも、rvcm_EnableQueue() を呼び出さねばならない。
【０２２５】
一旦、セッションがキューメンバになると、それは rv_Term() を用いる以外、メンバー権を放棄することができない。
【０２２６】
キューメンバ役割
各分散キューメンバセッションは、リスナとして、そして、ポテンシャルスケジューラとしての2つの明白な役割を有する。
【０２２７】
リスナの役割では、キューメンバセッションは、証明付配送呼出しの限定サブセット：rvcm_ListenSubject()、rvcm_NoAutoConfirm()、および rvcm_Confirm() をサポートする。キューメンバセッションは、他のいかなる証明付配送呼出し（特に、証明付メッセージの送信と関連する呼出し）もサポートしない。しかし、それらは、全ての標準システムコール（例えば、rv_Send()）をサポートする。
【０２２８】
システムフォールトトレランスソフトウェアは、各キュー内に正確に1つのアクティブスケジューラを維持する：スケジューラプロセスが終了する場合、別のメンバはスケジューラの役割を負う。スケジューラ役割におけるキューメンバセッションは、キュー内にリスナへのインバウンドタスクを割り当てる。（スケジューラは、それ自身のリスナコンポーネントにタスクを割り当てることができるが、これは、他の全てのリスナがビジーの場合だけである。）
パラメータ
【表３６】
0003860966.tif 000045
エラー
【表３７】
0003860966.tif 000046
参照
rvcm_Enable()、付属書Ａ
rvcm_ListenSubject()、付属書Ａ
*******
rvcm_SetQueueAcceptTime()
関数
宣言
#defme DEFAULT_ACCEPT_TIME (0)
rvcm_Error rvcm_SetQueueAccepCTime (
rv_Session session、
unsigned long acceptTime)；
目的
キューメンバセッションの承認時間パラメータを変更する。
注釈
このセッションが、スケジューラとして動作して、リスナ（別のキューメンバセッション）にタスクを割り当てる場合、これは、この長さ（ミリ秒）を用いてタイマーを設定する。スケジューラがリスナからの承認を受信する前に、タイマーが経過すると、スケジューラは別のリスナに対してタスクの再割当てを行なう。
【０２２９】
ゼロは特殊な値であり、承認時間に関して制限を指定しない。すなわち、スケジューラはタイマーを設定せず、タスクの再割当てを行なわない。
【０２３０】
キューメンバとしてセッションをイネーブル化すると、暗黙のうちにその承認時間パラメータをDEFAULT_ACCEPT_TIME（ゼロ）に設定する。
【０２３１】
パラメータ
【表３８】
0003860966.tif 000047
エラー
【表３９】
0003860966.tif 000048
参照
下記vcm_QueueAcceptTime()。
【０２３２】
rvcm_QueueAcceptTime()
関数
宣言
#define DEFAULT_ACCEPT_TIME (0)
rvcm_Error rvcm_QueueAcceptTime (
rv_Session       session,
unsigned long *  acceptTime)；
目的
キューメンバセッションの承認時間パラメータを抽出する。
注釈
このセッションが、スケジューラとして動作して、リスナ（別のキューメンバセッション）にタスクを割り当てる場合、これは、承認時間（ミリ秒）でタイマーを設定する。
【０２３３】
スケジューラがリスナからの承認を受信する前に、タイマーが経過すると、スケジューラは別のリスナに対してタスクの再割当てを行なう。
【０２３４】
ゼロは、特殊な値であり、承認時間に関して制限を指定しない。（スケジューラはタイマーを設定しない．）
キューメンバとしてセッションをイネーブル化すると、暗黙のうちにその承認時間パラメータをDEFAULT_ACCEPT_TIME（ゼロ）に設定する。
【０２３５】
パラメータ
【表４０】
0003860966.tif 000049
エラー
【表４１】
0003860966.tif 000050
rvcm_QueueCompleteTime()
【表４２】
0003860966.tif 000051
参照
上記rvcm_SetQueueAccepcTime()。
【０２３６】
rvcm_SetQueueCompleteTime()
関数
宣言
#define DEFAULT_COMPLETE_TIME (0)
rvcm_Error rvcm_SetQueueCompleteTime (
rv_Session      session、
unsigned long completeTime)；
目的
キューメンバセッションの完了時間パラメータを変更する。
注釈
このセッションが、スケジューラとして動作して、リスナ（別のキューメンバセッション）にタスクを割り当てる場合、これは、この長さ（ミリ秒）を用いてタイマーを設定する。スケジューラがリスナからの完了メッセージを受信する前に、タイマーが経過すると、スケジューラは別のリスナに対してタスクの再割当てを行なう。
【０２３７】
ゼロは、特殊な値であり、完了時間に関して制限を指定しない。（スケジューラはタイマーを設定しない．）
キューメンバとしてセッションをイネーブル化すると、暗黙のうちにその完了時間パラメータをDEFAULT_ACCEPT_TIME（ゼロ）に設定する。
【０２３８】
パラメータ
【表４３】
0003860966.tif 000052
エラー
【表４４】
0003860966.tif 000053
【０２３９】
【表４５】
0003860966.tif 000054
参照
下記rvcm_QueueCompleteTime()。
【０２４０】
rvcm_QueueCompleteTime()
関数
宣言
#define DEFAULT_COMPLETE_TIME (0)
rvcm_Error rvcm_QueueCompleteTime (
rv_Session          session,
unsigned long *     completeTime )；
目的
キューメンバセッションの完了時間パラメータを抽出する。
注釈
このセッションがスケジューラとして動作して、リスナ（別のキューメンバセッション）にタスクを割り当てる場合、これは、完了時間（ミリ秒）でタイマーを設定する。スケジューラがリスナからの完了メッセージを受信する前に、タイマーが経過すると、スケジューラは別のリスナに対してタスクの再割当てを行なう。
【０２４１】
ゼロは、特殊な値であり、完了時間に関して制限を指定しない。（スケジューラはタイマーを設定しない．）
キューメンバとしてセッションをイネーブル化すると、暗黙のうちにその完了時間パラメータを DEFAULT_ACCEPT_TIME （ゼロ）に設定する。
【０２４２】
パラメータ
【表４６】
0003860966.tif 000055
エラー
【表４７】
0003860966.tif 000056
【０２４３】
【表４８】
0003860966.tif 000057
参照
下記 rvcm_SetQueueCompleteTime()。
【０２４４】
rvcm_Error rvcm QueueCompleteTime ()
関数
宣言
#define DEFAULT_COMPLETE_TIME (0)
rvcm_Error rvcm_QueueCompleteTime (
rv_Session          session,
unsigned long *     completeTime)；
目的
キューメンバセッションの完了時間パラメータを抽出する。
注釈
このセッションが、スケジューラとして動作して、リスナ（別のキューメンバセッション）にタスクを割り当てる場合、これは、完了時間（ミリ秒）でタイマーを設定する。スケジューラがリスナからの完了メッセージを受信する前に、タイマーが経過すると、スケジューラは別のリスナに対してタスクの再割当てを行なう。
【０２４５】
ゼロは、特殊な値であり、完了時間に関して制限を指定しない。（スケジューラはタイマーを設定しない．）
キューメンバとしてセッションをイネーブル化すると、暗黙のうちにその完了時間パラメータをDEFAULT_ACCEPT_TIME（ゼロ）に設定する。
【０２４６】
パラメータ
【表４９】
0003860966.tif 000058
エラー
【表５０】
0003860966.tif 000059
参照
上記 rvcm_SetQueueCompleteTime()。
【０２４７】
rvcm_SetQueueListenerWeight()
関数
宣言
#define DEFAULT_LISTENER_WEIGHT (1)
rvcm_Error rvcm_SetQueueListenerWeight (
rv_Session          session,
unsigned long listenerWeight )；
目的
キューメンバセッションのリスナウエイトパラメータを変更する。
注釈
スケジューラがタスクを受信する場合、それはタスクを最も重いリスナウエイトを有する可用リスナに割り当てる。
【０２４８】
リスナは、これらの条件のいずれかが真でない限り、利用可能であると見なされる：
・リスナに割り当てられる未処理のタスクが、そのタスク許容量を超える。
【０２４９】
・リスナセッションが、スケジューラである。（他のいずれのリスナも利用可能でない場合、スケジューラはそれ自身のリスナにタスクを割り当てる。）
キューメンバとしてセッションをイネーブル化すると、暗黙のうちにそのリスナウエイトパラメータを DEFAULT_LISTENER_WEIGHT (1) に設定する。
【０２５０】
パラメータ
【表５１】
0003860966.tif 000060
エラー
【表５２】
0003860966.tif 000061
参照
下記 rvcm_QueueListenerWeight ()。
【０２５１】
rvcm_QueueListenerWeight()
関数
宣言
#define DEFAULT_LISTENER_WEIGHT (1)
rvcm Error rvcm_QueueListenerWeight (
rv_Session         session,
unsigned long *    listenerWeight)；
目的
キューメンバセッションのリスナウエイトパラメータを抽出する。
注釈
スケジューラがタスクを受信する場合、それはタスクを最も重いリスナウエイトを有する可用リスナに割り当てる。
【０２５２】
リスナは、これらの条件のいずれかが真でない限り、利用可能であると見なされる：
・リスナに割り当てられる未処理のタスクが、そのタスク許容量を超える。
【０２５３】
・リスナセッションが、スケジューラである。（他のいずれのリスナも利用可能でない場合、スケジューラはそれ自身のリスナにタスクを割り当てる。）
キューメンバとしてセッションをイネーブル化すると、暗黙のうちにそのリスナウエイトパラメータを DEFAULT_LISTENER_WEIGHT (1) に設定する。
【０２５４】
パラメータ
【表５３】
0003860966.tif 000062
エラー
【表５４】
0003860966.tif 000063
参照
上記 rvcm_SetQueueListenerWeight ()。
【０２５５】
rvcm_SetQueueListenerTasks()
関数
宣言
#define DEFAULT_LISTENER_TASKS (1)
rvcm_Error rvcm_SetQueueListenerTasks (
rv_Session          session、
unsigned long       listenerTasks)；
目的
キューメンバセッションのリスナタスクパラメータを変更する。
注釈
タスク許容量は、リスナが受け入れることのできるタスクの最大数である。承認タスク数が、この最大数に到達する場合、リスナは、それがひとつ以上のタスクを完了するまで、更なるタスクを受け入れることができない。
【０２５６】
スケジューラがタスクを受信する場合、それは、最も重いリスナウエイトを有するリスナ（キューメンバ）に、そのリスナに割り当てた未処理のタスクがそのタスク許容量を超えない限り、タスクを割り当てる。優先リスナが、あまりに多くのタスクを有する場合、スケジューラは新しいインバウンドタスクを次に重いリスナウエイトを有するリスナに割り当てる。
【０２５７】
キューメンバとしてセッションをイネーブル化すると、暗黙のうちにそのリスナタスクパラメータを DEFAULT_LISTENER_TASKS (1) に設定する。
【０２５８】
プログラマは、2つの要因に基づいてタスク許容量を調整することができる：
・マルチプロセッシングハードウエア上のマルチタスクプログラム。
【０２５９】
マルチプロセッシングコンピュータにおいて、インバウンドタスクにn個のスレッドおよびn個のプロセッサを当てるマルチスレッドプログラムは、タスク許容量nを有する。
【０２６０】
・通信タイムラグ。
【０２６１】
大部分の分散キューアプリケーションでは、通信時間は、タスクターンアラウンド時間のうちの取るに足らない端数である。すなわち、タスクおよびそれを完了させる信号を割り当てるのに必要とされる時間は、タスク自体を処理するのに必要とされる時間と比較して極めて少ない。例えば、平均タスクターンアラウンド時間が2000ミリ秒で、そのうち通信時間が合計10ミリ秒だけを要するとすると、タスク許容量はプロセッサまたはスレッドの数と同じである。
【０２６２】
しかし、ある状況では、通信時間は著しいものとなり得、例えば、キューメンバが、ワイドエリアネットワーク(WAN)によって接続されている遠隔サイトに分散されている場合に著しいものになり得る。通信時間が著しい場合、タスク許容量の意味は変化し；
リスナが並列処理できるタスク数を示す代わりに、通信タイムラグにもかかわらずリスナの許容量を満たすことのできるタスク数を示す。例えば、平均タスクターンアラウンド時間が1500ミリ秒で、そのうち平均タスク処理時間が合計1000ミリ秒を要するとすると、タスク許容量を3に設定することが、タスク間のリスナのアイドルタイムを最小にする。
【０２６３】
通信タイムラグを補正するためにタスク許容量を調整する場合、つり合いが重要である。
【０２６４】
リスナに（そのタスク許容量を非常に少なく設定することにより）負荷をかけなければ、リスナをアイドル状態のままにすることができる一方で、スケジュールにその次のタスクを割り当てるのを待機させる。逆に、リスナに（そのタスク許容量を非常に多く設定することにより）過負担をかければ、いくつかの割り当てられたタスクを待機させることができる一方で、それらのタスクを受け入れたであろう他のリスナをアイドル状態のままする。
【０２６５】
パラメータ
【表５５】
0003860966.tif 000064
エラー
【表５６】
0003860966.tif 000065
参照
下記 rvcm_QueueListenerTasks ()。
【０２６６】
rvcm_QueueListenerTasks()
関数
宣言
#define DEFAULT_LISTENER_WEIGHT (1)
rvcm_Error rvcm_QueueListenerTasks (
rv_Session          session,
unsigned long *     listenerTasks)；
目的
キューメンバセッションのリスナタスクパラメータを抽出する。
注釈
タスク許容量は、リスナが受け入れることのできるタスクの最大数である。承認タスク数が、この最大数に到達する場合、リスナは、それがひとつ以上のタスクを完了するまで、更なるタスクを受け入れることができない。
【０２６７】
スケジューラがタスクを受信する場合、それは、最も重いリスナウエイトを有するリスナ（キューメンバ）に、そのリスナに割り当てた未処理のタスクがそのタスク許容量を超えない限り、タスクを割り当てる。優先リスナが、あまりに多くのタスクを有する場合、スケジューラは新しいインバウンドタスクを次に重いリスナウエイトを有するリスナに割り当てる。
【０２６８】
キューメンバとしてセッションをイネーブル化すると、暗黙のうちにそのリスナタスクパラメータをDEFAULT_LISTENER_TASKS (1)に設定する。
【０２６９】
パラメータ
【表５７】
0003860966.tif 000066
エラー
【表５８】
0003860966.tif 000067
【０２７０】
【表５９】
0003860966.tif 000068
参照
上記 rvcm_SetQueueListenerTasks()。
【図面の簡単な説明】
添付図面において：
【図１】  図１は、本発明を示すのに役立つ代表的なパブリッシュ／サブスクライブ環境の略図であり；
【図２】  図２は、本発明の分散キュー操作およびタスクスケジューリング局面の図示に役立つ代表的なパブリッシュ／サブスクライブ環境の略図である。
【図１】
0003860966.tif 000069
【図２】
0003860966.tif 000070