(57)【要約】【課題】処理を行う対象となる相手の数を制限せず、処理効率の低下を軽減したデータ処理装置、データ処理サーバ、データ処理システムおよびデータ処理プログラムを提供する。【解決手段】サーバプログラム部３０１は１つのコネクションに専有させてデータを受信させるブロック受信制御部３３４と、事象待ち制御部３３２の多重受信待ちを利用してそれ以外のコネクションからのデータを受信する非ブロック受信制御部３３３を備え、各コネクションそれぞれの通信頻度を計算することでどちらに割り当てるかを動的に決めるようになっている。これにより接続の可能なコネクション数に対して自由度を維持した通信の多重処理だけでなく、高い通信性能も実現することができる。【選択図】図２
2006277675.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワークを介して１処理単位ずつのデータとしての単位データを順次受信する単位データ受信手段と、
この単位データ受信手段が単位データを受信するたびにこれらの送信元を判別する送信元判別手段と、
それぞれ所望の時間にわたって１つずつの送信元が専有する形で、同一送信元から間欠的にあるいは連続して送られてくる任意数の前記単位データの処理を行う１または複数の第１のデータ処理手段と、
前記単位データを１単位として各送信元の前記単位データを時分割処理する１または複数の第２のデータ処理手段と、
前記データ受信手段が前記単位データを受信するたびに前記送信元判別手段の判別結果に応じてそれぞれの送信元から送られてきた単位データを第１のデータ処理手段あるいは第２のデータ処理手段に振り分けるデータ振分手段
とを具備することを特徴とするデータ処理装置。
【請求項２】
通信ネットワークを介して１処理単位ずつのデータとしての単位データを順次受信する単位データ受信手段と、
この単位データ受信手段が受信した単位データの送信元を判別する送信元判別手段と、
前記単位データ受信手段が受信した単位データを一時格納するデータ格納手段と、
それぞれ所望の時間にわたって１つずつの送信元が専有する形で、同一送信元から間欠的にあるいは連続して送られてくる任意数の前記単位データの処理を行う１または複数の第１のデータ処理手段と、
前記単位データを１単位として各送信元が時分割で専有する形で、前記単位データを処理する１または複数の第２のデータ処理手段と、
前記データ受信手段が前記単位データを受信するたびに前記送信元判別手段の判別結果に応じて前記データ格納手段から単位データを前記第１のデータ処理手段に受け渡す第１のデータ受け渡し手段と、
この第１のデータ受け渡し手段により前記第１のデータ処理手段に受け渡されず前記データ格納手段に格納されている単位データの有無を判別するデータ有無判別手段と、
このデータ有無判別手段の判別結果がデータ有りのとき、前記データ格納手段からこの単位データを前記第２のデータ処理手段に受け渡す第２のデータ受け渡し手段
とを具備することを特徴とするデータ処理装置。
【請求項３】
前記第１のデータ処理手段および前記第２のデータ処理手段がそれぞれの処理を終了した単位データを受け取ってさらに別の処理を行う１または複数の第３のデータ処理手段を更に備えることを特徴とする請求項１あるいは請求項２のいずれかに記載のデータ処理装置。
【請求項４】
前記送信元判別手段は、送信元ごとにこれらの送信する前記単位データが第１のデータ処理手段あるいは第２のデータ処理手段に振り分けられるかを示す振分先テーブルと、前記単位データ受信手段が前記単位データを受信するたびにこの振分先テーブルを検索して振分先を判別する検索手段とを具備することを特徴とする請求項１記載のデータ処理装置。
【請求項５】
前記第１のデータ受け渡し手段は１または複数の前記第１のデータ処理手段のそれぞれに専有させる送信元を示す専有送信元テーブルを備え、前記データ受信手段が前記単位データを受信するたびに前記送信元判別手段の判別結果が示す送信元が、この専有送信元テーブルに含まれるかを検索し、含まれたときこの送信元に前記単位データを受け渡すことを特徴とする請求項２記載のデータ処理装置。
【請求項６】
前記送信元ごとに優先順位が付されており、前記データ振分手段は、前記第１のデータ処理手段および前記第２のデータ処理手段のそれぞれの使用効率に応じてそれぞれの送信元の振分先を調整する振分先調整手段を具備することを特徴とする請求項１記載のデータ処理装置。
【請求項７】
前記送信元ごとに優先順位が付されており、前記第１のデータ受け渡し手段は、前記第１のデータ処理手段および前記第２のデータ処理手段のそれぞれの使用効率に応じて前記第１のデータ処理手段に受け渡す送信元を調整する受け渡し調整手段を具備することを特徴とする請求項２記載のデータ処理装置。
【請求項８】
前記送信元ごとに前記単位データの受信頻度を監視する受信頻度監視手段を備え、前記データ振分手段は、送信する単位データの受信頻度の高い送信元から順に前記第１のデータ処理手段に割り当てることを特徴とする請求項１記載のデータ処理装置。
【請求項９】
前記送信元ごとに前記単位データの受信頻度を監視する受信頻度監視手段を備え、前記第１のデータ受け渡し手段は、送信する単位データの受信頻度の高い送信元から順に前記第１のデータ処理手段に割り当てて単位データを受け渡すことを特徴とする請求項２記載のデータ処理装置。
【請求項１０】
前記単位データが第１のデータ処理手段で処理されることを指定する送信元とこの指定を行わない送信元が存在し、前記データ振分手段は前記第１のデータ処理手段で処理されることを指定する送信元の単位データを第１のデータ処理手段に割り当て、それ以外の送信元の単位データを第２のデータ処理手段に割り当てることを特徴とする請求項１記載のデータ処理装置。
【請求項１１】
前記単位データが第１のデータ処理手段で処理されることを指定する送信元とこの指定を行わない送信元が存在し、前記第１のデータ受け渡し手段は前記第１のデータ処理手段で処理されることを指定する送信元の単位データを第１のデータ処理手段に受け渡し、前記第２のデータ受け渡し手段はそれ以外の送信元の単位データを第２のデータ処理手段に受け渡すことを特徴とする請求項２記載のデータ処理装置。
【請求項１２】
通信ネットワークを介してクライアントから１処理単位ずつのデータとしての単位データを順次受信する単位データ受信手段と、
この単位データ受信手段が単位データを受信するたびにこれらの送信元のクライアントを判別するクライアント判別手段と、
それぞれ所望の時間にわたって１つずつのクライアントが専有する形で、同一クライアントから間欠的にあるいは連続して送られてくる任意数の前記単位データの処理を行う１または複数の第１のデータ処理手段と、
前記単位データを１単位として各クライアントの前記単位データを時分割処理する１または複数の第２のデータ処理手段と、
前記データ受信手段が前記単位データを受信するたびに前記クライアント判別手段の判別結果に応じてそれぞれのクライアントから送られてきた単位データを第１のデータ処理手段あるいは第２のデータ処理手段に振り分けるデータ振分手段
とを具備することを特徴とするデータ処理サーバ。
【請求項１３】
通信ネットワークを介してクライアントから１処理単位ずつのデータとしての単位データを順次受信する単位データ受信手段と、
この単位データ受信手段が受信した単位データのクライアントを判別する送信元判別手段と、
前記単位データ受信手段が受信した単位データを一時格納するデータ格納手段と、
それぞれ所望の時間にわたって１つずつのクライアントが専有する形で、同一クライアントから間欠的にあるいは連続して送られてくる任意数の前記単位データの処理を行う１または複数の第１のデータ処理手段と、
前記単位データを１単位として各クライアントが時分割で専有する形で、前記単位データを処理する１または複数の第２のデータ処理手段と、
前記データ受信手段が前記単位データを受信するたびに前記クライアント判別手段の判別結果に応じて前記データ格納手段から単位データを前記第１のデータ処理手段に受け渡す第１のデータ受け渡し手段と、
この第１のデータ受け渡し手段により前記第１のデータ処理手段に受け渡されず前記データ格納手段に格納されている単位データの有無を判別するデータ有無判別手段と、
このデータ有無判別手段の判別結果がデータ有りのとき、前記データ格納手段からこの単位データを前記第２のデータ処理手段に受け渡す第２のデータ受け渡し手段
とを具備することを特徴とするデータ処理サーバ。
【請求項１４】
通信ネットワークと、
請求項１記載のデータ処理装置と、
前記通信ネットワークを介してこのデータ処理装置にデータを送信するデータ送信手段を備えた１または複数のデータ処理要求装置
とを具備することを特徴とするデータ処理システム。
【請求項１５】
通信ネットワークと、
請求項２記載のデータ処理装置と、
前記通信ネットワークを介してこのデータ処理装置にデータを送信するデータ送信手段を備えた１または複数のデータ処理要求装置
とを具備することを特徴とするデータ処理システム。
【請求項１６】
コンピュータに、
通信ネットワークを介して１処理単位ずつのデータとしての単位データを順次受信する単位データ受信処理と、
この単位データ受信処理で単位データを受信するたびにこれらの送信元を判別する送信元判別処理と、
それぞれ所望の時間にわたって１つずつの送信元が専有する形で、同一送信元から間欠的にあるいは連続して送られてくる任意数の前記単位データの処理を行う第１のデータ処理と、
前記単位データを１単位として各送信元の前記単位データを時分割処理する１または複数の第２のデータ処理と、
前記データ受信処理で前記単位データを受信するたびに前記送信元判別処理の判別結果に応じてそれぞれの送信元から送られてきた単位データを第１のデータ処理あるいは第２のデータ処理に振り分けるデータ振分処理
とを実行させることを特徴とするデータ処理プログラム。
【請求項１７】
通信ネットワークを介して１処理単位ずつのデータとしての単位データを順次受信する単位データ受信処理と、
この単位データ受信処理で受信した単位データの送信元を判別する送信元判別処理と、
前記単位データ受信処理で受信した単位データを一時格納するデータ格納処理と、
それぞれ所望の時間にわたって１つずつの送信元が専有する形で、同一送信元から間欠的にあるいは連続して送られてくる任意数の前記単位データの処理を行う１または複数の第１のデータ処理と、
前記単位データを１単位として各送信元が時分割で専有する形で、前記単位データを処理する１または複数の第２のデータ処理と、
前記データ受信処理で前記単位データを受信するたびに前記送信元判別処理の判別結果に応じて前記データ格納処理で格納した単位データを前記第１のデータ処理に受け渡す第１のデータ受け渡し処理と、
この第１のデータ受け渡し処理により前記第１のデータ処理に受け渡されず前記データ格納処理で格納されたままの単位データの有無を判別するデータ有無判別処理と、
このデータ有無判別処理の判別結果がデータ有りのとき、前記データ格納処理で格納した単位データを前記第２のデータ処理に受け渡す第２のデータ受け渡し処理
とを実行させることを特徴とするデータ処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の相手から受け取ったデータに対する処理を行うデータ処理装置およびデータ処理サーバとこれらの相手とデータ処理装置あるいはデータ処理サーバからなるデータ処理システムおよびそのデータ処理プログラムに関する。
【背景技術】
【０００２】
近年、ネットワーク機器とネットワーク接続サービスの高速化および低価格化が進み、ネットワークを用いた通信が多く行われている。これに伴い、ネットワークサーバの処理能力向上が求められている。ネットワークサーバには、たとえば、様々なアプリケーションをネットワークを介して提供するアプリケーションサーバや、金融機関で入出金といったひとまとまりの処理としてのトランザクション処理を行うトランザクションサーバやデータベースサーバなどがある。これらは、ネットワークに接続するクライアントから要求を受け、それに対する処理を行うことでサービスを提供している。このようなネットワークサーバでは、演算処理能力の向上はもちろんのこと、同時に起こり得る複数のクライアントからの処理要求に関するデータ受信およびその処理結果としてのデータ送信といった通信処理を効率よく行うことも重要である。
【０００３】
そこで、複数のタスクを生成することにより通信の多重処理を実現する手法が提案されている（たとえば特許文献１参照）。この提案のコンピュータはタスク生成部を備え、たとえば、他のコンピュータにデータの送信を行うときには新規にタスクを生成して、データの送信処理をそのタスクに任せるようになっている。したがって、このコンピュータでは、このデータの送信処理が完了する前でも、別の異なる処理を並列して行うことができる。つまり、ネットワークサーバにおいては複数のタスクを生成することにより、複数のクライアントとの通信処理を同時に行う、通信の多重処理が実現される。これにより、より多くの処理要求を受け、要求に応じたサービスを提供することが可能になる。
【０００４】
このような複数のタスクにより異なる複数の処理を行うマルチタスク処理は、ＣＰＵ（Central Processing Unit）の処理を時分割して、複数の処理対象に順番に割り当てることで、それぞれが同時に行われているように見せるものである。この時分割される一連の処理が、タスクあるいはプロセスと呼ばれている。マルチタスクで動作するＯＳ（Operating System）は、実際にはこのタスクあるいはプロセスをさらに同時に処理可能な一連の処理として、入力、計算、ファイル操作等の各処理に分割されたスレッドという単位で切り替えて、マルチスレッドとして動作を行っている。このタスクやプロセスおよびスレッドは、コンテキスト（context）と呼ばれている。各コンテキストには、スタック、レジスタ、実行カウンタ等の処理の実行状態を表わすものがそれぞれ固有に割り当てられている。これにより、他のコンテキストで進行する処理からの影響を受けず、独立して処理を行うことができる。また、コンテキストを増やすことによって、複数のＣＰＵを持つコンピュータにおいて同時に処理できる対象を増やし、より多くのＣＰＵにより多くの処理を割り当てることができる。
【０００５】
図１０は、ネットワークサーバが複数のコネクションを１つのコンテキストで制御する様子を表わしたものである。複数のコンテキストによる処理を説明する前に、まず、１つのコンテキストによる処理について説明を行う。第１〜第３のコネクション１０１1〜１０１3は、ネットワークサーバ１０２にそれぞれデータ１０３1〜１０３3を送信し、それに対する処理結果１０４1〜１０４3を処理待ち１０５1〜１０５3の後に受け取るようになっている。第１のコネクション１０１1について詳細に説明する。第１のコネクション１０１1は、ネットワークサーバ１０２にデータ１０３1を送信し、それに対する処理結果１０４1を処理待ち１０５1の後に受け取るようになっている。データ１０３1は一旦、バッファメモリ（バッファ）１０６にバッファリング１０７1されて、処理手段１０８のコンテキスト（Ｃ）１０９に受け渡される。コンテキスト１０９ではデータ処理１１１1が行われ、その処理結果１０４1が要求元の第１のコネクション１０１1に送り返されるようになっている。コンテキスト１０９では、第１のコネクション１０１1からデータ１０３1が到着していなければ、データ待ち１１０1を行い、到着後にデータ処理１１１1が完了するまで、他のコネクションに対する処理を行わない。このように１つのコネクションに対するデータ待ちとデータ処理からなる処理に専有された状態をブロックといい、このような受信方式をブロック受信方式という。つまり、第１のコネクションによるブロック１１２1は、この図に示すようにデータ待ち１１０1とデータ処理１１１1を併せたものになる。ここでは、受信方式に着目するため、処理結果１０４1の送信については説明を簡単にするためにＯＳによる処理を介さないように説明している。同様に説明を簡単にするために、バッファメモリ１０６の処理を１つの流れで説明しているが、実際にはマルチタスクのＯＳにより複数のバッファリングを同時に行うことができるようになっている。第２および第３のコネクション１０１2、１０１3についても、同様に処理が行われる。処理手段１０８はプログラムにより構成されるのが通常で、このようなネットワークサーバ１０２においてはサーバプログラムとよばれる。
【０００６】
ここでは、サーバプログラムを実行するコンテキスト１０９は１つで、第１〜第３のコネクション１０１1〜１０１3に対する処理がこの順番で行われるよう予め決められている。したがって、この図に示すように、たとえば第３のコネクション１０１3からのデータ１０３3がバッファメモリ１０６によりバッファリング１０７3され、すぐに処理を始められる状態になっても、コンテキスト１０９では予め決められた順番どおり第１のコネクション１０１1に対する処理の次は、第２のコネクション１０１2に対する処理を行うようになっている。このため、第２のコネクション１０１2からのデータ１０３2の到着が遅れると、第３のコネクション１０１3が処理結果１０４3を得られる時間も遅れてしまう。つまり、他のコネクションの影響を受け、各コネクションが処理結果を得るまでの処理待ちの時間に不平等が生じてしまう。そこで、ブロック受信方式で複数のコネクションを同時に扱うネットワークサーバは、第１の提案のように複数のコンテキストを生成することで実現される。
【０００７】
図１１は、ネットワークサーバが複数のコネクションを複数のコンテキストで制御する様子を表わしたものである。この図１１で図１０と同一の部分には同一の符号を付しており、これらの説明を適宜省略する。ネットワークサーバ１０２Ａの処理手段１０８Ａは、第１〜第３のコンテキスト１０９1〜１０９3で同時に、第１〜第３のコネクション１０１1〜１０１3に対するそれぞれのデータ処理１１１1〜１１１3を別々に行わせるようになっている。したがって、処理待ち時間は、それぞれ対応するコネクションに起因するものであって、他のコネクションからの影響を受けない。ブロック受信方式では複数のコンテキストを設けることにより通信の多重処理を実現することができる。
【０００８】
このように、ブロック受信方式では複数のコンテキストを設けることにより通信の多重処理が実現され、他のコネクションに影響しない処理を可能としている。しかし、ブロック受信方式で通信の多重処理を行うには、扱う接続先の数に応じた複数のコンテキストが必要とされる。各コンテキストはそれぞれ他のコンテキストの処理に影響を受けず、独自に処理を行っている。このためコンテキストごとに他のプログラムの進行状態により書き換えられることのない専用のメモリ領域を必要とする。したがって、リソースの面から扱うことのできるコネクションの数が限られてしまう。
【０００９】
そこで、ネットワークサーバでは非ブロック受信方式を用いるのが通常である。この方式では、各接続先から処理可能な受信データがバッファメモリにバッファリング済みかどうかを走査する手段と組み合わせて通信の多重処理を可能にしている。この手段はセレクタと呼ばれＯＳにより提供されている。セレクタはネットワークサーバのサーバプログラムにより呼び出され、走査の結果が１つ以上の事象を含むまで、繰り返し走査を行い、事象が発生するとその結果をサーバプログラムに返すようになっている。
【００１０】
図１２は、ネットワークサーバが複数のコネクションを１つのコンテキストとセレクタにより非ブロック受信方式で制御する様子を表わしたものである。この図１２で図１０と同一の部分には同一の符号を付しており、これらの説明を適宜省略する。ネットワークサーバ１０２Ｂでは、セレクタ１２０がバッファメモリ１０６に第１〜第３のコネクション１０１1〜１０１3からのデータ１０３1〜１０３3のうちバッファリング済みのものがあるかを走査するようになっている。この図に示すように、処理手段１０８Ｂでは、コンテキスト１０９が新たな処理を行うことができる状態にあるとセレクタ１２０による走査１２１1〜１２１6が行われるようになっている。セレクタ１２０の最初の走査１２１1によっては、データが見つからない。そのため、引き続き走査１２１2が行われる。この段階で第１のコネクション１０１1のデータ１０３1が見つかる。処理手段１０８Ｂは、セレクタ１２０のこの走査結果に基づき、コンテキスト１０９にデータ１０３1の受信およびそのデータ処理１１１1を行わせる。その後、処理結果１０４1が第１のコネクション１０１1に送り返される。次に行われる走査１２１3によって、第３のコネクション１０１3のデータ１０３3が見つかり、同様に処理される。セレクタ１２０は再びデータが見つかるまで走査１２14〜１２１6を繰り返す。走査１２１6によって第２のコネクション１０１2のデータ１０３2が見つかると、再び同様に処理が行われる。バッファメモリ１０６に複数のデータがバッファリングされているとき、セレクタ１２０はその中で一番早くバッファリングされたものだけを見つけるようにしてもよいし、すべてを見つけるようにしてもよい。後者の場合、処理手段１０８Ｂがコンテキスト１０９の処理状態をみて、１つ処理が完了するたびに、次の処理を行わせるようにする。ブロック受信は受信データが到着するまで待つのに対して、このように非ブロック受信方式は、セレクタを使用することで特定のコネクションで受信の待ち合わせをせずに、すぐに処理可能なデータを得ることができるため、一定の短い時間で処理を行うことが可能である。
【特許文献１】特開２００３−５８３８４号公報（段落００２３、図１）
【発明の開示】
【発明が解決しようとする課題】
【００１１】
ところで、非ブロック受信方式では、複数のコネクションを制御することができるものの、セレクタが走査するコネクションの数がたとえば数千や数万というように膨大な数になると、走査によるオーバーヘッドが問題になってくる。つまり、コネクションから見ると、データを送信しても、それが処理手段に受け渡され処理が行われるのは、走査によりデータが見つけられてからになるため、走査時間のタイムラグができる。したがって、データがＯＳによりバッファメモリにバッファリングされるとすぐに処理が行われるブロック方式に比べて、処理結果が得られるまでの時間が増すことになってしまう。これは無通信あるいは通信頻度の低いコネクションではあまり問題とならないが、送信するデータ数に伴って処理時間が増すため、通信頻度が高いコネクションでは処理効率の点で問題が大きい。また、走査でバッファメモリにデータが見つかるとその結果を報告する処理が行われるため、頻繁にデータを送信してくるコネクションが１つでも存在すると、走査結果の報告もその都度行われなければならない。したがって、通信頻度の低いコネクションだけに対して、データが見つかるまで走査を繰り返す場合に比べて、負担が大きくなってしまう。
【００１２】
以上、ネットワークサーバの通信制御を例に挙げて説明した。これ以外にも、複数の相手に対する処理を行うような装置で、同時に起こり得るこれらの相手からの処理要求およびそれに関するデータを効率的に受け取って処理する必要がある例は多く存在している。いずれの例の場合も、相手の数を制限しないために非ブロック受信方式を用いると、処理を頻繁に要求する相手に対しては処理効率について同様の問題があった。
【００１３】
そこで、本発明の目的は、処理を行う対象となる相手の数を制限せず、処理効率の低下を軽減したデータ処理装置、データ処理サーバ、データ処理システムおよびデータ処理方法を提供することにある。
【課題を解決するための手段】
【００１４】
本発明では、（イ）通信ネットワークを介して１処理単位ずつのデータとしての単位データを順次受信する単位データ受信手段と、（ロ）この単位データ受信手段が単位データを受信するたびにこれらの送信元を判別する送信元判別手段と、（ハ）それぞれ所望の時間にわたって１つずつの送信元が専有する形で、同一送信元から間欠的にあるいは連続して送られてくる任意数の単位データの処理を行う１または複数の第１のデータ処理手段と、（ニ）単位データを１単位として各送信元の単位データを時分割処理する１または複数の第２のデータ処理手段と、（ホ）データ受信手段が単位データを受信するたびに送信元判別手段の判別結果に応じてそれぞれの送信元から送られてきた単位データを第１のデータ処理手段あるいは第２のデータ処理手段に振り分けるデータ振分手段とをデータ処理装置に具備させる。
【００１５】
すなわち本発明では、データ処理装置は通信ネットワークを介して１処理単位ずつのデータとしての単位データを受信し、その送信元を判別するようにしている。そして、その送信元に応じて、それぞれ所望の時間にわたって１つずつの送信元に専有させて単位データの処理を行う第１のデータ処理手段と、各送信元の単位データを時分割処理する第２のデータ処理手段のどちらかに振り分けて処理させるようにしている。これにより、このデータ処理装置では複数の送信元からデータを受信して処理することができるだけでなく、データを頻繁に送信してくる送信元には、その送信元が専有できる処理手段を割り当て、効率よく処理することも可能となっている。
【００１６】
また本発明では、（イ）通信ネットワークを介して１処理単位ずつのデータとしての単位データを順次受信する単位データ受信手段と、（ロ）この単位データ受信手段が受信した単位データの送信元を判別する送信元判別手段と、（ハ）単位データ受信手段が受信した単位データを一時格納するデータ格納手段と、（ニ）それぞれ所望の時間にわたって１つずつの送信元が専有する形で、同一送信元から間欠的にあるいは連続して送られてくる任意数の単位データの処理を行う１または複数の第１のデータ処理手段と、（ホ）単位データを１単位として各送信元が時分割で専有する形で、単位データを処理する１または複数の第２のデータ処理手段と、（ヘ）データ受信手段が単位データを受信するたびに送信元判別手段の判別結果に応じてデータ格納手段から単位データを第１のデータ処理手段に受け渡す第１のデータ受け渡し手段と、（ト）この第１のデータ受け渡し手段により第１のデータ処理手段に受け渡されずデータ格納手段に格納されている単位データの有無を判別するデータ有無判別手段と、（チ）このデータ有無判別手段の判別結果がデータ有りのとき、データ格納手段からこの単位データを第２のデータ処理手段に受け渡す第２のデータ受け渡し手段とをデータ処理装置に具備させる。
【００１７】
すなわち本発明では、データ処理装置は通信ネットワークを介して１処理単位ずつのデータとしての単位データを受信して、これを一時格納し、その送信元を判別するようにしている。これと同時に、該当する送信元からの単位データについては、それぞれ所望の時間にわたって１つずつの送信元に専有させて単位データの処理を行う第１のデータ処理手段に単位データを受け渡すようにしているため、効率よくデータ処理が行われるようになっている。さらに第２のデータ処理手段が新たな処理を行えるとき、格納したままで未処理の単位データを走査して、データがあればこれを第２のデータ処理手段に受け渡し、処理を行うようになっている。これにより、複数の送信元からデータを受信して処理を行うことが可能になっている。
【００１８】
さらに本発明では、（イ）通信ネットワークを介してクライアントから１処理単位ずつのデータとしての単位データを順次受信する単位データ受信手段と、（ロ）この単位データ受信手段が単位データを受信するたびにこれらの送信元のクライアントを判別するクライアント判別手段と、（ハ）それぞれ所望の時間にわたって１つずつのクライアントが専有する形で、同一クライアントから間欠的にあるいは連続して送られてくる任意数の単位データの処理を行う１または複数の第１のデータ処理手段と、（ニ）単位データを１単位として各クライアントの単位データを時分割処理する１または複数の第２のデータ処理手段と、（ホ）データ受信手段が単位データを受信するたびにクライアント判別手段の判別結果に応じてそれぞれのクライアントから送られてきた単位データを第１のデータ処理手段あるいは第２のデータ処理手段に振り分けるデータ振分手段とをデータ処理サーバに具備させる。
【００１９】
すなわち本発明では、データ処理サーバは通信ネットワークを介して１処理単位ずつのデータとしての単位データを受信すると、そのクライアントを判別するようにしている。そして、クライアントに応じて、それぞれ所望の時間にわたって１つずつのクライアントに専有させて単位データの処理を行う第１のデータ処理手段と、各クライアントの単位データを時分割処理する第２のデータ処理手段のどちらかに振り分けて処理させるようにしている。これにより、このデータ処理サーバでは複数のクライアントからデータを受信して処理することができるだけでなく、データを頻繁に送信してくるクライアントには、そのクライアントが専有できる処理手段を割り当て、効率よく処理することも可能となっている。
【００２０】
また本発明では、（イ）通信ネットワークを介してクライアントから１処理単位ずつのデータとしての単位データを順次受信する単位データ受信手段と、（ロ）この単位データ受信手段が受信した単位データのクライアントを判別する送信元判別手段と、（ハ）単位データ受信手段が受信した単位データを一時格納するデータ格納手段と、（ニ）それぞれ所望の時間にわたって１つずつのクライアントが専有する形で、同一クライアントから間欠的にあるいは連続して送られてくる任意数の単位データの処理を行う１または複数の第１のデータ処理手段と、（ホ）単位データを１単位として各クライアントが時分割で専有する形で、単位データを処理する１または複数の第２のデータ処理手段と、（ヘ）データ受信手段が単位データを受信するたびにクライアント判別手段の判別結果に応じてデータ格納手段から単位データを第１のデータ処理手段に受け渡す第１のデータ受け渡し手段と、（ト）この第１のデータ受け渡し手段により第１のデータ処理手段に受け渡されずデータ格納手段に格納されている単位データの有無を判別するデータ有無判別手段と、（チ）このデータ有無判別手段の判別結果がデータ有りのとき、データ格納手段からこの単位データを第２のデータ処理手段に受け渡す第２のデータ受け渡し手段とをデータ処理サーバに具備させる。
【００２１】
すなわち本発明では、データ処理サーバは通信ネットワークを介して１処理単位ずつのデータとしての単位データを受信して、これを一時格納し、そのクライアントを判別するようにしている。これと同時に、該当するクライアントからの単位データについては、それぞれ所望の時間にわたって１つずつのクライアントに専有させて単位データの処理を行う第１のデータ処理手段に単位データを受け渡すようにしているため、効率よくデータ処理が行われるようになっている。さらに第２のデータ処理手段が新たな処理を行えるとき、格納したままで未処理の単位データを走査して、データがあればこれを第２のデータ処理手段に受け渡し、処理を行うようになっている。これにより、複数のクライアントからデータを受信して処理を行うことが可能になっている。
【００２２】
さらに本発明では、（イ）通信ネットワークと、（ロ）請求項１記載のデータ処理装置と、（ハ）通信ネットワークを介してこのデータ処理装置にデータを送信するデータ送信手段を備えた１または複数のデータ処理要求装置とをデータ処理システムに具備させる。
【００２３】
すなわち本発明では、請求項１記載のデータ処理装置に、通信ネットワークを介してデータ処理要求装置がデータを送信し、これに対する処理を行わせるようなデータ処理システムを構成するようにした。
【００２４】
また本発明では、（イ）通信ネットワークと、（ロ）請求項２記載のデータ処理装置と、（ハ）通信ネットワークを介してこのデータ処理装置にデータを送信するデータ送信手段を備えた１または複数のデータ処理要求装置とをデータ処理システムに具備させる。
【００２５】
すなわち本発明では、請求項２記載のデータ処理装置に、通信ネットワークを介してデータ処理要求装置がデータを送信し、これに対する処理を行わせるようなデータ処理システムを構成するようにした。
【００２６】
また本発明では、（イ）通信ネットワークを介して１処理単位ずつのデータとしての単位データを順次受信する単位データ受信処理と、（ロ）この単位データ受信処理で単位データを受信するたびにこれらの送信元を判別する送信元判別処理と、（ハ）それぞれ所望の時間にわたって１つずつの送信元が専有する形で、同一送信元から間欠的にあるいは連続して送られてくる任意数の単位データの処理を行う第１のデータ処理と、（ニ）単位データを１単位として各送信元の単位データを時分割処理する１または複数の第２のデータ処理と、（ホ）データ受信処理で単位データを受信するたびに送信元判別処理の判別結果に応じてそれぞれの送信元から送られてきた単位データを第１のデータ処理あるいは第２のデータ処理に振り分けるデータ振分処理とを具備したデータ処理プログラムをコンピュータに実行させる。
【００２７】
すなわち本発明は、請求項１記載の発明に対応したデータ処理プログラムである。
【００２８】
さらに本発明では、（イ）通信ネットワークを介して１処理単位ずつのデータとしての単位データを順次受信する単位データ受信処理と、（ロ）この単位データ受信処理で受信した単位データの送信元を判別する送信元判別処理と、（ハ）単位データ受信処理で受信した単位データを一時格納するデータ格納処理と、（ニ）それぞれ所望の時間にわたって１つずつの送信元が専有する形で、同一送信元から間欠的にあるいは連続して送られてくる任意数の単位データの処理を行う１または複数の第１のデータ処理と、（ホ）単位データを１単位として各送信元が時分割で専有する形で、単位データを処理する１または複数の第２のデータ処理と、（ヘ）データ受信処理で単位データを受信するたびに送信元判別処理の判別結果に応じてデータ格納処理で格納した単位データを第１のデータ処理に受け渡す第１のデータ受け渡し処理と、（ト）この第１のデータ受け渡し処理により第１のデータ処理に受け渡されずデータ格納処理で格納されたままの単位データの有無を判別するデータ有無判別処理と、（チ）このデータ有無判別処理の判別結果がデータ有りのとき、データ格納処理で格納した単位データを第２のデータ処理に受け渡す第２のデータ受け渡し処理とを具備したデータ処理プログラムをコンピュータに実行させる。
【００２９】
すなわち本発明は、請求項２記載の発明に対応したデータ処理プログラムである。
【発明の効果】
【００３０】
以上説明したように本発明では、複数の送信元からデータを受信して処理することができるだけでなく、データを頻繁に送信してくる送信元には、その送信元が専有できる処理手段を割り当て、効率よく処理することも可能となっている。さらに、各送信元との通信頻度を調べ、頻度に応じて割り当てを変更することができるので、例えば、送信元の多くが無通信あるいは送信頻度の低いものであっても、頻繁にデータを送信してくる送信元が１つでも存在すると、データが受信済みかどうかを走査するのにかかるオーバーヘッドが問題になるという状況を回避することができる。また、この割り当てを動的に行うことでより効率のよい処理が可能である。さらに、このような手法によれば、同時に行わせる処理の数を制限することができるので、装置全体の処理能力が低下するのを防ぐことができる。
【発明を実施するための最良の形態】
【００３１】
以下実施例につき本発明を詳細に説明する。
【実施例１】
【００３２】
図１は、本発明の一実施例のデータ処理システムの構成の概要を表わしたものである。このデータ処理システム２００は、サーバ２０１とＬＡＮ（Local Area Network）やインターネット等の通信ネットワーク２０２を介して接続する第１〜第ｎのクライアント２０３1〜２０３nとからなっている。このように、サーバ２０１は第１〜第ｎのクライアント２０３1〜２０３nと相互に通信を行っているが、これらの通信を同時に成立させるために、通信の多重処理が行われている。
【００３３】
サーバ２０１の構成について説明する。サーバ２０１は、第１〜第ｍのＣＰＵ（中央処理装置）２１１1〜２１１mを備えている。これら第１〜第ｍのＣＰＵの２１１1〜２１１mは、それぞれ並列に処理を行うことができるようになっている。そこで本明細書では、これらを単に「ＣＰＵ２１１」として説明する。ＣＰＵ２１１はデータバス等のバス２１２を通じて通信多重処理方式のサーバ２０１内の各部と接続されている。このうち、ＲＯＭ（リード・オンリ・メモリ）２１３は、不揮発性データあるいは制御プログラムを格納している。ＲＡＭ（ランダム・アクセス・メモリ）２１４はＣＰＵ２１１が各種制御を実行する際に必要となるデータを一時的に格納するようになっている。ハード・ディスク・ドライブ（ＨＤＤ）２１５は、このサーバ２０１の制御を行うためのＯＳ（Operating System）やアプリケーションプログラムが格納された磁気記憶装置である。表示部２１６は液晶あるいは有機パネルを使用したモニタを備え、情報を視覚的に表示するようになっている。操作部２１７は、キーボード、マウスおよびスイッチボタンを備え各種操作を受け付けるようになっている。時計回路２１８は時間を計時し、サーバ２０１の通信した時刻がこれにより分かるようになっている。通信制御部２１９は、通信ネットワーク２０２に接続するようになっている。ハード・ディスク・ドライブ２１５、表示部２１６および操作部２１７はそれぞれ通信制御部２１９を介して、サーバ２０１の外部に接続された形態であってもよい。
【００３４】
サーバ２０１では、複数の独立した通信相手としての第１〜第ｎのクライアント２０３1〜２０３nに対する処理を同時に行う場合に、それぞれの処理の実行内容が、他の処理の実行内容に影響を及ぼさないように、複数のコンテキストで処理を行うようになっている。複数のコンテキストを実現するには、マルチスレッドを利用する方式や、マルチプロセスで共有メモリを使用する方式がある。複数のスレッド間あるいは複数のプロセス間で相互にデータを共有することで、複数のスレッドあるいは複数のプロセスが、それぞれ同じデータを参照して、同じプログラムを実行することができる。このようにして、複数のコンテキストにより通信の多重処理が実現されている。同じプロセスのスレッド同士はメモリを共有しているので、スレッド間でデータを共有するのは比較的容易である。このため、本実施例ではマルチスレッドを使用する方式で説明を行うことにするが、マルチプロセスで共有メモリを使用する方法でも同様の実施が可能である。
【００３５】
図２は、データ処理システムを構成するサーバ上で動作するサーバプログラムで構成されるサーバプログラム部を表わしたものである。図１と共に説明を行う。サーバプログラム部３０１は、サーバ２０１に実装されるプログラムで実現する回路部分で、通信の多重処理を行うことができる。サーバ２０１と第１〜第ｎのクライアント２０３1〜２０３nの通信は、実際にはこのサーバプログラム部３０１と第１〜第ｎのクライアント２０３1〜２０３nに実装される各クライアントプログラムによって実現される図示しないクライアントプログラム部との通信であり、このようなサーバプログラム部３０１とクライアントプログラム部によって、データ処理システム２００が実現されている。
【００３６】
サーバプログラム部３０１は、事象待ちスレッド３１１、非ブロック受信スレッド３１２、ブロック受信スレッド３１３およびアプリケーションスレッド３１４という複数のスレッド上でそれぞれ対応する処理を行うようになっている。さらに、サーバ２０１を運用するのに必要なプログラムとデータを利用者ごとにひとまとまりとしたユーザオブジェクト３２１およびこのサーバ２０１が通信中のクライアントごとにそのクライアントとのコネクションに関するプログラムとデータをひとまとまりとしたコネクションオブジェクト３２２という２種類のオブジェクトを備える。これらはそれぞれデータ部としてユーザオブジェクトのデータ部３２３、コネクションオブジェクトのデータ部３２４を保持している。これらのユーザオブジェクトのデータ部３２３およびコネクションオブジェクトのデータ部３２４に基づき、ユーザオブジェクトのプログラム部３２５、コネクションオブジェクトのプログラム部３２６がそれぞれ動作する。これと共に、通信制御アクセスライブラリ３３０、実行スレッド制御部３３１、事象待ち制御部３３２、非ブロック受信制御部３３３、ブロック受信制御部３３４およびユーザプログラムによって実現されるユーザプログラム部３３５も動作するようになっている。本実施例では、多重通信処理により複数の接続先からデータを受信するという本発明を実施するために必要最小限のオブジェクトだけを挙げて説明を行っている。実際には、これ以外の目的のものについては、個別にオブジェクトを追加して利用することができる。たとえば、金融機関の入出金処理を扱うサーバであれば、クライアントごとにその計算処理や計算処理に必要なデータをまとめたオブジェクトを追加する。
【００３７】
それぞれのプログラム部およびスレッドについて説明を行う。
【００３８】
通信制御アクセスライブラリ３３０は、サーバプログラム部３０１上で動作するすべてのプログラムから呼び出し可能なプログラム部となっている。通信制御アクセスライブラリ３３０は、サーバ２０１上で動作するすべてのプログラムに対して、外部のプログラムとデータの送受信を行うための、インタフェースを提供している。具体的には、サーバ２０１とクライアント２０３間の通信路としてのコネクションの接続、切断を行い、データの送受信を行っている。通信制御アクセスライブラリ３３０は、例えば、ＢＳＤ  ＳＯＣＫＥＴ（Berkeley Software Distribution socket）をベースとしたもので実現することができる。
【００３９】
実行スレッド制御部３３１も、サーバプログラム部３０１上で動作するすべてのプログラムから呼び出し可能なプログラムによって実現されている。実行スレッド制御部３３１は、それぞれ異なるスレッド上で動作するプログラム部からプログラム部へと処理要求を伝えることができる。また、処理要求されたプログラム部の使用できるスレッドが全て使用中で、新たに処理要求を受け取ることができないとき、実行スレッド制御部３３１はこの処理要求を図示しないキューに保存するようになっている。
【００４０】
事象待ち制御部３３２は、事象待ちスレッド３１１上で動作するプログラムによって実現されている。事象待ち制御部３３２は、各クライアントプログラム部から接続の要求を受け、通信制御アクセスライブラリ３３０によって、そのコネクションの接続を行わせる。また、そのコネクションごとに対応するコネクションオブジェクト３２２をそれぞれ作成する。そして、ブロック受信スレッド３１３の空き状況や図示しない各クライアントプログラム部との通信頻度に従って、データ受信を非ブロック受信制御部３３３またはブロック受信制御部３３４のどちらで行わせるか決定する。この決定方法については後に具体的に説明を行う。事象待ち制御部３３２は、また、非ブロック受信制御部３３３に割り当てたクライアントプログラム部について、データの受信処理が可能なコネクション一覧を作成する多重受信待ちを行う。多重受信待ちについても後に具体的に説明を行う。さらに、事象待ち制御部３３２は、クライアントプログラム部から通信の切断要求も受け、切断処理を行う。
【００４１】
事象待ち制御部３３２によってブロック受信方式が選択されているコネクションのコネクションオブジェクト３２２への参照は、ブロック受信コネクション管理テーブル３４２に格納されている。このブロック受信コネクション管理テーブル３４２には、コネクションごとにそのコネクションからデータを受け取った時刻が管理されている。この受信時刻は受信を行うたびに時計回路２１８の計時する時刻で更新され、常に一番最後に受信を行った時刻の情報となっている。
【００４２】
また、非ブロック受信方式が選択されているコネクションへのコネクションオブジェクト３２２への参照は、非ブロック受信コネクション管理テーブル３４１に格納されている。この非ブロック受信コネクション管理テーブル３４１にも、ブロック受信コネクション管理テーブル３４２と同様にコネクションごとに最新の受信時刻が管理されている。事象待ち制御部３３２は、このテーブルに格納されたコネクションについて、受信可能なコネクション一覧を作成する多重受信待ちを行っている。
【００４３】
ブロック受信制御部３３４は、ブロック受信スレッド３１３上で動作するプログラムによって実現されており、事象待ち制御部３３２によって割り当てられたコネクションについて受信処理を行っている。ブロック受信制御部３３４は、一度割り当てられたコネクションから連続してデータを受信するように動作する。ブロック受信制御部３３４は、ブロック受信スレッド３１３において受信したデータを、実行スレッド制御部３３１を介して、ユーザプログラム部３３５に受け渡す。これにより、受信処理の後に引き続く他の処理を、ユーザプログラム部３３５にアプリケーションスレッド３１４で行わせ、ブロック受信制御部３３４はブロック受信スレッド３１３上で直ちに次の受信処理を行うことができる。したがって、連続して通信が行われる場合は少ないオーバーヘッドで通信処理を行うことができる。
【００４４】
非ブロック受信制御部３３３は、非ブロック受信スレッド３１２上で動作するプログラムによって実現されている。事象待ち制御部３３２によって割り当てられたコネクションについて受信データが存在するときにその受信処理を行っている。本実施例では、事象待ち制御部３３２により、常に受信可能になってから非ブロック受信制御部３３３が受信動作を行うようになっている。もし受信データが存在しないときに受信を行うと、非ブロック受信方式では受信データが無いという結果が直ちに返却される。ブロック受信制御部３３４と同様に、非ブロック受信制御部３３３は非ブロック受信スレッド３１２において受信したデータをユーザプログラム部３３５に受け渡し、自らは受信処理以外の処理を行わないようになっている。
【００４５】
ユーザプログラム部３３５は、アプリケーションスレッド３１４上で動作するプログラムによって実現されており、実行スレッド制御部３３１を介して、ブロック受信制御部３３４および非ブロック受信制御部３３３から受け取ったクライアントプログラム部からの受信データと処理要求に応じた処理を行うようになっている。受信以外の処理時間が極端に長いデータが存在する可能性もあり、データごとに処理時間が不均一な場合でも、このようにユーザプログラム部３３５が受信とは別のスレッドで処理を行うことで、受信に用いられるスレッドには影響が及ばないようになっている。もちろん、このようなデータ処理は、アプリケーションスレッド３１４で行わず、そのままブロック受信スレッド３１３および非ブロック受信スレッド３１２で行うようにすることもできる。サーバプログラム部３０１以外にサーバ２０１上でＣＰＵやメモリなどのリソースを使用して動作しているプログラムが存在する場合、スレッドの数、つまり実行多重度の数は、たとえば、サーバプログラム部３０１が始動したときのＣＰＵ２１１の使用率に基づいて決定するようにして、サーバ２０１全体的に処理能力が低下するのを防ぐ。また、ユーザプログラム部３３５でのデータ処理においても、データ受信と同様、アプリケーションスレッド３１４を１つのコネクションに専有させ処理を行わせるものと、それ以外とに分離することもできる。
【００４６】
図３は、サーバプログラム部全体の処理の流れを表わしたものである。図１および図２と共に説明を行う。サーバプログラム部３０１は、サーバ２０１のＯＳからサーバとしてコネクションを制御する処理を開始する要求を受信すると（ステップＳ４０１：Ｙ）、まず１つのスレッド上でサーバプログラム部３０１の動作を開始させる（ステップＳ４０２）。このスレッドは説明のために初期スレッドと呼ぶことにする。初期スレッドはＯＳがサーバプログラム部３０１の処理を開始するときに生成されるものであってもよいし、あるいは元々ＯＳが行う様々な処理用に確保していたスレッドのうちの１つであってもよい。サーバプログラム部３０１は事象待ちスレッド３１１、ブロック受信スレッド３１３、非ブロック受信スレッド３１２、およびアプリケーションスレッドといった各スレッドを生成し（ステップＳ４０３）、各スレッド上で、それぞれのプログラム部が動作を開始する（ステップＳ４０４）。ここから、サーバプログラム部３０１の処理は各スレッドにまたがって複数のプログラム部により並列で行われるようになり（ステップＳ４０５）、ＯＳから停止要求を受信するまで動作し続ける（ステップＳ４０６：Ｎ）。この並列で行われる各プログラム部の処理については、後で別途説明を行う。初期スレッドは図２には図示しないスレッドとしてそのままサーバプログラム部３０１の全体を制御するために確保しておいてもよいし、必要なければ他のプログラムの処理を行うために使用するようにしてもよい。サーバプログラム部３０１はＯＳから停止要求を受信すると（ステップＳ４０６：Ｙ）、各プログラム部を停止させ（ステップＳ４０７）、全体的に動作を終了する（エンド）。スレッドの数に応じて同時に行うことができる処理の数は増すが、スレッド数を必要以上に増やすと、ＣＰＵの処理能力が分散されることになり、スレッド１つ１つの処理能力が低下してしまう。したがって、サーバプログラム部３０１は、必要なときにだけスレッドを生成し、不必要なときには削除するような構成にしてもよい。しかし、この場合でも、事象待ちスレッド３１１は、クライアントからの接続要求を受けるために常に存在している方がのぞましい。ところで、スレッドの生成および削除を行うために必要な処理は一般的に多く、頻繁にこれを行うと結局ＣＰＵ２１１の負荷を増すことになってしまう。このため、サーバプログラム部３０１は、その起動時に全てのスレッドを生成すると、停止するまでそのまま動作させ続けたほうが効率的である。本明細書でも、サーバプログラム部３０１の動作中にスレッドの生成および削除は行わない場合について説明を行う。
【００４７】
図４は、サーバプログラム部の行う処理のうちの事象待ち制御部の処理の流れを表わしたものである。図１および図２と共に説明を行う。事象待ち制御部３３２はサーバプログラム部３０１により、事象待ちスレッド３１１上で始動すると、まずクライアント２０３からの接続要求を受けるための準備を行い、着信待ちの状態を開始する（ステップ４５１）。着信待ちの開始は、通信制御アクセスライブラリ３３０を起動することで実行される。実際には、例えば、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）プロトコルを用いる場合は、指定したポート番号でサーバソケットを作成し、クライアント２０３からの着信を待つ状態を作り出す。ＴＣＰ／ＩＰでは、１つのＩＰアドレスは複数のポートから構成され、通信を行うには、ＩＰアドレスとポート番号の指定を行う。例えば、１つのコンピュータでブラウザとメーラのような複数のプログラム部により通信を行う場合がある。このとき、どのプログラム部のための通信データかを指定するために、プログラムにポート番号が割り当てられている。ソケットとはＩＰアドレスとポート番号の組を指したものである。つまり、ソケットはプログラム部が他の装置のプログラムにより実現されるプログラム部と通信を行うときの、仮想的なインタフェースとして動作している。前述したように、通信制御アクセスライブラリ３３０は、ＢＳＤ  ＳＯＣＫＥＴをベースとしたもので実現することができ、これは現在主流のソケットである。この着信を待つものは、サーバソケットを示すファイル記述子やソケットオブジェクトとしても扱われるが、ここでは、これらを総称して着信待ちオブジェクトと呼ぶ。
【００４８】
事象待ち制御部３３２は停止要求を受信すると（ステップＳ４５２：Ｙ）、その処理を終了する（エンド）。停止要求を受信しないうちは（ステップＳ４５２：Ｎ）、事象待ちスレッド３１１上で処理を続行し、まず、非ブロック受信のための多重受信待ちを行う（ステップＳ４５３）。多重受信待ちとは、非ブロック受信コネクション管理テーブル３４１に登録された、非ブロック受信に割り当てられたコネクションを対象にして行われ、データが受信可能になるまで待つ処理である。これは、例えば、ＵＮＩＸ（登録商標）（UNiplexed Information and Computing System）  ＯＳでは「ｓｅｌｅｃｔ（）」や「ｐｏｌｌ（）」という名前のシステムコールやライブラリとして、サンマイクロシステム（Sun Microsystems）社のプログラミング言語であるＪＡＶＡ（登録商標）ではセレクタという名前のサービスとして提供されている。具体的には、これらの関数やサービスは、サーバプログラム部３０１により呼び出されると、ＯＳの実行によりバッファリングしたコネクションからのデータが、バッファメモリに存在するかどうかを走査し、１つ以上のデータを見つけた時点で、それをサーバプログラム部３０１に返却するようにして動作している。データが見つからなければ、見つかるまで走査が繰り返される。ここでは、このセレクタを利用してＯＳの実行によりバッファメモリにコネクションからの受信データがバッファリングされたかどうかを走査し、多重受信待ちの結果を得るとして説明を行うことにする。
【００４９】
図５は、多重受信待ちの結果の例を表わしたものである。図２と共に説明を行う。多重受信待ちの結果は、接続中のコネクションそれぞれに対して、バッファメモリにＯＳの実行によりバッファリングしたデータの有無を表わす情報で構成されている。セレクタによる走査結果が報告されるときは、必ず１つ以上のコネクションからサーバプログラム部３０１がすぐに受信可能なデータが存在するときである。この図５の例では、クライアントｘからのデータがすでにバッファメモリに存在することを表わしている。また、クライアントｙからのデータはまだ存在しない。このような情報が接続するクライアントの分、得られるようになっている。
【００５０】
図４に戻って、図５の多重受信待ちの結果の例を基にして説明を続ける。ステップＳ４５１の着信待ちおよびステップＳ４５３の多重受信待ちを開始した結果、新たなクライアントから接続を要求されたか、あるいは多重受信待ちの結果が報告された場合には、それぞれに応じた処理が行われる。そこで、処理対象が発生すると、これが２つのうちのどちらであるかを判断する判断処理が行われる（ステップＳ４５４）。これらの処理対象に応じた処理やそれに関するデータをまとめて処理対象オブジェクトとする。処理対象オブジェクトが着信待ちオブジェクトの場合（Ｙ）、接続要求元のクライアントに対するコネクションオブジェクト３２２を作成し、その参照を非ブロック受信コネクション管理テーブル３４１に格納する（ステップＳ４５５）。一方、処理対象オブジェクトが着信待ちオブジェクトではない場合（ステップＳ４５４：Ｎ）、つまり、セレクタによる走査結果を受けた場合、図５を例とすると、クライアントｘからのデータ受信を非ブロック受信制御部３３３またはブロック受信制御部３３４のどちらで行わせるか決定する処理を行う。まず、ブロック受信スレッド３１３に空きがあるかどうかを調べる（ステップＳ４５６）。空きがあれば（Ｙ）、実行スレッド制御部３３１を介して処理要求をブロック受信制御部３３４に行い、ブロック受信スレッド３１３上で処理させるようにして（ステップＳ４５７）、このクライアントｘとのコネクションをブロック受信コネクション管理テーブル３４２に登録する。ブロック受信スレッド３１３に空きがなければ（ステップＳ４５６：Ｎ）、受信処理を非ブロック受信スレッド３１２で行うようにする。非ブロック受信制御部３３３は複数のスレッドで順次受信処理を行うがスレッド数以上のコネクションを扱っている状態のとき、実際の受信処理が開始されるまで待ち時間が発生する。そこで、非ブロック受信制御部３３４に受信処理要求を送信する前に受信時刻を更新しておく（ステップＳ４５８）。その後、実行スレッド制御部３３１を介し、非ブロック受信スレッド３１２に対し受信処理の要求を送信する（ステップＳ４５９）。
【００５１】
このようにして、コネクションオブジェクトを作成してその参照を非ブロック受信コネクション管理テーブルに格納するか、ブロック受信制御部３３４または非ブロック受信制御部３３３に処理を割り当てるかした後（ステップＳ４５５、ステップＳ４５７、ステップＳ４５９）、処理対象オブジェクトを全て処理済みであれば（ステップＳ４６０：Ｙ）、スレッドの停止要求を受信しないかぎり（ステップＳ４５２：Ｎ）、ステップＳ４５３の多重受信待ちの再開から処理を繰り返す。また、処理対象オブジェクトが残っていれば（ステップＳ４６０：Ｎ）、全てなくなるまでステップＳ４５４からの処理を繰り返す。ここでは、クライアントから接続要求を受けた場合、ステップＳ４５５でコネクションオブジェクト作成後、参照を非ブロック受信コネクション管理テーブル３４１に格納するとした。しかし、ブロック受信スレッド３１３に空きがあれば、このコネクションオブジェクト３２２をブロック受信コネクション管理テーブル３４２に登録して、ブロック受信制御部３３４で行うようにしてもよい。しかし、接続だけ事前に行い、通信を行わないケースもあるため、接続の時点では非ブロック受信スレッド３１２で通信制御を行うことが望ましい。一般に、接続の処理は相手を認識し接続可否を判断する必要があるため通信そのものの処理に比べ処理量が多い。このため、サーバ２０１としては、事前接続を行いコネクションを維持するという形態をとる方が、より多くのコネクションに対して高いスループット（Throughput）を実現して、効率よい運用が可能になる。したがって、非ブロック受信方式で同時に扱えるコネクション数に対する自由度を維持しながらも、ブロック受信方式を一部のコネクションに適用することで、全体としての性能を向上させる本発明においては、接続時点ではブロック受信方式を選択するのではなく非ブロック受信方式を選択しておき、実際の通信が発生したときにブロック受信制御を選択することが効果的である。
【００５２】
図６は、サーバプログラム部の行う処理のうちブロック受信制御部の処理の流れを表わしたものである。図１および図２と共に説明を行う。ブロック受信制御部３３４はサーバプログラム部３０１によりブロック受信スレッド３１３上で始動すると、まず事象待ち制御部３３２から実行スレッド制御部３３１を介して処理要求が送られるのを待つ（ステップＳ５０１）。ブロック受信制御部３３４は停止要求を受信すると（ステップＳ５０２：Ｙ）、その処理を終了する（エンド）。停止要求を受信しないうちは（ステップＳ５０２：Ｎ）、ブロック受信スレッド３１３上で処理を続行し、処理要求を受信するまで待機する（ステップＳ５０３：Ｎ）。事象待ち制御部３３２の図４のステップＳ４５７の処理により、受信可能データをブロック受信で受信処理するようブロック受信制御部３３４に処理要求が送られると、この処理要求を受信し（ステップＳ５０３：Ｙ）、データ受信を行う（ステップＳ５０４）。これは通常のブロック受信方式で行われるため、データを待ち合わせる待ち時間を有する受信処理である。この待ち時間には所定の値（制限時間）が設定されている。
【００５３】
事象待ち制御部３３２は、図４のステップＳ４５４で受信可能データが処理対象として存在するとして、ステップＳ４５７に至りブロック受信制御部３３４に処理要求を送信している。したがって、事象待ち制御部３３２から処理要求を受信した直後のデータ受信は、即座に行われる。しかし、通常のブロック受信制御部３３４の動作では、データ受信を行うまでに時間が掛かる場合もある。これが所定の値を超えてタイムアウトになると（ステップＳ５０５：Ｙ）、このクライアント２０３からのデータ受信は非ブロック受信方式で行うように、コネクションへの参照をブロック受信コネクション管理テーブル３４２から非ブロック受信コネクション管理テーブル３４１へと移動させる（ステップＳ５０６）。これにより、このブロック受信スレッド３１３は空きスレッドとなり、ステップＳ５０１の処理に戻って、次のコネクションが割り当てられるのを待つようになる。
【００５４】
一方、タイムアウトすることなく受信が行われると（ステップＳ５０５：Ｎ）、続いてその受信データが正常なものかどうかの判断処理が行われる（ステップＳ５０７）。受信結果が正常でなかった場合（Ｎ）、その原因を記録したエラーログを作成し（ステップＳ５０８）、そのコネクションへの参照をブロック受信コネクション管理テーブル３４２から削除する（ステップＳ５０９）。これにより、このブロック受信スレッド３１３は空きスレッドとなり、ステップＳ５０１の処理に戻る。受信が異常と判断される原因としては、例えば、データの送信元であるクライアント２０３側がデータ受信処理が行われる前にコネクションを切断した場合、受信したもののその受信結果が異常である場合が考えられる。このようにして作成されたエラーログは、サーバ２０１の管理者あるいはクライアント２０３の利用者に通知するなどして利用することができる。
【００５５】
受信が正常に行われれば（ステップＳ５０７：Ｙ）、受信時刻を更新する（ステップＳ５１０）。続いて受信したデータを処理要求と共に実行スレッド制御部３３１を介して、アプリケーションスレッド３１４上のユーザプログラム３３５に受け渡す（ステップＳ５１１）。ここでスレッド停止要求を受信すれば（ステップＳ５１２：Ｙ）、処理を終了し（エンド）、受信しなければ（ステップＳ５１２：Ｎ）、ステップＳ５０４に戻って次のデータ受信を行う処理を繰り返す。
【００５６】
図７は、サーバプログラム部の行う処理のうち非ブロック受信制御部の処理の流れを表わしたものである。図１および図２と共に説明を行う。非ブロック受信制御部３３３はサーバプログラム部３０１により非ブロック受信スレッド３１２上で始動すると、まず事象待ち制御部３３２から実行スレッド制御部３３１を介して処理要求が送られるのを待つ（ステップＳ５５１）。非ブロック受信制御部３３３は停止要求を受信すると（ステップＳ５５２：Ｙ）、その処理を終了する（エンド）。停止要求を受信しないうちは（ステップＳ５５２：Ｎ）、非ブロック受信スレッド３１２上で処理を続行し、処理要求を受信するまで待機する（ステップＳ５５３：Ｎ）。
【００５７】
事象待ち制御部３３２の図４のステップＳ４５９の処理により、受信可能データを非ブロック受信で受信処理するよう非ブロック受信制御部３３３に処理要求が送られると、この処理要求を受信し（ステップＳ５５３：Ｙ）、データ受信を行う（ステップＳ５５４）。事象待ち制御部３３２は、図４のステップＳ４５４で受信可能データが処理対象として存在するとして、ステップＳ４５９に至り非ブロック受信制御部３３４に処理要求を送信している。したがって、非ブロック受信制御部３３４でのデータ受信は処理要求を受けるとすぐにそのデータの受信を行うようになっている。
【００５８】
受信が正常に行われなければ（ステップＳ５５５：Ｎ）、その原因を記録したエラーログを作成する（ステップＳ５５６）。さらに、このコネクションへの参照を非ブロック受信コネクション管理テーブル３４１から削除し（ステップＳ５５７）、ステップＳ５５１の事象待ち制御部３３２からの処理要求を待つ処理に戻って、再び同様に非ブロック受信方式での受信処理を繰り返す。
【００５９】
一方、受信が正常に行われれば（ステップＳ５５５：Ｙ）、受信したデータを処理要求と共に実行スレッド制御部３３１を介して、アプリケーションスレッド３１４上のユーザプログラム３３５に受け渡す（ステップＳ５５８）。そして、この受信データがそのコネクションからの最後のデータであるかどうかを判断する処理を行う（ステップＳ５５９）。これは、ファイルの終端を表わすＥＯＦ（End of File）コードが、受信データとともに受け取った受信結果の概要を表わす情報に含まれているかどうかで分かるようになっている。最後のデータであれば（Ｙ）、ステップＳ５５７の非ブロック受信コネクション管理テーブル３４１からこのコネクションへの参照を削除する処理を行った後に、一方、最後のデータでなければ（ステップＳ５５９：Ｎ）、そのままステップＳ５５１の事象待ち制御部３３２からの処理要求を待つ処理に戻って、再び同様に非ブロック受信方式での受信処理を繰り返す。
【００６０】
このように、非ブロック受信制御部３３３は、１回、処理要求を受信するごとに、そのスレッドで処理するコネクションを切り替えるようになっている。これにより、少ない数のスレッドを、特定のコネクションに専有させることなく、多くのコネクションに開放することが可能である。なお、非ブロック受信制御部３３３の処理に、受信時刻を更新する処理が含まれないのは、図４の事象待ち制御部３３２の処理のステップＳ４５８によりすでに行われているためである。前述したように、非ブロック受信スレッド３１２の数は、非ブロック受信方式に割り当てられたコネクションの数より少い可能性があり、このとき、図７のような非ブロック受信制御部３３３の処理は開始されない。したがって、事象待ち制御部３３２の処理で、非ブロック受信制御部３３３に送信された処理要求は、非ブロック受信スレッド３１２上で実行中の処理が終了し、空きスレッドができるまで、実行スレッド制御部３３１のキューに保存される。このため、スレッド数以上のコネクションにおいて受信事象が同時に発生したときには待ちが発生するが、これらは順次受信処理されるので、ブロック受信方式のように１つのコネクションに専有されてしまうことはない。つまり、接続相手の数に制限されることがないので、サーバシステムとしてはより広い分野に利用できるという拡張性が備わったものとなる。
【００６１】
以上説明したように、本実施例によれば、多数のコネクションを同時に扱うサーバプログラム部３０１において、通信頻度に応じてブロック受信制御部３３４と非ブロック受信制御部３３３を選択することができるようにした。これにより、通信頻度の高いコネクションにはブロック受信制御部３３４でスループットの高い通信を行うことを可能にし、非ブロック受信制御部３３３でこれ以外のコネクションに対して通信の多重処理を行うことを可能にした。また、ブロック受信制御部３３４で制御するコネクション数を一定数以上にはしないことで、コンテキスト数の増加を抑え、サーバプログラム部３０１全体としての処理能力低下を防ぐこともできるようにした。さらに、ブロック受信制御部３３４に割り当てたコネクションからのデータ受信に制限時間を設け、タイムアウトすると非ブロック受信制御部３３３に割当を変更するようにした。サーバには、ブロック受信方式か非ブロック受信方式のどちらかのサーバプログラムが実装され、接続相手の数を制限しない場合、非ブロック受信方式をセレクタと組み合わせたものとなるのが一般的である。しかし、接続相手の中に１つでも高い頻度で通信を行うものがあると、セレクタの走査によるオーバーヘッドが問題になってしまう。しかし、本実施例によれば、通信頻度の高い接続相手には、ブロック受信方式を用いることができるので、セレクタによる走査は無通信あるいは通信頻度の低い接続相手のみに対して行われる。このため、走査オーバーヘッドを低減させることができる。このように、動的にコネクションの割当を変更することで、本発明のデータ処理サーバは、接続の可能なコネクション数に対して自由度を維持しつつ、同時に高い通信性能を実現することができる。
【００６２】
従来、イベント型のプログラムを利用した非ブロック受信方式が提案されている。イベント型のプログラムでは、ある決まったイベントが発生することにより、プログラムの別の処理が誘発される仕組みになっている。たとえば、ＯＳによりコネクションからのデータがバッファメモリにバッファリングされた、というイベントにより誘発されて、データ受信およびデータ処理が開始される。これによれば、セレクタによりバッファリング済みのデータの有無を走査する必要がない。このため、走査によるオーバーヘッドを省くことができ、通信頻度の高いコネクションに対しても、走査時間に影響される処理効率の悪化の問題を排除することができる。このイベントドリブンの通信プログラムを実現するものとして、たとえば、ＵＮＩＸ（登録商標）互換のＯＳであるＢＳＤ（Berkeley Software Distribution）では「ｋｑｕｅｕｅ」、同じくＵＮＩＸ（登録商標）互換のＯＳであるＬｉｎｕｘでは「ｅｐｏｏｌ」、さらにマイクロソフト（Microsoft）社のＯＳであるウィンドウズ（登録商標）（Windows（登録商標））では「ＢｅｇｉｎＲｅｃｖ」や「ＥｎｄＲｅｃｖ」といった関数が提供されている。このようなイベント型のプログラムは、各処理の呼び出し関係がはっきりしたブロック受信方式および非ブロック受信方式のプログラムとは構造が大きく異なっている。ところが、既存のアプリケーションには、セレクタを用いた非ブロック受信方式により設計されたプログラムで実現されているものが多い。これらを新たに呼び出し関係のはっきりしないイベント型のプログラムに変更するには、多大な労力が必要とされるが、本発明の通信制御方式を使用すれば、より少ない労力でイベント型のプログラムに匹敵する効率のよいデータ受信を行うことができる。また、イベント型のプログラムでは、ＯＳあるいはライブラリが優先的に処理するコネクションを決定してしまう。ライブラリとは複数のプログラムにわたって汎用的に使われるデータや関数をまとめたもので、ＯＳと同様、サーバプログラムとは別に構成されたものであるため、自由にその動作を変更することができない。本発明のデータ処理方法によれば、コネクションの使用頻度の計算をサーバプログラム上に実装でき、イベント型と同様に優先するコネクションを動的に変更することが可能なだけでなく、利用者が任意に優先させるコネクションを変えることもできる。
【００６３】
ここでは、ＴＣＰ／ＩＰなどの通信プロトコルを使用し、ＬＡＮやインターネットなどを介し互いに通信を行うプログラムのうち、サーバプログラムについて説明を行った。本発明は、多数のコネクションを同時に処理するプログラムにおいてより効果的であるが、クライアントプログラムにおいて同じ実装を行うことももちろん可能である。
【００６４】
＜本発明の変形例＞
【００６５】
図８は、本発明の変形例のサーバプログラム部の行う処理のうちの事象待ち制御部の処理の流れを表わしたものである。この図８は実施例の図４に対応するものであり、図４と同一の部分は同一のステップ番号を付しており、適宜説明を省略する。またステップＳ４５４以前の処理は図示を省略している。実施例の事象待ち制御部３３２をこの変形例では事象待ち制御部３３２Ａとしている。また、実施例のブロック受信制御部３３４をこの変形例ではブロック受信制御部３３４Ａとしている。これらは、それぞれ実施例とは異なる処理を行うプログラムにより実現されているためである。図２と共に説明を行う。事象待ち制御部３３２Ａは受信可能なデータがあると、そのデータ受信をブロック受信制御部３３４Ａあるいは非ブロック受信制御部３３３のいずれかで行わせるかを、それぞれのコネクションの最新の受信時刻を元に判断するようになっている。図８のステップＳ４５６で、ブロック受信スレッド３１３に空きがない場合（Ｎ）、受信時刻の比較を行う（ステップＳ６０１）。受信時刻の比較には、ブロック受信コネクション管理テーブル３４２および非ブロック受信コネクション管理テーブル３４１の受信時刻が利用される。ここでは、受信可能データのある非ブロック受信制御部３３３に割り当てられたコネクションの受信時刻が、ブロック受信制御部３３４Ａに割り当てられたいずれかのコネクションの受信時刻より新しいものであるかどうかで判断されることになる（ステップＳ６０２）。新しければ（Ｙ）、ブロック受信制御部３３４Ａに割り当てられたコネクションのうち、最も受信時刻の古いものと、割り当ての交換が行われ（ステップＳ６０３）、ステップＳ４６０の処理に進む。古ければ（ステップＳ６０２：Ｎ）、非ブロック受信制御部３３３に割り当てたままでその後の処理が行われる（ステップＳ４５８〜ステップＳ４６０）。
【００６６】
図９は、変形例のサーバプログラム部の行う処理のうちブロック受信制御部の処理の流れを表わしたものである。この図９は実施例の図６に対応するものであり、図６と同一の部分は同一のステップ番号を付しており、適宜説明を省略する。図２と共に説明を行う。ブロック受信制御部３３４Ａはデータ待ちを含むデータ受信処理を行っているときに（ステップＳ５０４）、タイムアウトしていなくても（ステップＳ５０５：Ｎ）、事象待ち制御部３３２Ａにより非ブロック受信スレッド３１２に割り当ての変更を要求されると（ステップＳ６１０：Ｙ）、参照を非ブロック受信コネクション管理テーブル３４２に参照を移し割り当てを変更する（ステップＳ５０６）。変更を要求されなければ（ステップＳ６１０：Ｎ）、そのままブロック受信方式でデータ受信が行われる。
【００６７】
この変形例のデータ処理サーバによれば、ブロック受信制御部３３４Ａに割り当てられたコネクションがタイムアウトすることなく、頻繁に通信を行っている場合でも、非ブロック受信制御部３３３に割り当てられたコネクションのうち、より頻繁に通信を行っているものがあれば、割り当ての変更が可能である。しかし、本来、通信が頻繁でなく、たまたま連続でデータを受信した非ブロック受信制御部３３３に割り当てられたコネクションの場合も、割り当ての変更が行われることが考えられる。したがって、ブロック受信コネクション管理テーブル３４２および非ブロック受信コネクション管理テーブル３４１に過去１日、あるいは過去１時間といった期間の通信回数の情報を記録するようにしてもよい。この回数に応じて、受信制御の割り当てを行うことも可能である。
【図面の簡単な説明】
【００６８】
【図１】本発明の一実施例によるデータ処理システムの構成の概要を表わした構成図である。
【図２】データ処理システムを構成するサーバ上で動作するサーバプログラムで構成されるサーバプログラム部を表わした構成図である。
【図３】サーバプログラム部全体の処理の流れを表わした流れ図である。
【図４】サーバプログラム部の行う処理のうちの事象待ち制御部の処理の流れを表わした流れ図である。
【図５】多重受信待ちの結果の例を表わした説明図である。
【図６】サーバプログラム部の行う処理のうちブロック受信制御部の処理の流れを表わした流れ図である。
【図７】サーバプログラム部の行う処理のうち非ブロック受信制御部の処理の流れを表わした流れ図である。
【図８】本発明の変形例によるサーバプログラム部の行う処理のうちの事象待ち制御部の処理の流れを表わした流れ図である。
【図９】本発明の変形例によるサーバプログラム部の行う処理のうちブロック受信制御部の処理の流れを表わした流れ図である。
【図１０】ネットワークサーバが複数のコネクションを１つのコンテキストで制御する様子を表わした説明図である。
【図１１】ネットワークサーバが複数のコネクションを複数のコンテキストで制御する様子を表わした説明図である。
【図１２】ネットワークサーバが複数のコネクションを１つのコンテキストとセレクタにより非ブロック受信方式で制御する様子を表わした説明図である。
【符号の説明】
【００６９】
２００  データ処理システム
２０１  サーバ
２０３  クライアント
２１１  ＣＰＵ
３０１  サーバプログラム部
３１１  事象待ちスレッド
３１２  非ブロック受信スレッド
３１３  ブロック受信スレッド
３１４  アプリケーションスレッド
３２１  ユーザオブジェクト
３２２  コネクションオブジェクト
３３０  通信制御アクセスライブラリ
３３１  実行スレッド制御部
３３２  事象待ち制御部
３３３  非ブロック受信制御
３３４  ブロック受信制御
３３５  ユーザプログラム部
３４１  非ブロック受信コネクション管理テーブル
３４２  ブロック受信コネクション管理テーブル
【図１】
2006277675.tif 000003
【図２】
2006277675.tif 000004
【図３】
2006277675.tif 000005
【図４】
2006277675.tif 000006
【図５】
2006277675.tif 000007
【図６】
2006277675.tif 000008
【図７】
2006277675.tif 000009
【図８】
2006277675.tif 000010
【図９】
2006277675.tif 000011
【図１０】
2006277675.tif 000012
【図１１】
2006277675.tif 000013
【図１２】
2006277675.tif 000014