JP5173388B2 - 情報処理装置および情報処理方法 - Google Patents
情報処理装置および情報処理方法 Download PDFInfo
- Publication number
- JP5173388B2 JP5173388B2 JP2007320142A JP2007320142A JP5173388B2 JP 5173388 B2 JP5173388 B2 JP 5173388B2 JP 2007320142 A JP2007320142 A JP 2007320142A JP 2007320142 A JP2007320142 A JP 2007320142A JP 5173388 B2 JP5173388 B2 JP 5173388B2
- Authority
- JP
- Japan
- Prior art keywords
- request
- received
- error response
- server
- reject
- 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
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/62—Establishing a time schedule for servicing the requests
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
Description
対策1) ユーザ認証などでアクセス可能なユーザ数を絞り込む。
対策2) 図13のようにサーバの台数を増やし、一台一台のサーバが処理するリクエストを分散させる。
対策3) 一台一台のサーバにおいてセッション数に制限を設け、一度に処理するセッション数を絞り込む。
図14のように、複数のサーバを用意し、クライアントから送信されるリクエストを一台一台のサーバに振り分けて負荷分散を行う場合を考える。図14は図13の負荷分散を行っている状態から更にリクエストが増加した場合を示している。このような場合、負荷分散を行っているにもかかわらず、一台一台のサーバが処理するリクエスト数が結果的に増加してしまい、サーバの処理負荷が増大してしまう。
課題1) 一度セッションが開始されたクライアントからのリクエストに偏ってしまい、全てのクライアント(ユーザ)に一定のサービスレベルでサービスを提供することができなくなってしまう状況に対処できるようにする。
課題2) 汎用的なWebブラウザやWebサービスを利用するクライアント側で特別な処理(例えば特許文献1のような機能)が実装されていなくても対処できるようにする。
(第1の実施形態)
図1は、本実施形態を適用できる、インターネットなどネットワーク経由でサービスを提供するシステムの具体的なシステム構成例を示す図である。図1に示すように、サービスを提供するシステム100、および複数のPCなどのクライアント端末102(1)、102(2)、…、102(M)がネットワーク103を介して接続されている。サービスを提供するシステム100は、複数のサーバ101(1)、101(2)、…、102(N)を含んでいる。ネットワーク103はインターネット、イントラネットなどのネットワークを想定しているが、他のネットワークシステムであってもかまわない。
サーバ101(1)、101(2)、…、101(N)はサービスを提供するための処理を実行するサーバ群であって、任意のサーバ101(X)は他の任意のサーバ(X')とLANなどのネットワークで接続されている。
Step1) クライアント端末102(Y)は、サービスを提供するシステム100に対してネットワーク103を介してリクエストを送信する。
Step2) クライアント端末102(Y)からリクエストを受信したファイアウォール200は、リクエスト通過の可否を判断し、通過可の場合はロードバランサ201へリクエストを転送する。
Step3) ファイアウォール200からリクエストを受信したロードバランサ201は、負荷分散アルゴリズムにしたがって処理を依頼するサーバ101(X)を特定し、サーバ101(X)へリクエストを転送する。
Step4) ロードバランサ201からリクエストを受信したサーバ101(X)は、リクエストに対する処理を実行し実行結果をレスポンスとして、ロードバランサ201へ返信する。
Step5) ロードバランサ201は、サーバ101(X)から受信したレスポンスをファイアウォール200へ転送する。
Step6) ファイアウォール200は、ネットワーク103を介してロードバランサ201から転送されたレスポンスをクラアント端末102(Y)へ転送する。
符号305は、ビデオRAM(以下、VRAMを記述する)であり、後述する情報処理装置の稼動状態を示すCRT306の画面に表示させるための画像を展開し、その表示の制御を行う。
符号306は、ディスプレイ等の表示装置(以下、CRTと記述する)である。
符号308は、ユーザが行う操作を受け付けるための外部入力装置(以下、KBと記述する)であり、例えばキーボードやマウス等のポインティングデバイスが用いられる。
符号313は、FDD310によって読み出しされる磁気記録媒体、光記録媒体、光磁気記録媒体、半導体記録媒体等の取り外し可能なデータ記録装置(リムーバブル・メディア)である(以下、FDと記述する)。磁気記録媒体としては、例えばフロッピー(登録商標)ディスク(登録商標)や外付けハードディスクが挙げられる。光記録媒体としては、例えばCD−ROMが挙げられ、光磁気記録媒体としては、例えばMOが挙げられ、半導体記録媒体としては、例えばメモリカード等が挙げられる。尚、HDD309に格納するアプリケーションプログラムやデータをFD313に格納して使用することも可能である。
符号312は、印刷装置(以下、PRTと記述する)であり、例えばレーザープリンタ等が用いられる。
符号300は、上述した各ユニット間を接続するための伝送バス(アドレスバス、データバス、入出力バス、および制御バス)である。
符号401は、サービス提供手段であって、リクエスト受信手段400で受信したリクエストに対する処理を実行し、処理結果をレスポンスとしてクライアント端末102(Y)へ返信する。つまり、サービス提供手段401はエンドユーザにサービスを提供するための処理を実行するための手段である。
符号500は、リクエストIDであって、クライアント端末102(Y)から受信したリクエストを識別するための識別子である。
符号501は、セッションIDであって、複数のリクエストとレスポンスの組を一連のシーケンスとして識別するための識別子である。
符号502は、受信時刻であって、サーバ101(X)がリクエストを受信した時刻を示すものである。
符号600は、設定項目であって、リクエスト処理判定手段412によって参照される。本実施形態では、リクエスト処理判定手段412における判定基準としてリクエスト間隔閾値を採用するが、ある期間内に送信されたリクエスト数などを判定基準としてもよい。設定項目600には判定基準となるリクエスト間隔閾値や、期間内に送信されたリクエスト数を判断するためのリクエストカウント期間、期間内リクエスト数上限などが設定される。また、設定項目600には、サービスを提供しない場合のエラーレスポンス返信時刻を決定するためのレスポンス送信待ち時間も設定される。
符号601は、設定項目に対する設定値である。 図7はサーバ101(X)におけるエラーレスポンス送信待ちDB414の具体的なデータ構造例を示す図である。
符号700は、リクエストIDであって、リクエスト記録DB411におけるリクエストID500と対応付けられるものである。
符号701は、セッションIDであって、リクエスト記録DB411におけるセッションID501と対応付けられるものである。
符号702は、レスポンス予定時刻であって、クライアント端末102(Y)にリクエストID700に対応するレスポンスをエラーレスポンスとして返信する予定時刻である。
S801) リクエスト受信
リクエスト受信手段400は、クライアント端末102(Y)からリクエストを受信する。そして、リクエスト監視手段410は、受信したリクエストに対してリクエストIDを発行する。受信したリクエスト内にセッションIDが情報として存在しなければセッションIDも発行する。発行したセッションIDはHTTP通信におけるCookieなどの技術を利用して、クライアント端末102(Y)が次回送信するリクエストにセットされるようにする。
リクエスト処理判定手段412は、リクエスト記録DB411から、受信したリクエストと同一セッションIDを持つリクエストの中で最新の2つのリクエスト(今回受信したリクエストと前回受信したリクエスト)の受信した時刻を取得する。すなわち、同一セッションにおける、前回リクエスト受信時刻と今回リクエスト受信時刻とを取得する。
更に、リクエスト処理判定手段412は、リクエスト監視設定値管理DB413から、受信したリクエストに対して要求されたサービスを実行するか否か判定を行うための判定基準であるリクエスト間隔閾値(10秒)を取得する。
S802で取得した今回受信リクエストと前回受信リクエストの受信時刻の差分が上記リクエスト間隔閾値(10秒)を超えているかどうか確認する。
受信リクエストと前回受信リクエストの受信時刻の差分が前記リクエスト間隔閾値(10秒)を超えている場合、S804へ進む。
受信リクエストと前回受信リクエストの受信時刻の差分が前記リクエスト間隔閾値(10秒)を超えていない場合、S805へ進む。
すなわち、上記受信時刻の差分が予め設定された閾値であるリクエスト間隔閾値(10秒)を超えるか否かを基準として、S801にて受信したリクエストを拒否するか否かを判定する。
尚、本実施形態では判定基準としてリクエスト間隔閾値を採用するが、前述のように期間内に送信されたリクエスト数などを判定基準としてもよい。すなわち、同一セッションにおける一定期間内に受信したリクエスト数が予め設定された閾値である期間内リクエスト数上限を超えるか否かを基準として、S801にて受信したリクエストを拒否するか否かを判定するようにしても良い。すなわち期間内リクエスト数の上限を超える場合はステップS805へ進む。
サービス提供手段401は、S801にて受信したリクエストによって要求されたサービスに対する処理を実行し、処理結果をクライアント端末102(Y)にレスポンスとして返信する。
リクエスト処理判定手段412は、エラーレスポンス待ち時間の設定が0より大きく設定されているか否かを判定する。例えば、リクエスト監視設定値管理DB413から、エラーレスポンスを送信するまでの時刻を決定するためのエラーレスポンス待ち時間(12秒)を取得する。
上記エラーレスポンス待ち時間が0秒であった場合、S807へ進む。前記エラーレスポンス待ち時間が0秒より大きい場合、次のような処理を行う。現在時刻に上記エラーレスポンス待ち時間を加算した時刻をレスポンス予定時刻702として、リクエストID700、セッションIDとともにエラーレスポンス送信待ちDB414へ格納し、S806へ進む。
エラーレスポンス送信手段415は、エラーレスポンス送信待ちDB414を参照し、S801にて受信したリクエストとリクエストID700、セッションID701が同一のレスポンス予定時刻702を取得する。
上記取得したレスポンス予定時刻702まで待機する。待機後、S807へ進む。
エラーレスポンス送信手段415は、レスポンス予定時刻に達したエラーレスポンスをクライアント端末102(Y)へ送信する。
図9は本実施形態におけるサーバ101(X)とクライアント端末102(Y)間での処理シーケンス例を示す図である。図9を用いて、サーバ101(X)が図8で説明した処理を行った際のサーバ101(X)とクライアント端末102(Y)とのリクエストとレスポンスのシーケンスを説明する。
前提として、システム管理者がリクエスト監視設定値管理DB413に設定項目を設定しているものとする。ここで設定項目とは上記リクエスト間隔閾値および上記エラーレスポンス送信待ち時間である。上記リクエスト間隔閾値の代わりに「ある期間中のリクエスト数をカウントするためのリクエストカウント期間、期間内リクエスト数上限」であってもかまわない。
システム管理者によるリクエスト監視設定値管理DB413に設定項目を設定するまでの処理は次のようなものである。
ここで、管理者用クライアント端末はサーバ101(X)と同じシステム内のネットワークに接続されていてもよいし、クライアント端末102(Y)のようにシステム外のネットワークに接続されていてもよい。
第1の実施形態では、サーバ101(X)が前回受信したリクエストの受信時刻と今回受信したリクエストの受信時刻の差分が閾値を越えないリクエスト全てに対してエラーレスポンスを返信する形態について説明した。
S1101) リクエスト受信
クライアント端末102(Y)からリクエストを受信する。受信したリクエストに対してリクエストIDを発行する。リクエスト内にセッションIDが情報として存在しなければセッションIDも発行する。
次にリクエストID、セッションID、リクエストを受信した受信時刻(現在時刻)をリクエスト記録DB411のリクエストID700、セッションID701、受信時刻702にそれぞれ格納する。
エラーレスポンス送信待ちDB414を参照し、セッションID701が、ステップS1101にて受信した現在のリクエストと同じセッションIDを持つレコードが存在するか否か確認する。
レコードが存在する場合、S1103へ進む。レコードが存在しない場合、S1104へ進む。
ここでは、後述する、受信したリクエストを拒否するか否かを判定する前に、今回受信したリクエストと同一のクライアント端末102(Y)から送信されたリクエストについてすでにエラーレスポンス送信待ちのものがあるか否かを判定する。すなわち、エラーレスポンス送信待ちDB414を参照して、上記受信したリクエストを送信したクライアント端末102(Y)から以前に送信されたリクエストの中でエラーレスポンス送信待ちのリクエストの有無を確認する。該確認によって、該当するリクエストがある場合は、今回受信したリクエストを破棄する処理(S1103)に進むのである。
S1101にて今回受信したリクエストを破棄する。
リクエスト記録DB411から受信したリクエストと同一セッションIDを持つリクエストの中で最新の2つのリクエスト(受信リクエストと前回受信リクエスト)の受信した時刻を取得する。
リクエスト監視設定値管理DB413から、受信したリクエストに対して要求されたサービスを実行するか否か判定を行うための判定基準であるリクエスト間隔閾値(10秒)を取得する。
S1104で取得した受信リクエストと前回受信リクエストの受信時刻の差分が上記リクエスト間隔閾値(10秒)を超えているかどうか確認する。
受信リクエストと前回受信リクエストの受信時刻の差分が上記リクエスト間隔閾値(10秒)を超えている場合、S1106へ進む。
受信リクエストと前回受信リクエストの受信時刻の差分が上記リクエスト間隔閾値(10秒)を超えていない場合、S1107へ進む。
尚、本実施形態では判定基準としてリクエスト間隔閾値を採用するが、前述のように期間内に送信されたリクエスト数などを判定基準としてもよい。
受信したリクエストによって要求されたサービスに対する処理を実行し、処理結果をクライアント端末102(Y)にレスポンスとして返信する。
リクエスト監視設定値管理DB413から、エラーレスポンスを送信するまでの時刻を決定するためのエラーレスポンス待ち時間(12秒)を取得する。
上記エラーレスポンス待ち時間が0秒であった場合、S1109へ進む。上記エラーレスポンス待ち時間が0秒より大きい場合、次のような処理を行う。現在時刻に上記エラーレスポンス待ち時間(12秒)を加算した時刻をレスポンス予定時刻702として、リクエストID700、セッションID701とともにエラーレスポンス送信待ちDB414へ格納し、S1108へ進む。
エラーレスポンス送信待ちDB414を参照し、受信したリクエストとリクエストID700、セッションID701が同一のレスポンス予定時刻702を取得する。
次に、上記取得したレスポンス予定時刻702まで待機する。待機後、S1109へ進む。
エラーレスポンスをクライアント端末102(Y)へ送信する。
図12は本実施形態におけるサーバ101(X)とクライアント端末102(Y)間での処理シーケンス例を示す図である。図12を用いて、サーバ101(X)が図11で説明した処理を行った際のサーバ101(X)とクライアント端末102(Y)とのリクエストとレスポンスのシーケンスを説明する。
リクエストR1200を受信したサーバ101(X)はリクエストR1200を破棄する。
本発明は、複数の機器(例えばコンピュータ、インターフェース機器、リーダ、プリンタなど)から構成されるシステムに適用することも、1つの機器からなる装置(複合機、プリンタ、ファクシミリ装置など)に適用することも可能である。
101(1) サーバ(1)
101(2) サーバ(2)
101(N) サーバ(N)
102(1) クライアント端末(1)
102(2) クライアント端末(2)
102(M) クライアント端末(M)
103 ネットワーク
200 ファイアウォール
201 ロードバランサ
400 リクエスト受信手段
401 サービス提供手段
410 リクエスト監視手段
411 リクエスト記録データベース(リクエスト記録DB)
412 リクエスト処理判定手段
413 リクエスト監視設定値管理データベース(リクエスト監視設定値管理DB)
414 エラーレスポンス送信待ちデータベース(エラーレスポンス送信待ちDB)
415 エラーレスポンス送信手段
416 リクエスト管理設定値管理手段
Claims (12)
- リクエストを受信するリクエスト受信手段と、
前記リクエスト受信手段にて受信されたリクエストに関する情報であって、該受信したリクエストを拒否するか否かの判定に用いる情報を、リクエスト記録データベースに格納するリクエスト監視手段と、
受信したリクエストを拒否する判定を行う基準値を管理するリクエスト監視設定値管理データベースと、
前記リクエスト監視設定値管理データベースと前記リクエスト記録データベースとを参照して、前記リクエスト受信手段にて受信したリクエストを拒否するか否かを判定するリクエスト処理判定手段と、
前記リクエスト処理判定手段が前記受信したリクエストを拒否すると判定した場合に、該拒否の判定から一定時間経過した後に、前記リクエストを送信したクライアントに対してエラーレスポンスを返信するエラーレスポンス送信手段と
を備えることを特徴とする情報処理装置。 - 前記エラーレスポンスに関する情報を管理するエラーレスポンス送信待ちデータベースをさらに備え、
前記エラーレスポンス送信手段は、前記エラーレスポンス送信待ちデータベースで管理されている前記エラーレスポンスに関する情報に基づいて、前記一定時間経過した後に前記エラーレスポンスを返信することを特徴とする請求項1に記載の情報処理装置。 - 前記リクエスト処理判定手段は、前記受信したリクエストを拒否するか否かを判定する前に前記エラーレスポンス送信待ちデータベースを参照し、前記リクエストを送信したクライアントから以前に送信されたリクエストに対応するエラーレスポンスが前記エラーレスポンス送信待ちデータベースで管理されていると判断した場合は、当該受信したリクエストを破棄することを特徴とする請求項2に記載の情報処理装置。
- 前記リクエスト処理判定手段は、同一セッションにおける前回リクエスト受信時刻と当該リクエスト受信時刻の差分が予め設定された閾値を超えるか否かを基準として、前記受信したリクエストを拒否するか否かを判定することを特徴とする請求項1乃至3のいずれかに記載の情報処理装置。
- 前記リクエスト処理判定手段は、同一セッションにおける一定期間内に受信したリクエスト数が予め設定された閾値を超えるか否かを基準として、前記受信したリクエストを拒否するか否かを判定することを特徴とする請求項1乃至3のいずれかに記載の情報処理装置。
- 前記リクエスト処理判定手段は、同一ユーザIDによって送信されたリクエストの中で前回リクエスト受信時刻と当該リクエスト受信時刻の差分が予め設定された閾値を超えるか否かを基準として、前記受信したリクエストを拒否するか否かを判定することを特徴とする請求項1乃至3のいずれかに記載の情報処理装置。
- 前記リクエスト処理判定手段は、同一ユーザIDによって送信されたリクエストの中で一定期間内に受信したリクエスト数が予め設定された閾値を超えるか否かを基準として、前記受信したリクエストを拒否するか否かを判定することを特徴とする請求項1乃至3のいずれかに記載の情報処理装置。
- 前記リクエスト監視設定値管理データベースにおいて管理される設定値に対して所定の処理を行うリクエスト監視設定値管理手段をさらに備えることを特徴とする請求項1乃至7のいずれかに記載の情報処理装置。
- 前記リクエスト処理判定手段が前記受信したリクエストを拒否しないと判定した場合に、当該リクエストに対応する処理を実行するサービス提供手段を、更に備えることを特徴とする請求項1乃至8のいずれかに記載の情報処理装置。
- リクエストを受信するリクエスト受信工程と、
前記リクエスト受信手段にて受信されたリクエストに関する情報であって、該受信したリクエストを拒否するか否かの判定に用いる情報を、リクエスト記録データベースに格納するリクエスト監視工程と、
受信したリクエストを拒否する判定を行う基準値を管理するリクエスト監視設定値管理データベースと前記リクエスト記録データベースとを参照して、前記リクエスト受信工程にて受信したリクエストを拒否するか否かを判定するリクエスト処理判定工程と、
前記リクエスト処理判定工程にて前記受信したリクエストを拒否すると判定した場合に、該拒否の判定から一定時間経過した後に、前記リクエストを送信したクライアントに対してエラーレスポンスを返信するエラーレスポンス送信工程と
を有することを特徴とする情報処理方法。 - コンピュータを、
受信したリクエストに関する情報であって、該受信したリクエストを拒否するか否かの判定に用いる情報を、リクエスト記録データベースに格納するリクエスト監視手段、
受信したリクエストを拒否する判定を行う基準値を管理するリクエスト監視設定値管理データベースと前記リクエスト記録データベースとを参照して、前記受信したリクエストを拒否するか否かを判定するリクエスト処理判定手段、
前記リクエスト処理判定手段が前記受信したリクエストを拒否すると判定した場合に、該拒否の判定から一定時間経過した後に、前記リクエストを送信したクライアントに対してエラーレスポンスを返信するエラーレスポンス送信手段
として機能させるための、コンピュータプログラム。 - 請求項11に記載のコンピュータプログラムを格納した、コンピュータ読み取り可能な記憶媒体。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2007320142A JP5173388B2 (ja) | 2007-12-11 | 2007-12-11 | 情報処理装置および情報処理方法 |
US12/329,249 US8176171B2 (en) | 2007-12-11 | 2008-12-05 | Information processing device and information processing method |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2007320142A JP5173388B2 (ja) | 2007-12-11 | 2007-12-11 | 情報処理装置および情報処理方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2009146005A JP2009146005A (ja) | 2009-07-02 |
JP5173388B2 true JP5173388B2 (ja) | 2013-04-03 |
Family
ID=40722809
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2007320142A Active JP5173388B2 (ja) | 2007-12-11 | 2007-12-11 | 情報処理装置および情報処理方法 |
Country Status (2)
Country | Link |
---|---|
US (1) | US8176171B2 (ja) |
JP (1) | JP5173388B2 (ja) |
Families Citing this family (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100241760A1 (en) * | 2009-03-18 | 2010-09-23 | Microsoft Corporation | Web Front-End Throttling |
US8826304B2 (en) | 2009-08-13 | 2014-09-02 | Google Inc. | Virtual object indirection in a hosted computer environment |
US20110208854A1 (en) * | 2010-02-19 | 2011-08-25 | Microsoft Corporation | Dynamic traffic control using feedback loop |
US8892632B2 (en) * | 2010-06-04 | 2014-11-18 | Microsoft Corporation | Client-server interaction frequency control |
JP5689622B2 (ja) * | 2010-07-05 | 2015-03-25 | Kddi株式会社 | リクエスト受付装置、リクエスト受付方法、およびプログラム |
JP6024115B2 (ja) * | 2012-02-17 | 2016-11-09 | 日本電気株式会社 | 要求管理装置、要求管理方法、及び要求管理プログラム |
KR101368500B1 (ko) * | 2012-04-26 | 2014-02-28 | 주식회사 엘지씨엔에스 | 데이터베이스 히스토리 관리 방법 및 그를 위한 데이터베이스 히스토리 관리 시스템 |
WO2014080994A1 (ja) * | 2012-11-22 | 2014-05-30 | 日本電気株式会社 | 輻輳制御システム、制御装置、輻輳制御方法およびプログラム |
JP6516707B2 (ja) * | 2016-08-26 | 2019-05-22 | カブドットコム証券株式会社 | リクエスト受付サーバ及びリクエストの受付方法 |
US11223604B2 (en) * | 2018-05-18 | 2022-01-11 | T-Mobile Usa, Inc. | Detecting aggressive or attacking behaviors in IMS SIP signaling |
WO2022091259A1 (ja) | 2020-10-28 | 2022-05-05 | 日本電信電話株式会社 | 受理判断装置及び受理判断方法 |
CN115408242B (zh) * | 2022-11-01 | 2023-03-24 | 云和恩墨(北京)信息技术有限公司 | 数据库监控方法、***及存储介质 |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2900863B2 (ja) * | 1995-11-17 | 1999-06-02 | 凸版印刷株式会社 | 情報供給方法 |
JP2002189650A (ja) | 2000-12-20 | 2002-07-05 | Hitachi Ltd | 計算機制御方法及び装置並びにその処理プログラムを格納した記録媒体 |
US7464410B1 (en) * | 2001-08-30 | 2008-12-09 | At&T Corp. | Protection against flooding of a server |
JP4434551B2 (ja) * | 2001-09-27 | 2010-03-17 | 株式会社東芝 | サーバー計算機保護装置、サーバー計算機保護方法、サーバー計算機保護プログラム及びサーバー計算機 |
JP2004127172A (ja) * | 2002-10-07 | 2004-04-22 | Matsushita Electric Ind Co Ltd | コンテンツ閲覧制限装置、コンテンツ閲覧制限方法およびコンテンツ閲覧制限プログラム |
JP2004334455A (ja) * | 2003-05-07 | 2004-11-25 | Fujitsu Ltd | サーバ装置 |
JP4005047B2 (ja) * | 2004-03-31 | 2007-11-07 | 東芝ソリューション株式会社 | サーバ計算機保護装置 |
JP2007122396A (ja) * | 2005-10-27 | 2007-05-17 | Hitachi Ltd | ディスクアレイ装置及びその障害対応検証方法 |
ES2908589T3 (es) * | 2007-11-02 | 2022-05-03 | Ericsson Telefon Ab L M | Método y aparatos para procesar mensajes de control de errores en un sistema de comunicación inalámbrico |
-
2007
- 2007-12-11 JP JP2007320142A patent/JP5173388B2/ja active Active
-
2008
- 2008-12-05 US US12/329,249 patent/US8176171B2/en not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2009146005A (ja) | 2009-07-02 |
US20090150544A1 (en) | 2009-06-11 |
US8176171B2 (en) | 2012-05-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5173388B2 (ja) | 情報処理装置および情報処理方法 | |
JP4452185B2 (ja) | 管理ポリシーに基づいた要求トラフィックのリソース認識管理 | |
JP4550704B2 (ja) | 通信システム及び通信管理方法 | |
US11223544B2 (en) | Systems and methods for queuing access to network resources | |
US8255532B2 (en) | Metric-based monitoring and control of a limited resource | |
US7441046B2 (en) | System enabling server progressive workload reduction to support server maintenance | |
CN102684988B (zh) | 负荷控制装置及其方法 | |
US8224963B2 (en) | Managing requests for connection to a server | |
RU2316045C2 (ru) | Управление ресурсами сервера, анализ и предотвращение вторжения к ресурсам сервера | |
WO2007061824A1 (en) | System, method, and computer program product for throttling client traffic | |
US20110173319A1 (en) | Apparatus and method for operating server using virtualization technique | |
KR102047088B1 (ko) | 네트워크 시스템에서의 리소스 할당 방법 및 이를 구현하는 네트워크 시스템 | |
EP2115591A1 (en) | Method, system and program product for monitoring resources servicing a business transaction | |
JP5203919B2 (ja) | サーバシステム | |
JP2004206634A (ja) | 監視方法、稼動監視装置、監視システム及びコンピュータプログラム | |
CN107819754B (zh) | 一种防劫持方法、监控服务器、终端及*** | |
JP5268785B2 (ja) | Webサーバシステムへのログイン制限方法 | |
US20110219440A1 (en) | Application-level denial-of-service attack protection | |
JP3776848B2 (ja) | 管理サーバ及びプログラム | |
US20070130307A1 (en) | Selective activation of TCP/IP link and traffic | |
JP4463588B2 (ja) | アラート通知装置 | |
JP5441167B2 (ja) | ルータ装置、転送制御方法および転送制御プログラム | |
CN112698927A (zh) | 双向通信方法、装置、电子设备及机器可读存储介质 | |
JP6233141B2 (ja) | データベースシステム、データベースサーバ、データベースサーバプログラム、データベースクライアント及びデータベースクライアントプログラム | |
CN113765766B (zh) | 虚拟专用网络的会话控制方法、装置及设备 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20101106 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20101119 |
|
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: 20121204 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20121227 |
|
R151 | Written notification of patent or utility model registration |
Ref document number: 5173388 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20160111 Year of fee payment: 3 |