(57)【特許請求の範囲】
【請求項１】
ネットワークを介してサーバに接続されたクライアントがリモートプロシージャコールプロトコルを使用して通信する方法であって、
ａ）複数のコールメッセージを含む集合コールメッセージを前記サーバに送信するステップと、
ｂ）前記集合コールメッセージに含まれた前記コールメッセージの成功送信またはエラー送信を示すエラーメッセージを受信するステップと、
ｃ）前記エラーメッセージが、少なくとも１つのコールメッセージのエラー送信を示す場合、当該少なくとも１つのエラー送信されたコールメッセージを、前記エラー送信されたコールメッセージと複数の他のコールメッセージとを含む他の集合コールメッセージにより再送信するステップと、
を含む、前記方法。
【請求項２】
ステップｂ）は、前記集合コールメッセージに含まれたコールメッセージ専用の少なくとも１つのリプライメッセージと前記エラーメッセージとを受信するステップを有する、請求項１記載の方法。
【請求項３】
前記リプライメッセージは、前記集合コールメッセージに含まれたコールメッセージのうちの成功送信されたものの全てに対するリプライメッセージを含む、請求項２記載の方法。
【請求項４】
ネットワークを介してクライアントに接続されたサーバがリモートプロシージャコールプロトコルを使用して通信する方法であって、
ａ）複数のコールメッセージを含む集合コールメッセージを前記クライアントから受信するステップと、
ｂ）前記受信された集合コールメッセージの中の少なくとも１つのエラーを含むコールメッセージ（ＥＲＲ）を検出した場合、
ｃ）前記少なくとも１つのエラーを含むコールメッセージ（ＥＲＲ）に応答して少なくとも１つのエラーメッセージを生成するステップと、
ｄ）前記集合コールメッセージに含まれたコールメッセージ専用の少なくとも１つのリプライメッセージに前記少なくとも１つのエラーメッセージを連結するステップと、
ｅ）前記少なくとも１つのエラーメッセージと前記少なくとも１つのリプライメッセージとを送信するステップと、
を有する、前記方法。
【請求項５】
ステップｄ）の前記リプライメッセージは、前記集合コールメッセージに含まれたコールメッセージのうちの成功受信されたものの全てに対するリプライメッセージである、請求項４記載の方法。
【請求項６】
サーバと、クライアントと、前記サーバおよび前記クライアントを接続するネットワークとを有するコンピュータシステムであって、前記クライアントは請求項１、２または３記載の方法を実行するリモートプロシージャコールハンドラを備える、コンピュータシステム。
【請求項７】
前記サーバは請求項４または５記載の方法を実施する別のリモートプロシージャコールハンドラを備える、請求項６記載のコンピュータシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はクライアント及びサーバにおけるリモートプロシージャコールハンドラを動作させる方法に関する。また、本発明は前記クライアント及びサーバを含むコンピュータシステムにも関する。クライアント及びサーバの両方は、好ましくはリモートプロシージャコール（ＲＰＣ）プロトコルを使用してネットワークを介して通信を行う。
【背景技術】
【０００２】
下記の記載においてしばしば使用されるクライアント及びサーバという用語はハードウエアエンティティ（例えば、コンピュータ、マイクロプロセッサ、専用ネットワークチップ、ネットワークカード）及びソフトウエアエンティティ（例えば、適切なハードウエア上で起動しているプログラムまたはプロセス）を意味している。また、クライアント及びサーバという用語は特定のトランザクション・処理・行為にのみ用いられる。ハードウエアエンティティまたはソフトウエアエンティティは時間が異なれば（時間によって）両方の役割を果たすように動作することもできる。さらにクライアント及びサーバという用語は従来のトランスミッタ（送信器）及びレシーバ（受信器）のような関係も意味し、従って、上記２つのエンティティの一方または両方はハードウエア及び／またはソフトウエアにより実現されることもある。リモートプロシージャコールハンドラはサーバ内もしくはクライアント内の適切なソフトウエアエンティティもしくはハードウエアエンティティであり、少なくともコール（呼び出し）メッセージ及びリプライ（返信）メッセージの送信及び受信を扱う（好ましくはＲＰＣプロトコルを利用して）。
【０００３】
コンピュータシステムという用語は、当該コンピュータシステムがクライアントとサーバとを含む場合、ネットワークを介して通信するクライアント及びサーバを有する適切なハードウエアエンティティを意味する。コンピュータシステムという用語は従来の構成（複数の標準的なコンピュータがネットワークを介して接続されている構成）に限定されるべきではない。
【０００４】
このような従来のシステムでは、クライアントはネットワークを介してコールメッセージをサーバに送信することによってリモートプロシージャ動作を行う。サーバは所定動作によってレスポンスを行い、作成データをリプライメッセージの中に含めてネットワークを介してクライアントに返信する。サーバにおいてこのような動作を引き起こすためには、それぞれの動作に必要な全てのパラメータをコールメッセージ内に入れて、それらをサーバに送って処理させるという方法が考えられる。この動作の後、サーバは、上記と同じように、作成データをリプライメッセージに含めてクライアントに返す。
【０００５】
リモートプロシージャコール（ＲＰＣ）プロトコルの公知の仕様は非特許文献１に記載されている。この仕様はコールプロセス及びリプライプロセスの定義を示している。よって、コールする側（すなわちコーラ：ｃａｌｌｅｒ）であるクライアントは、まずプロシージャパラメータの全てを含むコールメッセージをサーバに送る。その後、クライアントはサーバからプロシージャの結果を含むリプライメッセージが来るのを待つ（中断する）。一旦リプライメッセージが受信されると、プロシージャの結果が抽出され、クライアント側の処理が再び始まる。サーバ側では、ＲＰＣプロセスは休止状態となり、新たなコールメッセージの到着を待つ。新たなコールメッセージが到着すると、サーバはプロシージャパラメータの抽出を開始し、結果を計算し、再びリプライメッセージを送信する。その後は、次のコールメッセージを待つ。このような動作モードによれば、常に２つのプロセスのうちの１つだけ（つまり、サーバのプロセスまたはクライアントのプロセス）しかアクティブにならない。このような動作モードは同期モードと称される。
【０００６】
別の動作モードが特許文献１に開示されており、これは非同期モードと称されるべきものである。複数のコールメッセージがパッケージ化され、集合コールメッセージ（ｃｏｌｌｅｃｔｅｄ  ｃａｌｌ  ｍｅｓｓａｇｅ）が形成される。つまり、複数のコールメッセージがＲＰＣプロトコルを使用してまとめてクライアントからサーバに送信される。このような集合コールは、即時レスポンスを必要としない事例に有利である。即時レスポンスを必要とするコールメッセージが生成されるまで、幾つかのコールメッセージがクライアント側で集められる。即時レスポンスを必要とするコールメッセージが生成されると、コールメッセージの集合がパッケージ化されサーバに送られる。この技術によれば、リクエストの数をかなり減ずることができる。さらに、ネットワークを介して送られる各データパッケージに対してネットワークプロトコルにより生成される必要なオーバーヘッドは、幾つかのコールが１つのデータパッケージに集約されるという事実により、減少する。常に２つのプロセスのうちの１つ（サーバプロセスまたはクライアントプロセス）しかアクティブにならないという厳しい条件は無くなるので、上記した動作モードは非同期的であると言われる。
【０００７】
しかしながら、同期モードも非同期モードも、誤った送信コールメッセージ及び送信リプライメッセージについては標準の対処法を適用している。例えば、公知のタイムアウト法もしくは再送信法が用いられている。本明細書においてエラー送信されたコールメッセージ及びリプライメッセージとは、受け取り側でエラーを含んで受信されたメッセージを意味する（当該エラーが、送信側、送信媒体もしくは受信側によって発生したかどうかに拘わらず）。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】米国特許第６，３２１，３７４号明細書
【非特許文献】
【０００９】
【非特許文献１】Ｒ．Ｓｒｉｎｉｖａｓａｎ著「ＲＰＣ：Ｒｅｍｏｔｅ  Ｐｒｏｃｅｄｕｒｅ  Ｃａｌｌ  Ｐｒｏｔｏｃｏｌ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ」第２版、１９９５年８月（ＲＦＣ１８３１）
【発明の概要】
【００１０】
本発明の目的はクライアント内及びサーバ内のリモートプロシージャコールハンドラを動作させる方法（動作方法・操作方法）を提供することである。この方法はエラー送信されたコールメッセージ及びリプライメッセージの扱い方について改良されている。本発明の他の目的は、このようなクライアント及びサーバを含むコンピュータシステムを提供することである。
【００１１】
上記目的は独立請求項に記載された内容・事項によって達成される。有利な実施形態の内容については従属請求項に記載されている。
【００１２】
本発明によれば、ネットワークを介してサーバに接続されたクライアントにおいてリモートプロシージャコールハンドラを動作させる方法が提供される。つぎのステップが実行される。
ａ）複数のコールメッセージを含む集合コールメッセージをサーバに送信するステップ。
ｂ）前記集合コールメッセージに含まれたコールメッセージの成功送信もしくはエラー送信を示すエラーメッセージを受信するステップ。エラーメッセージは、少なくとも１つのコールメッセージのエラー送信を示し、当該少なくとも１つのエラー送信されたコールメッセージは次のステップｃにより再送信される。
ｃ）前記エラー送信されたコールメッセージと複数の他のコールメッセージとを含む別の集合コールメッセージをサーバに送信するステップ。
【００１３】
本発明によれば、サーバ内のリモートプロシージャハンドラはクライアントの動作に応答して補完的な動作を行う。即ち、本発明によれば、ネットワークを介してクライアントに接続されたサーバにおいてリモートプロシージャコールハンドラを動作させる方法は、つぎのステップを有する。
【００１４】
ａ）複数のコールメッセージ（１６）を含む集合コールメッセージ（１２）をクライアント（４）から受信するステップ、
ｂ）受信した集合コールメッセージ（１６）の中から少なくとも１つのエラーコールメッセージ（ＥＲＲ：ｅｒｒｏｎｅｏｕｓ  ｃａｌｌｓ  ｍｅｓｓａｇｅ）を検出するステップ、
ｃ）前記少なくとも１つのエラーコールメッセージ（ＥＲＲ）に応答して少なくとも１つのエラーメッセージ（２０）を生成するステップ、
ｄ）複数のリプライメッセージ（２４）を含む集合リプライメッセージ（１４）をクライアント（４）に送信する準備ができるまで、前記少なくとも１つのエラーメッセージ（２０）を保持するステップ、
ｅ）前記少なくとも１つのエラーメッセージ（２０）を前記集合リプライメッセージ（１４）の前記リプライメッセージ（２４）に連結するステップ、
ｆ）前記少なくとも１つのエラーメッセージ（２０）と複数の他のリプライメッセージ（２４）とを含む前記集合リプライメッセージ（１４）を送信するステップ。
【００１５】
クライアントのリモートプロシージャコールハンドラを動作させる方法及びサーバのリモートプロシージャコールハンドラを動作させる方法は次の考察に基づいている。
【００１６】
ネットワークにおいて、サーバとクライアントとを接続する（両者はリモートプロシージャコールプロトコルに基づいて通信する）と、エラーメッセージの送信及びエラー送信されたデータパケットの再送信のために、大量のネットワークトラフィックが生成されることになる（コールメッセージ及びリプライメッセージはデータパケットであると考える）。本発明によれば、エラーメッセージの送信及びエラー送信されたデータパケットの再送信を別個に行う必要は排除される。
【００１７】
本発明の場合、クライアントは一般的にネットワークにおけるリクエスト側のエンティティと考えられ、サーバは一般的にネットワークにおける回答側のエンティティと考えられる。
【００１８】
以下の記載において、本発明による方法の典型的な適用例として、クライアントが集合コールメッセージをサーバに送り、当該コールメッセージがエラー送信される場合を説明する。
【００１９】
当該エラー送信されたコールメッセージを受信するサーバは、エラーメッセージだけを返信する代わりに、次のリプライメッセージがクライアントに送られるまで、当該エラーメッセージを保持する。エラーメッセージは前記リプライメッセージに連結される。その結果、サーバとクライアントとの間の通信回数が減少する。２つ以上のエラー送信されたコールメッセージが送信された場合、２つ以上のエラーメッセージがリプライメッセージに連結され、よって、送信回数が増えることはない。
【００２０】
前記エラーメッセージを含むリプライメッセージを受信するクライアントも、同じような処理をする。１つのコールメッセージをサーバに再送信する代わりに、次の集合コールメッセージをサーバに送信すべきときまで、当該コールメッセージをクライアント側で保持する。エラー送信されたコールメッセージは単に集合コールメッセージに連結されるだけである。ここでもまた、少なくとも１つの送信を省略することになる。もし複数のエラー送信されたコールメッセージがある場合には、複数（回）の送信を省略することができる。
【００２１】
本発明の方法はクライアントサーバ通信に適用することができるし、反対に、サーバクライアント通信に適用することもできる。換言すると、クライアントが誤った集合コールメッセージをサーバに送信する場合だけでなく、サーバが誤ったリプライメッセージをクライアントに送信する場合にも適用することができる。後者の場合、実施される方法は上記した方法と全く同様である。
【００２２】
請求項１に係るクライアントにおいてリモートプロシージャコールハンドラを動作させる方法及び請求項４に係るサーバにおいてリモートプロシージャコールハンドラを動作させる方法は相補的であり、共通の技術思想により関連づけることができる。
【００２３】
好ましくは、クライアントにおいてリモートプロシージャコールハンドラを動作させる方法のステップｂ）はさらに、前記集合コールのコールメッセージ専用の少なくとも１つのリプライメッセージと前記集合エラーメッセージとを含む集合リプライメッセージを受信するステップを有する。さらに好ましくは、前記集合リプライメッセージは前記集合コールの中の送信が成功したコールメッセージの全てに対するリプライメッセージを含む。
【００２４】
ネットワークの反対側では、サーバにおいてリモートプロシージャコールハンドラを動作させる方法のステップｆ）はさらに、ステップａ）で前記集合エラーメッセージとともに受信された集合コールのコールメッセージ専用の少なくとも１つのリプライメッセージを含む集合リプライメッセージを送信するステップを含む。さらに好ましくは、前記集合リプライメッセージは、前記集合コールに含まれた受信コールメッセージのうちの正しく受信されたメッセージの全てに対するリプライメッセージを含む。
【００２５】
有利には、クライアントとサーバはコールメッセージ及びリプライメッセージを再送信するだけでなく、次に送信される予定になっているコールメッセージ及びリプライメッセージとともに再送信を行う。クライアントは、次のリプライメッセージにおいて前記少なくとも部分的に送信された集合コールへの完全な回答を受信する。こうすることにより、ネットワーク通信量はさらに減じられる。
【００２６】
有利には、もし緊急の（アージェント）リクエストがサーバに送られてきた場合、リプライメッセージの連結は中断され、当該緊急のリクエストが先に実行される。好ましくは、たとえ集合リプライメッセージが通常の場合のように多くのリプライメッセージを含んでいなくても、そのときまでに生成されたリプライメッセージはサーバによって集合リプライメッセージの中に入れられて送信される。
【００２７】
以下の記載において本発明は図面に基づいてさらに詳細に説明される。  
【図面の簡単な説明】
【００２８】
【図１】クライアントとサーバとを含むネットワークを示す図である。
【図２】コールメッセージを送信している間のクライアント／サーバ通信を示す概略フローチャートである。
【図３】コールメッセージを送信している間のクライアント／サーバ通信を示す概略フローチャートである。
【図４】リプライメッセージを送信している間のサーバ／クライアント通信を示す概略フローチャートである。
【図５】リプライメッセージを送信している間のサーバ／クライアント通信を示す概略フローチャートである。
【発明を実施するための形態】
【００２９】
図１はクライアント４とサーバ６とを含むコンピュータシステム２を示している。クライアントとサーバとはネットワーク８を介して相互接続されている。クライアント４とサーバ６とは適切なハードウエアエンティティ１０（例えば、コンピュータ、マイクロプロセッサ、ネットワークカード、インターフェースチップ等）により構成されている。図１に示された例示的な実施形態によれば、クライアント４とサーバ６とはそれぞれのハードウエア１０上で動作しているアプリケーションである。ここで、クライアント４とサーバ６とはリモートプロシージャコール（ＲＰＣ）プロトコル（好ましくはＲＦＣ１８３１に基づいてプロトコル）を使用してデータを交換する。クライアント４は集合コールメッセージ１２をネットワーク８を介してサーバ６に送信する。前記集合コールメッセージ１２は複数のコールメッセージを含み、当該複数のコールメッセージは、サーバ６によって実行されるべきプロセスための数個（複数）のパラメータを含む。得られたデータ（上記のパラメータに基づいて計算されたもの）は集合リプライメッセージ１４に含められてサーバ６からクライアント４へ送信される。集合コールメッセージ１２と同様に、集合リプライメッセージ１４は複数のリプライメッセージを含む。集合コールメッセージ１２への回答としての集合リプライメッセージ１４は例えばクライアント４によって表示されるべきデータを含むことができる。集合コールメッセージ１２及び集合リプライメッセージ１４のデータ経路１２'、１４'は図１に示されている。
【００３０】
以下の記載において、コールメッセージを送信する間のクライアント／サーバ通信が、図２及び図３を参照して説明される。
【００３１】
図２に示されているように、クライアント４は８個のコールメッセージ１６を含む集合コールメッセージ１２をサーバ６に送信する。尚、図示の都合上、参照符号はコールメッセージのいくつかにのみ付されている。図２に示された概略フローチャートにおいて、集合コールメッセージ１２は「ＣＡＬＬ  ０」として示されている。ここで、８個のコールメッセージ１６のうちの２個（即ち、コールメッセージ番号４と６）は正しく送信されたがサーバ６により受信される際に壊れてしまった（たとえば送信エラーやネットワークの故障により）と仮定する。これらコールメッセージ１２は「ＥＲＲ」として図示されており、その他のコールメッセージは「ＯＫ」として図示されている。サーバ６は例えばＣＲＣ比較その他のリダンダンシーチェック（冗長検査）により、欠陥のあるメッセージを検出する。このようなエラー検出１８の結果、コールメッセージ１６の成功配信と失敗配信を示すエラー状態（図２に示されているもの）が生成される。図２に示されているように、エラー状態は８ビットからなり、各ビットは集合コールメッセージ１２のそれぞれのコールメッセージ１６に対応している。ここで、「０」はコールメッセージ１６の成功配信を示し、「１」は失敗配信を示している。
【００３２】
その後、成功配信されたコールメッセージ１６に含まれたデータに基づいて、サーバ６は結果を計算しそれを集合リプライメッセージ１４に含めてクライントに返信する。この集合リプライメッセージ１４は上記結果をペイロード２２として含んでいる。さらに、集合リプライメッセージ１４はエラーメッセージ２０を含んでいる。エラーメッセージはエラー状態を１６進コードで示したものである。集合リプライメッセージ１４は図２において「ＲＥＰＬＹ  ０」として示されている。
【００３３】
クライアント４はエラーメッセージ２０を復号化することができるので、クライアント４はコールメッセージ１６番号４と６がエラー送信されたという情報を認識する。従って、クライアント４は上記コールメッセージ１６を、次に送信する予定になっている集合コールメッセージ１２と共に再送信する。
【００３４】
上記次に送信されることになっている集合コールメッセージ１２は図３において「ＣＡＬＬ  １」と示されている。上記の２つのエラー送信されたコールメッセージ１６番号４と６である「ＣＡＬＬ  ０」は図３において「ＲＥＰ」と示されており、６個の新しいメッセージ１６に連結され、上記集合コールメッセージ１２「ＣＡＬＬ  １」を形成する。この手法により、エラー送信されたコールメッセージ１６の再送信が行われる。
【００３５】
図３に示された例示的な実施形態によれば、全てのブロック（つまり、集合コールメッセージ１２「ＣＡＬＬ  １」のコールメッセージ１６の全て）はサーバ６に正しく送信され、そのエラー検出１８の結果は、集合コールメッセージ１２の全てのコールメッセージ１６が成功配信されたことを示す新しいエラー状態を示す（図３に示されているとおり）。従って、「ＲＥＰＬＹ  １」と称される集合リプライメッセージ１４は、この成功配信を示すエラーメッセージ２０を含む。
【００３６】
以下の記載において、集合リプライメッセージ１４を送信している間のサーバ／クライアント通信が、図４及び図５を参照して説明される。
【００３７】
最初に、「ＣＡＬＬ  ０」と称される集合コールメッセージ１２がクライアント４からサーバ６に成功送信されたと仮定する。従って、サーバ側のエラー検出１８の結果は、成功配信を示すエラー状態を示す。集合リプライメッセージ１４において、当該成功配信を示すエラーメッセージ２０はペイロードデータ（すなわち集合コールメッセージ１２により受信されたパラメータの結果）を有する複数のリプライメッセージ２４の中に含まれる。尚、説明（図示）の都合上、リプライメッセージ２４のうちの幾つかにだけ、参照符号が付されている。
【００３８】
例えば、リプライメッセージ２４番号１と３（これらは正しく送信されたとする）は、クライアント４で受信される際に例えばネットワークの故障によって壊れてしまったとする。これらリプライメッセージ２４は「ＥＲＲ」として示されており、その他のリプライメッセージは「ＯＫ」として示されている。よって、クライアント側のエラー検出１８の結果はリプライメッセージ番号１と３が間違った形で送信されたことを示すエラー状態となり、これは「１」で示されている。クライアントのエラー検出１８はＣＲＣ比較等によって実施される。
【００３９】
対応する２進（バイナリ）エラーメッセージ２０は、図５に示されているように、さらなる集合コールメッセージ１２の中のコールメッセージ１６に含まれる。上記集合コールメッセージ１２は「ＣＡＬＬ  １」と称され、クライアント４からサーバ６へ配信される。サーバ６はエラーメッセージ２０を読むことができ、従って、間違った形で送信されたリプライメッセージ２４番号１と３（図５において「ＲＥＰ」として示されている）を、次の集合リプライメッセージ１４「ＲＥＰＬＹ  １」に含めて再送信する。クライアント側のエラー検出１８の結果は、全てのリプライメッセージ２４が成功配信されたことを示す新しいエラー状態となる（図５に示されているとおり）。次の集合コールメッセージ１２「ＣＡＬＬ  ２」には、配信が完全に成功したことを示すエラーメッセージ２０が組み込まれる。  
本発明は以下の態様を含む。
（付記１）
ネットワーク（８）を介してサーバ（６）に接続されたクライアント（４）においてリモートプロシージャコールハンドラを動作させる方法であって、
ａ）複数のコールメッセージ（１６）を含む集合コールメッセージ（１２）を前記サーバ（６）に送信するステップと、
ｂ）前記集合コールメッセージ（１２）に含まれたコールメッセージ（１６）の成功送信またはエラー送信を示すエラーメッセージ（２０）を受信するステップと、を有し、
前記エラーメッセージ（２０）は、少なくとも１つのコールメッセージ（１６）のエラー送信を示し、
当該少なくとも１つのエラー送信されたコールメッセージ（１６）は、
ｃ）前記エラー送信されたコールメッセージと複数の他のコールメッセージ（１６）とを含む他の集合コールメッセージ（１２）を送信するステップ
により再送信される、前記方法。
（付記２）
ステップｂ）は、前記集合コールメッセージ（１２）に含まれたコールメッセージ（１６）専用の少なくとも１つのリプライメッセージ（２４）と前記エラーメッセージ（２０）とを含む集合リプライメッセージ（１４）を受信するステップを有する、付記１記載の方法。
（付記３）
前記集合リプライメッセージ（１４）は、前記集合コールメッセージ（１２）に含まれたコールメッセージ（１６）のうちの成功送信されたものの全てに対するリプライメッセージ（２４）を含む、付記２記載の方法。
（付記４）
ネットワーク（２）を介してクライアント（４）に接続されたサーバ（６）においてリモートプロシージャコールハンドラを動作させる方法であって、
ａ）複数のコールメッセージ（１６）を含む集合コールメッセージ（１２）を前記クライアント（４）から受信するステップと、
ｂ）前記受信された集合コールメッセージ（１６）の中の少なくとも１つのエラー送信されたコールメッセージ（ＥＲＲ）を検出するステップと、
ｃ）前記少なくとも１つのエラー送信されたコールメッセージ（ＥＲＲ）に対して少なくとも１つのエラーメッセージ（２０）を生成するステップと、
ｄ）複数のリプライメッセージ（２４）を含む集合リプライメッセージ（１４）を前記クライアント（４）に送信する準備ができるまで、前記少なくとも１つのエラーメッセージ（２０）を保持するステップと、
ｅ）前記集合リプライメッセージ（１４）の中の前記リプライメッセージ（２４）に前記少なくとも１つのエラーメッセージを連結するステップと、
ｆ）前記少なくとも１つのエラーメッセージ（２０）とその他の複数のリプライメッセージ（２４）とを含む前記集合リプライメッセージ（１４）を送信するステップと、
を有する、前記方法。
（付記５）
ステップｆ）が、ステップａ）で受信された集合コールメッセージ（１２）のコールメッセージ（１６）専用の少なくとも１つのリプライメッセージ（２４）を含む集合リプライメッセージ（１４）を送信するステップを含む、付記４記載の方法。
（付記６）
ステップｅ）の前記リプライメッセージ（２４）は、前記集合コール（１２）に含まれたコールメッセージ（１６）のうちの成功受信されたすべてのものに対するリプライメッセージ（２４）である、付記５記載の方法。
（付記７）
サーバ（６）と、クライアント（４）と、前記サーバ（６）を前記クライアント（４）に接続するネットワーク（８）とを有するコンピュータシステムであって、前記クライアント（４）は付記１、２または３記載の方法を実行するリモートプロシージャコールハンドラを備える、コンピュータシステム（２）。
（付記８）
前記サーバ（６）は付記４または６記載の方法を実施する別のリモートプロシージャコールハンドラを備える、付記７記載のコンピュータシステム（２）。
【符号の説明】
【００４０】
４  クライアント
６  サーバ
８  ネットワーク
１０  ハードウエア
１２  集合コールメッセージ
１４  集合リプライメッセージ
１６  コールメッセージ
１８  エラー検出
２０  エラーメッセージ
２２  ペイロード（ｐａｙｌｏａｄ）
２４  リプライメッセージ
【図１】
0005665675.tif 000002
【図２】
0005665675.tif 000003
【図３】
0005665675.tif 000004
【図４】
0005665675.tif 000005
【図５】
0005665675.tif 000006