JP6369176B2 - 情報処理装置、通信制御方法及びプログラム - Google Patents

情報処理装置、通信制御方法及びプログラム Download PDF

Info

Publication number
JP6369176B2
JP6369176B2 JP2014139437A JP2014139437A JP6369176B2 JP 6369176 B2 JP6369176 B2 JP 6369176B2 JP 2014139437 A JP2014139437 A JP 2014139437A JP 2014139437 A JP2014139437 A JP 2014139437A JP 6369176 B2 JP6369176 B2 JP 6369176B2
Authority
JP
Japan
Prior art keywords
processing
message
stored
messages
buffer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2014139437A
Other languages
English (en)
Other versions
JP2016019072A (ja
Inventor
厚人 廣瀬
厚人 廣瀬
俊弘 川上
俊弘 川上
環 田中
環 田中
山田 俊昭
俊昭 山田
浩一 三浦
浩一 三浦
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2014139437A priority Critical patent/JP6369176B2/ja
Priority to US14/719,881 priority patent/US10148585B2/en
Publication of JP2016019072A publication Critical patent/JP2016019072A/ja
Application granted granted Critical
Publication of JP6369176B2 publication Critical patent/JP6369176B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/50Queue scheduling
    • H04L47/62Queue scheduling characterised by scheduling criteria
    • H04L47/622Queue service order
    • H04L47/623Weighted service order

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Communication Control (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、サーバの通信制御技術に関する。
ミッションクリティカルなオンラインシステム(例えば、株式の取引或いは外国為替証拠金取引等のオンラインシステム)は、システムの安定稼動に重要な信頼性及び可用性を備えるだけでなく、利用者端末が処理要求を送信してから処理結果を受信するまでの応答時間が可能な限り短くなるように構築される。また、或る特定の期間に取引が集中するような事態に対処するため、多数の処理要求を同時並行で処理することができるスループットを備えるように構築される。
サーバが実行する処理に関して、或る文献は以下のような技術を開示している。具体的には、受信した処理要求に基づきサーバが処理を実行し、処理結果であるメッセージを宛先毎に用意されたキューに分類する。そして、サーバは、キューに格納されたメッセージの数が所定の数以上になった場合に、キューに格納された複数のメッセージをまとめ、処理要求の送信元の装置に送信する。又は、サーバは、メッセージがキューに格納されてから所定の時間が経過すると、キューに格納された複数のメッセージをまとめ、処理要求の送信元の装置に送信する。このように、宛先が同じである複数のメッセージをまとめて送信することで、ネットワークのトラフィック量が減らすことができ、また、サーバの処理負荷を減らすことができる。
但し、上記の文献の技術を用いると、送信の回数を減らすことができても、応答時間が長くなってしまう場合が生じる。例えばサーバが受信する処理要求の数が比較的少ない場合、キューに処理結果が蓄積されにくい。従って、キューに格納された処理結果は、サーバの処理負荷が比較的少ないのにもかかわらず、所定の時間が経過するまでは送信されない場合が生じる。また、処理結果の宛先に偏りが無い場合にも、キューに処理結果が蓄積されにくい。すなわち、上記の文献の技術は、処理結果を統合することで応答性能を劣化させてしまう場合がある。
特開2006−31238号公報 特開平5−160855号公報
従って、本発明の目的は、1つの側面では、処理結果を統合する処理が原因で応答性能が劣化するのを抑制するための技術を提供することである。
本発明に係る情報処理装置は、送信すべき1又は複数のメッセージを格納するバッファと、バッファからメッセージを取り出し、取り出した当該メッセージを送信する処理を各々が実行する1又は複数の通信部と、バッファに格納されているメッセージの数と通信部の数との比較結果に基づき、バッファに格納されているメッセージの中から、宛先が同じである2以上のメッセージを統合する処理である統合処理の対象であるメッセージを特定し、特定された当該メッセージについて統合処理を実行する実行部とを有する。
1つの側面では、処理結果を統合する処理が原因で応答性能が劣化するのを抑制できるようになる。
図1は、本実施の形態の概要を説明するための図である。 図2は、本実施の形態の概要を説明するための図である。 図3は、本実施の形態の概要を説明するための図である。 図4は、本実施の形態の概要を説明するための図である。 図5は、本実施の形態の概要を説明するための図である。 図6は、本実施の形態の概要を説明するための図である。 図7は、本実施の形態のシステム概要を示す図である。 図8は、サーバの機能ブロック図である。 図9は、クライアント端末の機能ブロック図である。 図10は、サーバの定義ファイル格納部に格納されるデータの一例を示す図である。 図11は、クライアント端末の定義ファイル格納部に格納されるデータの一例を示す図である。 図12は、初期化処理の処理フローを示す図である。 図13は、サーバの管理テーブルの一例を示す図である。 図14は、生成されるセマフォの一例を示す図である。 図15は、コマンド受付処理の処理フローを示す図である。 図16は、受信処理の処理フローを示す図である。 図17は、処理要求の一例を示す図である。 図18は、サーバの要求管理テーブルに格納されるデータの一例を示す図である。 図19は、受信処理の処理フローを示す図である。 図20は、受信処理の処理フローを示す図である。 図21は、処理要求格納部に格納されるデータの一例を示す図である。 図22は、受信処理の処理フローを示す図である。 図23は、データ処理の処理フローを示す図である。 図24は、データ処理の処理フローを示す図である。 図25は、データ処理の処理フローを示す図である。 図26は、データ処理の処理フローを示す図である。 図27は、結果管理テーブルに格納されるデータの一例を示す図である。 図28は、データ処理の処理フローを示す図である。 図29は、データ処理の処理フローを示す図である。 図30は、データ処理の処理フローを示す図である。 図31は、データ処理の処理フローを示す図である。 図32は、データ処理の処理フローを示す図である。 図33は、処理結果格納部に格納されるデータの一例を示す図である。 図34は、データ処理の処理フローを示す図である。 図35は、データ処理の処理フローを示す図である。 図36は、データ処理の処理フローを示す図である。 図37は、データ処理の処理フローを示す図である。 図38は、データ処理の処理フローを示す図である。 図39は、送信処理の処理フローを示す図である。 図40は、送信処理の処理フローを示す図である。 図41は、処理結果の一例を示す図である。 図42は、送信処理の処理フローを示す図である。 図43は、クライアント端末が実行する処理の処理フローを示す図である。 図44は、クライアント端末の管理テーブルに格納されるデータの一例を示す図である。 図45は、クライアント端末の要求管理テーブルに格納されるデータの一例を示す図である。 図46は、クライアント端末が実行する処理の処理フローを示す図である。 図47は、コンピュータの機能ブロック図である。
図1乃至図6を用いて、本実施の形態の概要について説明する。
例えば図1に示すような状況を考える。図1においては、サーバがバッファ1000を有しており、サーバにおいては送信処理用スレッド1001及び1002が実行される。送信処理用スレッド1001及び1002は、バッファ1000から処理結果を取り出して送信する。実線で描かれた丸の図形は処理結果を表し、丸の内側にある文字列は宛先及びその宛先に送信される処理結果の番号を表す。例えば処理結果R1は、宛先Aに送信される1番目の処理結果であり、全体では1番目の処理結果である。太線で描かれた丸の図形は、複数の処理結果が統合されて1つの処理結果になったことを表す。例えば処理結果R4は、宛先Bに送信される2番目の処理結果及び3番目の処理結果を含み、全体では4番目の処理結果である。バッファ1000は5つの領域に分けられている。図1において左の領域にある処理結果ほど先に送信される。
本実施の形態においては、処理結果の数Xと、送信処理用スレッドの数Yとの比較結果に基づき、宛先が同じである複数の処理結果を統合する処理(以下、統合処理と呼ぶ)の対象になる処理結果を特定する。例えば図1においては、送信処理用スレッドの数Yは2である。統合された複数の処理結果は1つの処理結果としてカウントされるので、処理結果の数Xは5である。このように処理結果の数が送信処理用スレッドの数より多い場合には、(Y+1)番目以降の処理結果が統合処理の対象になり、それ以外の処理結果は統合処理の対象から除外される。図1においては、処理結果R3、R4及びR5が統合処理の対象になり、処理結果R1及びR2は統合処理の対象から除外される。このようにすれば、処理結果に対して統合処理を実行していることが原因で処理結果の送信を待たなければならなくなる可能性が低い。
また、本実施の形態においては、図2に示すようなデータをバッファ1000とは別に管理する。図2においては、宛先の識別情報と、最終番号と、空領域のサイズとが管理されている。最終番号とは、或る宛先についての処理結果の番号のうち最も大きい番号である。例えば図1の例では、宛先Aについての複数の処理結果(処理結果R1及びR3)のうち処理結果R3の番号が最も大きいので、最終番号は3である。空領域のサイズは、最終番号についての処理結果が格納された領域の空領域のサイズである。例えば図1の例では、処理結果R3が格納された領域の空領域のサイズは0である。本実施の形態においては、(Y+1)番目以降の処理結果のうち、最終番号についての処理結果を統合処理の対象にすることにする。これにより、空領域を探すためにバッファ1000をチェックすることが無くなり、送信処理用スレッド1001及び1002がバッファ1000の排他を獲得するために待つことを抑制できる。
そこで、例えば図3に示すように、新たに処理結果が生成されたとする。新たに生成された処理結果は宛先がBであり、サイズは500バイトである。本実施の形態においては、たとえ処理結果R2が格納された領域に十分な空領域があったとしても、処理結果R2は統合処理の対象ではないので、処理結果R2と統合されることは無い。また、最終番号についての処理結果を統合処理の対象にするので、処理結果R4も統合処理の対象ではない。この例では、図2に示したデータにおいて、処理結果R5が格納された領域の空領域のサイズが600バイトであることが示されているので、新たに生成された処理結果と処理結果R5とが統合される。
次に、図4に示すような状況を考える。図4においては、送信処理用スレッド1001乃至1003が実行されているので、送信処理用スレッドの数Yが3である。バッファ1000には、宛先Aに送信される1番目の処理結果である処理結果R1と、宛先Bに送信される1番目の処理結果である処理結果R2とが格納されている。よって処理結果の数Xは2である。このように、送信処理用スレッドの数Yが処理結果の数X以上である場合には、処理結果に対して統合処理を実行していることが原因で処理結果の送信を待つことになる可能性が有る。従って送信処理用スレッドの数が処理結果の数以上である場合には統合処理は実行されない。図4の例では、処理結果R1及びR2は統合処理の対象から除外される。
図4に示した状況においては、サーバは例えば図5に示すようなデータをバッファ1000とは別に管理する。図5においては、宛先Aについての処理結果である処理結果R1が格納された領域の空領域のサイズは500バイトであり、宛先Bについての処理結果である処理結果R2が格納された領域の空領域のサイズは550バイトである。
ここで、例えば図6に示すように、新たに処理結果が生成されたとする。新たに生成された処理結果は宛先がAであり、サイズは300バイトである。この場合、新たに生成された処理結果は、処理結果R1が格納された領域の空領域のサイズが500バイトであるにもかかわらず、処理結果R1とは統合されない。新たに生成された処理結果は、処理結果R1及びR2が格納された領域とは別の領域に格納される。これにより、宛先Aについて統合処理を実行することが原因で、処理結果R1を送信するタイミングが遅れてしまうことを防ぐことができる。
以上のように、統合処理を実行することで送信処理の回数を少なくすることができるので、ネットワークのトラフィック量を減らすとともに、サーバの処理負荷を減らすことができる。一方、統合処理を実行するのが好ましくない場合には統合処理を実行しないので、統合処理が原因で応答性能を劣化させるのを抑制できるようになる。
以下では、本実施の形態についてより具体的に説明する。
図7に、本実施の形態のシステム概要を示す。例えばインターネットであるネットワーク5には、処理要求を送信するクライアント端末30及び31と、受信した処理要求に基づきデータ処理を実行するサーバ10乃至12とが接続される。クライアント端末30及び31から送信された処理要求は、ネットワーク5に設置された中継装置(図示せず)によってサーバ10乃至12のいずれかに中継される。受信した処理要求に基づきデータ処理を実行したサーバは、データ処理の処理結果を、処理要求の送信元のクライアント端末に送り返す。
図8に、サーバ10の機能ブロック図を示す。サーバ10は、定義ファイル格納部100と、管理データ格納部105と、処理結要求格納部106と、処理結果格納部107と、データ格納部108とを有する。サーバ10においては、初期化処理部101と、受信処理用スレッド102と、データ処理用スレッド103と、送信処理用スレッド104とが実行される。図8においては、受信処理用スレッド102、データ処理用スレッド103及び送信処理用スレッド104の数は複数であるが、単数であってもよい。また、受信処理用スレッド102、データ処理用スレッド103及び送信処理用スレッドは、スレッドではなくプロセスであってもよい。なお、サーバ11及び12の機能ブロック図はサーバ10の機能ブロック図と同じであるので、説明を省略する。
初期化処理部101は、定義ファイル格納部100に格納されたデータに基づき、初期化処理を実行する。受信処理用スレッド102は、処理要求をクライアント端末30及び31から受信し、処理要求格納部106に格納する。また、受信処理用スレッド102は、管理データ格納部105に格納されたデータを更新する。データ処理用スレッド103は、処理要求格納部106に格納された処理要求に基づき、データ格納部108に格納されたデータに対してデータ処理を実行し、処理結果を処理結果格納部107に格納する。また、データ処理用スレッド103は、管理データ格納部105に格納されたデータを更新する。送信処理用スレッド104は、処理結果格納部107に格納された処理結果を取り出し、処理結果に対応する処理要求の送信元のクライアント端末に送信する。また、送信処理用スレッド104は、管理データ格納部105に格納されたデータを更新する。
図9に、クライアント端末30の機能ブロック図を示す。クライアント端末30は、定義ファイル格納部303と、管理データ格納部304とを有する。クライアント端末30においては、管理部301と、アプリケーションプログラムのプロセスであるクライアントプロセス302とが実行される。なお、クライアント端末31の機能ブロック図はクライアント端末30の機能ブロック図と同様であるので、説明を省略する。
クライアントプロセス302は、データ処理を要求するデータである要求本体を生成し、管理部301に出力する。管理部301は、クライアントプロセス302から受け取った要求本体を含む処理要求を生成し、サーバ10乃至12に送信する。管理部301は、サーバ10乃至12から受信した処理結果から結果本体を取り出し、クライアントプロセス302に出力する。管理部301は、定義ファイル格納部303に格納されたデータに基づき初期化処理を実行する。管理部301は、管理データ格納部304に格納されたデータを更新する。
図10に、サーバ10の定義ファイル格納部100に格納されるデータの一例を示す。図10の例では、サーバ10の処理に使用されるパラメタの値が格納される。1行目のパラメタは、受信処理用スレッド102の数及び送信処理用スレッド104の数を規定するパラメタである。2行目のパラメタは、データ処理用スレッド103の数を規定するパラメタである。3行目のパラメタは、処理要求を受信してから処理結果を送り返すまでの時間の上限を規定するパラメタである。単位は、例えば秒である。4行目のパラメタは、処理要求格納部106内に設けられるバッファの数及び処理結果格納部107内に設けられるバッファの数を規定するパラメタである。5行目のパラメタは、登録できるクライアントIDの数の最大値を規定するパラメタである。6行目のパラメタは、処理要求格納部106における1つのバッファのサイズ及び処理結果格納部107における1つのバッファのサイズを規定するパラメタである。単位は、例えばバイトである。なお、受信処理用スレッド102の数と送信処理用スレッド104の数とは同じでなくてもよい。
図11に、クライアント端末30の定義ファイル格納部303に格納されるデータの一例を示す。図11の例では、クライアント端末30の処理に使用されるパラメタの値が格納される。1行目のパラメタは、処理要求を送信してから処理結果を受信するまでの時間の上限を規定するパラメタである。2行目のパラメタは、クライアント端末30のクライアントIDを規定するパラメタである。3行目のパラメタは、送信先のサーバの識別情報(例えば、名称又はIPアドレス)を規定するパラメタである。4行目のパラメタは、送信先のサーバのポート番号を規定するパラメタである。5行目のパラメタは、クライアント端末30において使用されるポート番号である。
次に、図12乃至図42を用いて、サーバ10が実行する処理について説明する。まず、図12乃至図15を用いて、初期化処理部101が実行する初期化処理について説明する。なお、初期化処理の開始時点においては、受信処理用スレッド102、データ処理用スレッド103、及び送信処理用スレッド104は生成されていない。
サーバ10の初期化処理部101は、定義ファイル格納部100からパラメタの値を読み出し、管理データ格納部105に格納された管理テーブルに格納する(図12:ステップS1)。
図13に、サーバ10の管理テーブルの一例を示す。図13の例では、データ処理用スレッドの数と、通信処理用スレッドの数と、最大バッファ数と、サーバタイムアウトの時間と、バッファサイズと、プロセス停止フラグとが格納される。プロセス停止フラグは、サーバ10のプロセスを停止するか否か判定するためのフラグである。バッファサイズは、送信処理用スレッド104が一度に送信可能なデータ量以下になるように設定される。
図12の説明に戻り、初期化処理部101は、管理データ格納部105における要求管理テーブル及び結果管理テーブル、処理要求格納部106並びに処理結果格納部107の内容を初期化する(ステップS3)。
初期化処理部101は、受信処理用セマフォ、データ処理用セマフォ、及び送信処理用セマフォを生成し、管理データ格納部105に格納する(ステップS5)。
図14に、ステップS5において生成されるセマフォの一例を示す。図14の例では、受信処理用セマフォ、データ処理用セマフォ、及び送信処理用セマフォの各々について、ロック(LOCK)を表す値又はアンロック(UNLOCK)を表す値が格納される。受信処理用セマフォは、受信処理用スレッド102の動作を制御するためのセマフォである。データ処理用セマフォは、データ処理用スレッド103の動作を制御するためのセマフォである。送信処理用セマフォは、送信処理用スレッド104の動作を制御するためのセマフォである。
図12の説明に戻り、初期化処理部101は、管理テーブルにおけるプロセス停止フラグを”OFF”に設定する(ステップS7)。
初期化処理部101は、データ処理用スレッド103を、管理テーブルに格納されたデータ処理用スレッドの数だけ生成する(ステップS9)。初期化処理部101は、送信処理用スレッド104を、管理テーブルに格納された通信処理用スレッドの数だけ生成する(ステップS11)。初期化処理部101は、受信処理用スレッド102を、管理テーブルに格納された通信処理用スレッドの数だけ生成する(ステップS13)。
初期化処理部101は、コマンド受付処理を実行する(ステップS15)。コマンド受付処理については、図15を用いて説明する。
まず、初期化処理部101は、受信イベントが発生したか判断する(図15:ステップS21)。受信イベントとは、例えば管理者等からコマンドの入力を受け付けるというイベントである。受信イベントが発生していない場合(ステップS21:Noルート)、ステップS21の処理に戻る。一方、受信イベントが発生した場合(ステップS21:Yesルート)、初期化処理部101は、プロセス停止コマンドを受信したか判断する(ステップS23)。
プロセス停止コマンドを受信していない場合(ステップS23:Noルート)、ステップS21の処理に戻る。一方、プロセス停止コマンドを受信した場合(ステップS23:Yesルート)、初期化処理部101は、管理テーブルにおけるプロセス停止フラグに”ON”を設定する(ステップS25)。
初期化処理部101は、サーバ10のプロセスを停止するための処理を実行する(ステップS27)。そして呼び出し元の処理に戻り、処理を終了する。
以上のような処理を実行すれば初期化が完了し、クライアント端末30及び31から受信した処理要求に対して処理を行えるようになる。
次に、図16乃至図22を用いて、受信処理用スレッド102が実行する受信処理について説明する。まず、受信処理用スレッド102は、ローカル変数「結果コード」に”正常”を設定(図16:ステップS31)し、変数「処理番号」に0を設定する(ステップS33)。以下ではローカル変数を変数「***」のように表す。テーブル等の値及びグローバル変数については括弧を付さない。
受信処理用スレッド102は、クライアント端末30又は31から処理要求を受信したか判断する(ステップS35)。処理要求を受信していない場合(ステップS35:Noルート)、処理は端子Aを介して図22のステップS75の処理に移行する。端子A以降については後で説明する。
図17に、処理要求の一例を示す。図17の例では、処理要求は、制御データと要求本体とを含む。制御データは、サーバのIPアドレスと、サーバのポート番号と、クライアントIDと、要求番号と、クライアント端末のIPアドレスと、クライアント端末のポート番号と、クライアント端末において実行されているプロセスのプロセスIDと、クライアント端末において実行されているスレッドのスレッドIDと、セッションIDと、処理要求の送信時刻とを含む。要求本体は、処理種別と、処理要求の対象と、入力情報と、出力情報とを含む。セッションIDは、コネクションの確立時にサーバからクライアント端末に通知されるIDである。入力情報は、データ処理の実行に用いる情報である。出力情報は、データ処理の対象となる部分を指定する情報である。
図16の説明に戻り、処理要求を受信した場合(ステップS35:Yesルート)、受信処理用スレッド102は、例えばシステム時計等から現在時刻を取得し、変数「受信時刻」に設定する(ステップS37)。
受信処理用スレッド102は、管理データ格納部105に格納された要求管理テーブルの排他を獲得する(ステップS39)。
図18に、要求管理テーブルに格納されるデータの一例を示す。図18の例では、排他情報と、要求番号と、予約番号と、実行番号と、実行済番号とが格納される。ステップS39においては、例えば、要求管理テーブルにおける排他情報に排他を獲得したことを表す値を設定する。排他を獲得した受信処理用スレッド102は、要求管理テーブルの参照及び更新を行えるようになる。
図16の説明に戻り、受信処理用スレッド102は、変数「処理番号」が0であるか判断する(ステップS41)。変数「処理番号」が0ではない場合(ステップS41:Noルート)、ステップS45の処理に移行する。変数「処理番号」が0である場合(ステップS41:Yesルート)、受信処理用スレッド102は、要求管理テーブルにおける予約番号を1インクリメントし、予約番号を変数「処理番号」に設定する(ステップS43)。
受信処理用スレッド102は、要求管理テーブルにおける実行済番号を、変数「実行済番号」に設定する(ステップS45)。
受信処理用スレッド102は、要求管理テーブルの排他を解除する(ステップS47)。ステップS47においては、例えば、要求管理テーブルにおける排他情報に、排他が解除されていることを表す値を設定する。処理は端子Bを介して図19のステップS49の処理に移行する。
図19の説明に移行し、受信処理用スレッド102は、(変数「処理番号」の値−変数「実行済番号」の値)>(管理テーブルにおける最大バッファ数)が成立するか判断する(ステップS49)。成立しない場合(ステップS49:Noルート)、処理は端子Cを介して図20のステップS63の処理に移行する。成立する場合(ステップS49:Yesルート)、受信処理用スレッド102は、管理データ格納部105に格納された受信処理用のセマフォに、ロックを表す値を設定する(ステップS51)。
受信処理用スレッド102は、所定時間(例えば、100ミリ秒)が経過したか又は受信処理用のセマフォにアンロックを表す値が設定されるまで休止する(ステップS53)。後で説明するが、受信処理用のセマフォにはデータ処理においてアンロックを表す値が設定される。
所定時間が経過したか又は受信処理用のセマフォにアンロックを表す値が設定された場合、受信処理用スレッド102は、例えばシステム時計等から現在時刻を取得し、変数「現在時刻」に設定する(ステップS55)。
受信処理用スレッド102は、変数「受信時刻」の値から変数「現在時刻」の値までの時間を算出する(ステップS57)。
受信処理用スレッド102は、タイムアウトしたか判断する(ステップS59)。ステップS59においては、ステップS57において算出された時間が管理テーブルにおけるサーバタイムアウトまでの時間より長いか判断する。タイムアウトしていない場合(ステップS59:Noルート)、処理は端子Dを介して図16のステップS39の処理に戻る。
一方、タイムアウトした場合(ステップS59:Yesルート)、受信処理用スレッド102は、変数「結果コード」に”タイムアウト”を設定する(ステップS61)。処理は端子Dを介して図16のステップS39の処理に戻る。
図20の端子C以降の処理について説明する。受信処理用スレッド102は、処理要求格納部106における1乃至N(Nは最大バッファ数)の番号に対応する領域のうち、変数「処理番号」の値%最大バッファ数に対応する領域について排他を獲得する(図20:ステップS63)。ここで「%」は剰余を求める演算子である。例えば変数「処理番号」の値が102であり、最大バッファ数が100である場合、剰余である2に1を加えた「3」に対応する領域について排他を獲得する。
図21に、処理要求格納部106に格納されるデータの一例を示す。図21の例では、排他情報の領域と、受付時刻の領域と、結果コードの領域と、クライアントIDの領域と、バッファの領域とがそれぞれN個設けられている。結果コードについては、0は”正常”を表し1は”タイムアウト”を表す。
図20の説明に戻り、受信処理用スレッド102は、ステップS63において排他を獲得したバッファに処理要求を格納する(ステップS65)。受信処理用スレッド102は、ステップS63において排他を獲得した領域に変数「受付時刻」の値を格納する(ステップS67)。受信処理用スレッド102は、ステップS63において排他を獲得した領域に、処理要求の送信元のクライアントIDを格納する(ステップS69)。受信処理用スレッド102は、ステップS63において排他を獲得した領域に、変数「結果コード」の値を格納する(ステップS71)。
受信処理用スレッド102は、処理要求格納部106の排他を解除する(ステップS73)。処理は端子Aを介して図22のステップS75の処理に移行する。
図22の説明に移行し、受信処理用スレッド102は、要求管理テーブルの排他を獲得し(図22:ステップS75)、要求管理テーブルにおける要求番号を1インクリメントする(ステップS77)。そして、受信処理用スレッド102は、要求管理テーブルの排他を解除する(ステップS79)。
受信処理用スレッド102は、管理データ格納部105におけるデータ処理用のセマフォにアンロックを表す値を設定する(ステップS81)。
受信処理用スレッド102は、管理テーブルにおけるプロセス停止フラグに”OFF”が設定されているか判断する(ステップS83)。プロセス停止フラグに”ON”が設定されている場合(ステップS83:Noルート)、プロセス停止コマンドを受信したので、受信処理を終了する。
一方、プロセス停止フラグに”OFF”が設定されている場合(ステップS83:Yesルート)、受信処理用スレッド102は、変数「処理番号」の値が0であるか判断する(ステップS85)。
変数「処理番号」の値が0ではない場合(ステップS85:Noルート)、処理は端子Eを介して図16のステップS31に戻る。一方、変数「処理番号」の値が0である場合(ステップS85:Yesルート)、受信処理用スレッド102は、所定時間(例えば、100ミリ秒)が経過したか又は処理要求を受信するまで待機する(ステップS87)。
所定時間が経過したか又は処理要求を受信した場合、処理は端子Eを介して図16のステップS31に戻る。
以上のような処理を実行すれば、処理要求格納部106のバッファに格納された処理要求に対してデータ処理を行えるようになる。また、処理要求格納部106をサイクリックに使用できるようになる。
次に、図23乃至図38を用いて、データ処理用スレッド103が実行するデータ処理について説明する。
まず、データ処理用スレッド103は、ローカル変数の値の初期化を行う(図23:ステップS91)。具体的には、データ処理において使用するローカル変数に0を設定する。但し、変数「制御データサイズ」については所定の値を設定し、変数「ブロックサイズ」については変数「ブロックサイズ」の値=管理テーブルに格納されたバッファサイズ−変数「制御データサイズ」の値−共通制御データのサイズとする。共通制御データとは、複数の処理結果を統合した際に処理結果に付加される制御データである。
データ処理用スレッド103は、要求管理テーブルの排他を獲得する(ステップS93)。
データ処理用スレッド103は、要求管理テーブルにおける要求番号が要求管理テーブルにおける実行番号より大きいか判断する(ステップS95)。要求管理テーブルにおける要求番号が要求管理テーブルにおける実行番号以下である場合(ステップS95:Noルート)、ステップS99の処理に移行する。
一方、要求管理テーブルにおける要求番号が要求管理テーブルにおける実行番号より大きい場合(ステップS95:Yesルート)、次の処理要求について処理するため、データ処理用スレッド103は、要求管理テーブルにおける実行番号を1インクリメントし、変数「処理番号」に設定する(ステップS97)。
データ処理用スレッド103は、要求管理テーブルの排他を解除する(ステップS99)。
データ処理用スレッド103は、変数「処理番号」の値が0であるか判断する(ステップS101)。変数「処理番号」の値が0である場合(ステップS101:Yesルート)、処理は端子Fを介して図38のステップS265の処理に移行する。
一方、変数「処理番号」の値が0ではない場合(ステップS101:Noルート)、処理は端子Gを介して図24のステップS103の処理に移行する。
図24の説明に移行し、データ処理用スレッド103は、処理要求格納部106における1乃至N(Nは最大バッファ数)の番号に対応する領域のうち、変数「処理番号」の値%最大バッファ数に対応する領域の排他を獲得する(図24:ステップS103)。
データ処理用スレッド103は、排他が獲得された領域における処理要求を変数「処理要求」に設定する(ステップS105)。データ処理用スレッド103は、排他が獲得された領域における結果コードを変数「結果コード」に設定する(ステップS107)。データ処理用スレッド103は、排他が獲得された領域におけるクライアントIDを変数「クライアントID」に設定する(ステップS109)。
データ処理用スレッド103は、処理要求格納部106の排他を解除する(ステップS111)。処理は端子Hを介して図25のS113の処理に移行する。
図25の説明に移行し、データ処理用スレッド103は、変数「結果コード」の値は”タイムアウト”であるか判断する(図25:ステップS113)。
変数「結果コード」の値は”タイムアウト”である場合(ステップS113:Yesルート)、データ処理用スレッド103は、タイムアウトを表す値を変数「結果本体」に設定する(ステップS115)。そしてステップS121の処理に移行する。
変数「結果コード」の値は”タイムアウト”ではない場合(ステップS113:Noルート)、データ処理用スレッド103は、変数「処理要求」の値に基づき、データ格納部108に格納されたデータに対する処理を実行する(ステップS117)。
データ処理用スレッド103は、ステップS117における実行により得られたデータを、変数「結果本体」に設定する(ステップS119)。
データ処理用スレッド103は、変数「結果本体」に設定されたデータサイズを、変数「結果サイズ」に設定する(ステップS121)。データ処理用スレッド103は、変数「処理要求」に含まれる処理種別を変数「処理種別」に設定する(ステップS123)。
データ処理用スレッド103は、要求管理テーブルの排他を獲得し(ステップS125)、要求管理テーブルにおける実行済番号を1インクリメントする(ステップS127)。そして、データ処理用スレッド103は、要求管理テーブルの排他を解除する(ステップS129)。
データ処理用スレッド103は、管理データ格納部105における受信処理用のセマフォに、アンロックを表す値を設定する(ステップS131)。処理は端子Iを介して図26のステップS133の処理に移行する。
図26の説明に移行し、データ処理用スレッド103は、管理データ格納部105に格納されたデータ結果管理テーブルの排他を獲得する(図26:ステップS133)。
図27に、結果管理テーブルの一例を示す。図27の例では、排他情報と、送信済番号と、結果番号と、予約番号とが格納される。また、各宛先について、クライアントIDと、最終番号と、空領域のサイズとが格納される。最終番号は、或る宛先についての処理結果のうち最後にバッファに格納された処理結果の番号であり、空領域のサイズとは、そのバッファの空領域のサイズである。
図26の説明に戻り、データ処理用スレッド103は、変数「処理種別」の値は、処理要求が接続要求であることを表すか判断する(ステップS135)。変数「処理種別」の値は処理要求が接続要求であることを表していない場合(ステップS135:Noルート)、ステップS145の処理に移行する。
変数「処理種別」の値は処理要求が接続要求であることを表す場合(ステップS135:Yesルート)、データ処理用スレッド103は、変数「クライアントID」の値を結果管理テーブルに登録済みであるか判断する(ステップS137)。登録済みである場合(ステップS137:Yesルート)、ステップS145の処理に移行する。
変数「クライアントID」の値を結果管理テーブルに登録済みではない場合(ステップS137:Noルート)、データ処理用スレッド103は、変数「クライアントID」の値を結果管理テーブルに登録する(ステップS139)。
データ処理用スレッド103は、変数「クライアントID」の値に対応する最終番号に0を設定する(ステップS141)。データ処理用スレッド103は、変数「クライアントID」の値に対応する空領域サイズに0を設定する(ステップS143)。
データ処理用スレッド103は、変数「クライアントID」の値に対応する最終番号を、変数「最終番号」に設定する(ステップS145)。データ処理用スレッド103は、変数「クライアントID」に対応する空領域サイズを、変数「空領域サイズ」に設定する(ステップS147)。処理は端子Jを介して図28のステップS149の処理に移行する。
図28の説明に移行し、データ処理用スレッド103は、変数「最終番号」の値≠0且つ変数「空領域サイズ」の値≠0が成立するか判断する(ステップS149)。変数「最終番号」の値≠0且つ変数「空領域サイズ」の値≠0が成立しない場合(ステップS149:Noルート)、処理は端子Nを介して図31のステップS177の処理に移行する。
変数「最終番号」の値≠0且つ変数「空領域サイズ」の値≠0が成立する場合(ステップS149:Yesルート)、データ処理用スレッド103は、結果管理テーブルから送信済番号を読み出し、管理テーブルから通信スレッドの数を読み出す。そして、データ処理用スレッド103は、(変数「最終番号」の値−送信済番号)>通信スレッドの数が成立するか判断する(ステップS151)。
(変数「最終番号」の値−送信済番号)>通信スレッドの数が成立しない場合(ステップS151:Noルート)、統合処理を実行しないので、処理は端子Nを介して図31のステップS177の処理に移行する。
(変数「最終番号」の値−送信済番号)>通信スレッドの数が成立する場合(ステップS151:Yesルート)、統合処理を実行するので、データ処理用スレッド103は、変数「更新番号」に変数「最終番号」の値を設定する(ステップS153)。
データ処理用スレッド103は、変数「空領域サイズ」の値≧(変数「結果サイズ」の値+変数「制御データサイズ」の値)が成立するか判断する(ステップS155)。変数「空領域サイズ」の値≧(変数「結果サイズ」の値+変数「制御データサイズ」の値)が成立する場合(ステップS155:Yesルート)、処理は端子Kを介して図29のステップS157の処理に移行する。一方、変数「空領域サイズ」の値≧(変数「結果サイズ」の値+変数「制御データサイズ」の値)が成立しない場合(ステップS155:Noルート)、処理は端子Lを介して図30のステップS165の処理に移行する。
図29の説明に移行し、データ処理用スレッド103は、変数「更新サイズ」に、変数「結果サイズ」の値と変数「制御データサイズ」の値との和を設定する(図29:ステップS157)。
データ処理用スレッド103は、変数「更新位置」に、管理テーブルに格納されたバッファサイズから変数「空領域サイズ」の値を引いた値を設定する(ステップS159)。
データ処理用スレッド103は、変数「クライアントID」の値に対応する空領域サイズから、変数「結果サイズ」の値と変数「制御データサイズ」の値との和を差し引く(ステップS161)。
データ処理用スレッド103は、変数「結果サイズ」に0を設定する(ステップS163)。処理は端子Mを介して図31のステップS185の処理に移行する。
図30の端子L以降の処理について説明する。データ処理用スレッド103は、変数「結果サイズ」の値≦変数「制御データサイズ」の値が成立するか判断する(図30:ステップS165)。
変数「結果サイズ」の値≦変数「制御データサイズ」の値が成立する場合(ステップS165:Yesルート)、データ処理用スレッド103は、変数「更新番号」に0を設定する(ステップS167)。処理は端子Nを介して図31のステップS177の処理に移行する。
変数「結果サイズ」の値≦変数「制御データサイズ」の値が成立しない場合(ステップS165:Noルート)、データ処理用スレッド103は、変数「更新サイズ」に変数「空領域サイズ」の値を設定する(ステップS169)。
データ処理用スレッド103は、変数「更新位置」に、管理テーブルに格納されたバッファサイズ−変数「空領域サイズ」の値を設定する(ステップS171)。
データ処理用スレッド103は、結果管理テーブルにおいて変数「クライアントID」の値に対応付けられている空領域サイズに0を設定する(ステップS173)。
データ処理用スレッド103は、変数「結果サイズ」に、(変数「結果サイズ」の値−変数「更新サイズ」の値+変数「制御データサイズ」の値)を設定する(ステップS175)。処理は端子Nを介して図31のステップS177の処理に移行する。
図31の説明に移行し、データ処理用スレッド103は、変数「追加ブロック数」に、(変数「結果サイズ」の値÷変数「ブロックサイズ」の値)の整数部分を設定する(図31:ステップS177)。
データ処理用スレッド103は、変数「最終ブロックサイズ」に、(変数「結果サイズ」の値%変数「ブロックサイズ」の値)を設定する(ステップS179)。
データ処理用スレッド103は、変数「最終ブロックサイズ」の値が0であるか判断する(ステップS181)。変数「最終ブロックサイズ」の値が0である場合(ステップS181:Yesルート)、ステップS185の処理に移行する。
変数「最終ブロックサイズ」の値が0ではない場合(ステップS181:Noルート)、データ処理用スレッド103は、変数「追加ブロック数」の値を1インクリメントする(ステップS183)。
データ処理用スレッド103は、結果管理テーブルの排他を解除する(ステップS185)。処理は端子Oを介して図32のステップS187の処理に移行する。
図32の説明に移行し、データ処理用スレッド103は、変数「更新番号」の値が0であるか判断する(図32:ステップS187)。
変数「更新番号」の値が0である場合(ステップS187:Yesルート)、処理は端子Pを介して図34のステップS203の処理に移行する。
変数「更新番号」の値が0ではない場合(ステップS187:Noルート)、データ処理用スレッド103は、処理結果格納部107における1乃至N(Nは最大バッファ数)の番号に対応する領域のうち、変数「更新番号」の値%最大バッファ数に対応する領域の排他を獲得する(ステップS189)。
図33に、処理結果格納部107に格納されるデータの一例を示す。図33の例では、排他情報の領域と、受付時刻の領域と、結果コードの領域と、クライアントIDの領域と、バッファの領域とがそれぞれN個設けられている。結果コードについては、0は”正常”を表し1は”タイムアウト”を表す。
図32の説明に戻り、データ処理用スレッド103は、排他が獲得されたバッファにおいて、変数「更新位置」の値が表す位置を特定する(ステップS191)。
データ処理用スレッド103は、ステップS191において特定された位置に、処理結果に対応する処理要求に基づく制御データを格納する(ステップS193)。ここで、もし変数「追加ブロック数」の値が1以上である場合、制御データに含まれる「状態」の項目に未完了を表す値(例えば1)を設定する。
データ処理用スレッド103は、ステップS193において設定された制御データの後に、変数「結果本体」の値を(変数「更新サイズ」の値−変数「制御データサイズ」の値)の分だけ格納する(ステップS195)。
データ処理用スレッド103は、処理結果格納部107の排他を解除する(ステップS197)。
データ処理用スレッド103は、変数「更新位置」に0を設定する(ステップS199)。データ処理用スレッド103は、変数「オフセット」に変数「更新サイズ」の値を設定する(ステップ201)。処理は端子Pを介して図34のステップS203の処理に移行する。
図34の説明に移行し、データ処理用スレッド103は、変数「カウンタ」の値に0を設定する(図34:ステップS203)。データ処理用スレッド103は、変数「追加番号」に0を設定する(ステップS205)。
データ処理用スレッド103は、変数「カウンタ」の値<変数「追加ブロック数」の値が成立するか判断する(ステップS207)。変数「カウンタ」の値<変数「追加ブロック数」の値が成立しない場合(ステップS207:Noルート)、処理は端子Fを介して図38のステップS265の処理に移行する。
変数「カウンタ」の値<変数「追加ブロック数」の値が成立する場合(ステップS207:Yesルート)、データ処理用スレッド103は、結果管理テーブルの排他を獲得する(ステップS209)。
データ処理用スレッド103は、変数「追加ブロック数」の値が0であるか判断する(ステップS211)。変数「追加ブロック数」の値が0ではない場合(ステップS211:Noルート)、ステップS215の処理に移行する。
変数「追加ブロック数」の値が0である場合(ステップS211:Yesルート)、データ処理用スレッド103は、結果管理テーブルにおける予約番号を1インクリメントし、変数「追加番号」に設定する(ステップS213)。
データ処理用スレッド103は、変数「送信済番号」に、結果管理テーブルにおける送信済番号を設定する(ステップS215)。処理は端子Qを介して図35のステップS217の処理に移行する。
図35の説明に移行し、データ処理用スレッド103は、(変数「追加番号」の値−変数「送信済番号」の値)≦最大バッファ数が成立するか判断する(図35:ステップS217)。
(変数「追加番号」の値−変数「送信済番号」の値)≦最大バッファ数が成立しない場合(ステップS217:Noルート)、ステップS227の処理に移行する。
(変数「追加番号」の値−変数「送信済番号」の値)≦最大バッファ数が成立する場合(ステップS217:Yesルート)、データ処理用スレッド103は、結果管理テーブルにおける、変数「クライアントID」の値に対応する最終番号に、結果管理テーブルにおける予約番号を設定する(ステップS219)。
データ処理用スレッド103は、変数「カウンタ」の値が、(変数「追加ブロック数」の値−1)であるか判断する(ステップS221)。
変数「カウンタ」の値が(変数「追加ブロック数」の値−1)である場合(ステップS221:Yesルート)、データ処理用スレッド103は、変数「クライアントID」の値に対応する空領域サイズに、(変数「ブロックサイズ」の値−変数「最終ブロックサイズ」の値)を設定する(ステップS223)。そしてステップS227の処理に移行する。
変数「カウンタ」の値が(変数「追加ブロック数」の値−1)ではない場合(ステップS221:Noルート)、データ処理用スレッド103は、変数「クライアントID」の値に対応する空領域サイズに0を設定する(ステップS225)。そして、データ処理用スレッド103は、結果管理テーブルの排他を解除する(ステップS227)。
データ処理用スレッド103は、変数「追加番号」の値−変数「送信済番号」の値≦最大バッファ数が成立するか判断する(ステップS229)。
変数「追加番号」の値−変数「送信済番号」の値≦最大バッファ数が成立する場合(ステップS229:Yesルート)、処理は端子Rを介して図36のステップS231の処理に移行する。変数「追加番号」の値−変数「送信済番号」の値≦最大バッファ数が成立しない場合(ステップS229:Noルート)、処理は端子Sを介して図34のステップS209の処理に戻る。
図36の説明に移行し、データ処理用スレッド103は、処理結果格納部107における1乃至N(Nは最大バッファ数)の番号に対応する領域のうち、変数「追加番号」の値%最大バッファ数に対応する領域の排他を獲得する(図36:ステップS231)。そして、データ処理用スレッド103は、ステップS231において排他が獲得されたバッファに、共通制御データを設定する(ステップS233)。
データ処理用スレッド103は、変数「カウンタ」の値が、(変数「追加ブロック数」の値−1)であるか判断する(ステップS235)。
変数「カウンタ」の値が(変数「追加ブロック数」の値−1)である場合(ステップS235:Yesルート)、データ処理用スレッド103は、共通制御データの後に、「状態」の項目に完了を表す値が設定された、処理要求に基づく制御データを格納する(ステップS239)。
データ処理用スレッド103は、制御データの後に、変数「結果本体」の値を、変数「オフセット」の値が示す位置から変数「最終ブロックサイズ」の値の分だけ格納する(ステップS241)。
データ処理用スレッド103は、変数「オフセット」に、変数「オフセット」の値と変数「最終ブロックサイズ」の値との和を設定する(ステップS243)。そしてステップS253の処理に移行する。
一方、変数「カウンタ」の値が(変数「追加ブロック数」の値−1)ではない場合(ステップS235:Noルート)、データ処理用スレッド103は、共通制御データの後に、「状態」の項目に未完了を表す値が設定された、処理要求に基づく制御データを格納する(ステップS247)。
データ処理用スレッド103は、制御データの後に、変数「結果本体」の値を、変数「オフセット」の値が示す位置から変数「ブロックサイズ」の値の分だけ格納する(ステップS249)。
データ処理用スレッド103は、変数「オフセット」に、変数「オフセット」の値と変数「ブロックサイズ」の値との和を設定する(ステップS251)。
データ処理用スレッド103は、処理結果格納部107の排他を解除する(ステップS253)。処理は端子Tを介して図37のステップS255の処理に移行する。
図37の説明に移行し、データ処理用スレッド103は、結果管理テーブルの排他を獲得し(ステップS255)、結果管理テーブルにおける結果番号を1インクリメントする(ステップS257)。そして、データ処理用スレッド103は、結果管理テーブルの排他を解除する(ステップS259)。
データ処理用スレッド103は、管理データ格納部105に格納された送信処理用のセマフォに、アンロックを表す値を設定する(ステップS261)。
データ処理用スレッド103は、変数「カウンタ」の値を1インクリメントする(ステップS263)。処理は端子Uを介して図34のステップS205の処理に戻る。
図38の端子F以降の処理について説明する。データ処理用スレッド103は、管理テーブルにおけるプロセス停止フラグに”OFF”が設定されているか判断する(ステップS265)。プロセス停止フラグに”ON”が設定されている場合(ステップS265:Noルート)、プロセス停止コマンドを受信したので、データ処理を終了する。
一方、プロセス停止フラグに”OFF”が設定されている場合(ステップS265:Yesルート)、データ処理用スレッド103は、変数「更新番号」の値=0且つ変数「追加番号」の値=0が成立するか判断する(ステップS267)。
変数「更新番号」の値=0且つ変数「追加番号」の値=0が成立しない場合(ステップS267:Noルート)、処理は端子Vを介して図23のステップS91に戻る。一方、変数「更新番号」の値=0且つ変数「追加番号」の値=0が成立する場合(ステップS267:Yesルート)、データ処理用スレッド103は、データ処理用のセマフォにロックを表す値を設定する(ステップS269)。
データ処理用スレッド103は、所定時間(例えば、100ミリ秒)が経過したか又はデータ処理用のセマフォにアンロックを表す値が設定されるまで休止する(ステップS271)。
所定時間が経過したか又はデータ処理用のセマフォにアンロックを表す値が設定された場合、処理は端子Vを介して図23のステップS91に戻る。
以上のような処理を実行すれば、送信処理用スレッドの処理状況に応じて統合処理の対象である処理結果が決定されるので、統合処理が原因で応答性能が劣化するのを抑制できるようになる。
また、最終番号についての処理結果が格納された領域の空領域のサイズを管理するので、空領域のチェックのために使用する記憶領域のサイズが小さくなる。また、空領域を探すためにバッファ全体をチェックすることが無いので、送信処理用スレッド104が排他の獲得のために待つことになるのを抑制できる。さらに、送信処理用スレッド104の数を上回る分の処理結果のうち最終番号についての処理結果を統合処理の対象としているので、統合処理が送信処理用スレッド104の処理の邪魔をしてしまう可能性が低くくなる。
次に、図39乃至図42を用いて、送信処理用スレッド104が実行する送信処理について説明する。
まず、送信処理用スレッド104は、変数「処理番号」に0を設定する(図39:ステップS281)。
送信処理用スレッド104は、管理データ格納部105に格納された結果管理テーブルの排他を獲得する(ステップS283)。そして、送信処理用スレッド104は、結果管理テーブルにおいて、結果番号>予約番号が成立するか判断する(ステップS285)。
結果番号>予約番号が成立しない場合(ステップS285:Noルート)、ステップS289の処理に移行する。結果番号>予約番号が成立する場合(ステップS285:Yesルート)、送信処理用スレッド104は、結果管理テーブルにおける予約番号を1インクリメントし、変数「処理番号」に設定する(ステップS287)。
送信処理用スレッド104は、結果管理テーブルの排他を解除する(ステップS289)。処理は端子Wを介して図40のステップS291の処理に移行する。
図40の説明に移行し、送信処理用スレッド104は、変数「処理番号」の値は0であるか判断する(図40:ステップS291)。変数「処理番号」の値が0である場合(ステップS291:Yesルート)、処理は端子Xを介して図42のステップS309の処理に移行する。
変数「処理番号」の値が0ではない場合(ステップS291:Noルート)、送信処理用スレッド104は、処理結果格納部107における1乃至N(Nは最大バッファ数)の番号に対応する領域のうち、変数「処理番号」の値%最大バッファ数に対応する領域の排他を獲得する(ステップS293)。
送信処理用スレッド104は、排他が獲得された領域のバッファから処理結果を取り出し(ステップS295)、処理結果格納部107の排他を解除する(ステップS297)。
送信処理用スレッド104は、ステップS295において取り出された処理結果を、宛先のクライアント端末に送信する(ステップS299)。
図41に、処理結果の一例を示す。図41の例では、統合された複数の処理結果に、共通制御データが付加されている。処理結果は、制御データと、結果本体とを含む。制御データは、結果番号と、要求番号と、クライアント端末において実行されているプロセスのプロセスIDと、クライアント端末において実行されているスレッドのスレッドIDと、セッションIDと、処理要求の送信時刻と、処理結果の送信時刻と、状態に関する値とを含む。結果本体は、結果本体のサイズの情報と、結果とを含む。共通制御データは、クライアント端末のIPアドレスと、クライアント端末のポート番号と、クライアントIDと、クライアント端末のIPアドレスと、処理結果の数とを含む。処理結果の送信時刻は、例えば、送信処理用スレッド104が実際に処理結果を送信する際に設定される。
送信処理用スレッド104は、結果管理テーブルの排他を獲得し(ステップS301)、送信済番号を1インクリメントする(ステップS303)。そして、送信処理用スレッド104は、結果管理テーブルの排他を解除する(ステップS305)。
送信処理用スレッド104は、送信処理用のセマフォに、アンロックを表す値を設定する(ステップS307)。処理は端子Xを介して図42のステップS309の処理に移行する。
図42の説明に移行し、送信処理用スレッド104は、管理テーブルにおけるプロセス停止フラグに”OFF”が設定されているか判断する(ステップS309)。プロセス停止フラグに”ON”が設定されている場合(ステップS309:Noルート)、プロセス停止コマンドを受信したので、送信処理を終了する。
一方、プロセス停止フラグに”OFF”が設定されている場合(ステップS309:Yesルート)、データ処理用スレッド103は、変数「処理番号」の値は0であるか判断する(ステップS311)。
変数「処理番号」の値は0ではない場合(ステップS311:Noルート)、処理は端子Yを介して図39のステップS281の処理に戻る。一方、変数「処理番号」の値が0である場合(ステップS311:Yesルート)、送信処理用スレッド104は、送信処理用のセマフォにロックを表す値を設定する(ステップS313)。
送信処理用スレッド104は、所定時間(例えば、100ミリ秒)が経過したか又は送信処理用のセマフォにアンロックを表す値が設定されるまで休止する(ステップS315)。
所定時間が経過したか又は送信処理用のセマフォにアンロックを表す値が設定された場合、処理は端子Yを介して図39のステップS281の処理に戻る。
以上のような処理を実行すれば、処理要求の送信元のクライアント端末に処理結果を送り返せるようになる。
なお、本実施の形態においてはセマフォを用いているので、格納場所に空きを生じさせたスレッド等が、データの格納を行うスレッド等に、格納場所が空いたことを伝えることができる。従って、格納場所に空きができたタイミングとデータが格納されるタイミングとの間のタイムラグが生じにくい。もしセマフォを用いない場合には、データの格納を行うスレッド等が、格納場所が空いているか否か定期的にチェックすることになる。そのため、格納場所が空いてから実際にデータが格納されるまでの時間が本実施の形態と比較して長くなる。
また、処理要求格納部106及び処理結果格納部107はN個に分けられているため、排他の対象となる領域を最小限にすることができる。従って、排他制御によりスレッドの処理が滞ることを抑制できる。
さらに、宛先が同じである複数の処理結果の合計のデータ量は、送信処理用スレッド104が一度に送信可能なデータ量以下になるので、送信処理用スレッド104は効率的に送信処理を行うことができるようになる。
なお、サーバ11及び12が実行する処理はサーバ10が実行する処理と同様であるので、説明を省略する。
次に、図43乃至図46を用いて、クライアント端末30が実行する処理について説明する。
まず、クライアント端末30の管理部301は、定義ファイル格納部303からパラメタの値を読み出し、管理データ格納部304に格納された管理テーブルに格納する(図43:ステップS321)。
管理部301は、クライアント端末30のIPアドレス又はマシン名を取得し、管理データ格納部304に格納された管理テーブルに格納する(ステップS323)。
なお、ステップS321及びS323は初回のみ実行される処理であるため、ステップS321及びS323のブロックは点線で示されている。
図44に、クライアント端末30の管理テーブルに格納されるデータの一例を示す。図44の例では、クライアントIDと、送信先のサーバのIPアドレスと、送信先のサーバのポート番号と、クライアントタイムアウトの時間と、クライアント端末30のIPアドレスと、クライアント端末30において使用されるポート番号とが格納される。なお、IPアドレスの代わりにホスト名が格納されてもよい。
図43の説明に戻り、管理部301は、例えばシステム時計等から現在時刻を取得し、変数「開始時刻」に設定する(ステップS325)。
管理部301は、管理データ格納部304に格納された要求管理テーブルの排他を獲得する(ステップS327)。図45に、クライアント端末30の要求管理テーブルに格納されるデータの一例を示す。図45の例では、排他情報と、要求番号とが格納される。
管理部301は、要求管理テーブルにおける要求番号を1インクリメントし、変数「要求番号」に設定する(ステップS329)。
管理部301は、要求管理テーブルの排他を解除する(ステップS331)。
管理部301は、クライアントプロセス32から受け取った要求本体と制御データとを含む処理要求を生成し、宛先のサーバに送信する(ステップS333)。制御データは、管理テーブルに格納されたクライアントID、サーバのマシン名又はIPアドレス、サーバのポート番号、クライアント端末30のマシン名又はIPアドレス、クライアント端末30において使用されるポート番号、及び変数「要求番号」等を含む。処理要求は、図17に示したとおりである。
管理部301は、所定の時間(例えば、クライアントタイムアウトの時間の10分の1)が経過したか又はデータを受信するまで休止する(ステップS335)。所定の時間が経過したか又はデータを受信した場合、処理は端子Zを介して図46のステップS337に移行する。
図46の説明に移行し、管理部301は、受信したデータが、処理要求の宛先のサーバからの処理結果であるか判断する(図46:ステップS337)。処理結果である場合(ステップS337:Yesルート)、管理部301は、処理結果から結果本体を取り出し、返却域に追加で格納する(ステップS339)。返却域とは、クライアントプロセス32にデータを渡すための領域である。
管理部301は、処理結果に含まれる制御データが「未完了」を表すか判断する(ステップS341)。処理結果に含まれる制御データは、「未完了」又は「完了」のいずれかを表す値を含む。処理結果に含まれる制御データが「未完了」を表す場合(ステップS341:Yesルート)、後続の処理結果があるため、ステップS337の処理に戻る。
処理結果に含まれる制御データが「完了」を表す場合(ステップS341:Noルート)、後続のデータが無いため、管理部301は、結果本体が表す結果を表す値を復帰値に設定する(ステップS343)。そしてクライアントプロセス32に復帰し、処理を終了する。
一方、処理結果ではない場合(ステップS337:Noルート)、管理部301は、例えばシステム時計から現在時刻を取得し、変数「現在時刻」に設定する(ステップS345)。
管理部301は、変数「開始時刻」の値から変数「現在時刻」の値までの時間を算出する(ステップS347)。
管理部301は、タイムアウトしたか判断する(ステップS349)。ステップS349においては、ステップS347において算出された時間が管理テーブルにおけるクライアントタイムアウトまでの時間より長いか判断する。タイムアウトしていない場合(ステップS349:Noルート)、ステップS337の処理に戻る。
一方、タイムアウトした場合(ステップS349:Yesルート)、管理部301は、タイムアウトを表す値を復帰値に設定する(ステップS351)。そしてクライアントプロセス32に復帰し、処理を終了する。
以上のような処理を実行すれば、処理結果を複数回に分けて受信する場合であっても、クライアントプロセス32に適切に結果本体を渡せるようになる。
なお、クライアント端末31が実行する処理はクライアント端末30が実行する処理と同様であるので、説明を省略する。
以上本発明の一実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、上で説明したサーバ10及びクライアント端末30の機能ブロック構成は実際のプログラムモジュール構成に一致しない場合もある。
また、上で説明したデータ保持構成は一例であって、上記のような構成でなければならないわけではない。さらに、処理フローにおいても、処理結果が変わらなければ処理の順番を入れ替えることも可能である。さらに、並列に実行させるようにしても良い。
なお、クライアントIDは、処理要求が接続要求である場合に動的に生成しても良いし、定義ファイルにおけるパラメタ”MaxClientID”の値に基づき静的に生成してもよい。
また、クライアントIDから最終番号及び空領域サイズを特定するのを高速化するため、クライアントIDをキーとし最終番号及び空領域サイズを値とした、ハッシュテーブル又はB−Treeを利用してもよい。
また、時間の情報を管理テーブルに予め格納しておき、上記の「所定時間」として使用してもよい。
なお、上で述べたサーバ10乃至12並びにクライアント端末30及び31は、コンピュータ装置であって、図47に示すように、メモリ2501とCPU(Central Processing Unit)2503とハードディスク・ドライブ(HDD:Hard Disk Drive)2505と表示装置2509に接続される表示制御部2507とリムーバブル・ディスク2511用のドライブ装置2513と入力装置2515とネットワークに接続するための通信制御部2517とがバス2519で接続されている。オペレーティング・システム(OS:Operating System)及び本実施例における処理を実施するためのアプリケーションプログラムは、HDD2505に格納されており、CPU2503により実行される際にはHDD2505からメモリ2501に読み出される。CPU2503は、アプリケーションプログラムの処理内容に応じて表示制御部2507、通信制御部2517、ドライブ装置2513を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ2501に格納されるが、HDD2505に格納されるようにしてもよい。本発明の実施例では、上で述べた処理を実施するためのアプリケーションプログラムはコンピュータ読み取り可能なリムーバブル・ディスク2511に格納されて頒布され、ドライブ装置2513からHDD2505にインストールされる。インターネットなどのネットワーク及び通信制御部2517を経由して、HDD2505にインストールされる場合もある。このようなコンピュータ装置は、上で述べたCPU2503、メモリ2501などのハードウエアとOS及びアプリケーションプログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
以上述べた本発明の実施の形態をまとめると、以下のようになる。
本実施の形態の第1の態様に係る情報処理装置は、(A)送信すべき1又は複数のメッセージを格納するバッファと、(B)バッファからメッセージを取り出し、取り出した当該メッセージを送信する処理を各々が実行する1又は複数の通信部と、(C)バッファに格納されているメッセージの数と通信部の数との比較結果に基づき、バッファに格納されているメッセージの中から、宛先が同じである2以上のメッセージを統合する処理である統合処理の対象であるメッセージを特定し、特定された当該メッセージについて統合処理を実行する実行部とを有する。
このようにすれば、通信部の処理状況に応じて統合処理の対象であるメッセージを特定できるので、メッセージの統合処理が原因で送信性能が低下するのを抑制できるようになる。
また、上で述べた実行部は、(c1)バッファに格納されているメッセージの数が、通信部の数より多いか判定し、(c2)バッファに格納されているメッセージの数が通信部の数より多い場合に、バッファに格納されているメッセージのうち、通信部の数のメッセージを統合処理の対象から除外する処理を実行する。そして、統合処理の対象から除外されるメッセージは、バッファに格納されているメッセージのうち統合処理の対象であるメッセージより先にバッファから取り出されるメッセージであってもよい。このようにすれば、直ちに送信される可能性が低いメッセージについて統合処理を行えるようになる。
また、上で述べた実行部は、(c3)バッファに格納されているメッセージの数が、通信部の数以下である場合に、バッファに格納されているメッセージを統合処理の対象から除外してもよい。このようにすれば、直ちに送信される可能性が高いメッセージについては統合処理の対象から除外できるようになる。
また、上で述べたバッファは複数の領域を有してもよい。そして、上で述べた実行部は、(c4)宛先が異なる2以上のメッセージが1の領域に格納されないようにバッファに格納されているメッセージを複数の領域に分類してもよい。このようにすれば、バッファにおいてメッセージの統合を適切に行えるようになる。
また、本情報処理装置は、(D)宛先の識別情報に対応付けて、当該宛先に送信すべきメッセージが格納された領域を特定するための情報と当該領域の空容量の情報とを格納する管理データ格納部をさらに有してもよい。そして、上で述べた実行部は、(c5)管理データ格納部を用いて、新たに生成された第1のメッセージのデータ量が、第1のメッセージの宛先に送信すべき第2のメッセージが格納された領域である第1の領域の空容量より多いか判定し、(c6)第1のメッセージのデータ量が第1の領域の空容量以下であり且つ第2のメッセージが統合処理の対象である場合に、第1のメッセージと第2のメッセージとを統合してもよい。このようにすれば、領域の容量に上限がある場合においてもメッセージの統合を適切に行えるようになる。
また、上で述べた実行部は、(c7)第1のメッセージのデータ量が第1の領域の空容量より多く且つ第2のメッセージが統合処理の対象である場合に、第1の領域の空容量が無くなるように、第1のメッセージの一部を第1の領域に格納し、(c8)複数の領域のうちメッセージが格納されていない領域である第2の領域に、第1のメッセージのうち第1の領域に格納された部分以外の部分を格納してもよい。このようにすれば、領域の容量の上限に達した場合においてもメッセージを適切に処理できるようになる。
また、(d1)管理データ格納部に格納されている、宛先に送信すべきメッセージが格納された領域を特定するための情報は、当該宛先に送信すべきメッセージのうちバッファに格納された時点が最も後であるメッセージが格納された領域を特定するための情報であってもよい。このようにすれば、処理を高速化できるようになる。また、管理すべき情報の量を減らせるようになる。
また、複数の領域の各々に格納される1又は複数のメッセージの総データ量は、複数の通信部の各々が一度に送信できるデータ量以下であってもよい。このようにすれば、通信部は効率的に送信を行えるようになる。
また、上で述べた実行部は、(c9)第1のメッセージのうち第1の領域に格納された部分に、後続の部分があることを表す情報を設定し、第1のメッセージのうち第2の領域に格納された部分に、最後の部分であることを表す情報を設定してもよい。このようにすれば、メッセージを受信した装置がメッセージから情報を適切に抽出できるようになる。
本実施の形態の第2の態様に係る通信制御方法は、(E)送信すべきメッセージの数と、送信すべきメッセージを格納するバッファからメッセージを取り出して取り出した当該メッセージを送信する処理を各々が実行する1又は複数の通信部の数とを比較する比較処理と、比較処理の結果に基づき、バッファに格納されているメッセージの中から、宛先が同じである2以上のメッセージを統合する処理である統合処理の対象であるメッセージを特定し、特定された当該メッセージについて統合処理を実行する処理とを含む。
なお、上記方法による処理をコンピュータに行わせるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブルディスク、CD−ROM、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。尚、中間的な処理結果はメインメモリ等の記憶装置に一時保管される。
以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。
(付記1)
送信すべき1又は複数のメッセージを格納するバッファと、
前記バッファからメッセージを取り出し、取り出した当該メッセージを送信する処理を各々が実行する1又は複数の通信部と、
前記バッファに格納されているメッセージの数と前記通信部の数との比較結果に基づき、前記バッファに格納されているメッセージの中から、宛先が同じである2以上のメッセージを統合する処理である統合処理の対象であるメッセージを特定し、特定された当該メッセージについて前記統合処理を実行する実行部と、
を有する情報処理装置。
(付記2)
前記実行部は、
前記バッファに格納されているメッセージの数が、前記通信部の数より多いか判定し、
前記バッファに格納されているメッセージの数が前記通信部の数より多い場合に、前記バッファに格納されているメッセージのうち、前記通信部の数のメッセージを前記統合処理の対象から除外する
処理を実行し、
前記統合処理の対象から除外されるメッセージは、前記バッファに格納されているメッセージのうち前記統合処理の対象であるメッセージより先に前記バッファから取り出されるメッセージである
付記1記載の情報処理装置。
(付記3)
前記実行部は、
前記バッファに格納されているメッセージの数が、前記通信部の数以下である場合に、前記バッファに格納されているメッセージを前記統合処理の対象から除外する
付記2記載の情報処理装置。
(付記4)
前記バッファは複数の領域を有し、
前記実行部は、
宛先が異なる2以上のメッセージが1の領域に格納されないように前記バッファに格納されているメッセージを前記複数の領域に分類する
付記1乃至3のいずれか1つ記載の情報処理装置。
(付記5)
宛先の識別情報に対応付けて、当該宛先に送信すべきメッセージが格納された領域を特定するための情報と当該領域の空容量の情報とを格納する管理データ格納部
をさらに有し、
前記実行部は、
前記管理データ格納部を用いて、新たに生成された第1のメッセージのデータ量が、前記第1のメッセージの宛先に送信すべき第2のメッセージが格納された領域である第1の領域の空容量より多いか判定し、
前記第1のメッセージのデータ量が前記第1の領域の空容量以下であり且つ前記第2のメッセージが前記統合処理の対象である場合に、前記第1のメッセージと前記第2のメッセージとを統合する
付記4記載の情報処理装置。
(付記6)
前記実行部は、
前記第1のメッセージのデータ量が前記第1の領域の空容量より多く且つ前記第2のメッセージが前記統合処理の対象である場合に、前記第1の領域の空容量が無くなるように、前記第1のメッセージの一部を前記第1の領域に格納し、
前記複数の領域のうちメッセージが格納されていない領域である第2の領域に、前記第1のメッセージのうち前記第1の領域に格納された部分以外の部分を格納する
付記5記載の情報処理装置。
(付記7)
前記管理データ格納部に格納されている、前記宛先に送信すべきメッセージが格納された領域を特定するための情報は、当該宛先に送信すべきメッセージのうち前記バッファに格納された時点が最も後であるメッセージが格納された領域を特定するための情報である
付記5又は6記載の情報処理装置。
(付記8)
前記複数の領域の各々に格納される1又は複数のメッセージの総データ量は、前記複数の通信部の各々が一度に送信できるデータ量以下である
付記4乃至7のいずれか1つ記載の情報処理装置。
(付記9)
前記実行部は、
前記第1のメッセージのうち前記第1の領域に格納された部分に、後続の部分があることを表す情報を設定し、前記第1のメッセージのうち前記第2の領域に格納された部分に、最後の部分であることを表す情報を設定する
付記6記載の情報処理装置。
(付記10)
送信すべきメッセージの数と、前記送信すべきメッセージを格納するバッファからメッセージを取り出して取り出した当該メッセージを送信する処理を各々が実行する1又は複数の通信部の数とを比較する比較処理と、
前記比較処理の結果に基づき、前記バッファに格納されているメッセージの中から、宛先が同じである2以上のメッセージを統合する処理である統合処理の対象であるメッセージを特定し、特定された当該メッセージについて前記統合処理を実行する処理と、
をコンピュータが実行する通信制御方法。
(付記11)
送信すべきメッセージの数と、前記送信すべきメッセージを格納するバッファからメッセージを取り出して取り出した当該メッセージを送信する処理を各々が実行する1又は複数の通信部の数とを比較する比較処理と、
前記比較処理の結果に基づき、前記バッファに格納されているメッセージの中から、宛先が同じである2以上のメッセージを統合する処理である統合処理の対象であるメッセージを特定し、特定された当該メッセージについて前記統合処理を実行する処理と、
をコンピュータに実行させるためのプログラム。
10,11,12 サーバ 30,31 クライアント端末
5 ネットワーク
100 定義ファイル格納部 101 初期化処理部
102 受信処理用スレッド 103 データ処理用スレッド
104,1001,1002,1003 送信処理用スレッド
105 管理データ格納部 106 処理要求格納部
107 処理結果格納部 108 データ格納部
301 管理部 302 クライアントプロセス
303 定義ファイル格納部 304 管理データ格納部
1000 バッファ

Claims (9)

  1. 送信すべき1又は複数のメッセージを格納するバッファと、
    前記バッファからメッセージを取り出し、取り出した当該メッセージを送信する処理を各々が実行する1又は複数の通信部と、
    前記バッファに格納されているメッセージの数が、前記通信部の数より多いか判定し、前記バッファに格納されているメッセージの数が前記通信部の数より多い場合に、前記バッファに格納されているメッセージのうち、前記バッファから取り出される順番が前記通信部の数+1番目以降のメッセージであって、新たに生成されたメッセージと宛先が同じであるメッセージを特定し、特定された前記メッセージと前記新たに生成されたメッセージとを統合する実行部と、
    を有する情報処理装置。
  2. 前記実行部は、
    前記バッファに格納されているメッセージの数が前記通信部の数以下である場合に、前記メッセージを特定する処理を行わない
    請求項記載の情報処理装置。
  3. 前記バッファは複数の領域を有し、
    前記実行部は、
    宛先が異なる2以上のメッセージが1の領域に格納されないように前記バッファに格納されているメッセージを前記複数の領域に分類する
    請求項1又は2記載の情報処理装置。
  4. 宛先の識別情報に対応付けて、当該宛先に送信すべきメッセージが格納された領域を特定するための情報と当該領域の空容量の情報とを格納する管理データ格納部
    をさらに有し、
    前記実行部は、
    前記管理データ格納部を用いて、前記新たに生成されたメッセージのデータ量が、前記新たに生成されたメッセージの宛先に送信すべき他のメッセージが格納された領域である第1の領域の空容量より多いか判定し、
    前記新たに生成されたメッセージのデータ量が前記第1の領域の空容量以下であり且つ前記他のメッセージが前記バッファから取り出される順番が前記通信部の数+1番目以降のメッセージである場合に、前記他のメッセージを特定する
    請求項記載の情報処理装置。
  5. 前記実行部は、
    前記新たに生成されたメッセージのデータ量が前記第1の領域の空容量より多く且つ前記他のメッセージが前記バッファから取り出される順番が前記通信部の数+1番目以降のメッセージである場合に、前記第1の領域の空容量が無くなるように、前記新たに生成されたメッセージの一部を前記第1の領域に格納し、
    前記複数の領域のうちメッセージが格納されていない領域である第2の領域に、前記新たに生成されたメッセージのうち前記第1の領域に格納された部分以外の部分を格納する
    請求項記載の情報処理装置。
  6. 前記管理データ格納部に格納されている、前記宛先に送信すべきメッセージが格納された領域を特定するための情報は、当該宛先に送信すべきメッセージのうち前記バッファに格納された時点が最も後であるメッセージが格納された領域を特定するための情報である
    請求項4又は5記載の情報処理装置。
  7. 前記複数の領域の各々に格納される1又は複数のメッセージの総データ量は、前記複数の通信部の各々が一度に送信できるデータ量以下である
    請求項3乃至6のいずれか1つ記載の情報処理装置。
  8. 送信すべき1又は複数のメッセージを格納するバッファに格納されているメッセージの数が、前記バッファからメッセージを取り出し且つ取り出した当該メッセージを送信する処理を実行する通信部の数より多いか判定し、
    前記バッファに格納されているメッセージの数が前記通信部の数より多い場合に、前記バッファに格納されているメッセージのうち、前記バッファから取り出される順番が前記通信部の数+1番目以降のメッセージであって、新たに生成されたメッセージと宛先が同じであるメッセージを特定し、
    特定された前記メッセージと前記新たに生成されたメッセージとを統合する
    処理を、コンピュータが実行する通信制御方法。
  9. 送信すべき1又は複数のメッセージを格納するバッファに格納されているメッセージの数が、前記バッファからメッセージを取り出し且つ取り出した当該メッセージを送信する処理を実行する通信部の数より多いか判定し、
    前記バッファに格納されているメッセージの数が前記通信部の数より多い場合に、前記バッファに格納されているメッセージのうち、前記バッファから取り出される順番が前記通信部の数+1番目以降のメッセージであって、新たに生成されたメッセージと宛先が同じであるメッセージを特定し、
    特定された前記メッセージと前記新たに生成されたメッセージとを統合する
    処理を、コンピュータに実行させるためのプログラム。
JP2014139437A 2014-07-07 2014-07-07 情報処理装置、通信制御方法及びプログラム Active JP6369176B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2014139437A JP6369176B2 (ja) 2014-07-07 2014-07-07 情報処理装置、通信制御方法及びプログラム
US14/719,881 US10148585B2 (en) 2014-07-07 2015-05-22 Communication control method, information processing apparatus, and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2014139437A JP6369176B2 (ja) 2014-07-07 2014-07-07 情報処理装置、通信制御方法及びプログラム

Publications (2)

Publication Number Publication Date
JP2016019072A JP2016019072A (ja) 2016-02-01
JP6369176B2 true JP6369176B2 (ja) 2018-08-08

Family

ID=55017821

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014139437A Active JP6369176B2 (ja) 2014-07-07 2014-07-07 情報処理装置、通信制御方法及びプログラム

Country Status (2)

Country Link
US (1) US10148585B2 (ja)
JP (1) JP6369176B2 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10360079B2 (en) * 2017-06-16 2019-07-23 GM Global Technology Operations LLC Architecture and services supporting reconfigurable synchronization in a multiprocessing system

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0349339A (ja) * 1989-07-17 1991-03-04 Nec Corp データ伝送方式
JPH05160855A (ja) 1991-12-03 1993-06-25 Oki Electric Ind Co Ltd 送信アソシエーション制御方式
US5974465A (en) * 1998-01-21 1999-10-26 3Com Corporation Method and apparatus for prioritizing the enqueueing of outbound data packets in a network device
US6185208B1 (en) * 1998-04-30 2001-02-06 Phone.Com, Inc. Method and apparatus for fragmenting messages for a wireless network using group sharing of reference numbers
WO2003085677A1 (fr) * 2002-04-05 2003-10-16 Renesas Technology Corp. Memoire non volatile
US7724750B2 (en) * 2004-04-01 2010-05-25 Nokia Corporation Expedited data transmission in packet based network
JP2006031238A (ja) 2004-07-14 2006-02-02 Hitachi Ltd メッセージ転送制御方法、メッセージ転送制御プログラムおよびメッセージキューイング装置
JP4645325B2 (ja) * 2005-06-30 2011-03-09 ソニー株式会社 通信装置および通信システム
WO2013183649A1 (ja) * 2012-06-08 2013-12-12 日本電気株式会社 通信装置、通信システム、通信方法及びプログラム

Also Published As

Publication number Publication date
US10148585B2 (en) 2018-12-04
US20160006660A1 (en) 2016-01-07
JP2016019072A (ja) 2016-02-01

Similar Documents

Publication Publication Date Title
US20100138540A1 (en) Method of managing organization of a computer system, computer system, and program for managing organization
US10228979B1 (en) Dynamic virtual partitioning for delayed queues
US20070013948A1 (en) Dynamic and distributed queueing and processing system
JP5002647B2 (ja) ネットワークを管理するシステム及び方法
CN106506490B (zh) 一种分布式计算控制方法以及分布式计算系统
EP2230611A2 (en) Search device, search method, and search program
CN107872402A (zh) 全局流量调度的方法、装置及电子设备
US20160057212A1 (en) Managing Connection Failover in a Load Balancer
JP4205323B2 (ja) 配信システム、配信サーバとその配信方法、配信プログラム
US20080148272A1 (en) Job allocation program, method and apparatus
JP5560641B2 (ja) データ管理装置、データ管理プログラムおよびデータ管理方法
JP5531278B2 (ja) サーバ構成管理システム
JP6369176B2 (ja) 情報処理装置、通信制御方法及びプログラム
US20210266238A1 (en) Operation device and operation method
US10970098B2 (en) Methods for sharing input-output device for process automation on a computing machine and devices thereof
JP5630070B2 (ja) 中継装置、プログラム及び方法
CN117118982A (zh) 基于云原生多集群的消息传输方法、装置、介质及设备
JP2017174038A (ja) 情報処理システム、情報処理方法およびプログラム
JP5857815B2 (ja) 中継装置、中継処理のための情報処理方法及びプログラム、経路制御装置、経路制御のための情報処理方法及びプログラム、並びに情報処理システム
JP5835015B2 (ja) 分散キャッシュについてのシステム、プログラム及び方法
JP6459654B2 (ja) イベントドリブンシステム、情報処理装置、イベントドリブンプログラムおよびイベントドリブン方法
CN111163117B (zh) 一种基于Zookeeper的对等式调度方法和装置
JP5458944B2 (ja) メッセージ処理プログラム
JP2011070435A (ja) 計算機システム、リクエスト処理方法及びサーバ装置
JP6273916B2 (ja) 冗長処理方法、冗長処理システム及び情報処理装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170406

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20180118

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180313

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180420

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180612

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180625

R150 Certificate of patent or registration of utility model

Ref document number: 6369176

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150