(57)【特許請求の範囲】
【請求項１】
送信バッファからリクエスト情報を取得して通常リクエストを生成し、前記通常リクエストを再送バッファに記憶させる通常リクエスト生成部と、
再送要求に従って前記再送バッファから再送リクエストを取得する再送リクエスト取得部と、
目標の送信負荷に連動した時間間隔で、未送信の専用リクエストがあるか否かを確認し、未送信の前記専用リクエストがないとき、前記専用リクエストを生成する専用リクエスト生成部と、
前記通常リクエストおよび前記再送リクエストがないときに前記専用リクエストを送信する送信部と
を備えることを特徴とする送信装置。
【請求項２】
前記送信部は、前記再送リクエストを前記通常リクエストより優先させて送信する
ことを特徴とする請求項１に記載の送信装置。
【請求項３】
請求項１または請求項２に記載の送信装置と、
受信装置と
を備え、
前記受信装置は、
リクエストを受信する受信部と、
前記リクエストの障害を検出する障害検出部と、
前記障害が所定の障害処理条件を満たしたとき、障害処理を行う障害処理部と、
前記障害が検出された前記リクエストが前記通常リクエストあるいは前記再送リクエストのとき、前記リクエストの再送要求を前記再送リクエスト取得部へ送信する再送要求部と
を備え、
前記受信部は、前記リクエストとして、前記送信部から前記通常リクエスト、前記再送リクエストおよび前記専用リクエストを受信する
ことを特徴とする送受信システム。
【請求項４】
前記障害処理部は、前記障害の発生頻度が所定の頻度を超えたとき、前記障害処理を行う
ことを特徴とする請求項３に記載の送受信システム。
【請求項５】
前記障害処理部は、前記障害の累計発生回数が所定の回数を超えたとき、前記障害処理を行う
ことを特徴とする請求項３あるいは請求項４に記載の送受信システム。
【請求項６】
送信バッファからリクエスト情報を取得して通常リクエストを生成し、前記通常リクエストを再送バッファに記憶させ、
再送要求に従って前記再送バッファから再送リクエストを取得し、
目標の送信負荷に連動した時間間隔で、未送信の専用リクエストがあるか否かを確認し、未送信の前記専用リクエストがないとき、前記専用リクエストを生成し、
前記通常リクエストおよび前記再送リクエストがないときに前記専用リクエストを送信する
ことを特徴とする送信方法。
【請求項７】
コンピュータに、
送信バッファからリクエスト情報を取得して通常リクエストを生成し、前記通常リクエストを再送バッファに記憶させる通常リクエスト生成機能と、
再送要求に従って前記再送バッファから再送リクエストを取得する再送リクエスト取得機能と、
目標の送信負荷に連動した時間間隔で、未送信の専用リクエストがあるか否かを確認し、未送信の前記専用リクエストがないとき、前記専用リクエストを生成する専用リクエスト生成機能と、
前記通常リクエストおよび前記再送リクエストがないときに前記専用リクエストを送信する送信機能と
を実現させることを特徴とする送信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、再送機能を持つ、送信装置、送受信システム、送信方法およびプログラムに関する。
【背景技術】
【０００２】
高速シリアルインタフェース等のデータ送受信機能において、受信ユニットが受信したリクエストの障害を検出した場合に送信ユニットが対応するリクエストを再送することで、訂正可能障害の訂正を行っている。
【０００３】
たとえば、特許文献１に記載の方法では、送信ユニットが受信ユニットからＮＡＫ（Negative Acknowledgement）応答を受信した場合や、ＡＣＫ（Acknowledgement）応答またはＮＡＫ応答を受信しないままタイムアウトした場合に、リクエストを再送している。
【０００４】
また、再送を行っても障害を解消できない状態と判断した場合には、インタフェースのリセットや、たとえば特許文献２に記載の方法のように、インタフェースの縮退を行うことで、インタフェースを健全な状態にしている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開2008-204245号公報
【特許文献２】特開平5-173922号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかし、特許文献１に記載の方法のように、障害検出時に再送を行うとき、インタフェースが健全な状態ではなくなり障害が多発すると、障害検出に伴う再送処理も増加する。再送処理が連続で発生すると、再送処理を優先した結果、通常リクエストの処理が滞り、システムの性能低下につながってしまう場合がある。
【０００７】
また、障害多発を検知して、インタフェースのリセットや、特許文献２に記載の方法のようなインタフェースの縮退を行った場合、その障害処理の影響で、通常リクエストの処理が滞り、システムの性能が低下してしまう場合がある。
【０００８】
このように、障害検出時にリクエストの再送を行うシステムでは、障害多発時にシステム性能が低下してしまう場合がある。
【０００９】
本発明の目的は、再送の多発によるシステム性能低下を抑えることを可能とする、送信装置、送受信システム、送信方法およびプログラムを提供することにある。
【課題を解決するための手段】
【００１０】
上述の問題を解決するために、本発明の送信装置は、送信バッファからリクエスト情報を取得して通常リクエストを生成し、前記通常リクエストを再送バッファに記憶させる通常リクエスト生成部と、再送要求に従って前記再送バッファから再送リクエストを取得する再送リクエスト取得部と、所定の生成ルールに従って専用リクエストを生成する専用リクエスト生成部と、前記通常リクエストおよび前記再送リクエストがないときに前記専用リクエストを送信する送信部とを備えることを特徴とする。
【００１１】
また、本発明の送信方法は、送信バッファからリクエスト情報を取得して通常リクエストを生成し、前記通常リクエストを再送バッファに記憶させ、再送要求に従って前記再送バッファから再送リクエストを取得し、所定の生成ルールに従って専用リクエストを生成し、前記通常リクエストおよび前記再送リクエストがないときに前記専用リクエストを送信することを特徴とする。
【００１２】
また、本発明の送信プログラムは、コンピュータに、送信バッファからリクエスト情報を取得して通常リクエストを生成し、前記通常リクエストを再送バッファに記憶させる通常リクエスト生成機能と、再送要求に従って前記再送バッファから再送リクエストを取得する再送リクエスト取得機能と、所定の生成ルールに従って専用リクエストを生成する専用リクエスト生成機能と、前記通常リクエストおよび前記再送リクエストがないときに前記専用リクエストを送信する送信機能とを実現させることを特徴とする。
【発明の効果】
【００１３】
本発明の送信装置、送受信システム、送信方法およびプログラムにより、再送の多発によるシステム性能低下を抑えることが可能になる。
【図面の簡単な説明】
【００１４】
【図１】本発明の第一、第三の実施形態の送信装置の構成例を示す図である。
【図２】本発明の第一の実施形態の送信装置の動作例を示す図である。
【図３】本発明の第二の実施形態の送信装置および受信装置の構成例を示す図である。
【図４】本発明の第二の実施形態の送信ユニットの構成例を示す図である。
【図５】本発明の第二の実施形態の受信ユニットの構成例を示す図である。
【図６】本発明の第二の実施形態の送信装置の動作例を示す図である。
【図７】本発明の第二の実施形態の送信装置の動作例を示す図である。
【図８】本発明の第二の実施形態の送信装置の動作例を示す図である。
【図９】本発明の第二の実施形態の専用リクエストの例を示す図である。
【図１０】本発明の第二の実施形態の送信装置の動作例を示す図である。
【図１１】本発明の第二、第三の実施形態の受信装置の動作例を示す図である。
【図１２】本発明の第三の実施形態の送信ユニットの構成例を示す図である。
【図１３】本発明の第三の実施形態の送信装置の動作例を示す図である。
【図１４】本発明の各実施形態のハードウェア構成例を示す図である。
【発明を実施するための形態】
【００１５】
［第一の実施形態］
本発明の第一の実施の形態について説明する。
【００１６】
図１に本実施形態の送信装置１０の構成例を示す。
【００１７】
送信装置１０は、通常リクエスト生成部１１、再送リクエスト取得部１２、専用リクエスト生成部１３および送信部１４により構成される。
【００１８】
通常リクエスト生成部１１は、送信バッファからリクエスト情報を取得して通常リクエストを生成し、通常リクエストを再送バッファに記憶させる部分である。
【００１９】
再送リクエスト取得部１２は、再送要求に従って再送バッファから再送リクエストを取得する部分である。
【００２０】
専用リクエスト生成部１３は、所定の生成ルールに従って専用リクエストを生成する部分である。
【００２１】
送信部１４は、通常リクエストおよび再送リクエストがないときに専用リクエストを送信する部分である。
【００２２】
このように送信装置１０を構成することによって、再送の多発によるシステム性能低下を抑えることが可能になる。
【００２３】
次に、図２に本実施形態の送信装置１０の動作の例を示す。
【００２４】
まず、送信装置１０の通常リクエスト生成部１１は、送信バッファからリクエスト情報を取得して通常リクエストを生成し、通常リクエストを再送バッファに記憶させる（ステップＳ１０１）。
【００２５】
また、再送リクエスト取得部１２は、再送要求に従って再送バッファから再送リクエストを取得する（ステップＳ１０２）。
【００２６】
また、専用リクエスト生成部１３は、所定の生成ルールに従って専用リクエストを生成する（ステップＳ１０３）。
【００２７】
そして、送信部１４は、通常リクエストおよび再送リクエストがないときに専用リクエストを送信する（ステップＳ１０４）。
【００２８】
このように送信装置１０を動作させることによって、再送の多発によるシステム性能低下を抑えることが可能になる。
【００２９】
以上で説明したように、本発明の第一の実施形態では、通常リクエストとは異なる専用リクエストを送信する。これにより、専用リクエストを受信した受信装置は、通常リクエストの障害が多発して再送が多発する以前に、専用リクエストの障害を検出して障害処理を行ってインタフェースを健全な状態にし、再送の多発を抑えることが可能になる。そのため、再送の多発によるシステム性能低下を抑えることが可能になる。
【００３０】
［第二の実施形態］
次に、本発明の第二の実施の形態について説明する。
【００３１】
本実施形態は、通常のリクエストの送信負荷が低い状態で障害検出専用の専用リクエストを送信し、通常リクエストで障害が発生する前に障害処理を行って障害が起きにくい状態にする形態である。
【００３２】
図３に本実施形態の送受信システムの構成例を示す。本実施形態の送受信システムは、送信装置２０と受信装置３０により構成される。送信装置２０と受信装置３０は高速シリアルインタフェース４０でリンク接続されている。
【００３３】
送信装置２０は、送信装置１０に負荷判定部２５を追加した形態である。
【００３４】
負荷判定部２５は、送信部１４の送信負荷を判定する部分である。専用リクエスト生成部２３は、負荷判定部２５が低負荷と判定したときに、障害検出専用の専用リクエストを生成して送信部１４に出力する。そして、送信部１４は、通常リクエスト生成部１１からの通常リクエスト、再送リクエスト取得部１２からの再送リクエスト、専用リクエスト生成部２３からの専用リクエストを所定の優先ルールに従って送信する。このとき、送信部１４は、通常リクエストと再送リクエストを、専用リクエストより優先して送信する。
【００３５】
受信装置３０は、受信部３１、障害検出部３２、再送要求部３３および障害処理部３４により構成される。
【００３６】
受信部３１は、送信装置２０からリクエストを受信する部分である。
【００３７】
障害検出部３２は送信装置２０から受信したリクエストの障害を検出する部分である。
【００３８】
再送要求部３３は、障害検出部３２で障害を検出し、受信したリクエストが通常リクエスト（再送リクエストを含む）の場合、送信装置２０へリクエストの再送を要求する部分である。また、障害検出が所定の障害処理条件を満たしたとき、障害処理部３４へ障害処理を要求する。
【００３９】
障害処理部３４は、障害検出部３２からの要求に従って障害処理を行う部分である。
【００４０】
図４に本実施形態の送信装置２０を適用した送信ユニット２００の構成例を示す。
【００４１】
送信ユニット２００は、緩衝レジスタ２０１、送信バッファ２０２、通常リクエスト生成部２０３、再送バッファ２０６、再送リクエスト取得部２０７、セレクタ２０８、負荷判定部２０９、専用リクエスト生成部２１０により構成される。送信ユニット２００は、高速シリアルインタフェースを介して、受信装置３０にリクエストを送信する。
【００４２】
送信バッファ２０２は、受信装置３０に送信するリクエスト情報を格納するバッファである。送信バッファ２０２は、複数のエントリで構成されている。リクエストを格納する送信バッファ２０２のエントリおよびリクエストを読み出すエントリの決定には、ライトポインタ２０４およびリードポインタ２０５の値を使用する。
【００４３】
緩衝レジスタ２０１は、送信バッファ２０２にリクエスト情報を格納する際に、リクエスト情報を一時的に保持するレジスタである。緩衝レジスタ２０１は、リクエスト情報を一時的に保持することで、緩衝レジスタ２０１の入力側と出力側の処理速度の差を調整する。
【００４４】
ライトポインタ２０４は、リクエスト情報を格納する送信バッファ２０２のエントリを示すポインタであり、カウンタにより構成される。ライトポインタ２０４は、緩衝レジスタ２０１から送信されたリクエスト情報を送信バッファ２０２に格納する際にカウンタをカウントアップすることで、後続のリクエスト情報を格納するエントリを指示する。
【００４５】
リードポインタ２０５は、リクエスト情報を読み出す送信バッファ２０２のエントリを示すポインタであり、カウンタにより構成される。リードポインタ２０５は、送信バッファ２０２からリクエスト情報を読み出す際にカウンタをカウントアップすることで、次に読み出すリクエスト情報のエントリを指示する。
【００４６】
なお、ライトポインタ２０４とリードポインタ２０５のカウンタ値が同じである場合は、送信バッファ２０２にリクエスト情報を格納していないことを示す。
【００４７】
通常リクエスト生成部２０３は、送信バッファ２０２から読み出されたリクエスト情報に基づいて受信ユニットに送信するリクエスト（通常リクエスト）を生成し、セレクタ２０８に生成した通常リクエストを出力する。通常リクエスト生成部２０３は、図３の通常リクエスト生成部１１に相当する。
【００４８】
また、通常リクエスト生成部２０３は、セレクタ２０８に通常リクエストを出力するとともに、再送バッファ２０６に通常リクエストを格納する。
【００４９】
再送バッファ２０６は、受信装置が障害を検出した際にリクエストを再送するために、再送対象のリクエストを格納しておくバッファである。再送バッファ２０６は、通常リクエスト生成部２０３で生成された通常リクエストを格納する。
【００５０】
再送リクエスト取得部２０７は、受信装置から再送要求があったときに、再送バッファ２０６から再送対象のリクエスト（再送リクエスト）を取得し、セレクタ２０８に出力する部分である。また、リクエストを正常に受信装置へ送信でき、受信装置３０から正常受信通知を受信したときには、対象のリクエストを格納しているエントリを解放する。再送リクエスト取得部２０７は、図３の再送リクエスト取得部１２に相当する。
【００５１】
負荷判定部２０９は、セレクタ２０８の送信負荷を判定する部分である。負荷判定部２０９は独自のタイマーを持ち、定期的に負荷判定を行う。負荷判定部２０９は、図３の負荷判定部２５に相当する。
【００５２】
負荷の判定は、たとえば、ライトポインタ２０４とリードポインタ２０５の値を確認することによって行うことが可能である。ライトポインタ２０４とリードポインタ２０５のカウンタの値を比較し、送信待ちのリクエスト情報の数から送信負荷を判断する。
【００５３】
たとえば、ライトポインタ２０４のカウンタ値が１０、リードポインタ２０５のカウンタ値が１０の場合には、送信バッファ２０２にリクエスト情報が格納されていない状態のため、セレクタ２０８の送信負荷は低負荷であると判断する。ライトポインタ２０４のカウンタ値が１０、リードポインタ２０５のカウンタ値が５の場合には、処理待ちのリクエスト情報が送信バッファ２０２に格納されており、高負荷であると判断する。すなわち、受信装置に通常リクエストを送信できない状態であると判断することができる。
【００５４】
なお、このとき、処理待ちのリクエスト情報の有無で送信負荷を判断するのではなく、処理待ちのリクエスト情報の数が所定の数を超えたときに高負荷であると判断することも可能である。
【００５５】
専用リクエスト生成部２１０は、障害検出専用のリクエスト（専用リクエスト）を生成し、負荷判定部２０９に送信する部分である。専用リクエスト生成部２１０は、負荷判定部２０９が低負荷であると判断したとき、受信装置との送受信の障害状態を判断するための専用リクエストを生成してセレクタ２０８へ送信する。専用リクエスト生成部２１０は、図３の専用リクエスト生成部２３に相当する。
【００５６】
セレクタ２０８は、通常リクエスト生成部２０３から通常リクエストを、再送リクエスト取得部２０７から再送リクエストを、専用リクエスト生成部２１０から専用リクエストを受信して一時的に保持し、所定の優先ルールに従って受信装置へ送信する部分である。セレクタ２０８は、図３の送信部１４に相当する。
【００５７】
本実施形態では、たとえば、以下の優先ルールで受信装置へ送信するリクエストを決定する。
【００５８】
未送信の再送リクエストを受信している場合には、再送リクエストを送信する。未送信の再送リクエストを受信しておらず、かつ、未送信の通常リクエストを受信している場合には、通常リクエストを送信する。未送信の再送リクエスト、未送信の通常リクエストのいずれも受信しておらず、かつ、未送信の専用リクエストを受信している場合には、専用リクエストを送信する。
【００５９】
図５に本実施形態の受信装置３０を適用した受信ユニット３００の構成例を示す。
【００６０】
セレクタ３０１は、送信装置２０からリクエストを受信する部分である。受信したリクエストが通常リクエスト（再送リクエストを含む）の場合には、通常リクエスト障害検出部３０２にリクエストを出力し、専用リクエストの場合には、専用リクエスト障害検出部３０５にリクエストを出力する。セレクタ３０１は図３の受信部３１に相当する。
【００６１】
通常リクエスト障害検出部３０２は、通常リクエストの障害検出を行う部分である。障害を検出しなかった場合には、受信バッファ３０３にリクエストを出力し、また、再送要求部３０４に正常受信できたことを通知する。
【００６２】
通常リクエスト障害検出部３０２で障害を検出した場合には、再送要求部３０４に対してリクエストの再送指示を通知する。さらに、障害が所定の障害処理条件を満たし、再送による障害訂正が不可能な固定障害が発生していると判断した場合には、インタフェースを健全な状態にするために、障害処理部３０６へ障害処理を指示する。たとえば、障害発生の累計回数が所定の回数を超えたとき、障害処理部３０６へ障害処理を指示する。
【００６３】
専用リクエスト障害検出部３０５は、専用リクエストの障害を検出する部分である。そして、障害が所定の障害処理条件を満たしたとき、障害処理部３０６へ障害処理を指示する。たとえば、障害の発生頻度が所定の頻度を超えた場合に、障害処理部３０６へ障害処理を指示する。
【００６４】
なお、通常リクエスト障害検出部３０２および専用リクエスト障害検出部３０５は、図３の障害検出部３２に相当する。
【００６５】
受信バッファ３０３は、通常リクエスト障害検出部３０２から送信された通常リクエストを格納するバッファである。受信バッファ３０３には、通常リクエスト障害検出部３０２が障害を検出しなかった通常リクエストを格納する。
【００６６】
再送要求部３０４は、通常リクエスト障害検出部３０２の障害検出結果に従って、送信装置２０へ再送要求、あるいは、正常受信通知を行う部分である。通常リクエスト障害検出部３０２が障害を検出した場合、再送要求部３０４は送信装置２０に当該リクエストの再送要求を行う。障害を検出しなかった場合、つまり、リクエストが正常であった場合には、正常受信通知を送信装置２０へ送信する。再送要求部３０４は、図３の再送要求部３３に相当する。
【００６７】
障害処理部３０６は、通常リクエスト障害検出部３０２あるいは専用リクエスト障害検出部３０５からの指示に従って、障害処理を行う部分である。具体的には、たとえば、インタフェースのリセット、あるいは、リンクの縮退等を実行する。障害処理部３０６は図３の障害処理部３４に相当する。この障害処理により、障害発生頻度が低い状態にすることができる。
【００６８】
このように送信装置２０および受信装置３０を構成することによって、送信装置２０は障害検出専用の専用リクエストを送信し、受信装置３０は、専用リクエストによって障害処理を行うことが可能になる。これにより、通常リクエストの障害が多発して再送が多発する以前に、専用リクエストの障害を検出して障害処理を行ってインタフェースを健全な状態にし、再送の多発を抑えることが可能になる。そのため、再送の多発によるシステム性能低下を抑えることが可能になる。
【００６９】
次に、本実施形態の送信装置２０（送信ユニット２００）の動作の例について説明する。
【００７０】
まず、図６を用いて、通常リクエストの生成動作の例について説明する。
【００７１】
緩衝レジスタ２０１では、リクエスト情報を受信し、受信したリクエスト情報を送信バッファ２０２に格納する。そして、ライトポインタ２０４をカウントアップする。
【００７２】
通常リクエスト生成部２０３は、送信バッファ２０２にリクエスト情報が格納されているか確認する（ステップＳ２０１）。送信バッファ２０２にリクエスト情報が格納されている場合、セレクタ２０８が未送信の通常リクエストを保持しているか確認する（ステップＳ２０２）。送信バッファ２０２にリクエスト情報が格納されていない場合は、格納されるまで待機する。
【００７３】
ステップＳ２０２において、セレクタ２０８が未送信の通常リクエストを保持していなければ、送信バッファ２０２からリクエスト情報を読み出してリードポインタ２０５をカウントアップする。そして、読み出したリクエスト情報に基づいて通常リクエストを生成し、セレクタ２０８へ出力する（ステップＳ２０３）。未送信の通常リクエストがあれば、未送信の通常リクエストがなくなるまで待機する。
【００７４】
次に、図７を用いて、再送リクエストの取得動作の例について説明する。
【００７５】
再送リクエスト取得部２０７は、受信装置３０の再送要求部３３から再送要求を受信すると（ステップＳ２０４）、再送バッファ２０６から再送リクエストを取得し、セレクタ２０８へ出力する（ステップＳ２０５）。また、再送要求部３３から正常受信通知を受信した場合には（ステップＳ２０６）、再送バッファ２０６の当該リクエストのエントリを解放する（ステップＳ２０７）。
【００７６】
次に、図８を用いて、専用リクエストの生成動作の例について説明する。
【００７７】
負荷判定部２０９は、まず、セレクタ２０８の送信負荷を判定する（ステップＳ２０８）。負荷判定は、たとえば、上述のように、ライトポインタ２０４とリードポインタ２０５のカウンタ値から判定することが可能である。
【００７８】
セレクタ２０８が高負荷状態である場合、セレクタ２０８は再送リクエストや通常リクエストを優先的に送信する。そのため、負荷判定部２０９が高負荷と判定したときは、専用リクエスト生成部２１０は専用リクエストを生成しない。
【００７９】
負荷判定部２０９が低負荷と判定した場合（ステップＳ２０９）、専用リクエスト生成部２１０は、障害検出用の専用リクエストを生成し、セレクタ２０８に出力する（ステップＳ２１０）。
【００８０】
図９の送信リクエストは、専用リクエスト生成部２１０が生成する専用リクエストの例である。図９の例では、専用リクエストは１と０の繰り返しパターンとなっている。専用リクエストは、受信装置３０で障害検出が可能な形式であれば、どのような形式であっても良い。たとえば、リクエストごとに所定の生成ルールに従って異なるビット列となるようにしても良い。また、専用リクエストのビット幅やパケット数に制限はない。
【００８１】
次に、図１０を用いて、セレクタ２０８の送信動作の例について説明する。
【００８２】
セレクタ２０８は、通常リクエスト生成部２０３、再送リクエスト取得部２０７、専用リクエスト生成部２１０からリクエストを受信したとき、これらのリクエストを一時的に保持する。そして、保持しているリクエストから、所定の優先ルールに従って送信するリクエストを決定し、決定したリクエストを受信装置３０へ送信する。
【００８３】
図１０は、この優先ルールの例である。セレクタ２０８は、未送信の通常リクエストを保持していれば（ステップＳ２１１）、通常リクエストを送信する（ステップＳ２１２）。未送信の通常リクエストを保持しておらず、かつ、未送信の再送リクエストを保持している場合は（ステップＳ２１３）、再送リクエストを送信する（ステップＳ２１４）。未送信の通常リクエストも再送リクエストも保持しておらず、かつ、未送信の専用リクエストを保持している場合には（ステップＳ２１５）、専用リクエストを送信する（ステップＳ２１６）。
【００８４】
以上で、送信ユニット２００の動作の例について説明した。
【００８５】
次に、図１１に受信装置３０（受信ユニット３００）の動作の例を示す。
【００８６】
まず、セレクタ３０１は、送信装置２０からリクエストを受信する（ステップＳ３０１）。そして、リクエストが通常リクエスト（再送リクエストを含む）の場合は通常リクエスト障害検出部３０２で、専用リクエストの場合は専用リクエスト障害検出部３０５で障害を検出する（ステップＳ３０２）。
【００８７】
通常リクエスト障害検出部３０２では、リクエストの障害を検出した場合、当該リクエストは通常リクエストのため、当該リクエストのリクエスト情報を再送要求部３０４に出力する。そして、再送要求部３０４は再送要求を送信装置２０へ送信する（ステップＳ３０３、Ｓ３０４）。また、リクエストに障害がなかった場合、通常リクエスト障害検出部３０２はリクエストを受信バッファ３０３へ格納し、また、再送要求部３０４は送信装置２０へ正常受信通知を送信する。
【００８８】
また、通常リクエスト障害検出部３０２では、通常リクエスト障害検出部３０２で検出した障害が所定の障害処理条件を満たすかどうか判断し、所定の障害処理条件を満たす場合、障害処理部３０６へ障害処理を指示する。たとえば、障害発生の累計回数が、所定の回数を超えている場合、障害処理部３０６へ障害処理を指示する。そして、障害処理部３０６は障害処理を行う（ステップＳ３０５）。
【００８９】
専用リクエスト障害検出部３０５では、リクエストの障害を検出した場合、当該リクエストは障害処理用の専用リクエストのため、ステップＳ３０４の再送要求は行わない。専用リクエスト障害検出部３０５では、専用リクエストの障害発生が所定の障害処理条件を満たすかどうか確認し、所定の障害処理条件を満たす場合、障害処理部３０６に障害処理を指示する。たとえば、専用リクエストの障害発生頻度を確認し、障害発生頻度が所定の頻度を超えた場合、障害処理部３０６に障害処理を指示する。そして、障害処理部３０６ではインタフェースのリセットやリンクの縮退等の障害処理を行う。なお、障害処理の内容については、リセットや縮退に限定しない。
【００９０】
たとえば、障害処理条件を、障害が１リクエストあたり１０回を超えて発生したときとし、また、送信ユニット２００が図９の送信リクエストを専用リクエストとして送信し、図９の受信リクエストを受信ユニット３００が受信したとする。この場合、図９の送信リクエストと受信リクエストの不一致箇所は４か所（下線部）で、障害発生回数は１リクエストあたり４回のため、障害処理を行わない。障害発生回数が１リクエストあたり１０回を超えた場合には、障害処理を行う。
【００９１】
なお、障害検出は、送信リクエストと受信リクエストの不一致箇所を確認する以外にも、誤り訂正符号による誤り検出などで行っても良く、障害検出方法はこれらの方法に限定しない。
【００９２】
このように送信装置２０および受信装置３０を動作させることによって、再送の多発によるシステム性能低下を抑えることが可能になる。
【００９３】
以上で説明したように、本発明の第二の実施形態では、第一の実施形態と同様に、送信装置が障害検出専用の専用リクエストを送信する。これにより、専用リクエストを受信した受信装置は、通常リクエストの障害が多発して再送が多発する以前に、専用リクエストの障害を検出して障害処理を行ってインタフェースを健全な状態にし、再送の多発を抑えることが可能になる。そのため、再送の多発によるシステム性能低下を抑えることが可能になる。
【００９４】
さらに、本実施形態では、送信負荷が低負荷の状態で障害検出専用の専用リクエストを送信することで、低負荷時に障害処理を行うことを可能にするため、障害処理によるシステム性能低下を抑えることが可能になる。
【００９５】
［第三の実施形態］
次に、本発明の第三の実施の形態について説明する。
【００９６】
第二の実施形態は、障害の発生頻度がインタフェースの負荷状態によって増減しないシステムであることを前提としている。
【００９７】
本実施形態では、インタフェースの負荷状態が低負荷から高負荷、あるいは、高負荷から低負荷になったとき、つまり、急激な負荷変動時に障害の発生頻度が増加するシステムの場合の実施形態について説明する。
【００９８】
本実施形態では、通常リクエストが少なくインタフェースが低負荷のときに、障害検出専用の専用リクエストを送信することで、インタフェースの負荷状態を高負荷に保つ。これにより、急激な負荷変動を防止し、負荷変動による障害発生回数を低減させる。
【００９９】
本実施形態の送信装置１０の構成例は、図１と同様である。また、受信装置３０の構成例は、図３と同様である。
【０１００】
図１２に本実施形態の送信装置１０を適用した送信ユニット１００の構成例を示す。送信ユニット１００と第二の実施形態の送信ユニット２００の差分は、送信ユニット１００には、負荷判定部２０９が含まれない点である。
【０１０１】
専用リクエスト生成部１１０では、送信負荷と関係なく、未送信の専用リクエストがないときに専用リクエストを生成する。これにより、セレクタ２０８には常に未送信の専用リクエストが保持されている状態となる。
【０１０２】
このように送信装置１０を構成することによって、再送の多発によるシステム性能低下を抑えることが可能になる。
【０１０３】
次に、本実施形態の送信装置１０の動作の例について説明する。なお、受信装置３０の動作の例については第二の実施形態と同様のため、説明を省略する。
【０１０４】
通常リクエストの生成動作および再送リクエストの取得動作は、第二の実施形態（図６、図７）と同様である。
【０１０５】
図１３に専用リクエストの生成動作の例を示す。
【０１０６】
専用リクエスト生成部１１０は、まず、セレクタ２０８が未送信の専用リクエストを保持しているか確認する（ステップＳ４０１）。そして、未送信の専用リクエストが保持されていない場合、専用リクエスト生成部１１０は専用リクエストを生成してセレクタ２０８へ出力する（ステップＳ４０２）。
【０１０７】
セレクタ２０８の送信動作の例は図１０と同様である。
【０１０８】
セレクタ２０８は、通常リクエスト生成部２０３、再送リクエスト取得部２０７、専用リクエスト生成部１１０からリクエストを受信したとき、これらのリクエストを一時的に保持する。そして、保持しているリクエストから、所定の優先ルールに従って送信するリクエストを決定し、決定したリクエストを受信装置３０へ送信する。
【０１０９】
本実施形態では、未送信の専用リクエストがないときに専用リクエスト生成部１１０が専用リクエストを生成するため、ステップＳ２１５では常に未送信の専用リクエストがある状態になる。そのため、未送信の通常リクエストおよび再送リクエストがないときには常に専用リクエストが送信させることになり、セレクタ２０８の送信負荷を高負荷に保つことになる。セレクタ２０８では、再送リクエストより優先して通常リクエストおよび再送リクエストを送信するため、専用リクエストの送信によるシステム性能の低下は発生しない。
【０１１０】
なお、専用リクエスト生成部１１０の専用リクエストの生成については、目標の送信負荷となるように、定期的に未送信の専用リクエストの有無を確認して専用リクエストを生成するようにすることも可能である。このようにすると、送信すべき再送リクエストおよび通常リクエストがないとき、目標の送信負荷に応じて定期的に専用リクエストが送信されることになる。
【０１１１】
このように送信装置１０を動作させることによって、再送の多発によるシステム性能低下を抑えることが可能になる。
【０１１２】
以上で説明したように、本発明の第三の実施形態では、第一、第二の実施形態と同様に、送信装置が障害検出専用の専用リクエストを送信する。これにより、専用リクエストを受信した受信装置は、通常リクエストの障害が多発して再送が多発する以前に、専用リクエストの障害を検出して障害処理を行ってインタフェースを健全な状態にし、再送の多発を抑えることが可能になる。そのため、再送の多発によるシステム性能低下を抑えることが可能になる。
【０１１３】
さらに、本実施形態では、通常リクエストおよび再送リクエストが送信されていないときに専用リクエストを送信することにより、送信負荷を一定に保つことができる。そのため、負荷の変動により障害が発生するシステムにおいて、送信負荷を一定に保つことが可能になり、障害の発生を低減することが可能になる。
【０１１４】
［ハードウェア構成例］
上述した本発明の各実施形態における送信装置（１０、２０）あるいは受信装置３０を、一つの情報処理装置（コンピュータ）を用いて実現するハードウェア資源の構成例について説明する。なお、送信装置（１０、２０）あるいは受信装置３０は、物理的または機能的に少なくとも二つの情報処理装置を用いて実現してもよい。また、送信装置（１０、２０）あるいは受信装置３０は、専用の装置として実現してもよい。また、送信装置（１０、２０）あるいは受信装置３０の一部の機能のみを情報処理装置を用いて実現しても良い。
【０１１５】
図１４は、本発明の各実施形態の送信装置あるいは受信装置を実現可能な情報処理装置のハードウェア構成例を概略的に示す図である。情報処理装置５０は、通信インタフェース５１、入出力インタフェース５２、演算装置５３、記憶装置５４および不揮発性記憶装置５５を備える。
【０１１６】
通信インタフェース５１は、各実施形態の送信装置（１０、２０）あるいは受信装置３０が、有線あるいは／および無線で外部装置と通信するための通信手段である。なお、送信装置（１０、２０）あるいは受信装置３０を、少なくとも二つの情報処理装置を用いて実現する場合、それらの装置の間を通信インタフェース５１経由で相互に通信可能なように接続しても良い。
【０１１７】
入出力インタフェース５２は、入力デバイスの一例であるキーボードや、出力デバイスとしてのディスプレイ等のマンマシンインタフェースである。
【０１１８】
演算装置５３は、汎用のＣＰＵ（Central Processing Unit）やマイクロプロセッサ等の演算処理装置である。演算装置５３は、たとえば、不揮発性記憶装置５５に記憶された各種プログラムを記憶装置５４に読み出し、読み出したプログラムに従って処理を実行することが可能である。
【０１１９】
記憶装置５４は、演算装置５３から参照可能な、ＲＡＭ（Random Access Memory）等のメモリ装置であり、プログラムや各種データ等を記憶する。記憶装置５４は、揮発性のメモリ装置であっても良い。
【０１２０】
不揮発性記憶装置５５は、たとえばＲＯＭ（Read Only Memory）、フラッシュメモリ、等の、不揮発性の記憶装置であり、各種プログラムやデータ等を記録することが可能である。
【０１２１】
本発明の各実施形態は、たとえば、図１４に例示した情報処理装置５０により送信装置（１０、２０）あるいは受信装置３０を構成し、この送信装置あるいは受信装置に対して、上記各実施形態において説明した機能を実現可能なプログラムを供給することにより実現してもよい。この場合、送信装置あるいは受信装置に対して供給したプログラムを、演算装置５３が実行することによって、実施形態を実現することが可能である。また、送信装置あるいは受信装置のすべてではなく、一部の機能を情報処理装置５０で構成することも可能である。
【０１２２】
さらに、上記プログラムを外部記憶媒体に記録しておき、送信装置あるいは受信装置の出荷段階、あるいは運用段階等において、適宜上記プログラムが不揮発性記憶装置５５に格納されるよう構成してもよい。なお、この場合、上記プログラムの供給方法は、出荷前の製造段階、あるいは運用段階等において、適当な治具を利用して送信装置あるいは受信装置内にインストールする方法を採用してもよい。また、上記プログラムの供給方法は、インターネット等の通信回線を介して外部からダウンロードする方法等の一般的な手順を採用してもよい。
【０１２３】
なお、上述する各実施の形態は、本発明の好適な実施の形態であり、本発明の要旨を逸脱しない範囲内において種々変更実施が可能である。
【０１２４】
上記の実施形態の一部または全部は、以下の付記のようにも記載されうるが、以下には限られない。
【０１２５】
（付記１）
送信バッファからリクエスト情報を取得して通常リクエストを生成し、前記通常リクエストを再送バッファに記憶させる通常リクエスト生成部と、
再送要求に従って前記再送バッファから再送リクエストを取得する再送リクエスト取得部と、
所定の生成ルールに従って専用リクエストを生成する専用リクエスト生成部と、
前記通常リクエストおよび前記再送リクエストがないときに前記専用リクエストを送信する送信部と
を備えることを特徴とする送信装置。
【０１２６】
（付記２）
前記送信部の送信負荷を判定する負荷判定部
を備え、
前記専用リクエスト生成部は、前記送信負荷が低いときに前記専用リクエストを生成する
ことを特徴とする付記１に記載の送信装置。
【０１２７】
（付記３）
前記負荷判定部は、前記送信バッファの残量の大小から前記送信負荷の高低を判定する
ことを特徴とする付記２に記載の送信装置。
【０１２８】
（付記４）
前記専用リクエスト生成部は、前記送信部が前記専用リクエストを保持していないとき、前記専用リクエストを生成する
ことを特徴とする付記１から付記３のいずれかに記載の送信装置。
【０１２９】
（付記５）
前記送信部は、前記再送リクエストを前記通常リクエストより優先させて送信する
ことを特徴とする付記１から付記４のいずれかに記載の送信装置。
【０１３０】
（付記６）
付記１から付記５のいずれかに記載の送信装置と、
受信装置と
を備え、
前記受信装置は、
リクエストを受信する受信部と、
前記リクエストの障害を検出する障害検出部と、
前記障害が所定の障害処理条件を満たしたとき、障害処理を行う障害処理部と、
前記障害が検出された前記リクエストが前記通常リクエストあるいは前記再送リクエストのとき、前記リクエストの再送要求を前記再送リクエスト取得部へ送信する再送要求部と
を備え、
前記受信部は、前記送信部から前記通常リクエスト、前記再送リクエストおよび前記専用リクエストを受信する
ことを特徴とする送受信システム。
【０１３１】
（付記７）
前記障害処理部は、前記障害の発生頻度が所定の頻度を超えたとき、前記障害処理を行う
ことを特徴とする付記６に記載の送受信システム。
【０１３２】
（付記８）
前記障害処理部は、前記障害の累計発生回数が所定の回数を超えたとき、前記障害処理を行う
ことを特徴とする付記６あるいは付記７に記載の送受信システム。
【０１３３】
（付記９）
送信バッファからリクエスト情報を取得して通常リクエストを生成し、前記通常リクエストを再送バッファに記憶させ、再送要求に従って前記再送バッファから再送リクエストを取得し、所定の生成ルールに従って専用リクエストを生成し、前記通常リクエストおよび前記再送リクエストがないときに前記専用リクエストを送信する
ことを特徴とする送信方法。
【０１３４】
（付記１０）
前記送信の送信負荷を判定し、前記送信負荷が低いときに前記専用リクエストを生成する
ことを特徴とする付記９に記載の送信方法。
【０１３５】
（付記１１）
前記負荷判定部は、前記送信バッファの残量の大小から前記送信負荷の高低を判定する
ことを特徴とする付記１０に記載の送信方法。
【０１３６】
（付記１２）
前記専用リクエスト生成部は、前記送信部が前記専用リクエストを保持していないとき、前記専用リクエストを生成する
ことを特徴とする付記９から付記１１のいずれかに記載の送信方法。
【０１３７】
（付記１３）
前記送信部は、前記再送リクエストを前記通常リクエストより優先させて送信する
ことを特徴とする付記９から付記１２のいずれかに記載の送信方法。
【０１３８】
（付記１４）
コンピュータに、
送信バッファからリクエスト情報を取得して通常リクエストを生成し、前記通常リクエストを再送バッファに記憶させる通常リクエスト生成機能と、
再送要求に従って前記再送バッファから再送リクエストを取得する再送リクエスト取得機能と、
所定の生成ルールに従って専用リクエストを生成する専用リクエスト生成機能と、
前記通常リクエストおよび前記再送リクエストがないときに前記専用リクエストを送信する送信機能と
を実現させることを特徴とする送信プログラム。
【０１３９】
（付記１５）
前記送信の送信負荷を判定する負荷判定機能
を実現させ、
前記専用リクエスト生成機能は、前記送信負荷が低いときに前記専用リクエストを生成する
ことを特徴とする付記１４に記載の送信プログラム。
【０１４０】
（付記１６）
前記負荷判定機能は、前記送信バッファの残量の大小から前記送信負荷の高低を判定する
ことを特徴とする付記１５に記載の送信プログラム。
【０１４１】
（付記１７）
前記専用リクエスト生成機能は、前記送信機能が前記専用リクエストを保持していないとき、前記専用リクエストを生成する
ことを特徴とする付記１４から付記１６のいずれかに記載の送信プログラム。
【０１４２】
（付記１８）
前記送信機能は、前記再送リクエストを前記通常リクエストより優先させて送信する
ことを特徴とする付記１４から付記１７のいずれかに記載の送信プログラム。
【符号の説明】
【０１４３】
１０、２０    送信装置
１１    通常リクエスト生成部
１２    再送リクエスト取得部
１３、２３    専用リクエスト生成部
１４    送信部
２５    負荷判定部
３０    受信装置
３１    受信部
３２    障害検出部
３３    再送要求部
３４    障害処理部
５０    情報処理装置
５１    通信インタフェース
５２    入出力インタフェース
５３    演算装置
５４    記憶装置
５５    不揮発性記憶装置
１００、２００    送信ユニット
２０１    緩衝レジスタ
２０２    送信バッファ
２０３    通常リクエスト生成部
２０４    ライトポインタ
２０５    リードポインタ
２０６    再送バッファ
２０７    再送リクエスト取得部
２０８    セレクタ
２０９    負荷判定部
２１０、１１０    専用リクエスト生成部
３００    受信ユニット
３０１    セレクタ
３０２    通常リクエスト障害検出部
３０３    受信バッファ
３０４    再送要求部
３０５    専用リクエスト障害検出部
３０６    障害処理部
【図１】
0006734031.tif 000002
【図２】
0006734031.tif 000003
【図３】
0006734031.tif 000004
【図４】
0006734031.tif 000005
【図５】
0006734031.tif 000006
【図６】
0006734031.tif 000007
【図７】
0006734031.tif 000008
【図８】
0006734031.tif 000009
【図９】
0006734031.tif 000010
【図１０】
0006734031.tif 000011
【図１１】
0006734031.tif 000012
【図１２】
0006734031.tif 000013
【図１３】
0006734031.tif 000014
【図１４】
0006734031.tif 000015