JP3966711B2 - 代理応答方法 - Google Patents
代理応答方法 Download PDFInfo
- Publication number
- JP3966711B2 JP3966711B2 JP2001340604A JP2001340604A JP3966711B2 JP 3966711 B2 JP3966711 B2 JP 3966711B2 JP 2001340604 A JP2001340604 A JP 2001340604A JP 2001340604 A JP2001340604 A JP 2001340604A JP 3966711 B2 JP3966711 B2 JP 3966711B2
- Authority
- JP
- Japan
- Prior art keywords
- server
- packet
- packet data
- charging
- response
- 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.)
- Expired - Fee Related
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/56—Provisioning of proxy services
-
- 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/56—Provisioning of proxy services
- H04L67/59—Providing operational support to end devices by off-loading in the network or by emulation, e.g. when they are unavailable
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
-
- 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/2866—Architectures; Arrangements
- H04L67/2871—Implementation details of single intermediate entities
-
- 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/56—Provisioning of proxy services
- H04L67/561—Adding application-functional data or data for application control, e.g. adding metadata
-
- 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/56—Provisioning of proxy services
- H04L67/565—Conversion or adaptation of application format or content
-
- 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/56—Provisioning of proxy services
- H04L67/565—Conversion or adaptation of application format or content
- H04L67/5651—Reducing the amount or size of exchanged application data
Description
【０００１】
【発明が属する技術分野】
本発明は、パケットを中継するコンピュータにおける代理応答技術に関する。
【０００２】
【従来の技術】
ラディウス（RADIUS:Remote Authentication Dial In-User Service）サーバは、例えば公衆回線網及び当該公衆回線網に接続しているアクセス・サーバを介してユーザ端末からユーザ認証情報を受信すると、ユーザ認証処理を実施し、ＤＮＳ（Domain Name Sysyem）サーバ指定やＰＰＰ（Point-to-Point Protocol）接続指定等の接続制御や、課金に必要な情報を取得したりするサーバである。これらの処理が完了すると、ユーザ端末は例えばインターネットへの接続を許可されたり、特別なサービスを受けることができるようになる。ＲＡＤＩＵＳプロトコルについては、ＲＦＣ（Request For Comments）２８６５及びＲＦＣ２８６６に規定がなされている。ＲＡＤＩＵＳプロトコルは、ＵＤＰ（User Datagram Protocol）を用いている。
【０００３】
例えば複数のアクセスポイントにアクセス・サーバを設けて、このアクセス・サーバをネットワークで接続し、当該ネットワークを例えばＩＳＰ（Internet Service Provider）等の企業に開放するというサービスがある。このサービスを利用する企業は、自己のシステムに大きな変更を加えることなくユーザに対してアクセス手段を増やすことができる。各企業は、ＲＡＤＩＵＳサーバを用意して、上記ネットワークに接続する。ネットワークには、ユーザからの要求を当該ユーザに対してサービスを行う企業のＲＡＤＩＵＳサーバに振り分けるために中継サーバが設けられる。この中継サーバでは、転送結果を記録してネットワークの使用量を正確に把握して正確な課金を行ったり、パケットの内容を確認して変更したりする。
【０００４】
このような環境において、１つの企業のＲＡＤＩＵＳサーバが障害などでダウンしてしまうと、リクエストに対するレスポンスが得られないために、アクセス・サーバは同じリクエストに係るパケットを何度も再送する。そのためネットワークのトラフィックが増加して、正常に動作している他の企業のＲＡＤＩＵＳサーバに対してもレスポンスの低下を招いてしまうという問題がある。また、通常送信したパケットはアクセスサーバ側で管理しているが、再送によるトラフィックの増加によりアクセス・サーバのバッファ・オーバーフローが発生し、パケットが失われてしまう場合もあり、正確に課金できない可能性がある。中継サーバやアクセス・サーバのログを調べて障害中に送信されていたパケットを探し、企業側にその情報を通知しなければならないが、量が多いため不可能な場合も多い。
【０００５】
【発明が解決しようとする課題】
このように障害時のトラフィックの増加は非常に問題が多い。
【０００６】
従って、本発明の目的は、障害時のトラフィックの増加を防止する技術を提供することである。
【０００７】
また本発明の他の目的は、障害時のトラフィックの増加を招くパケットの再送を防止するための技術を提供することである。
【０００８】
さらに本発明の他の目的は、課金リクエストに係るパケットの喪失を防止し、正確な課金情報の取得を可能とする技術を提供することである。
【０００９】
【課題を解決するための手段】
上記目的を解決するため本発明に係る代理応答方法は、第１のコンピュータ（例えば実施の形態におけるアクセス・サーバ。ルータのような接続機器の場合もある）からパケットを受信した場合、当該パケット・データに含まれるユーザ識別情報から転送先の第２のコンピュータ（例えば実施の形態における課金サーバ（ＲＡＤＩＵＳサーバ））を特定するステップと、特定された転送先の第２のコンピュータに、パケット・データに基づくパケットを送信するステップと、転送先の第２のコンピュータから所定期間内にレスポンスを受信しない場合、パケット・データを記憶装置（例えば実施の形態における代理応答リスト）に保存すると共に、パケット・データに対応するレスポンスを生成し、第１のコンピュータに送信するステップとを含む。
【００１０】
このようにすれば、第１のコンピュータはレスポンスを得ることができるので、パケットを何度も再送して、ネットワークの輻輳を招くことがなくなる。また、記憶装置にパケット・データが保存されるので、代理応答を行うコンピュータにおいて後で第２のコンピュータに送付できるようになる。
【００１１】
また、本発明において、所定のタイミングにて記憶装置に保存されたパケット・データを読み出して、当該パケット・データに含まれるユーザ識別情報から転送先の第２のコンピュータを特定する第２特定ステップと、特定された転送先の第２のコンピュータに、読み出されたパケット・データに基づくパケットを送信するステップと、転送先の第２のコンピュータから所定期間内にレスポンスを受信した場合、当該レスポンスと、記憶装置に保存された、対応するパケット・データとを破棄するステップとをさらに含むような構成であってもよい。
【００１２】
このようにすれば、第２のコンピュータにおいても正常どおり応答したものとして処理できる。すなわち第２のコンピュータについては何ら本発明を採用するに当たって変更を要しない。また、代理応答を行うコンピュータにおいて第２のコンピュータからのレスポンスを破棄するので、第１のコンピュータにおいても変更を要しない。
【００１３】
さらに、本発明において、少なくとも、記憶装置に保存されたパケット・データに含まれる遅延時間を表すデータを当該パケット・データを受信した時刻からの経過時間に基づき変更することにより、読み出されたパケット・データに基づくパケットを生成するステップをさらに含むような構成であってもよい。
【００１４】
このようにすれば、第２のコンピュータはパケットをどの程度遅れて受信したかを判断することができるようになる。例えば課金リクエストに係るパケットを第１のコンピュータが送信している場合には、第２のコンピュータは第１のコンピュータの課金リクエスト送信時を得ることができるようになるので、正確な課金を行うことができるようになる。
【００１５】
本発明において、パケット・データが課金リクエストに関するデータであるか判断するステップをさらに含むような構成であってもよい。第２のコンピュータでは、課金リクエストに応じて取得するデータに基づき二重ログインチェック等を行う場合もあり、正確な課金と共に正確なログインチェックという点においても重要である。なお、課金リクエストについては開始時の課金リクエストと終了時の課金リクエストがあるが、終了時の課金リクエストは正確な課金情報の取得という点において非常に重要である。
【００１６】
なお、上述の方法はプログラムにて実施することができ、このプログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークなどを介して配布される場合もある。尚、中間的な処理結果はメモリ等の記憶装置に一時保管される。
【００１７】
【発明の実施の形態】
図１に本発明の一実施の形態に係るシステム概要図を示す。例えばパーソナル・コンピュータであるユーザ端末７は公衆回線網９を介してアクセス・サーバＡ（３）に接続する。また、例えばノート型コンピュータであるユーザ端末２７も公衆回線網９を介してアクセス・サーバＡ（３）に接続する。例えばパーソナル・コンピュータであるユーザ端末２５は、公衆回線網２３を介してアクセス・サーバＢ（２１）に接続する。また、例えばＰＤＡ（Personal Digital Asistance）であるユーザ端末２９も公衆回線網２３を介してアクセス・サーバＢ（２１）に接続する。端末の種類及び数は、これらに限定されるものではなく、携帯電話機が用いられる場合もある。また、アクセス・サーバは、サーバのようなコンピュータであってもよいし、ルータのような接続機器であっても良いが、ここではこれらをコンピュータとして説明する。また、公衆回線網に接続するアクセス・サーバの数は２に限定されるものではなく、より多くのアクセス・サーバを設けることができる。
【００１８】
アクセス・サーバＡ（３）及びアクセス・サーバＢ（２１）は、ＩＰ（Internet Protocol）ネットワーク１に接続されている。ＩＰネットワーク１は例えばインターネット１１にも接続されている。また、ＩＰネットワーク１には、中継サーバ５も接続されている。図１では中継サーバは１台しか設けられていないが、複数台設ける場合もある。中継サーバ５は、企業ＡのＲＡＤＩＵＳサーバである課金サーバ１３ａ及び認証サーバ１３ｂに接続されている。また、企業ＢのＲＡＤＩＵＳサーバである課金サーバ１５ａ及び認証サーバ１５ｂに接続されている。中継サーバ５に接続される企業のＲＡＤＩＵＳサーバの数は２に限定されない。また、ここでは説明のため課金サーバ及び認証サーバを分けて説明しているが、これらは１台のサーバにてその機能を実現することも可能である。また、バックアップや処理負荷分散のために多くの課金サーバや認証サーバを一つの企業が用意する場合もある。課金サーバ１３ａは企業Ａのユーザの課金情報を蓄積する課金ＤＢ１８を管理しており、認証サーバ１３ｂは企業Ａのユーザの認証情報を格納する認証ＤＢ１７を管理している。課金サーバ１５ａは企業Ｂのユーザの課金情報を蓄積する課金ＤＢ１９を管理しており、認証サーバ１５ｂは企業Ｂのユーザの認証情報を格納する認証ＤＢ２０を管理している。
【００１９】
中継サーバ５には、代理応答処理部５１と代理応答後処理部５３とが設けられている。これらの処理内容については後に図を用いて説明する。また、中継サーバ５は、中継サーバ５が代理応答したリクエストについてのパケット・データを格納する代理応答リスト格納部５５及び中継サーバ５が中継するＲＡＤＩＵＳサーバの稼動状況に関する情報についてのステータス表を格納するステータス表格納部５７を有する。
【００２０】
次に図２乃至図４を用いて、図１に示したアクセス・サーバ（ここではアクセス・サーバＡ（３））、中継サーバ５、認証サーバ（ここでは認証サーバ１３ｂ）、課金サーバ（ここでは課金サーバ１３ａ）の従来における処理を説明する。
【００２１】
最初に、例えばユーザ端末７からログイン要求を受信するとアクセス・サーバＡ（３）は、認証リクエスト（Access-Request）のパケットを生成し、中継サーバ５に送信する（ステップ（１））。中継サーバ５は、アクセス・サーバＡ（３）から認証リクエストのパケットを受信すると一旦記憶装置に格納し、パケット・データに含まれるユーザＩＤ等のユーザ識別情報を元に転送先のＲＡＤＩＵＳサーバを特定すると共にパケットの送信先を変更するなどの処理を施した後、認証リクエストのパケットを認証サーバ１３ｂに転送する（ステップ（２））。
【００２２】
認証サーバ１３ｂは、中継サーバ５から認証リクエストのパケットを受信すると一旦記憶装置に格納し、認証ＤＢ１７に格納されたデータを用いて認証処理を実施する（ステップ（３））。認証処理については従来と何ら変わりがないので、これ以上述べない。ここでは認証に成功したものとする。そうすると、認証サーバ１３ｂは、認証レスポンス（Access-Accept）のパケットを生成し、中継サーバ５に送信する（ステップ（４））。中継サーバ５は、認証サーバ１３ｂから認証レスポンスのパケットを受信すると一旦記憶装置に格納し、パケット・データを確認して送信先のアクセス・サーバ（ここではアクセス・サーバＡ（３））を特定し、パケットの送信先を変更するなどの処理を施した後、認証レスポンスのパケットをアクセス・サーバＡ（３）に転送する（ステップ（５））。アクセス・サーバＡ（３）は、中継サーバ５から認証レスポンスのパケットを受信する。ここまでの処理で、認証が完了し、ＰＰＰセッションが確立される（ステップ（６））。
【００２３】
次に、アクセス・サーバＡ（３）は、開始（後に述べるが属性Acct-Status-Typeの値が１（Start））を表す課金リクエスト（Accounting-Request）のパケットを生成し、中継サーバ５に送信する（ステップ（７））。中継サーバ５は、アクセス・サーバＡ（３）から開始を表す課金リクエストのパケットを受信すると一旦記憶装置に格納し、パケット・データに含まれるユーザＩＤ等のユーザ識別情報を元に転送先のＲＡＤＩＵＳサーバを特定すると共にパケットの送信先を変更するなどの処理を施した後、開始を表す課金リクエストのパケットを課金サーバ１３ａに転送する（ステップ（８））。
【００２４】
課金サーバ１３ａは、中継サーバ５から開始を表す課金リクエストのパケットを受信すると一旦記憶装置に格納し、課金処理を実施する（ステップ（９））。すなわち、課金開始を認識し、課金開始を課金ＤＢ１８に登録する。そして、課金サーバ１３ａは、課金レスポンス（Accounting-Response）のパケットを生成し、中継サーバ５に送信する（ステップ（１０））。中継サーバ５は、課金サーバ１３ａから課金レスポンスのパケットを受信すると一旦記憶装置に格納し、パケット・データを確認して送信元のアクセス・サーバ（ここではアクセス・サーバＡ（３））を特定し、パケットの送信先を変更するなどの処理を施した後、課金レスポンスのパケットをアクセス・サーバＡ（３）に転送する（ステップ（１１））。アクセス・サーバＡ（３）は、中継サーバ５から課金レスポンスのパケットを受信する。ここまでの処理でユーザ端末７は通信を開始することができるようになる（ステップ（１２））。すなわち、例えばインターネットへのアクセスが可能となる。
【００２５】
一方、例えばユーザ端末７からログオフ要求（通信終了通知など）を受信するとアクセス・サーバＡ（３）は、終了（後に述べるが属性Acct-Status-Typeの値が２（Stop））を表す課金リクエスト（Accounting-Request）のパケットを生成し、中継サーバ５に送信する（ステップ（２１））。中継サーバ５は、アクセス・サーバＡ（３）から終了を表す課金リクエストのパケットを受信すると一旦記憶装置に格納し、パケット・データに含まれるユーザＩＤ等のユーザ識別情報を元に転送先のＲＡＤＩＵＳサーバを特定すると共にパケットの送信先を変更するなどの処理を施した後、終了を表す認証リクエストのパケットを課金サーバ１３ａに転送する（ステップ（２２））。
【００２６】
課金サーバ１３ａは、中継サーバ５から終了を表す課金リクエストのパケットを受信すると一旦記憶装置に格納し、課金処理を実施する（ステップ（２３））。すなわち、課金終了を認識し、課金終了を課金ＤＢ１８に登録する。そして、課金サーバ１３ａは、課金レスポンス（Accounting-Response）のパケットを生成し、中継サーバ５に送信する（ステップ（２４））。中継サーバ５は、課金サーバ１３ａから課金レスポンスのパケットを受信すると一旦記憶装置に格納し、パケット・データを確認して送信元のアクセス・サーバ（ここではアクセス・サーバＡ（３））を特定し、パケットの送信先を変更するなどの処理を施した後、課金レスポンスのパケットをアクセス・サーバＡ（３）に転送する（ステップ（２５））。アクセス・サーバＡ（３）は、中継サーバ５から課金レスポンスのパケットを受信する。このような処理によりユーザ端末７との通信は終了する（ステップ（２６））。
【００２７】
図２及び図３では課金サーバ１３ａも認証サーバ１３ｂも通常どおり稼動している場合の処理フローである。もし、課金サーバ１３ａがダウンしている場合には、図４のような処理が実施される。すなわち、アクセス・サーバＡ（３）は、課金リクエストのパケットを生成すると、中継サーバ５に送信する（ステップ（３１））。中継サーバ５は、アクセス・サーバＡ（３）から課金リクエストのパケットを受信すると一旦記憶装置に格納し、パケット・データに含まれるユーザＩＤ等のユーザ識別情報を元に転送先のＲＡＤＩＵＳサーバを特定すると共にパケットの送信先を変更するなどの処理を施した後、課金リクエストのパケットを課金サーバ１３ａに転送する（ステップ（３２））。
【００２８】
しかし、課金サーバ１３ａがダウンしているために応答がない。従って、所定期間経過後、アクセス・サーバＡ（３）は、課金リクエストのパケットを中継サーバ５に送信する（ステップ（３３））。なお、本課金リクエストでは、セッションＩＤ（属性のAcct-Session-ID）が前に送信した課金リクエストのセッションＩＤと同じであり、遅延時間（属性のAcct-Delay-time）が最初のパケット送信時からの経過時間分加算された値となっている。中継サーバ５は、アクセス・サーバＡ（３）から課金リクエストのパケットを受信すると一旦記憶装置に格納し、パケット・データに含まれるユーザＩＤ等のユーザ識別情報を元に転送先のＲＡＤＩＵＳサーバを特定すると共にパケットの送信先を変更するなどの処理を施した後、課金リクエストのパケットを課金サーバ１３ａに転送する（ステップ（３４））。
【００２９】
同様に課金サーバ１３ａがダウンしているため応答がない。応答がないので、アクセス・サーバＡ（３）は、上で述べた処理を繰り返さなければならない。課金サーバ１３ａに課金リクエストを送信するすべてのアクセス・サーバが同じ処理を実施する。これにより、ＩＰネットワーク１に輻輳が生じてしまう。
【００３０】
本実施の形態では、図５に示すような処理を実施することにより、図４で生じるようなネットワークの輻輳を防止する。すなわち、アクセス・サーバＡ（３）は、課金リクエストのパケットを生成し、中継サーバ５に送信する（ステップ（４１））。中継サーバ５は、アクセス・サーバＡ（３）から課金リクエストのパケットを受信すると一旦記憶装置に格納し、パケット・データに含まれるユーザＩＤ等のユーザ識別情報を元に転送先のＲＡＤＩＵＳサーバを特定すると共にパケットの送信先を変更するなどの処理を施した後、課金リクエストのパケットを課金サーバ１３ａに転送する（ステップ（４２））。ここまでは従来と同じである。
【００３１】
しかし、課金サーバ１３ａがダウンしていると課金レスポンスは送られてこないので、中継サーバ５は、所定期間内に課金レスポンスを課金サーバ１３ａから受信しない場合には、課金リクエストのパケット・データを代理応答リスト格納部５５に格納し、当該課金リクエストのパケット・データから課金レスポンスを生成し、代理で課金レスポンスのパケットをアクセス・サーバＡ（３）に返信する（ステップ（４３））。このようにすれば、アクセス・サーバＡ（３）が何度も同じ課金リクエストを送信するような事態を避けることができる。なお、中継サーバ５は、課金サーバ１３ａのダウンをステータス表格納部５７のステータス表に登録する。
【００３２】
中継サーバ５は、所定の周期又は任意のタイミングにて、代理応答リスト格納部５５に格納された課金リクエストのパケット・データを読み出して、課金リクエストのパケットを生成し、課金サーバ１３ａに送信してみる（ステップ（４４））。この際、パケット・データに含まれるユーザＩＤから送信先である課金サーバ１３ａを特定し、またパケット・データに含まれる遅延時間を当該課金リクエストのパケットを受信した時刻からの経過時間分増加させるといった変更処理を実施している。
【００３３】
もし、課金サーバ１３ａが既に復帰している場合には、中継サーバ５から課金リクエストのパケットを受信すると、課金処理を実施する（ステップ（４５））。なお、開始を表す課金リクエストの場合には、課金開始を認識し、課金開始に関する情報を課金ＤＢ１８に登録する。終了を表す課金リクエストの場合には、課金終了を認識し、課金終了に関する情報を課金ＤＢ１８に登録する。なお、上でも述べたように遅延時間は中継サーバ５により変更されているが、従来でもこの遅延時間を考慮して課金開始及び課金終了についての情報を登録するようになっているので、課金ＤＢ１８に登録される情報としては問題が生じない。すなわち、本実施の形態を採用してもＲＡＤＩＵＳサーバについて修正・変更は必要ない。
【００３４】
なお、課金サーバ１３ａがまだ復帰していない場合には、中継サーバ５は課金リクエストのパケットを再送することはなく、この段階で課金サーバ１３ａへの送信を中止する。
【００３５】
課金処理を実施すると、課金サーバ１３ａは、課金レスポンスのパケットを生成し、中継サーバ５に送信する（ステップ（４６））。中継サーバ５は、課金サーバ１３ａからの課金レスポンスのパケットを受信すると一旦記憶装置に格納するが、ステップ（４４）において送信した課金リクエストに対応する課金レスポンスのパケットであることを判別すると、当該課金レスポンスのパケットを破棄する（ステップ（４７））。既に代理応答しているため、中継サーバ５がこのパケットをアクセス・サーバＡ（３）に送信してもネットワークのトラフィックを増加させるだけで何らの利益もないからである。従って、アクセス・サーバＡ（３）は、中継サーバ５が代理応答することによって新たに必要になる処理や、変更が必要となる処理はない。なお、中継サーバ５は、代理応答リスト格納部５５に格納してあった本処理に係る課金レスポンスのパケット・データを破棄する処理も実施する。
【００３６】
以上のような処理を実施することにより、課金サーバ１３ａの障害時に、ＩＰネットワーク１のトラフィックを増加させることはなくなる。また、アクセス・サーバにおけるバッファ限界が生じ、パケット破棄などによる課金リクエストのパケットロストが生じることを防止することもできるようになる。また、再送を繰り返さなくなるため、アクセス・サーバの負荷増加を防止することも可能となる。また、一つの企業のＲＡＤＩＵＳサーバのダウンによる他の企業への影響を軽減することができる。さらに、中継サーバ５の代理応答リスト格納部５５に代理応答の処理対象となった課金リクエストのパケットは格納されており、後にあたかも通常の処理のように課金サーバに送信されるので、課金サーバにおける障害復旧作業が大幅に軽減される。課金リクエストの処理が適正になされれば、適正な課金処理も行うことができる。
【００３７】
なお、図５では開始を表す課金リクエストと終了を表す課金リクエストとを区別しなかったが、本実施の形態においては両方に対して実施することができる。但し、中継サーバ５の処理負荷や代理応答リスト格納部５５の容量、課金の確実性といった観点からすれば、終了を表す課金リクエストについて図５のような処理を実施する方が好ましい場合もある。上でも述べたが、終了を表す課金リクエストか否かは、パケット・データの属性Acct-Status-Typeの値が２（Stop）であるか否かを判断すればよい。
【００３８】
次に、図５のような処理を実施するための中継サーバ５の処理をより詳細に説明する。中継サーバ５の代理応答処理部５１の処理を図６に示す。図６において、代理応答処理部５１は、パケットを受信すると一旦記憶装置に格納し、当該パケットが課金リクエストのパケットか否かを判断する（ステップＳ１）。なお、課金リクエストのパケットか否かは、パケットのコードにて判断できる。
【００３９】
図７にＲＡＤＩＵＳにおけるパケットのフォーマットを示す。図７の例で示すように、パケットは、コード（code）、識別子（identifier）、長さ（length）、オーセンティケータ（Authenticator）、属性（Attribute）で構成される。属性のデータは可変長であり、属性のタイプ（type）、長さ（length）、及び可変長の値（value）を各属性につき保持する。このパケットのデータはＵＤＰパケットのデータ・フィールドにカプセル化される。
【００４０】
コードは、パケットの種類を表し、例えば１は認証リクエスト（Access-Request）、２は許可を表す認証レスポンス（Access-Accept）、３は拒否を表す認証レスポンス（Access-Reject）、４は課金リクエスト（Accounting-Reqest）、５は課金レスポンス（Accounting-Response）を表す。従って、代理応答処理部５１はパケットのコードが４であるかを判断する。また、識別子は、リクエストとその応答を対応付けるために用いるデータである。長さは、コード、識別子、オーセンティケータ及び属性フィールドの長さを示す。オーセンティケータは、このパケットの認証を行うためのデータであって、コード、識別子及び長さ等のＭＤ５のハッシュ値である。属性については、後に説明する。
【００４１】
なお、上でも述べたが本実施の形態を終了を表す課金リクエストのみについて実施することも可能であり、その場合には属性Acct-Status-Typeの値が２（stop）であることをさらに確認しなければならない。
【００４２】
もし、課金リクエストのパケットでなければ、通常の処理が実施される（ステップＳ１９）。これについては従来と変わりないので、ここでは説明を省略する。一方、課金リクエストのパケットであると判断されれば、代理応答処理部５１は、受信したパケットの属性に含まれるユーザＩＤ（属性User-Nameの値）を元に転送先の課金サーバを特定し、転送用の課金リクエストのパケットを生成し、記憶装置に格納する（ステップＳ３）。この際、ステータス表格納部５７に格納されているステータス表を用いる。
【００４３】
図８にステータス表の一例を示す。グループ名の行には、例えば企業名など、グループ名が格納される。図８の例では企業Ａと企業Ｂが存在している。課金サーバの行には、各グループに属する課金サーバ名が格納される。図８の例では企業ＡにはＲａｄ１という課金サーバと、Ｒａｄ２という課金サーバが設けられている。すなわち、各グループの課金サーバは、負荷分散又はバックアップ等のため一台に限定されない。企業ＢにはＲａｄ３という課金サーバと、Ｒａｄ４という課金サーバが設けられている。ステータスの行には、各課金サーバの稼動状況が格納される。稼動中であれば「ｕｐ」が、ダウンしていれば「ｄｏｗｎ」が格納される。リトライ回数の行には、各課金サーバに対して課金リクエストのパケットを再送した回数を格納している。図８の例では、Ｒａｄ１、Ｒａｄ２及びＲａｄ４については０回だが、Ｒａｄ３について２回パケットを再送している。
【００４４】
ステップＳ３では、ステータス表において転送先の課金サーバが稼動中かを確認する。例えばユーザＩＤから課金リクエストの送付先が企業Ａであると特定された場合には、企業Ａに属する課金サーバのうち稼動している課金サーバを特定する。もし、稼動している課金サーバが存在しない場合には、いずれかの課金サーバを選択する。この際、リトライ回数が少ない課金サーバを選択するような構成であってもよい。
【００４５】
代理応答処理部５１は、特定された課金サーバへ課金リクエストのパケットを送信する（ステップＳ５）。代理応答処理部５１は、所定期間、課金サーバからの課金レスポンスのパケットを待つ。そして、課金サーバから課金リクエストのパケットを受信したか判断する（ステップＳ７）。なお、１つの課金サーバから課金レスポンスを受信しない場合、上で述べたようにグループ内に複数の課金サーバが存在する場合もあるので、例えば課金レスポンスを受信するまで、当該グループ内の他の課金サーバに課金リクエストのパケットを送信するようにしても良い。また、ステータス表を参照して、グループ内の課金サーバを順番に選択して課金リクエストのパケットを送信するようにしても良い。
【００４６】
もし、課金サーバから課金レスポンスのパケットを受信した場合には、一旦記憶装置に格納し、ステータス表格納部５７に格納されたステータス表を更新する（ステップＳ１５）。例えば、課金レスポンスのパケットを送信してきた課金サーバについて、ステータス表のステータスがダウンを表している場合には、稼動（ｕｐ）に変更し、リトライ回数を０にリセットする。なお、課金レスポンスを受信する前に何台かの課金サーバに課金リクエストを送信して応答が得られなかった場合には、当該応答が得られなかった課金サーバについてのステータスを変更する必要がある場合もある。もし、ステータスが稼動（ｕｐ）を表している場合には、ダウン（ｄｏｗｎ）に変更する。もし、ステータスがダウン（ｄｏｗｎ）を表している場合には、リトライ回数を増加させる。そして、パケットの識別子などにより要求元のアクセス・サーバを特定し、課金レスポンスのパケットの送信先を変更するなどの処理を施した後、特定されたアクセス・サーバに課金レスポンスのパケットを送信する（ステップＳ１７）。そして、次の処理に移行する。
【００４７】
一方、課金サーバから課金レスポンスのパケットを受信しなかった場合には、ステータス表格納部５７に格納されたステータス表を更新する（ステップＳ９）。課金リクエストのパケットを送信したが課金レスポンスを送信してこなかった課金サーバについては、ステータス表のステータスが稼動（ｕｐ）を表している場合にはダウンを登録する。
【００４８】
そして、代理応答処理部５１は、代理応答リスト格納部５５に格納された代理応答リストに課金リクエストのパケット・データを格納する（ステップＳ１１）。
【００４９】
代理応答リストに格納されるデータは、主にパケットの属性の部分であり、図９のようになる。図９の例では、中継サーバ５の受信時刻（属性値ではない）、ユーザＩＤ等の識別情報（Use-Name）、Service-Type（ログイン（＝１）など）、Framed-Protocol（例えばＰＰＰ（＝１）など）、Framed-IP-Address（アクセス・サーバのアドレス）、Framed-IP-Netmask、Framed-Routing、Filter-Id、Framed-MTU、Login-IP-Host、Login-Service、Login-TCP-Port、Callback-Number、Callback-Id、Framed-Route、Framed-IPX-Network、Class、Vendor-Specific、Session-Timeout、Idle-Timeout、Termination-Action、Called-Station-Id、Proxy-State、Login-LAT-Group、Framed-AppleTalk-Link、Framed-AppleTalk-Netwok、Framed-AppleTalk-Zone、Acct-Status-Type（開始（＝１）や終了（＝２）など）、Acct-Delay-Time（アクセス・サーバが最初の同一パケットを送信した時からの遅延時間）、Acct-Input-Octets、Acct-Session-Id（セッションを識別するＩＤ）、Acct-Authentic、Acct-Session-Time（セッション開始からの経過時間）、Acct-Input-Packets（アクセス・サーバの入力パケット数）、Acct-Output-Packets（アクセス・サーバの出力パケット数）、Acct-Terminate-Cause、Acct-Multi-Session-Id、Acct-Link-Countが含まれる。これらについてはＲＦＣ２８６５及び２８６６に詳しく述べられているのでこれ以上述べない。
【００５０】
そして、代理応答処理部５１は、課金リクエストのパケット・データに基づき課金レスポンスのパケットを生成し、アクセス・サーバへ送信する（ステップＳ１３）。このようにすれば、アクセス・サーバが何度も課金リクエストのパケットを再送することがなくなり、ネットワークの輻輳を招くこともない。
【００５１】
次に、図１０を用いて代理応答後処理部５３の処理を説明する。代理応答後処理部５３は、例えば定期的に又は任意のタイミングで、代理応答リスト格納部５５の代理応答リストに課金リクエストのパケット・データが格納されているか判断する（ステップＳ２１）。一つでも課金リクエストのパケット・データが格納されていれば、代理応答後処理部５３は、パケット・データに含まれるユーザＩＤ（User-Name）を元に送付先を判別し、課金リクエストのパケットを生成する（ステップＳ２３）。送付先の判別は、グループ（企業）を特定するものである。グループに１つの課金サーバが設けられる場合には、課金サーバが特定される。なお、このパケット再送時からさらに遅延が生じているので、当該課金リクエストのパケット受信時刻からの経過時間を、遅延時間（Acct-Delay-Time）の値に加算して変更する。
【００５２】
そして、判別された送付先に基づきステータス表格納部５７に格納されたステータス表を検査する（ステップＳ２５）。そして、送付先グループ内の全ての課金サーバがダウンしているかどうか確認する（ステップＳ２７）。もし、ステータス表において送付先グループのうち少なくとも１つの課金サーバが稼動していると示されている場合、代理応答後処理部５７は、送付先グループのうち稼動している課金サーバを１つ選択し（ステップＳ２９）、当該課金サーバを宛先に設定して課金リクエストのパケットを送信する（ステップＳ３１）。そして、所定時間内に課金レスポンスのパケットを受信したか判断する（ステップＳ３３）。もし、課金サーバから課金レスポンスのパケットを受信した場合には、一旦記憶装置に格納し、当該受信パケット・データに基づき再送された課金リクエストに対応する課金レスポンスであることを確認できれば、受信した課金レスポンスのパケットを破棄する（ステップＳ３５）。そして、代理応答リスト格納部５５の代理応答リストから、再送したパケット・データを特定して削除する（ステップＳ３７）。そしてステップＳ５７に移行する。これにより、課金リクエストの生成元であるアクセス・サーバには重ねて課金レスポンスが送付されることはなくなる。すなわち、ＩＰネットワーク１のトラフィックを増加させることはなく、またアクセス・サーバの構成を変更する必要もない。
【００５３】
一方、課金レスポンスのパケットを所定時間内に受信しなかった場合には、代理応答後処理部５５は、ステータス表格納部５７のステータス表において、課金レスポンスを返送してこなかった課金サーバのステータスをダウンに更新する（ステップＳ３９）。そして、ステータス表を参照して、同じ送付先グループ内に、未送付の稼動している課金サーバが存在しているか判断する（ステップＳ４１）。もし、存在している場合にはステップＳ２９に戻る。一方、存在しない場合にはステップＳ５７に移行する。
【００５４】
ステップＳ２７においてステータス表において送付先グループ内の全ての課金サーバがダウンしていると判断された場合には、送付先グループの課金サーバのうちリトライ回数が少ない課金サーバを選択し（ステップＳ４３）、当該課金サーバを宛先に設定して課金リクエストのパケットを送信する（ステップＳ４５）。そして、所定時間内に課金レスポンスのパケットを受信したか判断する（ステップＳ４７）。もし、課金サーバから課金レスポンスのパケットを受信した場合には、一旦記憶装置に格納し、当該受信パケット・データに基づき再送された課金リクエストに対応する課金レスポンスであることを確認できれば、受信した課金レスポンスのパケットを破棄する（ステップＳ４９）。そして、代理応答リスト格納部５５の代理応答リストから、再送したパケット・データを特定して削除する（ステップＳ５１）。また、ステータス表において課金サーバはダウンしたと記録されていたため、ステータス表において課金レスポンスを返信してきた課金サーバのステータスを稼動（ｕｐ）に、リトライ回数を０に更新する（ステップＳ５３）。そしてステップＳ５７に移行する。これにより、課金リクエストの生成元であるアクセス・サーバには重ねて課金レスポンスが送付されることはなくなる。すなわち、ＩＰネットワーク１のトラフィックを増加させることはなく、またアクセス・サーバの構成を変更する必要もない。
【００５５】
一方、課金レスポンスのパケットを所定時間内に受信しなかった場合には、代理応答後処理部５５は、ステータス表格納部５７のステータス表において、課金レスポンスを返送してこなかった課金サーバのリトライ回数を１インクリメントするように更新する（ステップＳ５５）。そしてステップＳ５７に移行する。
【００５６】
ステップＳ２１において一つも代理応答リストにパケット・データが格納されていなかったと判断された場合にはステップＳ５７に移行する。ステップＳ４１で未送付の稼動している課金サーバが無いと判断された場合、ステップＳ３７、ステップＳ５３又はステップＳ５５の後に、処理終了すべきか判断される（ステップＳ５７）。処理終了しない場合にはステップＳ２１に戻る。それ以外は処理を終了する。
【００５７】
以上本発明の一実施の形態について説明したが、本発明はこれに限定されない。例えば上ではＲＡＤＩＵＳサーバのシステムにおいて本発明を適用する例を説明したが、これに類似の状況が生ずる場合には、本発明を適用することができる。また、アクセス・サーバは、例えばルータなどの接続機器の場合もあるが、これらも本願ではコンピュータとして取り扱う。また、中継サーバ５の本発明に関連する機能を代理応答処理部５１及び代理応答後処理部５３とに分けたが、これは一例であって他の態様に分けることもできる。また、企業Ａや企業Ｂから提供されるサービスは認証や課金だけでなく、例えば有料コンテンツの提供などのサーバが設けられる場合もある。
【００５８】
（付記１）
第１のコンピュータからパケットを受信した場合、当該パケット・データに含まれるユーザ識別情報から転送先の第２のコンピュータを特定するステップと、特定された前記転送先の第２のコンピュータに、前記パケット・データに基づくパケットを送信するステップと、
前記転送先の第２のコンピュータから所定期間内にレスポンスを受信しない場合、前記パケット・データを記憶装置に保存すると共に、前記パケット・データに対応するレスポンスを生成し、前記第１のコンピュータに送信するステップと、
を含む代理応答方法。
【００５９】
（付記２）
所定のタイミングにて前記記憶装置に保存されたパケット・データを読み出して、当該パケット・データに含まれるユーザ識別情報から転送先の第２のコンピュータを特定する第２特定ステップと、
特定された前記転送先の第２のコンピュータに、読み出された前記パケット・データに基づくパケットを送信するステップと、
前記転送先の第２のコンピュータから所定期間内にレスポンスを受信した場合、当該レスポンスと、前記記憶装置に保存された、対応する前記パケット・データとを破棄するステップと、
をさらに含む付記１記載の代理応答方法。
【００６０】
（付記３）
少なくとも、前記記憶装置に保存されたパケット・データに含まれる遅延時間を表すデータを当該パケット・データを受信した時刻からの経過時間に基づき変更することにより、前記読み出された前記パケット・データに基づくパケットを生成するステップ
をさらに含むことを特徴とする付記２記載の代理応答方法。
【００６１】
（付記４）
前記転送先の第２のコンピュータからのレスポンスの有無に基づき、当該転送先の第２のコンピュータの稼動状況に関するデータを記憶装置に記録するステップ
をさらに含む付記２記載の代理応答方法。
【００６２】
（付記５）
前記第２特定ステップが、
所定のタイミングにて前記記憶装置に保存されたパケット・データを読み出して、当該パケット・データに含まれるユーザ識別情報及び前記稼動状況に関するデータを用いて、転送先の第２のコンピュータを特定するステップ
であることを特徴とする付記４記載の代理応答方法。
【００６３】
（付記６）
前記稼動状況に関するデータが、前記転送先の第２のコンピュータ毎にパケットの再送回数のデータを含むことを特徴とする付記５記載の代理応答方法。
【００６４】
（付記７）
前記パケット・データが課金リクエストに関するデータであるか判断するステップをさらに含むことを特徴とする付記１乃至６のいずれか１つ記載の代理応答方法。
【００６５】
（付記８）
前記パケット・データが課金終了についての課金リクエストに関するデータであるか判断するステップをさらに含むことを特徴とする付記１乃至６のいずれか１つ記載の代理応答方法。
【００６６】
（付記９）
前記第２のコンピュータがラディウス・サーバであることを特徴とする付記１乃至８のいずれか１つ記載の代理応答方法。
【００６７】
（付記１０）
付記１乃至１０のいずれか１つ記載の代理応答方法をコンピュータに実行させるためのプログラム。
【００６８】
（付記１１）
第１のコンピュータからパケットを受信した場合、当該パケット・データに含まれるユーザ識別情報から転送先の第２のコンピュータを特定する手段と、
特定された前記転送先の第２のコンピュータに、前記パケット・データに基づくパケットを送信する手段と、
前記転送先の第２のコンピュータから所定期間内にレスポンスを受信しない場合、前記パケット・データを記憶装置に保存すると共に、前記パケット・データに対応するレスポンスを生成し、前記第１のコンピュータに送信する手段と、
を有する中継コンピュータ。
【００６９】
【発明の効果】
以上のように、本発明により、障害時のトラフィックの増加を防止することができる。
【００７０】
また、障害時のトラフィックの増加を招くパケットの再送を防止することができる。
【００７１】
さらに、課金リクエストに係るパケットの喪失を防止し、正確な課金情報を取得できるようになる。
【図面の簡単な説明】
【図１】本発明の一実施の形態におけるシステム構成例を示す図である。
【図２】全体の処理フローを示す図である。
【図３】全体の処理フロー（続き）を示す図である。
【図４】課金サーバに障害が生じた場合の処理を示す図である。
【図５】本発明の一実施の形態に係る処理フローを示す図である。
【図６】中継サーバの処理フローを示す図である。
【図７】パケット・フォーマットを示す図である。
【図８】ステータス表の一例を示す図である。
【図９】代理応答リストに格納されるデータの一例を示す図である。
【図１０】中継サーバの処理フローを示す図である。
【符号の説明】
１ ＩＰネットワーク
３ アクセス・サーバ
５ 中継サーバ
７，２５，２７，２９ ユーザ端末
９，２３ 公衆回線網
１１ インターネット
１３ａ，１５ａ 課金サーバ
１３ｂ，１５ｂ 認証サーバ
１７，１９ 認証ＤＢ
１８，２０ 課金ＤＢ
５１ 代理応答処理部
５３ 代理応答後処理部
５５ 代理応答リスト格納部
５７ ステータス表格納部
【発明が属する技術分野】
本発明は、パケットを中継するコンピュータにおける代理応答技術に関する。
【０００２】
【従来の技術】
ラディウス（RADIUS:Remote Authentication Dial In-User Service）サーバは、例えば公衆回線網及び当該公衆回線網に接続しているアクセス・サーバを介してユーザ端末からユーザ認証情報を受信すると、ユーザ認証処理を実施し、ＤＮＳ（Domain Name Sysyem）サーバ指定やＰＰＰ（Point-to-Point Protocol）接続指定等の接続制御や、課金に必要な情報を取得したりするサーバである。これらの処理が完了すると、ユーザ端末は例えばインターネットへの接続を許可されたり、特別なサービスを受けることができるようになる。ＲＡＤＩＵＳプロトコルについては、ＲＦＣ（Request For Comments）２８６５及びＲＦＣ２８６６に規定がなされている。ＲＡＤＩＵＳプロトコルは、ＵＤＰ（User Datagram Protocol）を用いている。
【０００３】
例えば複数のアクセスポイントにアクセス・サーバを設けて、このアクセス・サーバをネットワークで接続し、当該ネットワークを例えばＩＳＰ（Internet Service Provider）等の企業に開放するというサービスがある。このサービスを利用する企業は、自己のシステムに大きな変更を加えることなくユーザに対してアクセス手段を増やすことができる。各企業は、ＲＡＤＩＵＳサーバを用意して、上記ネットワークに接続する。ネットワークには、ユーザからの要求を当該ユーザに対してサービスを行う企業のＲＡＤＩＵＳサーバに振り分けるために中継サーバが設けられる。この中継サーバでは、転送結果を記録してネットワークの使用量を正確に把握して正確な課金を行ったり、パケットの内容を確認して変更したりする。
【０００４】
このような環境において、１つの企業のＲＡＤＩＵＳサーバが障害などでダウンしてしまうと、リクエストに対するレスポンスが得られないために、アクセス・サーバは同じリクエストに係るパケットを何度も再送する。そのためネットワークのトラフィックが増加して、正常に動作している他の企業のＲＡＤＩＵＳサーバに対してもレスポンスの低下を招いてしまうという問題がある。また、通常送信したパケットはアクセスサーバ側で管理しているが、再送によるトラフィックの増加によりアクセス・サーバのバッファ・オーバーフローが発生し、パケットが失われてしまう場合もあり、正確に課金できない可能性がある。中継サーバやアクセス・サーバのログを調べて障害中に送信されていたパケットを探し、企業側にその情報を通知しなければならないが、量が多いため不可能な場合も多い。
【０００５】
【発明が解決しようとする課題】
このように障害時のトラフィックの増加は非常に問題が多い。
【０００６】
従って、本発明の目的は、障害時のトラフィックの増加を防止する技術を提供することである。
【０００７】
また本発明の他の目的は、障害時のトラフィックの増加を招くパケットの再送を防止するための技術を提供することである。
【０００８】
さらに本発明の他の目的は、課金リクエストに係るパケットの喪失を防止し、正確な課金情報の取得を可能とする技術を提供することである。
【０００９】
【課題を解決するための手段】
上記目的を解決するため本発明に係る代理応答方法は、第１のコンピュータ（例えば実施の形態におけるアクセス・サーバ。ルータのような接続機器の場合もある）からパケットを受信した場合、当該パケット・データに含まれるユーザ識別情報から転送先の第２のコンピュータ（例えば実施の形態における課金サーバ（ＲＡＤＩＵＳサーバ））を特定するステップと、特定された転送先の第２のコンピュータに、パケット・データに基づくパケットを送信するステップと、転送先の第２のコンピュータから所定期間内にレスポンスを受信しない場合、パケット・データを記憶装置（例えば実施の形態における代理応答リスト）に保存すると共に、パケット・データに対応するレスポンスを生成し、第１のコンピュータに送信するステップとを含む。
【００１０】
このようにすれば、第１のコンピュータはレスポンスを得ることができるので、パケットを何度も再送して、ネットワークの輻輳を招くことがなくなる。また、記憶装置にパケット・データが保存されるので、代理応答を行うコンピュータにおいて後で第２のコンピュータに送付できるようになる。
【００１１】
また、本発明において、所定のタイミングにて記憶装置に保存されたパケット・データを読み出して、当該パケット・データに含まれるユーザ識別情報から転送先の第２のコンピュータを特定する第２特定ステップと、特定された転送先の第２のコンピュータに、読み出されたパケット・データに基づくパケットを送信するステップと、転送先の第２のコンピュータから所定期間内にレスポンスを受信した場合、当該レスポンスと、記憶装置に保存された、対応するパケット・データとを破棄するステップとをさらに含むような構成であってもよい。
【００１２】
このようにすれば、第２のコンピュータにおいても正常どおり応答したものとして処理できる。すなわち第２のコンピュータについては何ら本発明を採用するに当たって変更を要しない。また、代理応答を行うコンピュータにおいて第２のコンピュータからのレスポンスを破棄するので、第１のコンピュータにおいても変更を要しない。
【００１３】
さらに、本発明において、少なくとも、記憶装置に保存されたパケット・データに含まれる遅延時間を表すデータを当該パケット・データを受信した時刻からの経過時間に基づき変更することにより、読み出されたパケット・データに基づくパケットを生成するステップをさらに含むような構成であってもよい。
【００１４】
このようにすれば、第２のコンピュータはパケットをどの程度遅れて受信したかを判断することができるようになる。例えば課金リクエストに係るパケットを第１のコンピュータが送信している場合には、第２のコンピュータは第１のコンピュータの課金リクエスト送信時を得ることができるようになるので、正確な課金を行うことができるようになる。
【００１５】
本発明において、パケット・データが課金リクエストに関するデータであるか判断するステップをさらに含むような構成であってもよい。第２のコンピュータでは、課金リクエストに応じて取得するデータに基づき二重ログインチェック等を行う場合もあり、正確な課金と共に正確なログインチェックという点においても重要である。なお、課金リクエストについては開始時の課金リクエストと終了時の課金リクエストがあるが、終了時の課金リクエストは正確な課金情報の取得という点において非常に重要である。
【００１６】
なお、上述の方法はプログラムにて実施することができ、このプログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークなどを介して配布される場合もある。尚、中間的な処理結果はメモリ等の記憶装置に一時保管される。
【００１７】
【発明の実施の形態】
図１に本発明の一実施の形態に係るシステム概要図を示す。例えばパーソナル・コンピュータであるユーザ端末７は公衆回線網９を介してアクセス・サーバＡ（３）に接続する。また、例えばノート型コンピュータであるユーザ端末２７も公衆回線網９を介してアクセス・サーバＡ（３）に接続する。例えばパーソナル・コンピュータであるユーザ端末２５は、公衆回線網２３を介してアクセス・サーバＢ（２１）に接続する。また、例えばＰＤＡ（Personal Digital Asistance）であるユーザ端末２９も公衆回線網２３を介してアクセス・サーバＢ（２１）に接続する。端末の種類及び数は、これらに限定されるものではなく、携帯電話機が用いられる場合もある。また、アクセス・サーバは、サーバのようなコンピュータであってもよいし、ルータのような接続機器であっても良いが、ここではこれらをコンピュータとして説明する。また、公衆回線網に接続するアクセス・サーバの数は２に限定されるものではなく、より多くのアクセス・サーバを設けることができる。
【００１８】
アクセス・サーバＡ（３）及びアクセス・サーバＢ（２１）は、ＩＰ（Internet Protocol）ネットワーク１に接続されている。ＩＰネットワーク１は例えばインターネット１１にも接続されている。また、ＩＰネットワーク１には、中継サーバ５も接続されている。図１では中継サーバは１台しか設けられていないが、複数台設ける場合もある。中継サーバ５は、企業ＡのＲＡＤＩＵＳサーバである課金サーバ１３ａ及び認証サーバ１３ｂに接続されている。また、企業ＢのＲＡＤＩＵＳサーバである課金サーバ１５ａ及び認証サーバ１５ｂに接続されている。中継サーバ５に接続される企業のＲＡＤＩＵＳサーバの数は２に限定されない。また、ここでは説明のため課金サーバ及び認証サーバを分けて説明しているが、これらは１台のサーバにてその機能を実現することも可能である。また、バックアップや処理負荷分散のために多くの課金サーバや認証サーバを一つの企業が用意する場合もある。課金サーバ１３ａは企業Ａのユーザの課金情報を蓄積する課金ＤＢ１８を管理しており、認証サーバ１３ｂは企業Ａのユーザの認証情報を格納する認証ＤＢ１７を管理している。課金サーバ１５ａは企業Ｂのユーザの課金情報を蓄積する課金ＤＢ１９を管理しており、認証サーバ１５ｂは企業Ｂのユーザの認証情報を格納する認証ＤＢ２０を管理している。
【００１９】
中継サーバ５には、代理応答処理部５１と代理応答後処理部５３とが設けられている。これらの処理内容については後に図を用いて説明する。また、中継サーバ５は、中継サーバ５が代理応答したリクエストについてのパケット・データを格納する代理応答リスト格納部５５及び中継サーバ５が中継するＲＡＤＩＵＳサーバの稼動状況に関する情報についてのステータス表を格納するステータス表格納部５７を有する。
【００２０】
次に図２乃至図４を用いて、図１に示したアクセス・サーバ（ここではアクセス・サーバＡ（３））、中継サーバ５、認証サーバ（ここでは認証サーバ１３ｂ）、課金サーバ（ここでは課金サーバ１３ａ）の従来における処理を説明する。
【００２１】
最初に、例えばユーザ端末７からログイン要求を受信するとアクセス・サーバＡ（３）は、認証リクエスト（Access-Request）のパケットを生成し、中継サーバ５に送信する（ステップ（１））。中継サーバ５は、アクセス・サーバＡ（３）から認証リクエストのパケットを受信すると一旦記憶装置に格納し、パケット・データに含まれるユーザＩＤ等のユーザ識別情報を元に転送先のＲＡＤＩＵＳサーバを特定すると共にパケットの送信先を変更するなどの処理を施した後、認証リクエストのパケットを認証サーバ１３ｂに転送する（ステップ（２））。
【００２２】
認証サーバ１３ｂは、中継サーバ５から認証リクエストのパケットを受信すると一旦記憶装置に格納し、認証ＤＢ１７に格納されたデータを用いて認証処理を実施する（ステップ（３））。認証処理については従来と何ら変わりがないので、これ以上述べない。ここでは認証に成功したものとする。そうすると、認証サーバ１３ｂは、認証レスポンス（Access-Accept）のパケットを生成し、中継サーバ５に送信する（ステップ（４））。中継サーバ５は、認証サーバ１３ｂから認証レスポンスのパケットを受信すると一旦記憶装置に格納し、パケット・データを確認して送信先のアクセス・サーバ（ここではアクセス・サーバＡ（３））を特定し、パケットの送信先を変更するなどの処理を施した後、認証レスポンスのパケットをアクセス・サーバＡ（３）に転送する（ステップ（５））。アクセス・サーバＡ（３）は、中継サーバ５から認証レスポンスのパケットを受信する。ここまでの処理で、認証が完了し、ＰＰＰセッションが確立される（ステップ（６））。
【００２３】
次に、アクセス・サーバＡ（３）は、開始（後に述べるが属性Acct-Status-Typeの値が１（Start））を表す課金リクエスト（Accounting-Request）のパケットを生成し、中継サーバ５に送信する（ステップ（７））。中継サーバ５は、アクセス・サーバＡ（３）から開始を表す課金リクエストのパケットを受信すると一旦記憶装置に格納し、パケット・データに含まれるユーザＩＤ等のユーザ識別情報を元に転送先のＲＡＤＩＵＳサーバを特定すると共にパケットの送信先を変更するなどの処理を施した後、開始を表す課金リクエストのパケットを課金サーバ１３ａに転送する（ステップ（８））。
【００２４】
課金サーバ１３ａは、中継サーバ５から開始を表す課金リクエストのパケットを受信すると一旦記憶装置に格納し、課金処理を実施する（ステップ（９））。すなわち、課金開始を認識し、課金開始を課金ＤＢ１８に登録する。そして、課金サーバ１３ａは、課金レスポンス（Accounting-Response）のパケットを生成し、中継サーバ５に送信する（ステップ（１０））。中継サーバ５は、課金サーバ１３ａから課金レスポンスのパケットを受信すると一旦記憶装置に格納し、パケット・データを確認して送信元のアクセス・サーバ（ここではアクセス・サーバＡ（３））を特定し、パケットの送信先を変更するなどの処理を施した後、課金レスポンスのパケットをアクセス・サーバＡ（３）に転送する（ステップ（１１））。アクセス・サーバＡ（３）は、中継サーバ５から課金レスポンスのパケットを受信する。ここまでの処理でユーザ端末７は通信を開始することができるようになる（ステップ（１２））。すなわち、例えばインターネットへのアクセスが可能となる。
【００２５】
一方、例えばユーザ端末７からログオフ要求（通信終了通知など）を受信するとアクセス・サーバＡ（３）は、終了（後に述べるが属性Acct-Status-Typeの値が２（Stop））を表す課金リクエスト（Accounting-Request）のパケットを生成し、中継サーバ５に送信する（ステップ（２１））。中継サーバ５は、アクセス・サーバＡ（３）から終了を表す課金リクエストのパケットを受信すると一旦記憶装置に格納し、パケット・データに含まれるユーザＩＤ等のユーザ識別情報を元に転送先のＲＡＤＩＵＳサーバを特定すると共にパケットの送信先を変更するなどの処理を施した後、終了を表す認証リクエストのパケットを課金サーバ１３ａに転送する（ステップ（２２））。
【００２６】
課金サーバ１３ａは、中継サーバ５から終了を表す課金リクエストのパケットを受信すると一旦記憶装置に格納し、課金処理を実施する（ステップ（２３））。すなわち、課金終了を認識し、課金終了を課金ＤＢ１８に登録する。そして、課金サーバ１３ａは、課金レスポンス（Accounting-Response）のパケットを生成し、中継サーバ５に送信する（ステップ（２４））。中継サーバ５は、課金サーバ１３ａから課金レスポンスのパケットを受信すると一旦記憶装置に格納し、パケット・データを確認して送信元のアクセス・サーバ（ここではアクセス・サーバＡ（３））を特定し、パケットの送信先を変更するなどの処理を施した後、課金レスポンスのパケットをアクセス・サーバＡ（３）に転送する（ステップ（２５））。アクセス・サーバＡ（３）は、中継サーバ５から課金レスポンスのパケットを受信する。このような処理によりユーザ端末７との通信は終了する（ステップ（２６））。
【００２７】
図２及び図３では課金サーバ１３ａも認証サーバ１３ｂも通常どおり稼動している場合の処理フローである。もし、課金サーバ１３ａがダウンしている場合には、図４のような処理が実施される。すなわち、アクセス・サーバＡ（３）は、課金リクエストのパケットを生成すると、中継サーバ５に送信する（ステップ（３１））。中継サーバ５は、アクセス・サーバＡ（３）から課金リクエストのパケットを受信すると一旦記憶装置に格納し、パケット・データに含まれるユーザＩＤ等のユーザ識別情報を元に転送先のＲＡＤＩＵＳサーバを特定すると共にパケットの送信先を変更するなどの処理を施した後、課金リクエストのパケットを課金サーバ１３ａに転送する（ステップ（３２））。
【００２８】
しかし、課金サーバ１３ａがダウンしているために応答がない。従って、所定期間経過後、アクセス・サーバＡ（３）は、課金リクエストのパケットを中継サーバ５に送信する（ステップ（３３））。なお、本課金リクエストでは、セッションＩＤ（属性のAcct-Session-ID）が前に送信した課金リクエストのセッションＩＤと同じであり、遅延時間（属性のAcct-Delay-time）が最初のパケット送信時からの経過時間分加算された値となっている。中継サーバ５は、アクセス・サーバＡ（３）から課金リクエストのパケットを受信すると一旦記憶装置に格納し、パケット・データに含まれるユーザＩＤ等のユーザ識別情報を元に転送先のＲＡＤＩＵＳサーバを特定すると共にパケットの送信先を変更するなどの処理を施した後、課金リクエストのパケットを課金サーバ１３ａに転送する（ステップ（３４））。
【００２９】
同様に課金サーバ１３ａがダウンしているため応答がない。応答がないので、アクセス・サーバＡ（３）は、上で述べた処理を繰り返さなければならない。課金サーバ１３ａに課金リクエストを送信するすべてのアクセス・サーバが同じ処理を実施する。これにより、ＩＰネットワーク１に輻輳が生じてしまう。
【００３０】
本実施の形態では、図５に示すような処理を実施することにより、図４で生じるようなネットワークの輻輳を防止する。すなわち、アクセス・サーバＡ（３）は、課金リクエストのパケットを生成し、中継サーバ５に送信する（ステップ（４１））。中継サーバ５は、アクセス・サーバＡ（３）から課金リクエストのパケットを受信すると一旦記憶装置に格納し、パケット・データに含まれるユーザＩＤ等のユーザ識別情報を元に転送先のＲＡＤＩＵＳサーバを特定すると共にパケットの送信先を変更するなどの処理を施した後、課金リクエストのパケットを課金サーバ１３ａに転送する（ステップ（４２））。ここまでは従来と同じである。
【００３１】
しかし、課金サーバ１３ａがダウンしていると課金レスポンスは送られてこないので、中継サーバ５は、所定期間内に課金レスポンスを課金サーバ１３ａから受信しない場合には、課金リクエストのパケット・データを代理応答リスト格納部５５に格納し、当該課金リクエストのパケット・データから課金レスポンスを生成し、代理で課金レスポンスのパケットをアクセス・サーバＡ（３）に返信する（ステップ（４３））。このようにすれば、アクセス・サーバＡ（３）が何度も同じ課金リクエストを送信するような事態を避けることができる。なお、中継サーバ５は、課金サーバ１３ａのダウンをステータス表格納部５７のステータス表に登録する。
【００３２】
中継サーバ５は、所定の周期又は任意のタイミングにて、代理応答リスト格納部５５に格納された課金リクエストのパケット・データを読み出して、課金リクエストのパケットを生成し、課金サーバ１３ａに送信してみる（ステップ（４４））。この際、パケット・データに含まれるユーザＩＤから送信先である課金サーバ１３ａを特定し、またパケット・データに含まれる遅延時間を当該課金リクエストのパケットを受信した時刻からの経過時間分増加させるといった変更処理を実施している。
【００３３】
もし、課金サーバ１３ａが既に復帰している場合には、中継サーバ５から課金リクエストのパケットを受信すると、課金処理を実施する（ステップ（４５））。なお、開始を表す課金リクエストの場合には、課金開始を認識し、課金開始に関する情報を課金ＤＢ１８に登録する。終了を表す課金リクエストの場合には、課金終了を認識し、課金終了に関する情報を課金ＤＢ１８に登録する。なお、上でも述べたように遅延時間は中継サーバ５により変更されているが、従来でもこの遅延時間を考慮して課金開始及び課金終了についての情報を登録するようになっているので、課金ＤＢ１８に登録される情報としては問題が生じない。すなわち、本実施の形態を採用してもＲＡＤＩＵＳサーバについて修正・変更は必要ない。
【００３４】
なお、課金サーバ１３ａがまだ復帰していない場合には、中継サーバ５は課金リクエストのパケットを再送することはなく、この段階で課金サーバ１３ａへの送信を中止する。
【００３５】
課金処理を実施すると、課金サーバ１３ａは、課金レスポンスのパケットを生成し、中継サーバ５に送信する（ステップ（４６））。中継サーバ５は、課金サーバ１３ａからの課金レスポンスのパケットを受信すると一旦記憶装置に格納するが、ステップ（４４）において送信した課金リクエストに対応する課金レスポンスのパケットであることを判別すると、当該課金レスポンスのパケットを破棄する（ステップ（４７））。既に代理応答しているため、中継サーバ５がこのパケットをアクセス・サーバＡ（３）に送信してもネットワークのトラフィックを増加させるだけで何らの利益もないからである。従って、アクセス・サーバＡ（３）は、中継サーバ５が代理応答することによって新たに必要になる処理や、変更が必要となる処理はない。なお、中継サーバ５は、代理応答リスト格納部５５に格納してあった本処理に係る課金レスポンスのパケット・データを破棄する処理も実施する。
【００３６】
以上のような処理を実施することにより、課金サーバ１３ａの障害時に、ＩＰネットワーク１のトラフィックを増加させることはなくなる。また、アクセス・サーバにおけるバッファ限界が生じ、パケット破棄などによる課金リクエストのパケットロストが生じることを防止することもできるようになる。また、再送を繰り返さなくなるため、アクセス・サーバの負荷増加を防止することも可能となる。また、一つの企業のＲＡＤＩＵＳサーバのダウンによる他の企業への影響を軽減することができる。さらに、中継サーバ５の代理応答リスト格納部５５に代理応答の処理対象となった課金リクエストのパケットは格納されており、後にあたかも通常の処理のように課金サーバに送信されるので、課金サーバにおける障害復旧作業が大幅に軽減される。課金リクエストの処理が適正になされれば、適正な課金処理も行うことができる。
【００３７】
なお、図５では開始を表す課金リクエストと終了を表す課金リクエストとを区別しなかったが、本実施の形態においては両方に対して実施することができる。但し、中継サーバ５の処理負荷や代理応答リスト格納部５５の容量、課金の確実性といった観点からすれば、終了を表す課金リクエストについて図５のような処理を実施する方が好ましい場合もある。上でも述べたが、終了を表す課金リクエストか否かは、パケット・データの属性Acct-Status-Typeの値が２（Stop）であるか否かを判断すればよい。
【００３８】
次に、図５のような処理を実施するための中継サーバ５の処理をより詳細に説明する。中継サーバ５の代理応答処理部５１の処理を図６に示す。図６において、代理応答処理部５１は、パケットを受信すると一旦記憶装置に格納し、当該パケットが課金リクエストのパケットか否かを判断する（ステップＳ１）。なお、課金リクエストのパケットか否かは、パケットのコードにて判断できる。
【００３９】
図７にＲＡＤＩＵＳにおけるパケットのフォーマットを示す。図７の例で示すように、パケットは、コード（code）、識別子（identifier）、長さ（length）、オーセンティケータ（Authenticator）、属性（Attribute）で構成される。属性のデータは可変長であり、属性のタイプ（type）、長さ（length）、及び可変長の値（value）を各属性につき保持する。このパケットのデータはＵＤＰパケットのデータ・フィールドにカプセル化される。
【００４０】
コードは、パケットの種類を表し、例えば１は認証リクエスト（Access-Request）、２は許可を表す認証レスポンス（Access-Accept）、３は拒否を表す認証レスポンス（Access-Reject）、４は課金リクエスト（Accounting-Reqest）、５は課金レスポンス（Accounting-Response）を表す。従って、代理応答処理部５１はパケットのコードが４であるかを判断する。また、識別子は、リクエストとその応答を対応付けるために用いるデータである。長さは、コード、識別子、オーセンティケータ及び属性フィールドの長さを示す。オーセンティケータは、このパケットの認証を行うためのデータであって、コード、識別子及び長さ等のＭＤ５のハッシュ値である。属性については、後に説明する。
【００４１】
なお、上でも述べたが本実施の形態を終了を表す課金リクエストのみについて実施することも可能であり、その場合には属性Acct-Status-Typeの値が２（stop）であることをさらに確認しなければならない。
【００４２】
もし、課金リクエストのパケットでなければ、通常の処理が実施される（ステップＳ１９）。これについては従来と変わりないので、ここでは説明を省略する。一方、課金リクエストのパケットであると判断されれば、代理応答処理部５１は、受信したパケットの属性に含まれるユーザＩＤ（属性User-Nameの値）を元に転送先の課金サーバを特定し、転送用の課金リクエストのパケットを生成し、記憶装置に格納する（ステップＳ３）。この際、ステータス表格納部５７に格納されているステータス表を用いる。
【００４３】
図８にステータス表の一例を示す。グループ名の行には、例えば企業名など、グループ名が格納される。図８の例では企業Ａと企業Ｂが存在している。課金サーバの行には、各グループに属する課金サーバ名が格納される。図８の例では企業ＡにはＲａｄ１という課金サーバと、Ｒａｄ２という課金サーバが設けられている。すなわち、各グループの課金サーバは、負荷分散又はバックアップ等のため一台に限定されない。企業ＢにはＲａｄ３という課金サーバと、Ｒａｄ４という課金サーバが設けられている。ステータスの行には、各課金サーバの稼動状況が格納される。稼動中であれば「ｕｐ」が、ダウンしていれば「ｄｏｗｎ」が格納される。リトライ回数の行には、各課金サーバに対して課金リクエストのパケットを再送した回数を格納している。図８の例では、Ｒａｄ１、Ｒａｄ２及びＲａｄ４については０回だが、Ｒａｄ３について２回パケットを再送している。
【００４４】
ステップＳ３では、ステータス表において転送先の課金サーバが稼動中かを確認する。例えばユーザＩＤから課金リクエストの送付先が企業Ａであると特定された場合には、企業Ａに属する課金サーバのうち稼動している課金サーバを特定する。もし、稼動している課金サーバが存在しない場合には、いずれかの課金サーバを選択する。この際、リトライ回数が少ない課金サーバを選択するような構成であってもよい。
【００４５】
代理応答処理部５１は、特定された課金サーバへ課金リクエストのパケットを送信する（ステップＳ５）。代理応答処理部５１は、所定期間、課金サーバからの課金レスポンスのパケットを待つ。そして、課金サーバから課金リクエストのパケットを受信したか判断する（ステップＳ７）。なお、１つの課金サーバから課金レスポンスを受信しない場合、上で述べたようにグループ内に複数の課金サーバが存在する場合もあるので、例えば課金レスポンスを受信するまで、当該グループ内の他の課金サーバに課金リクエストのパケットを送信するようにしても良い。また、ステータス表を参照して、グループ内の課金サーバを順番に選択して課金リクエストのパケットを送信するようにしても良い。
【００４６】
もし、課金サーバから課金レスポンスのパケットを受信した場合には、一旦記憶装置に格納し、ステータス表格納部５７に格納されたステータス表を更新する（ステップＳ１５）。例えば、課金レスポンスのパケットを送信してきた課金サーバについて、ステータス表のステータスがダウンを表している場合には、稼動（ｕｐ）に変更し、リトライ回数を０にリセットする。なお、課金レスポンスを受信する前に何台かの課金サーバに課金リクエストを送信して応答が得られなかった場合には、当該応答が得られなかった課金サーバについてのステータスを変更する必要がある場合もある。もし、ステータスが稼動（ｕｐ）を表している場合には、ダウン（ｄｏｗｎ）に変更する。もし、ステータスがダウン（ｄｏｗｎ）を表している場合には、リトライ回数を増加させる。そして、パケットの識別子などにより要求元のアクセス・サーバを特定し、課金レスポンスのパケットの送信先を変更するなどの処理を施した後、特定されたアクセス・サーバに課金レスポンスのパケットを送信する（ステップＳ１７）。そして、次の処理に移行する。
【００４７】
一方、課金サーバから課金レスポンスのパケットを受信しなかった場合には、ステータス表格納部５７に格納されたステータス表を更新する（ステップＳ９）。課金リクエストのパケットを送信したが課金レスポンスを送信してこなかった課金サーバについては、ステータス表のステータスが稼動（ｕｐ）を表している場合にはダウンを登録する。
【００４８】
そして、代理応答処理部５１は、代理応答リスト格納部５５に格納された代理応答リストに課金リクエストのパケット・データを格納する（ステップＳ１１）。
【００４９】
代理応答リストに格納されるデータは、主にパケットの属性の部分であり、図９のようになる。図９の例では、中継サーバ５の受信時刻（属性値ではない）、ユーザＩＤ等の識別情報（Use-Name）、Service-Type（ログイン（＝１）など）、Framed-Protocol（例えばＰＰＰ（＝１）など）、Framed-IP-Address（アクセス・サーバのアドレス）、Framed-IP-Netmask、Framed-Routing、Filter-Id、Framed-MTU、Login-IP-Host、Login-Service、Login-TCP-Port、Callback-Number、Callback-Id、Framed-Route、Framed-IPX-Network、Class、Vendor-Specific、Session-Timeout、Idle-Timeout、Termination-Action、Called-Station-Id、Proxy-State、Login-LAT-Group、Framed-AppleTalk-Link、Framed-AppleTalk-Netwok、Framed-AppleTalk-Zone、Acct-Status-Type（開始（＝１）や終了（＝２）など）、Acct-Delay-Time（アクセス・サーバが最初の同一パケットを送信した時からの遅延時間）、Acct-Input-Octets、Acct-Session-Id（セッションを識別するＩＤ）、Acct-Authentic、Acct-Session-Time（セッション開始からの経過時間）、Acct-Input-Packets（アクセス・サーバの入力パケット数）、Acct-Output-Packets（アクセス・サーバの出力パケット数）、Acct-Terminate-Cause、Acct-Multi-Session-Id、Acct-Link-Countが含まれる。これらについてはＲＦＣ２８６５及び２８６６に詳しく述べられているのでこれ以上述べない。
【００５０】
そして、代理応答処理部５１は、課金リクエストのパケット・データに基づき課金レスポンスのパケットを生成し、アクセス・サーバへ送信する（ステップＳ１３）。このようにすれば、アクセス・サーバが何度も課金リクエストのパケットを再送することがなくなり、ネットワークの輻輳を招くこともない。
【００５１】
次に、図１０を用いて代理応答後処理部５３の処理を説明する。代理応答後処理部５３は、例えば定期的に又は任意のタイミングで、代理応答リスト格納部５５の代理応答リストに課金リクエストのパケット・データが格納されているか判断する（ステップＳ２１）。一つでも課金リクエストのパケット・データが格納されていれば、代理応答後処理部５３は、パケット・データに含まれるユーザＩＤ（User-Name）を元に送付先を判別し、課金リクエストのパケットを生成する（ステップＳ２３）。送付先の判別は、グループ（企業）を特定するものである。グループに１つの課金サーバが設けられる場合には、課金サーバが特定される。なお、このパケット再送時からさらに遅延が生じているので、当該課金リクエストのパケット受信時刻からの経過時間を、遅延時間（Acct-Delay-Time）の値に加算して変更する。
【００５２】
そして、判別された送付先に基づきステータス表格納部５７に格納されたステータス表を検査する（ステップＳ２５）。そして、送付先グループ内の全ての課金サーバがダウンしているかどうか確認する（ステップＳ２７）。もし、ステータス表において送付先グループのうち少なくとも１つの課金サーバが稼動していると示されている場合、代理応答後処理部５７は、送付先グループのうち稼動している課金サーバを１つ選択し（ステップＳ２９）、当該課金サーバを宛先に設定して課金リクエストのパケットを送信する（ステップＳ３１）。そして、所定時間内に課金レスポンスのパケットを受信したか判断する（ステップＳ３３）。もし、課金サーバから課金レスポンスのパケットを受信した場合には、一旦記憶装置に格納し、当該受信パケット・データに基づき再送された課金リクエストに対応する課金レスポンスであることを確認できれば、受信した課金レスポンスのパケットを破棄する（ステップＳ３５）。そして、代理応答リスト格納部５５の代理応答リストから、再送したパケット・データを特定して削除する（ステップＳ３７）。そしてステップＳ５７に移行する。これにより、課金リクエストの生成元であるアクセス・サーバには重ねて課金レスポンスが送付されることはなくなる。すなわち、ＩＰネットワーク１のトラフィックを増加させることはなく、またアクセス・サーバの構成を変更する必要もない。
【００５３】
一方、課金レスポンスのパケットを所定時間内に受信しなかった場合には、代理応答後処理部５５は、ステータス表格納部５７のステータス表において、課金レスポンスを返送してこなかった課金サーバのステータスをダウンに更新する（ステップＳ３９）。そして、ステータス表を参照して、同じ送付先グループ内に、未送付の稼動している課金サーバが存在しているか判断する（ステップＳ４１）。もし、存在している場合にはステップＳ２９に戻る。一方、存在しない場合にはステップＳ５７に移行する。
【００５４】
ステップＳ２７においてステータス表において送付先グループ内の全ての課金サーバがダウンしていると判断された場合には、送付先グループの課金サーバのうちリトライ回数が少ない課金サーバを選択し（ステップＳ４３）、当該課金サーバを宛先に設定して課金リクエストのパケットを送信する（ステップＳ４５）。そして、所定時間内に課金レスポンスのパケットを受信したか判断する（ステップＳ４７）。もし、課金サーバから課金レスポンスのパケットを受信した場合には、一旦記憶装置に格納し、当該受信パケット・データに基づき再送された課金リクエストに対応する課金レスポンスであることを確認できれば、受信した課金レスポンスのパケットを破棄する（ステップＳ４９）。そして、代理応答リスト格納部５５の代理応答リストから、再送したパケット・データを特定して削除する（ステップＳ５１）。また、ステータス表において課金サーバはダウンしたと記録されていたため、ステータス表において課金レスポンスを返信してきた課金サーバのステータスを稼動（ｕｐ）に、リトライ回数を０に更新する（ステップＳ５３）。そしてステップＳ５７に移行する。これにより、課金リクエストの生成元であるアクセス・サーバには重ねて課金レスポンスが送付されることはなくなる。すなわち、ＩＰネットワーク１のトラフィックを増加させることはなく、またアクセス・サーバの構成を変更する必要もない。
【００５５】
一方、課金レスポンスのパケットを所定時間内に受信しなかった場合には、代理応答後処理部５５は、ステータス表格納部５７のステータス表において、課金レスポンスを返送してこなかった課金サーバのリトライ回数を１インクリメントするように更新する（ステップＳ５５）。そしてステップＳ５７に移行する。
【００５６】
ステップＳ２１において一つも代理応答リストにパケット・データが格納されていなかったと判断された場合にはステップＳ５７に移行する。ステップＳ４１で未送付の稼動している課金サーバが無いと判断された場合、ステップＳ３７、ステップＳ５３又はステップＳ５５の後に、処理終了すべきか判断される（ステップＳ５７）。処理終了しない場合にはステップＳ２１に戻る。それ以外は処理を終了する。
【００５７】
以上本発明の一実施の形態について説明したが、本発明はこれに限定されない。例えば上ではＲＡＤＩＵＳサーバのシステムにおいて本発明を適用する例を説明したが、これに類似の状況が生ずる場合には、本発明を適用することができる。また、アクセス・サーバは、例えばルータなどの接続機器の場合もあるが、これらも本願ではコンピュータとして取り扱う。また、中継サーバ５の本発明に関連する機能を代理応答処理部５１及び代理応答後処理部５３とに分けたが、これは一例であって他の態様に分けることもできる。また、企業Ａや企業Ｂから提供されるサービスは認証や課金だけでなく、例えば有料コンテンツの提供などのサーバが設けられる場合もある。
【００５８】
（付記１）
第１のコンピュータからパケットを受信した場合、当該パケット・データに含まれるユーザ識別情報から転送先の第２のコンピュータを特定するステップと、特定された前記転送先の第２のコンピュータに、前記パケット・データに基づくパケットを送信するステップと、
前記転送先の第２のコンピュータから所定期間内にレスポンスを受信しない場合、前記パケット・データを記憶装置に保存すると共に、前記パケット・データに対応するレスポンスを生成し、前記第１のコンピュータに送信するステップと、
を含む代理応答方法。
【００５９】
（付記２）
所定のタイミングにて前記記憶装置に保存されたパケット・データを読み出して、当該パケット・データに含まれるユーザ識別情報から転送先の第２のコンピュータを特定する第２特定ステップと、
特定された前記転送先の第２のコンピュータに、読み出された前記パケット・データに基づくパケットを送信するステップと、
前記転送先の第２のコンピュータから所定期間内にレスポンスを受信した場合、当該レスポンスと、前記記憶装置に保存された、対応する前記パケット・データとを破棄するステップと、
をさらに含む付記１記載の代理応答方法。
【００６０】
（付記３）
少なくとも、前記記憶装置に保存されたパケット・データに含まれる遅延時間を表すデータを当該パケット・データを受信した時刻からの経過時間に基づき変更することにより、前記読み出された前記パケット・データに基づくパケットを生成するステップ
をさらに含むことを特徴とする付記２記載の代理応答方法。
【００６１】
（付記４）
前記転送先の第２のコンピュータからのレスポンスの有無に基づき、当該転送先の第２のコンピュータの稼動状況に関するデータを記憶装置に記録するステップ
をさらに含む付記２記載の代理応答方法。
【００６２】
（付記５）
前記第２特定ステップが、
所定のタイミングにて前記記憶装置に保存されたパケット・データを読み出して、当該パケット・データに含まれるユーザ識別情報及び前記稼動状況に関するデータを用いて、転送先の第２のコンピュータを特定するステップ
であることを特徴とする付記４記載の代理応答方法。
【００６３】
（付記６）
前記稼動状況に関するデータが、前記転送先の第２のコンピュータ毎にパケットの再送回数のデータを含むことを特徴とする付記５記載の代理応答方法。
【００６４】
（付記７）
前記パケット・データが課金リクエストに関するデータであるか判断するステップをさらに含むことを特徴とする付記１乃至６のいずれか１つ記載の代理応答方法。
【００６５】
（付記８）
前記パケット・データが課金終了についての課金リクエストに関するデータであるか判断するステップをさらに含むことを特徴とする付記１乃至６のいずれか１つ記載の代理応答方法。
【００６６】
（付記９）
前記第２のコンピュータがラディウス・サーバであることを特徴とする付記１乃至８のいずれか１つ記載の代理応答方法。
【００６７】
（付記１０）
付記１乃至１０のいずれか１つ記載の代理応答方法をコンピュータに実行させるためのプログラム。
【００６８】
（付記１１）
第１のコンピュータからパケットを受信した場合、当該パケット・データに含まれるユーザ識別情報から転送先の第２のコンピュータを特定する手段と、
特定された前記転送先の第２のコンピュータに、前記パケット・データに基づくパケットを送信する手段と、
前記転送先の第２のコンピュータから所定期間内にレスポンスを受信しない場合、前記パケット・データを記憶装置に保存すると共に、前記パケット・データに対応するレスポンスを生成し、前記第１のコンピュータに送信する手段と、
を有する中継コンピュータ。
【００６９】
【発明の効果】
以上のように、本発明により、障害時のトラフィックの増加を防止することができる。
【００７０】
また、障害時のトラフィックの増加を招くパケットの再送を防止することができる。
【００７１】
さらに、課金リクエストに係るパケットの喪失を防止し、正確な課金情報を取得できるようになる。
【図面の簡単な説明】
【図１】本発明の一実施の形態におけるシステム構成例を示す図である。
【図２】全体の処理フローを示す図である。
【図３】全体の処理フロー（続き）を示す図である。
【図４】課金サーバに障害が生じた場合の処理を示す図である。
【図５】本発明の一実施の形態に係る処理フローを示す図である。
【図６】中継サーバの処理フローを示す図である。
【図７】パケット・フォーマットを示す図である。
【図８】ステータス表の一例を示す図である。
【図９】代理応答リストに格納されるデータの一例を示す図である。
【図１０】中継サーバの処理フローを示す図である。
【符号の説明】
１ ＩＰネットワーク
３ アクセス・サーバ
５ 中継サーバ
７，２５，２７，２９ ユーザ端末
９，２３ 公衆回線網
１１ インターネット
１３ａ，１５ａ 課金サーバ
１３ｂ，１５ｂ 認証サーバ
１７，１９ 認証ＤＢ
１８，２０ 課金ＤＢ
５１ 代理応答処理部
５３ 代理応答後処理部
５５ 代理応答リスト格納部
５７ ステータス表格納部
Claims (5)
- 第１のコンピュータからパケットを受信した場合、当該パケット・データに含まれるユーザ識別情報から転送先の第２のコンピュータを特定する特定ステップと、
前記特定ステップにより特定された前記転送先の第２のコンピュータに、前記パケット・データに基づくパケットを送信する送信ステップと、
前記転送先の第２のコンピュータから所定期間内にレスポンスを受信しない場合、前記パケット・データを記憶装置に保存すると共に、前記パケット・データに関する処理が正常終了したことを示すレスポンスを生成し、前記第１のコンピュータに送信するステップと、
所定のタイミングにて、前記記憶装置に前記パケット・データが保存されているか確認するステップと、
前記記憶装置に前記パケット・データが保存されていると判断された場合、前記記憶装置に保存された前記パケット・データを読み出して、当該パケット・データに含まれるユーザ識別情報から前記転送先の第２のコンピュータを特定する第２特定ステップと、
前記第２特定ステップにより特定された前記転送先の第２のコンピュータに、読み出された前記パケット・データに基づくパケットを送信する第２送信ステップと、
を含み、コンピュータにより実行される代理応答方法。 - 前記転送先の第２のコンピュータから前記レスポンスを受信した場合、当該レスポンスと、前記記憶装置に保存された、対応する前記パケット・データとを破棄するステップ、
をさらに含む請求項１記載の代理応答方法。 - 前記第２送信ステップが、
少なくとも、前記記憶装置に保存されたパケット・データに含まれる遅延時間を表すデータを当該パケット・データを受信した時刻からの経過時間に基づき変更することにより、前記読み出された前記パケット・データに基づくパケットを生成するステップ
をさらに含むことを特徴とする請求項１記載の代理応答方法。 - 前記パケット・データが課金リクエストに関するデータであるか判断するステップ
をさらに含むことを特徴とする請求項１乃至３のいずれか１つ記載の代理応答方法。 - 請求項１乃至４のいずれか１つ記載の代理応答方法をコンピュータに実行させるためのプログラム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001340604A JP3966711B2 (ja) | 2001-11-06 | 2001-11-06 | 代理応答方法 |
| US10/093,487 US7072962B2 (en) | 2001-11-06 | 2002-03-11 | Proxy reply method and apparatus |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001340604A JP3966711B2 (ja) | 2001-11-06 | 2001-11-06 | 代理応答方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003143250A JP2003143250A (ja) | 2003-05-16 |
| JP3966711B2 true JP3966711B2 (ja) | 2007-08-29 |
Family
ID=19154778
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001340604A Expired - Fee Related JP3966711B2 (ja) | 2001-11-06 | 2001-11-06 | 代理応答方法 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7072962B2 (ja) |
| JP (1) | JP3966711B2 (ja) |
Families Citing this family (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7617317B2 (en) * | 2001-12-03 | 2009-11-10 | Sprint Spectrum L.P. | Method and system for allowing multiple service providers to serve users via a common access network |
| US7337234B2 (en) * | 2002-04-05 | 2008-02-26 | Oracle International Corporation | Retry technique for multi-tier network communication systems |
| KR100442610B1 (ko) * | 2002-04-22 | 2004-08-02 | 삼성전자주식회사 | 라디우스 프로토콜의 플로우 제어방법 |
| US7340508B1 (en) * | 2002-09-18 | 2008-03-04 | Open Invention Network, Llc | Exposing process flows and choreography controllers as web services |
| US7904359B1 (en) * | 2003-01-29 | 2011-03-08 | Cisco Technology, Inc. | Providing accounting services for a communication network |
| JP2005085102A (ja) * | 2003-09-10 | 2005-03-31 | Canon Inc | 保証システム |
| KR20070020207A (ko) * | 2004-01-29 | 2007-02-20 | 존 쥐. 힐디브랜드 | 신호의 전송 및 재생을 지원하는 시스템 및 방법 |
| EP1562343A1 (fr) * | 2004-02-09 | 2005-08-10 | France Telecom | Procédé et système de gestion d'autorisation d'accès d'un utilisateur au niveau d'un domaine administratif local lors d'une connexion de l'utilisateur à un réseau IP |
| JP4718122B2 (ja) * | 2004-04-06 | 2011-07-06 | 株式会社日立製作所 | メディア配信装置 |
| CN100589374C (zh) * | 2004-07-08 | 2010-02-10 | 中兴通讯股份有限公司 | 一种使用点到点协议时防止ip地址泄漏的方法 |
| EP1834677A1 (en) * | 2004-12-16 | 2007-09-19 | Sega Corporation | Game machine management device having penalty function, game device, operation program thereof, and penalty setting server |
| JP4717464B2 (ja) * | 2005-02-18 | 2011-07-06 | キヤノン株式会社 | 情報処理装置、情報処理方法及びプログラム |
| US20070097408A1 (en) * | 2005-10-27 | 2007-05-03 | Makoto Ohkado | Image forming device |
| JP4900268B2 (ja) * | 2008-02-04 | 2012-03-21 | 富士通株式会社 | アプリケーション通信制御装置及びプログラム |
| JP5212913B2 (ja) * | 2009-03-02 | 2013-06-19 | 日本電気株式会社 | Ｖｐｎ接続システム、及びｖｐｎ接続方法 |
| US8131811B2 (en) * | 2009-12-14 | 2012-03-06 | At&T Intellectual Property I, L.P. | Methods, apparatus and articles of manufacture to control network element management traffic |
| US9281950B2 (en) * | 2011-10-07 | 2016-03-08 | Alcatel Lucent | Method for using intelligent router in charging system and apparatus associated therewith |
| US9654604B2 (en) * | 2012-11-22 | 2017-05-16 | Intel Corporation | Apparatus, system and method of controlling data flow over a communication network using a transfer response |
| JP5677524B2 (ja) * | 2013-07-17 | 2015-02-25 | Kddi株式会社 | 通信制御装置、通信制御システム及び通信制御方法 |
| WO2018110047A1 (ja) * | 2016-12-13 | 2018-06-21 | オリンパス株式会社 | 中継装置 |
| JP7279388B2 (ja) * | 2019-02-12 | 2023-05-23 | 日本電気株式会社 | ルータシステムおよびパケット送信判定方法 |
| CN111741041B (zh) * | 2019-07-10 | 2023-05-12 | 北京京东尚科信息技术有限公司 | 消息处理方法及其装置、电子设备及计算机可读介质 |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5781715A (en) * | 1992-10-13 | 1998-07-14 | International Business Machines Corporation | Fault-tolerant bridge/router with a distributed switch-over mechanism |
| US5604803A (en) * | 1994-06-03 | 1997-02-18 | Sun Microsystems, Inc. | Method and apparatus for secure remote authentication in a public network |
| US5689566A (en) * | 1995-10-24 | 1997-11-18 | Nguyen; Minhtam C. | Network with secure communications sessions |
| US6061357A (en) * | 1997-02-06 | 2000-05-09 | Gte Laboratories Incorporated | Ethernet to ADSL adapter |
| US6070243A (en) * | 1997-06-13 | 2000-05-30 | Xylan Corporation | Deterministic user authentication service for communication network |
| GB9715857D0 (en) * | 1997-07-29 | 1997-10-01 | Philips Electronics Nv | Wireless networked message routing |
| US6161185A (en) * | 1998-03-06 | 2000-12-12 | Mci Communications Corporation | Personal authentication system and method for multiple computer platform |
| US6119160A (en) * | 1998-10-13 | 2000-09-12 | Cisco Technology, Inc. | Multiple-level internet protocol accounting |
-
2001
- 2001-11-06 JP JP2001340604A patent/JP3966711B2/ja not_active Expired - Fee Related
-
2002
- 2002-03-11 US US10/093,487 patent/US7072962B2/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| US7072962B2 (en) | 2006-07-04 |
| US20030088679A1 (en) | 2003-05-08 |
| JP2003143250A (ja) | 2003-05-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3966711B2 (ja) | 代理応答方法 | |
| KR100454680B1 (ko) | Ａａａ 프로토콜 기반의 배치처리 과금방법 | |
| US7554992B2 (en) | Mobile device communications system and method | |
| CN101252788B (zh) | 支持RADIUS协议的Diameter-AAA服务器的工作方法 | |
| US7894359B2 (en) | System and method for distributing information in a network environment | |
| JP4160092B2 (ja) | パケットデータ課金細分化方法及びそのシステム | |
| US9716636B2 (en) | Techniques for accounting for multiple transactions in a transport control protocol (TCP) payload | |
| CN102014416B (zh) | 一种对连接进行双向检测的方法及系统 | |
| US20090025010A1 (en) | Systems and methods for providing centralized subscriber session state information | |
| KR100693320B1 (ko) | 소스 어드레스 선택시스템, 라우터장치, 라우터장치로서 컴퓨터를 기능시키기 위한 프로그램을 기록한 컴퓨터 독출가능한 기록매체, 통신노드 및 소스 어드레스 선택방법 | |
| Hess et al. | Performance evaluation of AAA/mobile IP authentication | |
| WO1999044339A2 (en) | Remote computer communication | |
| JP2006508609A (ja) | より正確な加入者装置課金を行うための方法およびデバイス | |
| CN1647451B (zh) | 用于在网络环境中监视信息的装置、方法和系统 | |
| US20040167834A1 (en) | Method for processing accounting requests in a communications system | |
| US7471634B1 (en) | Method for generation of a single accounting stream during heterogeneous access network mobility | |
| Tschofenig et al. | Diameter: New Generation AAA Protocol-Design, Practice, and Applications | |
| EP1472827A2 (en) | Optimization of point-to-point sessions | |
| WO2021259026A1 (zh) | 计费通知功能实体、计费功能实体、话单处理方法、装置和存储介质 | |
| KR100491819B1 (ko) | 무선랜 과금 시스템에서 라디우스 과금 클라이언트의 운용방법 | |
| JP5450412B2 (ja) | モバイルＩＰｖ４用の新しいＤｉａｍｅｔｅｒシグナリング | |
| KR100641895B1 (ko) | 무선 인터넷 서비스 가입자 식별 정보 보정 방법 및 장치 | |
| KR100812822B1 (ko) | 무선 네트워크 시스템에서 목적지 상태에 기초한 무선데이터 통신 방법 | |
| JP2012065350A (ja) | 終端装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041101 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060921 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060926 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061120 |
|
| 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: 20070529 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070529 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 3966711 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110608 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120608 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120608 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130608 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140608 Year of fee payment: 7 |
|
| LAPS | Cancellation because of no payment of annual fees |