JP5224964B2

JP5224964B2 - 受信装置の受信方法及び受信装置並びにプログラム

Info

Publication number: JP5224964B2
Application number: JP2008198624A
Authority: JP
Inventors: 晋吾岩崎
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2008-07-31
Filing date: 2008-07-31
Publication date: 2013-07-03
Anticipated expiration: 2028-07-31
Also published as: WO2010013397A1; US9032040B2; JP2010041117A; US20100250696A1

Description

本発明は、ネットワークからメッセージを受信する受信装置の受信方法及びメッセージを受信する受信装置並びにプログラムに関するものである。

近年、コンピュータネットワークの普及に伴い、様々なサービスがコンピュータネットワークを介して提供されている。現在、とりわけ世界的に注目され、利用されている技術として、Ｗｅｂサービス関連技術が挙げられる。Ｗｅｂサービスとは、ＨＴＴＰに代表される様々な通信プロトコルを利用して、人間の手を介さすにコンピュータ同士がデータを動的に交換する仕組みである。Ｗｅｂサービスでは、クライアント及びサーバ間における通信プロトコル上をＳＯＡＰメッセージが流れることにより、様々なコンピュータ機器や組み込み機器などが情報を受け取ることができる。

Ｗｅｂサービスを利用することで、テキストだけでなく、画像などの大容量のデータを含むＳＯＡＰメッセージを交換することも可能である。ＳＯＡＰメッセージを受け付けるサービスを公開しているサーバに対して、クライアントが大容量のＳＯＡＰメッセージを送信した場合、ＳＯＡＰメッセージの送信が終了するまでには時間がかかる。

そのため、大容量のＳＯＡＰメッセージを送信中に、緊急性の高いＳＯＡＰメッセージをサーバ側に先に受信してもらいたい場合、緊急性の高いＳＯＡＰメッセージを優先して先に送信させる制御の仕組みが必要である。

クライアント及びサーバ間における優先順位を制御する技術としては、ネットワーク上を流れるＩＰパケット毎に優先度を与えることで、ＩＰパケットレベルで優先順位を制御する技術がある。この優先順位制御技術は、クライアント及びサーバ間にＩＰパケットの優先度を解釈し、優先度の高いパケットを送信する中継装置を設置することで実現される（例えば、特許文献１参照）。
特開２００３−２０９５７３号公報

しかしながら、上記優先順位制御技術では、アプリケーションで設定した優先度をＩＰパケットの優先度に変換させる独自の装置やクライアント及びサーバ間にＩＰパケットの優先度を制御する独自の中継装置が必要である。

本来、Ｗｅｂサービスでは、ネットワーク層やトランスポート層には非依存な仕様にもかかわらず、上記優先順位制御技術を使用した場合、必ずＩＰパケットを制御する装置とセットで使用しなければならない。

そのため、ＳＯＡＰメッセージレベルの処理を行う装置を、ネットワークからＳＯＡＰメッセージを受信し、ストリームとして処理可能とする汎用的なサーブレットコンテナ上で動かすなどが困難になり、装置自体の汎用性が低下する。

また、ネットワーク層やトランスポート層に依存しない処理で、緊急性の高いＳＯＡＰメッセージを優先して先に送信させるには、送信中の緊急性の低いＳＯＡＰメッセージを１度キャンセルさせるしかなかった。そのため、再度キャンセルしたＳＯＡＰメッセージを送信するには、最初から送信を開始しなければならず、送信が完了するまで、より時間がかかってしまうという問題があった。

ここでは、ＳＯＡＰを例に説明したが、ＳＯＡＰ以外のメッセージング技術、例えば、ＸＭＬ−ＲＰＣ（Remote Procedure Call）などにおいても、同様である。

本発明は、緊急性の高いメッセージを早く受信でき、緊急性の低いメッセージの送信をキャンセルして採用するよりも、緊急性の低いメッセージの送信時間を短縮させることを目的とする。

本発明は、ネットワークからメッセージを受信する受信装置の受信方法であって、
受信手段が、前記ネットワークから前記メッセージを受信する受信工程と、
読み込み手段が、前記受信工程において受信されたメッセージを読み込む読み込み工程と、
取得手段が、第一のメッセージを受信中に当該第一のメッセージよりも優先度の高い第二のメッセージが送信された場合、当該第二のメッセージの全体サイズと当該第一のメッセージの未受信部分のサイズとを取得する取得工程と、
算出手段が、前記第一のメッセージの未受信部分のサイズに基づいて当該未受信部分を受信するための第一の時間を算出し、前記第二のメッセージの全体サイズに基づいて当該第二のメッセージを受信するための第二の時間を算出する算出工程と、
制御手段が、前記第一の時間および前記第二の時間に基づいて、前記第一のメッセージと並行して前記第二のメッセージを読み込みながら、当該第一のメッセージより先に当該第二のメッセージの読み込みが完了するように、前記読み込み工程における前記第一のメッセージの読み込み速度を制御する制御工程とを有することを特徴とする。

また、本発明は、ネットワークからメッセージを受信する受信装置であって、
前記ネットワークから前記メッセージを受信する受信手段と、
前記受信手段により受信されたメッセージを読み込む読み込み手段と、
第一のメッセージを受信中に当該第一のメッセージよりも優先度の高い第二のメッセージが送信された場合、当該第二のメッセージの全体サイズと当該第一のメッセージの未受信部分のサイズとを取得する取得手段と、
前記第一のメッセージの未受信部分のサイズに基づいて当該未受信部分を受信するための第一の時間を算出し、前記第二のメッセージの全体サイズに基づいて当該第二のメッセージを受信するための第二の時間を算出する算出手段と、
前記第一の時間および前記第二の時間に基づいて、前記第一のメッセージと並行して前記第二のメッセージを読み込みながら、当該第一のメッセージより先に当該第二のメッセージの読み込みが完了するように、前記読み込み手段による前記第一のメッセージの読み込み速度を制御する制御手段とを有することを特徴とする。

本発明によれば、緊急性の高いメッセージを早く受信でき、緊急性の低いメッセージの送信をキャンセルして採用するよりも、緊急性の低いメッセージの送信時間を短縮させることが可能となる。

以下、図面を参照しながら発明を実施するための最良の形態について詳細に説明する。

本実施形態では、送信側と受信側との間でメッセージを送受信する通信システムとしてクライアントサーバシステムを例に説明する。また、クライアントのアプリケーションが送信したストリームのメッセージに対してサーバがそのメッセージに対応するサービスを提供する場合を説明する。

まず、クライアント及びサーバ間において、受信中のメッセージよりも、優先度が高いメッセージが送信された場合に、優先度の高いメッセージを先に受信するように制御する優先順位制御部の概要を説明する。

図１は、本実施形態におけるクライアントサーバシステムの構成を示す図である。図１において、１００及び１０１は優先順位制御部であり、ＳＯＡＰメッセージに設定された優先度に応じて、そのＳＯＡＰメッセージの受信を制御する。１０２はクライアント側の装置（クライアント）であり、１０３はサーバ側の装置（サーバ）である。

尚、ここではＳＯＡＰメッセージを例に説明するが、送受信されるメッセージは、ＳＯＡＰ以外のメッセージ、例えばＸＭＬ−ＲＰＣ（Remote Procedure Call）のメッセージなどでも良い。ＸＭＬ−ＲＰＣでは、リクエストヘッダにＨＴＴＰヘッダ、リクエストのボディにＸＭＬ文書という構成からなるメッセージが送受信される。

優先順位制御部１００、１０１は、クライアントとしての機能と、サーバとしての機能を兼ね備えたものであり、図１では、便宜的に区別して示しているが、同一のものである。優先順位制御部１００、１０１が設置される機器としては、例えばコピー、スキャン、プリントなどの複数の機能を有する複合機であっても良く、またパーソナルコンピュータであっても良い。

クライアント１０２には、優先順位制御部１００を利用してサーバ側のＷｅｂサービスにアクセスするアプリケーション１０４がインストールされている。そして、このアプリケーション１０４からの指示１０５により、優先順位制御部１００が対応するプロトコルバインディングヘッダを含むＳＯＡＰメッセージ１０６を生成し、サーバ１０３側に送信する。送信されたＳＯＡＰメッセージ１０６は、ネットワーク上でストリーム１０７として流れ、サーバ１０３に設置されたサーブレットコンテナ１０８がＳＯＡＰメッセージの先頭のデータから受け取りを開始する。ここで、プロトコルバインディングヘッダは、ＳＯＡＰメッセージを伝送するプロトコル（例えば、ＨＴＴＰ）で処理される情報を含むヘッダである。

次に、サーバ１０３の優先順位制御部１０１がサーブレットコンテナ１０８からプロトコルバインディングヘッダの情報１０９を取得し、またストリーム１１０としてＳＯＡＰメッセージを取得する。サーバ１０３は、プロトコルバインディングヘッダの情報１０９から、受信したメッセージがＳＯＡＰメッセージであることを、アプリケーション層であるＨＴＴＰのレベルにおいて判断できる。そして、ＳＯＡＰメッセージ全体の取得が終了すると、ＳＯＡＰメッセージをサービスロジック１１１へバインディングする。一方、ＳＯＡＰメッセージを受信したサービスロジック１１１は、アプリケーション１０４から指示されたサービスの処理を実行する。

ここで、クライアント側で緊急性の低いＳＯＡＰメッセージの送信をキャンセルすることなく、緊急性の高いＳＯＡＰメッセージを優先的にサーバ側へ送信する優先順位制御部１００、１０１の処理を説明する。

まず、クライアント１０２のアプリケーション１０４が、ＳＯＡＰメッセージ１０６を送信中に、緊急性の高いＳＯＡＰメッセージ１１４をサーバ１０３へ優先的に送信させたい旨を優先順位制御部１００に指示する（１１２）。優先順位制御部１００は、ＳＯＡＰメッセージ１１４のプロトコルバインディングヘッダに、拡張ヘッダとして優先度を設定できるようにし、緊急性が高いことを示すように優先度の値を高く設定する（１１３）。プロトコルバインディングヘッダとしては、例えばＨＴＴＰヘッダが挙げられ、ＨＴＴＰヘッダでは、任意のヘッダを定義して送信することが可能である。

ＨＴＴＰの仕様では、ユーザが任意のヘッダとその値を設定することが許されている。したがって、受信したＨＴＴＰヘッダを解析する側では、解析できないヘッダがあれば、それは無視する。

よって、ヘッダに優先度など独自のヘッダをいれたメッセージを送ったとしても、相手が解釈できなければ、相手は通常のメッセージの処理を行えばよく、処理を続行することが可能である。

逆にプロトコルバインディングヘッダではなく、例えばメッセージのボディ部分にあたるＳＯＡＰ文書内に優先度を入れてしまうと、場合によってはそれを受信した相手側でＳＯＡＰ文書の解析時に不具合を起こす可能性もある。

また、ヘッダ部分に優先度を入れる方が、ヘッダ部分は、情報量が少ないので、受信側の解析処理の負荷がかからず、ボディ部のＳＯＡＰ文書の受信速度のコントロール処理及び優先処理をより早く開始できる。したがって、緊急性の高いメッセージを早く受信できる。

ＳＯＡＰメッセージ１１４は、ネットワーク上でストリーム１１５として流れ、サーバ１０３のサーブレットコンテナ１０８が受信する。次に、優先順位制御部１０１がサーブレットコンテナ１０８からＳＯＡＰメッセージのプロトコルバインディングヘッダの情報１１６を取得する。そして、優先順位制御部１０１は取得したプロトコルバインディングヘッダの優先度の値と、先に受信中のＳＯＡＰメッセージ１０６の優先度の値とを比較し、ＳＯＡＰメッセージ１１４の優先度が高いと判断する。

次に、優先度の高いＳＯＡＰメッセージ１１４を先に取得完了させるためには、優先度の低いＳＯＡＰメッセージ１０６の読み込み速度をどれくらい低減させればよいかを算出する。算出した結果に基づいて、先に受信中のＳＯＡＰメッセージ１０６の読み込み速度を低減させる（１１８）。そして、ストリーム１１９としてＳＯＡＰメッセージ１１４を取得し、ＳＯＡＰメッセージ１１４の取得が全て終了すると、サービスロジック１１１へバインディングする。

このように、ＳＯＡＰメッセージ１０６の送信をキャンセルすることなく、緊急性の高いＳＯＡＰメッセージ１１４を先にサーバ１０３へ送信させることが可能となる。

ここで、プロトコルバインディングヘッダを含むＳＯＡＰメッセージを、図２を用いて具体的に説明する。

図２は、プロトコルバインディングヘッダを含むＳＯＡＰメッセージの一例を示す図である。２０１はプロトコルバインディングヘッダを含むＳＯＡＰメッセージ全体であり、プロトコルバインディングヘッダ部２０２とメッセージのボディ部２０３とで構成されている。本実施形態では、プロトコルとしてＨＴＴＰを例に説明する。

プロトコルバインディングヘッダ部２０２は、ＳＯＡＰメッセージを伝送するプロトコル（例えば、ＨＴＴＰ）で処理される情報を含むヘッダ部２０２を有する。ここで、プロトコルバインディングヘッダ部２０２では、Content-TypeやContent-LengthなどのＨＴＴＰの仕様に基づいたヘッダ情報を記載している。このヘッダ部２０２には、上述の優先順位制御に必要な優先度を示すPriorityヘッダ２０４が拡張ヘッダとして追加されている。ＨＴＴＰヘッダは、任意のヘッダを定義して送信することが可能であるため、このような記述ができる。

サーバ１０３の優先順位制御部１０１は、この拡張ヘッダの値から優先度を判断する。図２では、「Priority:1」として、数値で優先度を示しているが、この記述に限定されるものではない。即ち、クライアント側とサーバ側とで合意した数値ではない他の仕様にも対応可能である。

ＳＯＡＰメッセージが大容量になるパターンとして、バイナリデータがＳＯＡＰメッセージ内に埋め込まれていることが想定される。その例を示したのが２０５であり、２０５では、バイナリデータがＢａｓｅ６４に変換された状態で埋め込まれている。２０５では、途中の情報を省略しているが、本来は、バイナリデータのサイズが大きければ、ＳＯＡＰメッセージ自体も大容量となり、読み込みに時間を要する。

上述したように、ＳＯＡＰメッセージ１０６を送信中に、緊急性の高いＳＯＡＰメッセージ１１４を送信したくなった時点で、まだ途中の部分２０６までしかサーバ１０３側で読み込めてないという状態が発生する。そのため、従来は、ＳＯＡＰメッセージ１０６の送信を一旦キャンセルするしかなかった。

次に、上述のＳＯＡＰメッセージ１０６の送信をキャンセルすることなく緊急性の高いＳＯＡＰメッセージ１１４を送信する際の優先順位制御部１００、１０１の具体的な処理内容を、図３を用いて説明する。

図３は、本実施形態における優先順位制御部の構成の一例を示す図である。図３では、図１と同じものには同じ符号を付し、その説明は省略する。

まず、クライアント側で、アプリケーション１０４が優先順位制御部１００の優先順位設定処理部３０１に送信しようとしているＳＯＡＰメッセージの優先度を通知する。一方、優先順位設定処理部３０１は、通知された優先度をプロトコルバインディングヘッダの拡張ヘッダの値として設定する。そして、拡張ヘッダとして優先度を設定したプロトコルバインディングヘッダを含むＳＯＡＰメッセージ１１４を生成し、メッセージ送信処理部３０２からネットワーク３０３上に流す。

次に、サーバ側では、クライアント側が先に送信していたＳＯＡＰメッセージ１０６をサーブレットコンテナ１０８からメッセージ読み込み処理部３０４が読み込み中であるとする。ここで、ＳＯＡＰメッセージ１１４をサーブレットコンテナ１０８が受信し、プロトコルバインディングヘッダ読み込み処理部３０５が、そのＳＯＡＰメッセージ１１４のプロトコルバインディングヘッダの情報を読み込む。

そして、優先順位解析処理部３０６がプロトコルバインディングヘッダの情報から拡張ヘッダに設定されている優先度の情報を取得し、ＳＯＡＰメッセージ１０６の優先度の情報と比較する。比較した結果、既に読み込み中のＳＯＡＰメッセージ１０６よりも、受信したＳＯＡＰメッセージ１１４の読み込みを優先すると判断する。判断した結果、ストリーム読み込み制御算出処理部３０７が、読み込んだヘッダの情報からＳＯＡＰメッセージ１１４に関する情報を取得する。ここで、ＳＯＡＰメッセージ１１４に関する情報とは、例えばＳＯＡＰメッセージ１１４の全体サイズなどである。

また、優先順位解析処理部３０６から比較結果を受け取り、メッセージ読み込み処理部３０４から、既に読み込み中のＳＯＡＰメッセージ１０６に関する情報を取得する。このＳＯＡＰメッセージ１０６に関する情報とは、例えばＳＯＡＰメッセージ１０６のうち、まだ読み込んでない部分がどのくらい残っているかなどを示す情報である。

そして、ストリーム読み込み制御算出処理部３０７はＳＯＡＰメッセージ１１４を優先して読み込むために、ＳＯＡＰメッセージ１０６の読み込み速度をどの程度低減させれば良いかを解析し、制御情報を算出する。

次に、メッセージ読み込み処理部３０４がストリーム読み込み制御算出処理部３０７から算出された制御情報に応じて、ＳＯＡＰメッセージ１０６の読み込み速度を低減させてＳＯＡＰメッセージ１１４を先に読み込む。その後、ＳＯＡＰメッセージ１１４の読み込みが終了すると、ＳＯＡＰメッセージ１１４の情報をサービスロジック１１１にバインドする。そして、読み込み速度を低減させたＳＯＡＰメッセージ１０６の読み込みが終了すると、ＳＯＡＰメッセージ１１４と同様に、サービスロジック１１１へバインドする。

次に、サーバ１０３の優先順位制御部１０１におけるストリーム読み込み制御算出処理部３０７の具体的な処理内容を、図４及び図５を用いて説明する。

図４は、本実施形態における優先順位制御を開始する時点での具体的な数値を示す図である。また、図５は、ストリーム読み込み制御算出処理部の処理を示すフローチャートである。

図４において、４０１はサーバ１０３の処理能力を示す数値の一例である。ここでは、ストリームからメッセージを読み込む速度として1000［byte/s］が、またストリームからメッセージを１度に読み込むバッファサイズとして1000［byte］が記憶される。４０２は各メッセージの情報であり、メッセージの全体サイズ、受信済みサイズ、優先度の数値が記憶される。

図５に示すステップＳ５０１で、ストリーム読み込み制御算出処理部３０７は優先順位解析処理部３０６が解析した結果を取得する。各メッセージの情報４０２から、優先度の数値はそれぞれ、第一受信メッセージが“１”、第二受信メッセージが“１０”となり、第二受信メッセージの方が優先度が高いという結果になる。

次に、ステップＳ５０２で、プロトコルバインディングヘッダ読み込み処理部３０５が読み込んだプロトコルバインディングヘッダの情報から、第一及び第二受信メッセージの全体サイズ（データ量）を取得する。各メッセージの情報４０２から、全体のサイズはそれぞれ、第一受信メッセージが20000［byte］、第二受信メッセージは、40000［byte］となる。

次に、ステップＳ５０３で、受信中の第一受信メッセージをどれくらい既に受信し終わっているかを示す受信済みサイズ（データ量）を取得する。各メッセージの情報４０２から、第一受信メッセージの受信済みサイズは10000［byte］となる。

次に、ステップＳ５０４で、第一受信メッセージの受信してない残りの部分を受信するために、どのくらいの時間がかかるかを算出する。この例では、受信してない残りの部分（未受信のデータ量）は全体のサイズから受信済みサイズを引いた値、即ち、20000−10000＝10000［byte］となる。また、ストリームからメッセージを読み込む速度は、1000［byte/s］に設定されているので、受信してない残りの部分を読み込むのに必要な時間は、以下の計算により１０秒となる。

10000［byte］÷1000［byte/s］＝10［s］
次に、ステップＳ５０５で、第二受信メッセージを全て受信するための時間を算出する。各メッセージの情報４０２から、ストリームからメッセージを読み込む速度は、1000［byte/s］に設定されているので、以下の計算により４０秒となる。

40000［byte］÷1000［byte/s］＝40［s］
そして、ステップＳ５０６で、優先順位の比較結果と、計算結果とから、メッセージをストリームから１度に読み込む間隔毎に設定する読み込み待機時間を算出する。例えば、取得した優先順位の比較結果から、まず第一受信メッセージよりも第二受信メッセージの方を優先的に受信しなければならないと判断する。そして、第二受信メッセージの方を第一受信メッセージより先に受信し終わるためには、第一受信メッセージの読み込み速度をどのくらい遅くすればよいかを解析する。

即ち、第一受信メッセージのストリームから１度に読み込む間隔毎に設定する読み込み待機時間をどの程度にすれば良いかを解析する。この例では、ストリームからメッセージを１度に読み込むバッファサイズは1000［byte］である。そのため、第一受信メッセージの受信してないサイズである10000［byte］を読み込むためには、以下の計算により10回ループする必要がある。

10000［byte］÷1000［byte］＝10［回］
以上の結果をまとめると、第一受信メッセージの未受信部分を読み込む時間が１０秒、読み込むために処理をループさせる回数は１０回、第二受信メッセージを受信し終わる時間が４０秒となる。これらの結果から、最終的な算出値である、読み込み待機時間（waittime）は以下の計算式により、３秒と算出される。

10［s］＋waittime×10［回］＞40［s］
waittime＞3［s］
よって、１回のループ毎に、読み込み待機時間（waittime）として３秒より大きい値を設定すれば、第一受信メッセージの未受信部分よりも先に第二受信メッセージの読み込みを終了させることができる。

以上の処理内容を踏まえ、第一受信メッセージをＳＯＡＰメッセージ１０６とし、第二受信メッセージをＳＯＡＰメッセージ１１４とする。

尚、本実施形態では、ストリームから第一のメッセージを読み込む間隔を読み込み待機時間だけ長くすることで第一のメッセージの読み込み速度を低減させる方法を説明したが、本発明はこの方法に限定されるものではない。

例えば、ストリームから第一のメッセージを読み込む１回の読み込み量（バイト数）を少なくして第一のメッセージの読み込み速度を低減させても良い。この方法によっても、上述した方法と同様に、第二のメッセージを優先的に受信することができる。

本実施形態によれば、ＨＴＴＰなどのアプリケーション層で優先順位制御を行うことで、ネットワーク層やトランスポート層に依存することなく装置自体の汎用性を高めることができる。

また、送信側で第一のメッセージの送信をキャンセルすることなく、受信側で緊急性の高い第二のメッセージを優先的に受信することが可能となる。

［他の実施形態］
次に、本実施形態におけるクライアント１０２及びサーバ１０３として、情報処理装置（コンピュータ）を使用することも可能である。

図６は、クライアント又はサーバとして機能する情報処理装置の構成の一例を示す図である。上述した実施形態の機能を実現するソフトウェアを実行する情報処理装置のハードウェア構成の一例を示している。

情報処理装置は、ハードウェア構成として入力装置６０１と、表示装置６０２と、記憶媒体ドライブ装置６０３と、ＲＯＭ６０５と、ＲＡＭ６０６と、ＣＰＵ又はＭＰＵ６０７と、インターフェース装置６０８と、ＨＤ（ハードディスク）６０９とを含む。入力装置６０１は、情報処理装置の操作者（オペレータ）が操作するキーボード及びマウスなどで構成され、情報処理装置に各種操作情報などを入力するのに用いられる。表示装置６０２は、情報処理装置の操作者が利用するディスプレイなどで構成され、各種情報（又は画面）などを表示するのに用いられる。

インターフェース装置６０８は、情報処理装置をネットワークなどに接続するインターフェースである。上述した処理などに係るプログラムは、例えばＣＤ−ＲＯＭなどの記憶媒体６０４によって情報処理装置に提供されるか、ネットワークなどを通じてダウンロードされる。記憶媒体６０４は、記憶媒体ドライブ装置６０３にセットされ、プログラムが記憶媒体６０４から記憶媒体ドライブ装置６０３を介してＨＤ６０９にインストールされる。

ＲＯＭ６０５は情報処理装置の電源投入時に最初に読み込まれるプログラムなどを格納する。ＲＡＭ６０６は、情報処理装置のメインメモリである。ＣＰＵ６０７は、ＨＤ６０９よりプログラムを読み出して、ＲＡＭ６０６に格納し、プログラムを実行することで、前述の処理内容を実現したりする。ＨＤ６０９は、プログラム以外に、例えばＷＥＢサービスフロー記述文書、ＷＥＢサービスインターフェース記述文書などを格納する。

このプログラムコードを供給するための記録媒体として、例えばフレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。

また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、次の場合も含まれることは言うまでもない。即ち、プログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理により前述した実施形態の機能が実現される場合である。

更に、コンピュータ読み取り可能な記録媒体から読出されたプログラムがコンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理により、前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

本実施形態におけるクライアントサーバシステムの構成を示す図である。プロトコルバインディングヘッダを含むＳＯＡＰメッセージの一例を示す図である。本実施形態における優先順位制御部の構成の一例を示す図である。本実施形態における優先順位制御を開始する時点での具体的な数値を示す図である。ストリーム読み込み制御算出処理部の処理を示すフローチャートである。クライアント又はサーバとして機能する情報処理装置の構成の一例を示す図である。

符号の説明

１００優先順位制御部
１０１優先順位制御部
１０２クライアント
１０３サーバ
１０４アプリケーション
１０６ＳＯＡＰメッセージ
１０８サーブレットコンテナ
１１１サービスロジック
１１４ＳＯＡＰメッセージ

Claims

ネットワークからメッセージを受信する受信装置の受信方法であって、
受信手段が、前記ネットワークから前記メッセージを受信する受信工程と、
読み込み手段が、前記受信工程において受信されたメッセージを読み込む読み込み工程と、
取得手段が、第一のメッセージを受信中に当該第一のメッセージよりも優先度の高い第二のメッセージが送信された場合、当該第二のメッセージの全体サイズと当該第一のメッセージの未受信部分のサイズとを取得する取得工程と、
算出手段が、前記第一のメッセージの未受信部分のサイズに基づいて当該未受信部分を受信するための第一の時間を算出し、前記第二のメッセージの全体サイズに基づいて当該第二のメッセージを受信するための第二の時間を算出する算出工程と、
制御手段が、前記第一の時間および前記第二の時間に基づいて、前記第一のメッセージと並行して前記第二のメッセージを読み込みながら、当該第一のメッセージより先に当該第二のメッセージの読み込みが完了するように、前記読み込み工程における前記第一のメッセージの読み込み速度を制御する制御工程とを有することを特徴とする受信装置の受信方法。
前記制御工程では、前記第一の時間および前記第二の時間に基づいて、前記第一のメッセージと並行して前記第二のメッセージを読み込みながら、当該第一のメッセージより先に当該第二のメッセージの読み込みが完了するように、当該第一のメッセージの読み込み間隔における待機時間を制御することを特徴とする請求項１に記載の受信装置の受信方法。
前記制御工程では、前記第一の時間および前記第二の時間に基づいて、前記第一のメッセージと並行して前記第二のメッセージを読み込みながら、当該第一のメッセージより先に当該第二のメッセージの受信が完了するように、当該第一のメッセージの１回の読み込み量を制御することを特徴とする請求項１に記載の受信装置の受信方法。
前記優先度は、前記メッセージを伝送するプロトコルで処理されるヘッダに含まれることを特徴とする請求項１に記載の受信装置の受信方法。
ネットワークからメッセージを受信する受信装置であって、
前記ネットワークから前記メッセージを受信する受信手段と、
前記受信手段により受信されたメッセージを読み込む読み込み手段と、
第一のメッセージを受信中に当該第一のメッセージよりも優先度の高い第二のメッセージが送信された場合、当該第二のメッセージの全体サイズと当該第一のメッセージの未受信部分のサイズとを取得する取得手段と、
前記第一のメッセージの未受信部分のサイズに基づいて当該未受信部分を受信するための第一の時間を算出し、前記第二のメッセージの全体サイズに基づいて当該第二のメッセージを受信するための第二の時間を算出する算出手段と、
前記第一の時間および前記第二の時間に基づいて、前記第一のメッセージと並行して前記第二のメッセージを読み込みながら、当該第一のメッセージより先に当該第二のメッセージの読み込みが完了するように、前記読み込み手段による前記第一のメッセージの読み込み速度を制御する制御手段とを有することを特徴とする受信装置。
前記制御手段は、前記第一の時間および前記第二の時間に基づいて、前記第一のメッセージと並行して前記第二のメッセージを読み込みながら、当該第一のメッセージより先に当該第二のメッセージの読み込みが完了するように、当該第一のメッセージの読み込み間隔における待機時間を制御することを特徴とする請求項５に記載の受信装置。
前記制御手段は、前記第一の時間および前記第二の時間に基づいて、前記第一のメッセージと並行して前記第二のメッセージを読み込みながら、当該第一のメッセージより先に当該第二のメッセージの受信が完了するように、当該第一のメッセージの１回の読み込み量を制御することを特徴とする請求項５に記載の受信装置。
前記優先度は、前記メッセージを伝送するプロトコルで処理されるヘッダに含まれることを特徴とする請求項５に記載の受信装置。
ネットワークからメッセージを受信する受信装置の受信手順をコンピュータに実行させるためのプログラムであって、
前記受信手段により受信されたメッセージを読み込む読み込み手順と、
第一のメッセージを受信中に当該第一のメッセージよりも優先度の高い第二のメッセージが送信された場合、当該第二のメッセージの全体サイズと当該第一のメッセージの未受信部分のサイズとを取得する取得手順と、
前記第一のメッセージの未受信部分のサイズに基づいて当該未受信部分を受信するための第一の時間を算出し、前記第二のメッセージの全体サイズに基づいて当該第二のメッセージを受信するための第二の時間を算出する算出手順と、
前記第一の時間および前記第二の時間に基づいて、前記第一のメッセージと並行して前記第二のメッセージを読み込みながら、当該第一のメッセージより先に当該第二のメッセージの読み込みが完了するように、前記読み込み手順における前記第一のメッセージの読み込み速度を制御する制御手順とをコンピュータに実行させることを特徴とするプログラム。
前記制御手順では、前記第一の時間および前記第二の時間に基づいて、前記第一のメッセージと並行して前記第二のメッセージを読み込みながら、当該第一のメッセージより先に当該第二のメッセージの読み込みが完了するように、当該第一のメッセージの読み込み間隔における待機時間を制御することを特徴とする請求項９に記載のプログラム。
前記制御手順では、前記第一の時間および前記第二の時間に基づいて、前記第一のメッセージと並行して前記第二のメッセージを読み込みながら、当該第一のメッセージより先に当該第二のメッセージの受信が完了するように、当該第一のメッセージの１回の読み込み量を制御することを特徴とする請求項９に記載のプログラム。