JP4319539B2 - マルチキャストサポートのための方法及び装置 - Google Patents

Description

本発明は企業メッセージ通信システムに一般的に関係し、詳しくは単一のメッセージソース（源）から複数のサービス品質を同時に提供するシステム及び方法に関するものである。

カリフォルニアのパロアルトにあるSun Microsystems社によって製造されたJava（登録商標）2 Platform Enterprise Edition（”Ｊ２ＥＥ”）の部分である、Ｊａｖａ（登録商標）メッセージサービス（”ＪＭＳ”）のアプリケーションプログラム・インタフェース（”ＡＰＩ”）は、企業メッセージ通信システムにアクセスするのに有用なソフトウェアインタフェースである。多くの主な企業メッセージ通信製品によってサポートされる共通の企業メッセージ通信ＡＰＩを定義することによって、ＪＭＳはアプリケーションが非同期でデータを送受信するための能力を提供する。ＪＭＳは、メッセージの待ち行列及び参加型メッセージ通信をサポートする。コンピュータ分野の当業者によく知られた構成要素であるEnterprise Java beansは、企業メッセージを送信しかつ同期又は非同期にそれらを受信するためにＪＭＳ ＡＰＩを使用する。

ＪＭＳ ＡＰＩは、終端間（end-to-end）での同期メッセージの配信及び通知を提供しない。他のメッセージ通信システムは、信頼できるアプリケーションを実行する機構として同期した配信を提供することができたり、又はメッセージが受信されない場合に配信通知を顧客に提供することができたりする。これに対して、ＪＭＳ ＡＰＩは、保証された単一のメッセージ配信のみを提供する。ＪＭＳ ＡＰＩは、配信通知のようなシステムメッセージを利用しない。どんな通知もアプリケーションレベルで行われなければならない。

さらに、ＪＭＳは、真のマルチキャスト通信サービスを提供しない。ＪＭＳは、単なる”肯定応答”モードのみを提供する。それは、ユーザが特定の”トピックス”、又はテーマによって整えられ又は寄せ集められたメッセージに参加することを許可している。ＪＭＳは、選択基準を特定したり、或いはローカルに生成されたメッセージをフィルタリングする能力を提供しない。マルチキャストは、待ち行列の消費者又は永続性のある消費者のためにサポートされない。さらに、マルチキャスト自体は、メッセージが失われることが可能な信頼性のないプロトコルに基づいている。ＪＭＳ ＡＰＩによるメッセージの”１回限り”の送信を使用することは、行方不明のメッセージが回復されることが不可能なことを意味する。これは一部のユーザにとっては望ましいことではない。

先行技術における他の同期待ち行列システムでは、待ち行列及び信頼できる移送のためにあるＡＰＩを必要とするのが典型的である。これらのシステムは、入ってくるメッセージの全てを入手するために絶えず非待ち行列（de-queue）を有しているのが普通である。ユーザがマルチキャストトラフィック（multicast traffic）を受信していれば、異なるＡＰＩを使用する必要があるだろう。ロウ・モード（raw mode）においては、ソケットを読み出すと、その次に待ち行列を、次にソケットを、次に待ち行列等のように読み出す必要がある。システムは、それ自体の多重化とスライシング（slicing）の両方を同時に処理することができるようにする必要がある。また、開発者は、異なる２つのＡＰＩを理解しかつプログラムしなければならないだろう。オペレーティングシステムレベルで、生（raw）のマルチキャスト通信を行わない場合でさえ、開発者はカスタマイズされたＡＰＩでこのシステムをおおい包むのが典型的である。サービスの異なる品質を受信することが望まれる場合、ＡＰＩを完全に切り換えることが必要であろう。

したがって、マルチキャスト通信の利点を利用するメッセージ通信システムを開発することが望ましいが、同時に行方不明のメッセージを望まないユーザに対して改善された信頼性を提供する。

また、分離したＡＰＩを必要とせずに機能するメッセージ通信システムを開発することが望まれている。

（優先権主張された特許請求の範囲）
本出願は、２００１年７月１６日に出願された、マルチキャストサポートのための方法及び装置という表題の仮特許出願番号６０／３０５，９８５を優先権主張する。

本特許文書の開示の一部は、著作権保護を条件とする内容を含む。著作権の所有者は、それが特許商標庁の特許ファイル又は記録においてあらわれるときに、特許文書又は特許開示に関する任意の者によるファクシミリの複製については何ら異議を唱えない。しかしその他の場合には、どんなことでもすべての著作権を確保する。

（発明の概要）
本発明は、単一のデータストリームから２つのサービス品質を提供するシステム及び方法を含む。システムの各ユーザのために、記憶空間が、第１のサービス品質の選択及び／または第２のサービス品質の選択を格納するために用いられる。システムのプロセッサは、各ユーザのために、サービス品質に関するユーザの選択に従ってデータストリーム及び／またはそのデータストリーム上のメッセージを方向付けるためにプログラムされる。

このシステムは、プロセッサからのデータストリームを受信しかつ第１のサービス品質の選択が格納されるために、そのデータストリームを各ユーザへマルチキャスト通信するマルチキャスト通信装置を含んでいる。また、このシステムは、プロセッサからデータストリームを受信し、かつ第２のサービス品質の選択が格納されるために、各ユーザがデータストリーム及び／またはメッセージを受信することを保証する、ポイントツー・ポイント機器のような機器を含んでいる。

（発明の詳細な説明）
本発明は、先行技術のメッセージ通信システムに関する多数の不具合を克服する。ＪＭＳ ＡＰＩのような先行技術のメッセージ通信システムは、典型的には、ブロードキャストである情報のソースを確立する。これらのシステムユーザは、このソースに対して情報を公表し、次に、それはブロードキャスト通信のために使用される。しかしながら、この方法におけるソース及び公表は、実際には信頼できないものである。ユーザが誤ったメッセージを望まない場合、これらのシステムユーザは、それらの再送信スキームを発展させかつ実行することができる。

本発明に従うシステムは、マルチキャスト通信を行うサーバにメッセージをかわりに送信する。このサーバは、前述したように信頼できないマルチキャスト通信サービスを提供することが可能だけでなく、信頼できるサービスを提供することもできる。これらのサービスは連続して又は一連に動作することができるともに、各メッセージのためのサービスを替わりに行うことができる。

先行技術のシステムとは異なり、このようなシステムは、マルチキャスト又は信頼できるソースの何れかのみで構成されるのではなく、同一のチャネルを通じた両方のサービスを提供する。

ある実施例において、ユーザは、そのユーザへ送信された又はそのユーザによって受信されたメッセージに使用されるべきサービスの品質（”ＱｏＳ”）を特定することができる。システムの各ユーザは関連した属性を持つことができ、その１つがサービス品質である。サービスに関する高い品質を選択するユーザのために付加的な情報がメッセージとして提供され、例えばそのようなメッセージは、マルチキャスト通信によるメッセージのユーザに知らせるために送信される。他の参加者が信頼性を希望し、どんなメッセージも失敗しないことを望む一方で、あるユーザは、マルチキャスト可能なソースを構成し又は利用できるようにする。本発明の一実施例に従ったシステムは、異なるサービス品質によるユーザ通信の両方を単一のソースから実際にサービスしている。この二重のサービス通信は、ＱｏＳの何れかのユーザに対して完全に透過的（トランスペアレント）である。

図１は、本発明に従ったシステム１００を示しており、各ユーザ１１８,１２０,１２２,１２４が信頼できるサービス品質を選択する。この場合、ポイントツー・ポイントプロトコルが利用される。図１において、送信者１０２が、データストリーム１０４に沿って単一のメッセージをシステムサーバ１０６に送信する。このシステムサーバ１０６は、ネットワーク１１２へメッセージ１０８を送信し、ネットワーク１１２はユーザＡ１１８へメッセージ１１４を配信する。ユーザＡ１１８は、ネットワーク１１２へ戻る応答１１６を送信する。ネットワーク１１２は、システムサーバ１０６へ肯定応答の受信１１０を配信する。また、システムサーバ１０６は、ユーザＢ１２０、ユーザＣ１２２、及びユーザＤ１２４のために前記ステップに従う。これらのステップは複数のユーザのために、順次に並行に又は同時に生じ、そして、ユーザ間の適切な順番で行われる。

図２は、同様なシステム１００を示し、各ユーザ１１８,１２０,１２２,１２４は、速いが信頼性の少ないサービス品質を選択する。この場合、マルチキャストプロトコルが利用される。図２において、送信者１０２が、データストリーム１０４に沿って単一のメッセージをシステムサーバ１０６に送信する。このシステムサーバ１０６は、ネットワーク１１２へ単一のメッセージ１２６を送信し、ネットワーク１１２はユーザＡ１１８、ユーザＢ１２０、ユーザＣ１２２、及びユーザＤ１２４へメッセージ１２８を配信する。ユーザは、信頼性の少ないサービス品質によるメッセージを受信することを選択する。このサービス品質のために、ユーザ１１８、１２０、１２２、１２４は、システムサーバ１０６によって受信される必要がある応答を送信しない。各ユーザはこのメッセージをほぼ同時に受信するが、メッセージを取得することが保証されはしない。

図３において、送信者１０２は、単一のメッセージをデータストリーム１０４に沿ってシステムサーバ１０６へ再度送信する。このシステムサーバ１０６は、一時記憶としての揮発性又は実行時メモリのような記憶空間１４２を示し、ユーザが信頼できるサービスの品質を選択することを判断したり、及びユーザが信頼の少ないサービス品質を選択することを判断する。

ユーザＡ１１８及びユーザＣ１２２のために、システムサーバ１０６は、ネットワーク１１２へ単一のメッセージ１３０を送信する。ネットワーク１１２はユーザＡ１１８及びユーザＣ１２２へメッセージ１３６を配信する。ユーザは信頼の少ないサービス品質によるメッセージを受信することを選択する。このサービス品質のために、ユーザＡ１１８及びユーザＣ１２２は、システムサーバ１０６によって受信される必要がある応答を送信しない。各ユーザＡ１１８及びユーザＣ１２２は、このメッセージ１３６をほぼ同時に受信するが、メッセージを取得することが保証されはしない。

また、システムサーバ１０６は、ネットワーク１１２へメッセージ１３２を送信する。ネットワーク１１２は、ユーザＢ１２０へメッセージ１３８を配信する。ユーザＢ１２０は、信頼できるサービス品質によるメッセージを受信することを選択する。ユーザＢ１２０は、ネットワーク１１２へ戻る応答１４０を送信する。ネットワーク１１２は、システムサーバ１０６へ肯定応答の受信１３４を配信する。また、システムサーバ１０６は、ユーザＤ１２４のために信頼できる処理を受ける。

図４は、本発明の一実施例に従った別のシステム２００を示す。送信者２０２が、データストリーム２０４に沿って単一のメッセージをシステムプロセッサ２０６に送信する。このシステムプロセッサ２０６は、一時記憶としての実行時又は揮発性メモリのような記憶空間２３０を示し、ユーザが信頼できるサービス品質を選択することを判断したり、及びユーザが信頼の少ないサービス品質を選択することを判断する。ユーザＡ２１４及びユーザＣ２１８のために、システムプロセッサ２０６はマルチキャスト装置２１０へ単一のメッセージ２０８を送信する。マルチキャスト装置２１０は、ユーザＡ２１４及びユーザＣ２１８へメッセージ２１２を配信する。ユーザは信頼の少ないサービス品質によるメッセージを受信することを選択する。このサービス品質のために、ユーザＡ２１４及びユーザＣ２１８は応答を送信しない。各ユーザＡ２１４及びユーザＣ２１８は、このメッセージ２１２をほぼ同時に受信するが、メッセージ２１２を取得することが保証されはしない。

また、システムプロセッサ２０６は、ポイントツー・ポイント装置２２４へメッセージ２２２を送信する。ポイントツー・ポイント装置２２４はユーザＢ２１６へメッセージ２２６を配信する。ユーザＢ２１６は、信頼できるサービス品質によるメッセージを受信することを選択する。次に、ユーザＢ２１６は、ポイントツー・ポイント装置２２４へ戻る応答２２８送信する。また、ポイントツー・ポイント装置２２４は、ユーザＤ２２０のために、ポイントツー・ポイント処理を受ける。マルチキャスト及び、ポイントツー・ポイント分配を実行するとき、ポイントツー・ポイントの前、後、又は同時に、マルチキャスト通信が初期化され又は日程計画される。この２つの分配方法のための個々のタスクが資源のために競合することができ、かつ任意の順序で及び／または同時に計算されることができる。

図５は、ユーザＢ２１６が両方のサービス品質によってメッセージを受信することを選択する点を除き、同様なシステム２００を示す。例えば、これは、ユーザが信頼できないＱｏＳなどによって、メッセージを迅速に受信することを望むがメッセージの全てを受信することが保証されないときに適切である。したがって、メッセージが信頼できるＱｏＳによって送信されることを要求する。ユーザＡ２１４、ユーザＢ２１６、及びユーザＣ２１８のために、システムプロセッサ２０６は、マルチキャスト装置２１０へ単一のメッセージ２０８を送信する。マルチキャスト装置２１０は、ユーザＡ２１４、ユーザＢ２１６、及びユーザＣ２１８へメッセージ２３２を配信する。ユーザは信頼の少ないサービス品質によるメッセージを受信することを選択する。また、システムプロセッサ２０６は、ポイントツー・ポイント装置２２４へメッセージ２２２を送信する。ポイントツー・ポイント装置２２４は、ユーザＢ２１６及びユーザＤ２２０へメッセージ２２６を配信する。ユーザは、信頼できるサービス品質によるメッセージを受信することを選択する。ユーザＢ２１６は、信頼できるサービスだけのためにポイントツー・ポイント装置２２４へ戻る応答２２８を送信する。

図１のシステム及び図４のシステムの両方のために、図６に示す本発明の一実施例に従って処理３００が用いられる。この処理において、第１及び／または第２のサービス品質の選択が、システムの各ユーザのために、又は少なくとも、送信者３０２からのメッセージを受信することを選択する各ユーザのために格納される。データストリーム上で受信されたメッセージは、サービス品質に関するユーザの選択に３０４に従い、各ユーザに向けられる。第１のサービス品質の選択を選ぶユーザにとって、メッセージはそのような各ユーザに対してほぼ同時にマルチキャスト通信される。第２のサービス品質の選択を選ぶユーザにとって、メッセージはそのような各ユーザに対して個別に送信され、そして各ユーザがメッセージ３０８を受信することが保証される。

あるユーザがマルチキャストアプローチを好む１つの理由は、十分に信頼できるサービスにおいて固有のペナルティーが存在するからである。そのようなのペナルティーの１つは、システムの全体性能の縮小を含む。システムの全体性能は減じられる。十分に信頼できるサービスは、典型的には、マルチキャスト通信システムよりも遅くかつ拡張性が少ないの両方である。マルチキャスト通信のとき、いかに多数の参加者が存在するかにかまわずメッセージは一度だけ送信される。マルチキャストメッセージは、オンメッセージのルーチンのようなルーチン経由で配信されることができる。ユーザはマルチキャストセッションにおける消費者、及びその消費者のための登録リスナーを生成することができる。次に、消費者からのメッセージは、他の非同期メッセージのようなセッション中に順番に並べられる。

マルチキャストアプローチを好む別の理由は、実際上、幾つかのアプリケーションが配信待ち時間に非常に敏感であることからきている。また、アプリケーションは、異なる受信者がメッセージを得る際の順番に敏感なこともある。メッセージを早く受信することが大きな利益になり得るのに対して、他の受信者よりも遅くメッセージを得ることは大きな不利益となる可能性がある。マルチキャストを使用するとき、これらのアプリケーション及び受信者はほぼ同時にメッセージを得て、待ち時間及び／または順番の論点を殆ど問題としない。

信頼できる場合、各参加者と接触して待ち続ける必要がある。信頼できるシステムを使用するとき、全ての参加者がデータを受信することを保証するため、サービスがハンドシェーク（同期をとるための信号交換）を要求する際に大きな数に定めたのでは実行できない。本アプローチが相当に大きなユーザ数に用いられる場合、システムは大量のメッセージ通信ロード状態を保持することができない。

本発明の一実施例に従ったシステムは、ユーザにＱｏＳ選択を提供することによってこれらの問題を回避する。ブロードキャストすべきメッセージを有するユーザ又はサーバは、各メッセージをシステムに一度だけ送信する必要があるにすぎない。システムはそのメッセージに関する両方のサービス品質を扱うことができる。ある実施例では、ユーザリストをそれぞれがサービス品質のための２つのグループに分離する。これらのグループは、一時記憶としての揮発性又は実行時メモリに、又はもっと永続的な記憶を要求するシステム又はアプリケーションのためのシステムデータベースに、適切な記憶方法で保持される。

また、システムはサーバ側のフィルタリング処理よりもクライアント側のフィルタリング処理を行うことができる。これは、サーバからクライアントへいくつかの機能性を移動させることによって、システムの実行性能を改善する。メッセージがアプリケーションに与えられる前に、フィルタリング処理はＪＭＳなどによってクライアント上で行われることができる。フィルタリング処理がクライアント側で行われる限り、それはＪＭＳであってフィルタリング処理制御に存在するアプリケーションではない。ポイントツー・ポイント配信の場合、フィルタリング処理はＪＭＳによってサーバ側で行われることができる。どちらかのＱｏＳのよってメッセージがクライアントに到着するとき、クライアント又はユーザは、その時点でメッセージをフィルタリングして取り除くために常に選択することができる。様々なメッセージフィルタリング処理方法が使用され、例えば、それらは本技術分野で知られ且つ使用されているようなものである。

前述したように、ＪＭＳ ＡＰＩは、ユーザが”肯定応答”モードを使用するレベルのようなハンドシェークレベルを指定することを許可する。肯定応答モードにおいて、ユーザは、入ってくるメッセージのすべて、いくつか、又は何もない肯定応答を選択することができる。肯定応答モードは、ユーザの関与から離れたスイッチであり、そしてリスナーはメッセージを受信するために使用されることができる。マルチキャスト通信が”肯定応答でない”モードに設定されるとき、メッセージが受信される方法を実際に変化させる必要はない。クライアントはメッセージを一度に扱い、典型的には、肯定応答を有しないメッセージを受信するために何も行う必要はない。

先行技術のシステムにおいて、ＱｏＳを変えるためにはプログラムＡＰＩを変える必要があった。消費者は、マルチキャストを好む参加者、及びより信頼できるサービスを好む参加者であるが、両方のグループに適応するために２つのＡＰＩを生成しかつ管理する必要はない。

本発明に従ったシステムにおいて、ユーザは１つのパラメータを単に設定し、所望のＱｏＳを使用するメッセージを受信することができる。このシステムにおいて、マルチキャスト参加者のための実行スレッドがある。この実行スレッドは、ユーザの利益に耳を傾けた背景で実行するプログラムを含むことができる。メッセージがマルチキャストストリームに到着するとき、メッセージは、正規のＪＭＳメッセージのように実装され、リスナーに配信されることができる。メッセージが到着するときはいつでも、リスナーはコールバックなどを介して呼び出されることができる。

信頼できる参加者のために、サーバはクライアントに直接、メッセージを手渡し、次にリスナーに対してそのメッセージを同様に実装しかつ配信することができる。両方のメッセージがリスナーに入る。小さな”grab back”プログラムのようなプログラムは、メッセージをつかまえてそれをクライアントに手渡すために用いられる。この方法で、クライアントは同じメッセージをみることが可能になる。

永続したリスナーが、ユーザのためのサービスに置かれる。メッセージが到着するときはいつでも、ユーザによってセットアップされている通常のリスナーとして待ち行列に入れられることが可能である。実行スレッドは、待ち行列に受信メッセージを置きながら、入力ストリーム又はソケットを絶えず聞くことができる。ＪＭＳセンス（sense）には、入ってくるメッセージの単順序ストリーム（single-ordered stream）又は”セッション”がある。ＪＭＳセンスのセッションは、”肯定応答”モードを指定することにより生成されたマルチキャストセッションである。

セッション内で、ユーザは多重入力ストリームの興味を表現することができる。これら全てのストリームがマルチキャストストリームの場合、そのソケットを聞く唯一のソケット及び唯一のスレッドがある。メッセージが受信されるとき、ユーザがメッセージのソースを区別する方法でそのメッセージをユーザに分配することができる。また、ユーザは、多重スレッドを聞くために多重セッションを生成することができる。実際、ユーザが専用ソケットにある各スレッドを選べば、ユーザは各トピックスに専用のスレッドをもつことができる。

ユーザが多重の情報ソースを持つ場合、ユーザはすべてを聞くために選択し且つ後でそれを区別することができる。また、ユーザは１または２のソースを聞くために選択することができる。各ソースは分離した媒体を使用するために構成される。ユーザは、あるソケット又は”マルチキャストグループ”の幾つかのトピックスをセットアップするために選択することができる。ユーザが１つのトピックスに興味がある場合、そのユーザに来る他の全てのトピックスを捨てる必要がある。

１つのメッセージを処理する間に、他のメッセージを失う可能性がある。システムは、メッセージが失われることをユーザに告げることができる。本質的に、各メッセージは通し番号でタグ付けされることができる。メッセージが失われたことをＪＭＳが検出する場合、連続の隙間（sequence gap）があることを報告することができる。

また、マルチキャストプロトコルは順序を保証しない。メッセージが順序どおりに受信されない場合、これは連続の隙間として検出されかつ報告される。ExceptionListenerのような例外リスナーに対してSequenceGapExceptionのような例外を配信することによって、連続の隙間が報告される。セッションが例外リスナーを持たない場合、例えば、setExceptionListener()methodを用いて設定される場合には、どんな連続の隙間も報告されない。

あるタイプの連続の隙間では、メッセージバックを得る方法がまったくない。第２のタイプの連続の隙間では、ユーザは長い情報ストリームを受信し続ける。その結果、メッセージの中間で情報パケットが欠落し、破損したメッセージ生じる。本発明に従った一実施例において、このようなメッセージの第１のパケットは、メッセージの源、メッセージの長さ、メッセージｉｄ、ヘッダー属性などのメッセージに関係した情報を含む。初期のパケットは、この情報の幾つか又は全てをユーザに報告するために求められる。

入ってくる全てのメッセージは、メッセージが入ってくるデータストリームを知っていることが可能な情報でタグ付けされている。異なるストリームからのメッセージは互いに真に競合しておらず、それらはトラフィックが重いときには互いを排除する。しかしながら、イーサネット（登録商標）で物理的な問題となり得る。サーバは最近のメッセージのためにバッファを保持し、メッセージが失われた場合にサーバはそれらを要求することができる。

例えば、システムはKeepOld方法のようなより新しいメッセージを取り去ることによってメッセージストリームを保存するルーチン又は方法を使用する。これはアプリケーションにとって望まれていることであり、単一ストリーム内のメッセージをより効率的に処理する。また、システムはKeepNewのようなルーチン又は方法を使用する。これはより古いメッセージを取り去ることによってより新しいメッセージを保存することができる。これは、アプリケーションにとって望まれていることであり、繰り返されるメッセージをより効率的に処理してよりタイムリーな情報を含んでいる。

各マルチキャストメッセージに要求された処理の量に依存して、クライアントは容易に遅延することが可能であった。このシナリオにおいて、メッセージがクライアントに積まれ始める。MessagesMaximumのような新たな属性が未処理のメッセージの数を制限するために追加され、所定のセッションが未処理状態を有することが可能となる。マルチキャストセッションのためにメッセージが一度捨てられ、クライアントは最大メッセージ閾値に到達する。メッセージ最大のための有効値は、例えば−１及び／または１〜２³¹−１の範囲にある。−１の値は、セッションに積み重ねることが可能な未処理のメッセージ数に何の制限もないことを示している。

最大のメッセージ値を拡大することの結果としてメッセージが捨てられるとき、定義された基準に従ってそれらは捨てられる。例えば、方法又はパラメータに含まれたり、ポリシー又はオーバランポリシー（OverrunPolicy）をオーバランする。オーバランポリシーのための有効な値は、例えば、” KeepOld”及び”KeepNew”である。メッセージ最大及びオーバランポリシーの両方は、接続場所を経由して構成され、そして例えば、weblogic.jms.extension.WLSessionのようなクラスの方法を使ったセッションを基礎にして置き換えられることができる。

本発明の好ましい実施例の先の記述は、図示及び説明のために提供されていた。それは、本発明が開示された厳密な形式に徹底させたり制限することを意図していない。明らかに、本技術分野の当業者であれば多くの修正及びバリエーションが適用可能であろう。本発明の原理及びその実際の応用を最良に説明するために実施例が選択されかつ記載されていた。したがって、本技術分野の当業者であれば、様々な実施例及び考慮された特定の使用に適合させるための様々な修正によって本発明を理解することが可能であろう。本発明の範囲は、特許請求の範囲及びその均等物により定義されることが意図される。

本発明の一実施例に従い、各ユーザ用のポーントツー・ポイントのサービス品質を示したシステム図である。 本発明の一実施例に従い、各ユーザ用のマルチキャストのサービス品質を示したシステム図である。 本発明の一実施例に従い、サービスに関する両方品質を示したシステム図である。 本発明の一実施例に従い、サービスに関する両方品質を示したシステム図である。 本発明の一実施例に従い、サービスに関する両方品質を示したシステム図である。 本発明の一実施例に従い、メッセージ通信処理のステップを示したフローチャートである。

Claims (24)

1. 単一データストリームから２つのサービス品質を供給するシステムであって、
   （ａ）複数のユーザのそれぞれのために、第１のサービス品質の選択と第２のサービス品質の選択との少なくとも１つを格納する記憶空間と、
   （ｂ）サービス品質に関するユーザの選択に従って、各ユーザのために前記データストリームを直接プログラムしたプロセッサと、
   （ｃ）前記記憶空間に格納された前記第１のサービス品質の選択のために、前記プロセッサから前記データストリームを受信し、かつ当該データストリームを各ユーザにマルチキャスト通信するマルチキャスト通信装置であって、各ユーザのために、単一又は複数のデータストリームから入ってくるメッセージを聞くことができるスレッドを備えた当該マルチキャスト通信装置と、
   （ｄ）前記プロセッサから前記データストリームを受信し、かつ前記第２のサービス品質が前記記憶空間に格納されるために、各ユーザが当該データストリームを受信することを保証する、ポイントツー・ポイント通信機器とを含むことを特徴とするシステム。
2. 前記システムのユーザの１人に対し、前記データストリームに送信された情報を聞くために適合されたリスナーをさらに含むことを特徴とする請求項１に記載のシステム。
3. サービスに関する両方の品質のためにプロセッサに対して命令を提供する単一ＡＰＩをさらに含むことを特徴とする請求項１に記載のシステム。
4. 各ユーザがマルチキャストのサービス品質を選択するための実行スレッドをさらに含み、前記実行スレッドは、前記ユーザに代わって前記マルチキャストストリーム上のメッセージを聞き、次に前記ユーザへ前記メッセージを配信することを特徴とする請求項１に記載のシステム。
5. ユーザがサービスに関する両方の品質のためのメッセージを受信することを許可する、各リスナーの待ち行列をさらに含むことを特徴とする請求項１に記載のシステム。
6. 複数のデータストリームのために前記記憶空間が各ユーザの分離した選択を格納する請求項１に記載のシステム。
7. 前記データストリームのあるメッセージをろ過することをユーザに許可するフィルタリング機器をさらに含むことを特徴とする請求項１に記載のシステム。
8. ユーザがメッセージ配信に関するサービス品質を選択することを許可する方法であって、
   （ａ）システムの各ユーザのために、第１のサービス品質の選択と第２のサービス品質の選択との少なくとも１つを格納し、
   （ｂ）サービス品質に関するユーザの選択に従い、各ユーザのために、単一ＡＰＩを用いてデータストリーム上で受信した各メッセージを処理するとともに当該メッセージを転送し、
   （ｃ）前記第１のサービス品質を選択する各ユーザに対して前記メッセージをマルチキャスト通信し、その間、各ユーザのために、単一又は複数のデータストリームから入ってくるメッセージを聞くことができるスレッドを処理し、
   （ｄ）前記第２のサービスの品質選択する各ユーザに直接前記メッセージを送信し、かつ前記ユーザが前記メッセージを受信することを保証する、
   ことを含むことを特徴とする方法。
9. サービス関する何れかの品質によって、ユーザにより受信された前記メッセージをフィルタリングするステップをさらに含むことを特徴とする請求項８に記載の方法。
10. 各ユーザのために、前記ユーザに代わってメッセージを聞くリスナーを供給するステップをさらに含むことを特徴とする請求項８に記載の方法。
11. １人ずつ前記ユーザに配信されるようにするため、サービス関する何れかの品質によってユーザに送信されたメッセージを待ち行列に入れるステップをさらに含むことを特徴とする請求項８に記載の方法。
12. メッセージが失われているかどうかをユーザが示すことができるようにするため、各メッセージに通し番号のタグをつけるステップをさらに含むことを特徴とする請求項８に記載の方法。
13. 前記メッセージが受信されている前記データストリームをユーザが示すことができるようにするため、各メッセージにタグをつけるステップをさらに含むことを特徴とする請求項８に記載の方法。
14. ユーザが前記フィルタリングのために用いられるフィルタリング基準を選択することを許可するステップをさらに含むことを特徴とする請求項９に記載の方法。
15. 単一のデータストリームから２つのサービス品質を提供する方法であって、
    （ａ）複数のユーザのそれぞれのために、第１のサービス品質の選択と第２のサービス品質の選択との少なくとも１つを格納し、
    （ｂ）サービス品質に関するユーザの選択に従い、各ユーザのために、前記データストリーム上で受信した各メッセージを方向付け、
    （ｃ）各ユーザが前記第１のサービス品質を選択する各ユーザに対して前記メッセージをマルチキャスト通信し、その間、各ユーザのために、単一又は複数のデータストリームから入ってくるメッセージを聞くことができるスレッドを処理し、
    （ｄ）前記第２のサービス品質を選択する各ユーザに直接前記メッセージを送信し、かつ前記ユーザが前記メッセージを受信することを保証する、
    ことを含むことを特徴とする方法。
16. サービス関する何れかの品質によって、ユーザにより受信された前記メッセージをフィルタリングするステップをさらに含むことを特徴とする請求項１５に記載の方法。
17. 各ユーザのために、前記ユーザに代わってメッセージを聞くリスナーを供給するステップをさらに含むことを特徴とする請求項１５に記載の方法。
18. １人ずつ前記ユーザに配信されるようにするため、サービス関する何れかの品質によってユーザに送信されたメッセージを待ち行列に入れるステップをさらに含むことを特徴とする請求項１５記載の方法。
19. メッセージが失われているかどうかをユーザが示すことができるようにするため、各メッセージに通し番号のタグをつけるステップをさらに含むことを特徴とする請求項１５に記載の方法。
20. 前記メッセージが受信されている前記データストリームをユーザが示すことができるようにするため、各メッセージにタグをつけるステップをさらに含むことを特徴とする請求項１５に記載の方法。
21. コンピュータを、
    （ａ）システムの各ユーザのために、第１のサービス品質の選択と第２のサービス品質の選択との少なくとも１つを格納する手段と、
    （ｂ）サービス品質に関するユーザの選択に従い、各ユーザのために、単一ＡＰＩを用いてデータストリーム上で受信した各メッセージを処理するとともに当該メッセージを転送する手段と、
    （ｃ）前記第１のサービス品質を選択する各ユーザに対して前記メッセージをマルチキャスト通信し、その間、各ユーザのために、単一又は複数のデータストリームから入ってくるメッセージを聞くことができるスレッドを処理する手段と、
    （ｄ）前記第２のサービス品質を選択する各ユーザに直接前記メッセージを送信し、かつ前記ユーザが前記メッセージを受信することを保証する手段と、
    して機能させるためのプログラムを記録したコンピュータ読取り可能な記録媒体。
22. ユーザがメッセージ配信に関するサービス品質を選択することを許可するための、サーバコンピュータによって実行するコンピュータプログラムであって、
    （ａ）システムの各ユーザのために、第１のサービス品質の選択と第２のサービス品質の選択との少なくとも１つを格納するコンピュータコードと、
    （ｂ）サービス品質に関するユーザの選択に従い、各ユーザのために、単一ＡＰＩを用いてデータストリーム上で受信した各メッセージを処理するとともに当該メッセージを転送するコンピュータコードと、
    （ｃ）前記第１のサービス品質を選択する各ユーザに対して前記メッセージをマルチキャスト通信し、その間、各ユーザのために、単一又は複数のデータストリームから入ってくるメッセージを聞くことができるスレッドを処理するコンピュータコードと、
    （ｄ）前記第２のサービス品質を選択する各ユーザに直接前記メッセージを送信し、かつ前記ユーザが前記メッセージを受信することを保証するコンピュータコードとを、
    含むことを特徴とするコンピュータプログラム。
23. ユーザがメッセージ配信に関するサービス品質を選択することを許可するためシステムであって、
    （ａ）システムの各ユーザのために、第１のサービス品質の選択と第２のサービス品質の選択との少なくとも１つを格納する手段と、
    （ｂ）サービス品質に関するユーザの選択に従い、各ユーザのために、単一ＡＰＩを用いてデータストリーム上で受信した各メッセージを処理するとともに当該メッセージを転送する手段と、
    （ｃ）前記第１のサービス品質を選択する各ユーザに対して前記メッセージをマルチキャスト通信し、その間、各ユーザのために、単一又は複数のデータストリームから入ってくるメッセージを聞くことができるスレッドを処理する手段と、
    （ｄ）前記第２のサービス品質を選択する各ユーザに直接前記メッセージを送信し、かつ前記ユーザが前記メッセージを受信することを保証する手段とを、
    含むことを特徴とするシステム。
24. プロセッサと、
    前記プロセッサによって実行されるオブジェクトコードを含むコンピュータシステムであって、
    前記オブジェクトコードは、
    （ａ）システムの各ユーザのために、第１のサービス品質の選択と第２のサービス品質の選択との少なくとも１つを格納し、
    （ｂ）サービス品質に関するユーザの選択に従い、各ユーザのために、単一ＡＰＩを用いてデータストリーム上で受信した各メッセージを処理するとともに当該メッセージを転送し、
    （ｃ）前記第１のサービス品質を選択する各ユーザに対して前記メッセージをマルチキャスト通信し、その間、各ユーザのために、単一又は複数のデータストリームから入ってくるメッセージを聞くことができるスレッドを処理し、
    （ｄ）前記第２のサービス品質を選択する各ユーザに直接前記メッセージを送信し、かつ前記ユーザが前記メッセージを受信することを保証する、手段とで構成されていることを含むコンピュータシステム。

Images