(57)【要約】【課題】  通信性能を低下させず、かつメモリに格納されたデータと管理上のメモリ内のデータとに生じる差をなくす技術を提供する。【解決手段】  通信装置は、送受信データの送信または受信の要求である送受信要求に応じて、前記送受信データをＤＭＡ（Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ）転送する通信手段と、前記送受信要求が所定の条件を満たす場合、前記通信手段における前記送受信要求に応じた処理が完了したか否かを確認する完了確認手段と、前記通信手段における前記処理が完了したと確認した場合、前記送受信要求に関連するデータを前記通信手段から受信する記憶手段における記憶領域に、該送受信要求に関連するデータが格納されるまで待機する保証手段と、を備える。【選択図】      図１３
2018147430.tif 000002
【特許請求の範囲】
【請求項１】
送受信データの送信または受信の要求である送受信要求に応じて、前記送受信データをＤＭＡ（Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ）転送する通信手段と、
前記送受信要求が所定の条件を満たす場合、前記通信手段における前記送受信要求に応じた処理が完了したか否かを確認する完了確認手段と、
前記通信手段における前記処理が完了したと確認した場合、前記送受信要求に関連するデータを前記通信手段から受信する記憶手段における記憶領域に、該送受信要求に関連するデータが格納されるまで待機する保証手段と、を備える通信装置。
【請求項２】
前記送受信要求を前記通信手段に送信する処理手段を備え、
前記完了確認手段は、前記処理手段が送信する前記送受信要求の数が閾値より多い場合、前記通信手段の処理が完了したか否かを確認する請求項１に記載の通信装置。
【請求項３】
前記保証手段は、送受信要求ごとに、前記記憶領域に前記送受信要求に関連するデータが格納されたか否か確認する確認処理を行い、前記確認処理において、前記送受信要求に関連するデータが格納されていない場合、該送受信要求に関連するデータが格納されるまで待機する請求項１に記載の通信装置。
【請求項４】
前記保証手段は、前記状態情報と、前記送受信要求に関連するデータが格納されたか否か確認した前記送受信要求とに基づいて、前記送受信要求に関連するデータが前記記憶領域に格納されたことを前記完了確認手段に通知し、
前記完了確認手段は、前記通知に基づき、前記送受信要求の送信元に、前記送受信要求の前記状態情報と、前記送受信要求を識別する識別子とを送信する請求項３に記載の通信装置。
【請求項５】
前記送受信要求の送信元から前記送受信要求を受信し、受信した送受信要求を前記記憶手段に記憶させ、前記送受信データの送受信の開始の指示を前記通信手段に送信する要求送受信手段を備え、
前記通信手段は、該指示に基づき、前記送受信要求に応じて、前記送受信データの送信または受信を行う請求項１から４のいずれか１項に記載の通信装置。
【請求項６】
送受信データの送信または受信の要求である送受信要求に応じて、前記送受信データをＤＭＡ転送し、
前記送受信要求が所定の条件を満たす場合、前記送受信要求に応じたＤＭＡ転送の処理が完了したか否かを確認し、
前記送受信要求に応じたＤＭＡ転送の処理が完了したと確認した場合、前記送受信要求に関連するデータを受信する記憶手段における記憶領域に、該送受信要求に関連するデータが格納されるまで待機する通信方法。
【請求項７】
前記送受信要求の送信元が送信する前記送受信要求の数が閾値より多い場合、前記送受信要求に応じたＤＭＡ転送の処理が完了したか否かを確認する請求項６に記載の通信方法。
【請求項８】
送受信データの送信または受信の要求である送受信要求に応じて、前記送受信データをＤＭＡ転送する通信処理と、
前記送受信要求が所定の条件を満たす場合、前記通信処理が完了したか否かを確認する完了確認処理と、
前記通信処理が完了したと確認した場合、前記送受信要求に関連するデータを受信する記憶手段における記憶領域に、該送受信要求に関連するデータが格納されるまで待機する保証処理と、
をコンピュータに実行させるプログラム。
【請求項９】
前記送受信要求を前記通信処理に送信する処理を実行し、
前記完了確認処理は、前記処理が送信する前記送受信要求の数が閾値より多い場合、前記通信処理における前記送受信要求に応じた処理が完了したか否か確認する請求項1０に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、通信装置、通信方法およびプログラムに関する。
【背景技術】
【０００２】
高性能計算分野では、低レイテンシの通信を実現するため、ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）のシステムコールやハードウェアの割り込みを使用することなく、ユーザプログラムから直接ＲＤＭＡ（Ｒｅｍｏｔｅ  Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ）が可能なＩｎｆｉｎｉＢａｎｄなどのインターコネクトを利用することがある。
【０００３】
また、一般的なアーキテクチャでは、ネットワークインタフェースからＤＭＡ（Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ）やＲＤＭＡを用いたメモリへの書き込みは、書き込みが行われた順に完了することが保証されている。しかしながら、一部のアーキテクチャでは、ネットワークインタフェースからメモリへの書き込みは、書き込みが行われた順に書き込みが完了する順序保証がされていない場合がある。一部のアーキテクチャでは、実際にメモリに格納されたデータと、管理上のメモリ上のデータとに差が生じる場合がある。
【０００４】
このため、アーキテクチャによってはＤＭＡまたはＲＤＭＡでのメモリへの格納が完了した後に実際にメモリに格納されたデータと、管理上のメモリ上のデータとの差をなくすための処理が必要となる。
【０００５】
この処理の例として、特許文献１には、ネットワークインタフェースからメモリへの書き込みにおいて、順序保証のない構成を前提とし、その順序保証を行う技術が開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１１−８６７８号公報
【特許文献２】特開平９−１６２９４８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、特許文献１に記載の技術は、ネットワークインタフェースとメモリとの間に複数のパスが存在し、パス間での順序保証がないことを前提としているが、１つのパス内での順序保証があることを前提としている。そのため、ネットワークインタフェースとメモリ間のパスが一本であり、そのパス内での順序保証がない場合、特許文献１に記載の技術を適用することは難しい。また、ネットワークインタフェースとメモリとの間のパスが一本である場合、ネットワークインタフェースとメモリとの間のパスが複数である場合と比べ、通信性能が低下してしまう。
【０００８】
本開示は、上記問題を鑑みたものであって、通信性能を低下させず、かつメモリに格納されたデータと管理上のメモリ内のデータとに生じる差をなくす技術を提供することを目的とする。
【課題を解決するための手段】
【０００９】
本開示の一形態の係る通信装置は、送受信データの送信または受信の要求である送受信要求に応じて、前記送受信データをＤＭＡ（Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ）転送する通信手段と、前記送受信要求が所定の条件を満たす場合、前記通信手段における前記送受信要求に応じた処理が完了したか否かを確認する完了確認手段と、前記通信手段における前記処理が完了したと確認した場合、前記送受信要求に関連するデータを前記通信手段から受信する記憶手段における記憶領域に、該送受信要求に関連するデータが格納されるまで待機する保証手段と、を備える。
【００１０】
本開示の一形態に係る通信方法は、送受信データの送信または受信の要求である送受信要求に応じて、前記送受信データをＤＭＡ転送し、前記送受信要求が所定の条件を満たす場合、前記送受信要求に応じたＤＭＡ転送の処理が完了したか否かを確認し、前記送受信要求に応じたＤＭＡ転送の処理が完了したと確認した場合、前記送受信要求に関連するデータを受信する記憶手段における記憶領域に、該送受信要求に関連するデータが格納されるまで待機する。
【００１１】
本開示の一形態に係るプログラムは、送受信データの送信または受信の要求である送受信要求に応じて、前記送受信データをＤＭＡ転送する通信処理と、前記送受信要求が所定の条件を満たす場合、前記通信処理が完了したか否かを確認する完了確認処理と、前記通信処理が完了したと確認した場合、前記送受信要求に関連するデータを受信する記憶手段における記憶領域に、該送受信要求に関連するデータが格納されるまで待機する保証処理と、をコンピュータに実行させる。
【発明の効果】
【００１２】
本開示によれば、通信性能を低下させず、かつメモリに格納されたデータと管理上のメモリ内のデータとに生じる差をなくす技術を提供することができる。
【図面の簡単な説明】
【００１３】
【図１】本開示の第１実施形態に係る通信システムの構成の一例を示す図である。
【図２】本開示の第１実施形態に係る通信システムの構成の一例を示す機能ブロック図である。
【図３】送受信要求を説明するための図である。
【図４】完了バッファに格納される要求テーブルの一例を示す図である。
【図５】本開示の第１実施形態に係る通信装置を実現する情報処理装置のハードウェア構成の一例を示すブロック図である。
【図６】経過時間ｔと、通信部から記憶部へのデータの送信と、記憶部に送信されるデータの流れと、を説明するための図である。
【図７】記憶部のハードウェア構成の一例を示す図である。
【図８】経過時間ｔと、記憶部から通信部へのデータの送信と、通信部に送信されるデータの流れと、を説明するための図である。
【図９】保証部が行う保証処理の動作を説明するための図である。
【図１０】完了確認部が行う完了確認処理の一例を示すフローチャートである。
【図１１】保証処理の一例を示すフローチャートである。
【図１２】第１実施形態に係る通信システムの変形例の一例を示す図である。
【図１３】第２実施形態に係る通信装置の構成の一例を示す機能ブロック図である。
【発明を実施するための形態】
【００１４】
以下、本開示の実施形態について図面を参照して詳細に説明する。
【００１５】
＜第１実施形態＞
図１は、本開示の第１実施形態に係る通信システム１０の構成の一例を示す図である。通信システム１０は、通信装置１と、外部装置１００とを含む。通信装置１と外部装置１００とは、有線または無線のネットワークを介し、互いにデータ通信を行う。
【００１６】
図２は、本開示の第１実施形態に係る通信システム１０の構成の一例を示す機能ブロック図である。通信装置１は、記憶部１１と、通信部１２と、処理部１３と、要求送受信部１４と、完了確認部１５と、保証部１６とを備える。
【００１７】
（処理部１３）
処理部１３は、通信装置１を使用するユーザによって作成されたユーザプログラムを実行する。具体的に、処理部１３は、ユーザプログラムを実行し、送受信要求を要求送受信部１４に送信する。
【００１８】
図３は、送受信要求を説明するための図である。送受信要求は、図３に示すテーブルの各エントリのように、データの送信またはデータの受信という要求の要求種別と、送受信要求を識別するための送受信リクエストＩＤ（Ｉｄｅｎｄｉｆｉｅｒ）と、送受信データ１１１（後述）のアドレスと、送受信データ１１１のサイズと、送信または受信を行う相手（送受信相手）の情報とによって構成される。
【００１９】
送受信相手の情報とは、例えば、ネットワークアドレス、送受信の対象となる装置の名称、または装置のメモリアドレス等である。
【００２０】
（記憶部１１）
記憶部１１は、送受信データ１１１を通信部１２から受信し、記憶する。または、記憶部１１は、記憶した送受信データを通信部１２へ送信する。また、記憶部１１は、完了バッファ１１２と、リクエストキュー１１３とを含む。送受信データ１１１は、通信装置１が外部装置１００に送信する送信データおよび、通信装置１が外部装置１００から受信する受信データの少なくともいずれかである。リクエストキュー１１３は、通信部１２が処理を行う送受信要求が格納される領域を示す。完了バッファ１１２は、要求テーブル１１２１と、次エントリ番号１１２２と、完了確認済みエントリ番号１１２３とを格納する領域である。完了バッファ１１２については、図４を用いて説明する。
【００２１】
図４は、完了バッファ１１２の一例を示す図である。本実施形態では、完了バッファ１１２は、リングバッファであるとする。リングバッファの各領域には、要求テーブル１１２１の各エントリが格納される。つまり、以下に説明する要求テーブル１１２１は、リングバッファの各領域に格納されたデータを表形式で表したものである。つまり、要求テーブル１１２１は、循環リストである。
【００２２】
要求テーブル１１２１は、エントリ番号と、送受信リクエストＩＤ１１７と、完了ステータス１１８と、完了フラグ１１９とに対応する各値を有するエントリを格納する。
【００２３】
エントリとはエントリ番号に紐づく要求テーブル１１２１の各行を示す。エントリ番号は各エントリを識別するための番号である。送受信リクエストＩＤ１１７は、送受信要求を識別するための識別子である。完了ステータス１１８は、処理部１３が、完了確認部１５を介して、送受信要求が成功したか否かを識別するための情報である。なお、完了ステータス１１８に１が設定されている場合、処理部１３は、完了ステータス１１８を参照することにより、再度送受信要求を要求送受信部１４に送信する、またはプログラム終了するなどの処理を行うことができる。
【００２４】
完了フラグ（状態情報）１１９は、後述する通信部１２の処理が完了したことを示すフラグである。完了フラグ１１９は、記憶部１１に送信されたデータを管理する情報である。また、本実施形態において、エントリ番号は０を含む自然数とする。
【００２５】
なお、送受信要求の種別が受信を示す場合、送受信データ１１１と送受信リクエストＩＤ１１７と完了ステータス１１８との少なくとも１つを送受信要求に関連するデータとする。また、送受信要求の種別が送信を示す場合、送受信リクエストＩＤ１１７と完了ステータス１１８との少なくとも１つを送受信要求に関連するデータとする。
【００２６】
なお、要求テーブル１１２１の各エントリは、通信部１２が送受信要求に応じた送信または受信を完了した場合、通信部１２によって書き込まれる。
【００２７】
次エントリ番号１１２２は、完了確認部１５が次に処理部１３に返却するエントリの番号を示す。言い換えると、次エントリ番号１１２２は、要求テーブル１１２１上で、保証部１６が保証処理（後述）を行うべきエントリの位置を示すポインタである。
【００２８】
完了確認済みエントリ番号１１２３は、保証処理の進行状況を示す情報である。例えば、完了確認済みエントリ番号１１２３の値が「２」である場合、エントリ番号が０から２までのエントリは、既に保証処理済みであることを示す。なお、図４に示すように完了確認済みエントリ番号１１２３には、初期値として−１が設定される。
【００２９】
（要求送受信部１４）
要求送受信部１４は、処理部１３から送受信要求を受信する。そして、要求送受信部１４は、送受信の開始の指示を通信部１２に送信する。また、要求送受信部１４は、送受信要求をリクエストキュー１１３に格納する。
【００３０】
（通信部１２）
通信部１２は、要求送受信部１４からの指示に基づき、リクエストキュー１１３を参照し、有線または無線のネットワークで接続された外部装置１００とＲＤＭＡを用いて通信を行う。
【００３１】
また具体的に、通信部１２は、要求送受信部１４から送受信の開始の指示をうけとると、リクエストキュー１１３を参照し、リクエストキュー１１３に格納された送受信要求に応じ、送受信データ１１１を、ＲＤＭＡを用いて外部装置１００に送信する。または、通信部１２は、外部装置１００から送受信データ１１１を受信した場合、受信した送受信データ１１１を記憶部１１に送信する。
【００３２】
また、通信部１２は、記憶部１１または外部装置１００に対し送受信データ１１１を送信した場合、送信または受信が完了した送受信データ１１１のエントリを要求テーブル１１２１に書き込む。
【００３３】
このように、通信装置１と外部装置１００とがＲＤＭＡを用いて通信を行うことで、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）を介さずに直接データのやり取りを行うことができる。
【００３４】
また、通信部１２は、要求送受信部１４からの指示に基づき、リクエストキュー１１３を参照する。このため、通信部１２は、リクエストキュー１１３に送受信要求がない場合、リクエストキュー１１３を参照せずに済む。したがって、通信部１２の負荷を軽減することができる。
【００３５】
（完了確認部１５）
完了確認部１５は、完了確認処理を行う。完了確認処理とは、通信部１２が送受信要求に応じたデータの送信または受信が完了したか否かを確認する処理である。完了確認処理の詳細は後述する。また、完了確認部１５は、ループカウンタｉ（ｉ：０を含む自然数）を有する。
【００３６】
（保証部１６）
保証部１６は、記憶部１１に書込まれた送受信データ１１１に対し、保証処理を行う。保証処理については後述する。
【００３７】
図５は、本開示の第１実施形態に係る通信装置１を実現する情報処理装置９００のハードウェア構成の一例を示すブロック図である。本開示の第１実施形態に係る通信装置１は、例えば図５に示す情報処理装置９００とプログラムとの任意の組み合わせにより実現される。情報処理装置９００は、一例として、以下のような構成を含む。
【００３８】
・ＣＰＵ９０１
・ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）９０２
・ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）９０３
・ＲＡＭ９０３にロードされるプログラム９０４
・プログラム９０４を格納する記憶装置９０５
・通信ネットワーク９０９と接続する通信インターフェース９０８
・データの入出力を行う入出力インターフェース９１０
・各構成要素を接続するバス９１１
通信部１２は、例えば、通信インターフェース９０８によって構成される。
【００３９】
処理部１３は、例えば、ＲＯＭ９０２及び記憶装置９０５に記憶されたプログラム９０４をＲＡＭ９０３に書き込み、書き込まれたプログラム９０４を実行するＣＰＵ９０１によって構成される。
【００４０】
要求送受信部１４は、例えば、ＲＯＭ９０２及び記憶装置９０５に記憶されたプログラム９０４をＲＡＭ９０３に書き込み、書き込まれたプログラム９０４を実行するＣＰＵ９０１によって構成される。
【００４１】
完了確認部１５は、例えば、ＲＯＭ９０２及び記憶装置９０５に記憶されたプログラム９０４をＲＡＭ９０３に書き込み、書き込まれたプログラム９０４を実行するＣＰＵ９０１によって構成される。
【００４２】
保証部１６は、例えば、ＲＯＭ９０２及び記憶装置９０５に記憶されたプログラム９０４をＲＡＭ９０３に書き込み、書き込まれたプログラム９０４を実行するＣＰＵ９０１が、通信装置１の構成要素の１つである保証部１６として機能する。なお、記憶部１１のハードウェア構成については、後述する。
【００４３】
なお、情報処理装置９００は、記録媒体の読み書きを行うドライブ装置を含んでいても良い。
【００４４】
情報処理装置９００の電源が投入されると、実施形態１に係る通信装置１として情報処理装置９００を機能させるプログラムが実行され、実施形態１に係る通信装置１が実現される。
【００４５】
ここで、通信部１２から記憶部１１に送信された送受信データ１１１と、要求テーブル１１２１の各エントリとの書き込みの完了の順序が保証されないことについて説明する。以下、通信装置１が、送受信データ１１１の一例として、受信データ１１１１および受信データ１１１２とを外部装置１００から受信する場合について説明する。
【００４６】
図６は、経過時間ｔと、通信部１２から記憶部１１への受信データ１１１１および受信データ１１１２の送信と、記憶部１１に送信される受信データ１１１１および受信データ１１１２の流れと、を説明するための図である。
【００４７】
図６は、通信部１２が、記憶部１１に受信データ１１１１を送信する時刻からの経過時間ｔを横軸としている。図６に示す上段は、通信部１２が記憶部１１にデータを送信する順序であり、下段は通信部１２から送信されたデータが記憶部１１に格納される順序を示している。まず通信部１２は、送受信要求に従って外部装置１００から受信した受信データ１１１１を、記憶部１１に送信する。
【００４８】
本実施形態において、受信データ１１１１は５つに分割されているとし、５つに分割されたそれぞれを受信データ１１１１ａ、受信データ１１１１ｂ、受信データ１１１１ｃ、受信データ１１１１ｄおよび受信データ１１１１ｅと呼ぶ。
【００４９】
同様に、受信データ１１１２は５つに分割されているとし、５つに分割されたそれぞれを受信データ１１１２ａ、受信データ１１１２ｂ、受信データ１１１２ｃ、受信データ１１１２ｄおよび受信データ１１１２ｅと呼ぶ。
【００５０】
通信部１２は、受信データ１１１１を記憶部１１に送信した後で、要求テーブル１１２１に受信データ１１１１のエントリを書き込む。つまり通信部１２は、該受信データ１１１１の送受信リクエストＩＤ１１７と、完了ステータス１１８と、完了フラグ１１９とを記憶部１１に送信する。通信部１２は、上述した順番でデータを記憶部１１に送信する。
【００５１】
しかしながら、記憶部１１では、受信データ１１１１ｄが格納される前に、受信データ１１１１ｅと、送受信リクエストＩＤ１１７と、完了ステータス１１８と、完了フラグ１１９とが格納されている。また、完了ステータス１１８が記憶部１１に格納される前に、完了フラグ１１９が記憶部１１に格納されている。このように、記憶部１１にデータが格納される順序と記憶部１１にデータが送信される順序とは、一致しないことがある。言い換えると、記憶部１１にデータが送信される順序と、記憶部１１にデータが格納される順序との間にずれが生じてしまう可能性がある。
【００５２】
図７は、記憶部１１のハードウェア構成の一例を示す図である。
【００５３】
例えば、記憶部１１は、図７に示すようにメモリモジュール（１１４−１〜１１４−６）と、コントローラ（１１５−１〜１１５−６）と、リング状のバス（以降、リングバスと称する）１１６とから構成される。なお、本実施形態では、メモリモジュール（１１４−１〜１１４−６）のそれぞれを区別しない場合、または、総称する場合には、これらをメモリモジュール１１４（記憶領域）と呼ぶ。同様に、コントローラ（１１５−１〜１１５−６）のそれぞれを区別しない場合、または総称する場合には、これらをそれぞれコントローラ１１５と呼ぶ。
【００５４】
コントローラ１１５は、メモリモジュール１１４の物理アドレスによってどのメモリモジュール１１４にアクセスを行うかが決まっている。そのため、コントローラ１１５によって、アクセス可能なメモリモジュール１１４が決まっている。具体的には、コントローラ１１５−１は、メモリモジュール１１４−１を制御する。
【００５５】
また、コントローラ１１５は自装置が接続しているメモリモジュール１１４へ格納するデータであれば自装置内で処理し、そうでない場合、最短経路となるように隣のコントローラ１１５にデータを転送する。なお、リングバス１１６上でのデータの追い越しは、発生しないものとする。
【００５６】
図７に示す例においては、通信部１２から記憶部１１の最初のコントローラ１１５−１までは、記憶部１１にデータが送信される順序と、記憶部１１にデータが格納される順序とは等しい。しかしながら、データによって格納先のメモリモジュール１１４が異なる場合や、コントローラ１１５間の距離によってデータがメモリモジュール１１４に格納されるまでにかかる時間が異なる場合がある。よって、データが送信される順序と、データが格納される順序との間にずれが生じてしまう可能性がある。
【００５７】
図７に示す例は、図６の時点Ｔ１の記憶部１１内における受信データ１１１１（１１１１ａ〜１１１１ｅ）および受信データ１１１２ａと、受信データ１１１１の送受信リクエストＩＤ１１７、完了ステータス１１８および完了フラグ１１９と、を表す。完了フラグ１１９は、通信部１２に最も近いメモリモジュール１１４−１に格納されている。すなわち、すでに完了フラグ１１９は、記憶部１１に格納されている。
【００５８】
しかしながら、完了フラグ１１９より前に記憶部１１に送信されたデータである、受信データ１１１１ｄと完了ステータス１１８とは、リングバス１１６上に存在している。同様に、受信データ１１１２ａは、リングバス１１６上に存在している。すなわち、受信データ１１１１ｄと、完了ステータス１１８と、受信データ１１１２ａとは、未だメモリモジュール１１４に格納されていない。
【００５９】
図８は、経過時間ｔと、記憶部１１から通信部１２へのデータの送信と、通信部１２に送信されるデータの流れと、を説明するための図である。以下、通信装置１が、送受信データ１１１の一例として、送信データ１１１３を外部装置１００に送信する場合について説明する。
【００６０】
図８は、記憶部１１が通信部１２に送信データ１１１３を送信する時刻からの経過時間ｔを横軸としている。図８に示す上段は、記憶部１１が通信部１２に送信するデータの順序であり、下段は、通信部１２が記憶部１１から送信されたデータを受信する順序を示している。まず、通信部１２は、要求種別が送信である送受信要求に従って、記憶部１１に、送信データ１１１３を通信部１２に送信する指示を送信する。
【００６１】
本実施形態において、送信データ１１１３は、５つに分割されているとし、５つに分割されたそれぞれを送信データ１１１３ａと、送信データ１１１３ｂと、送信データ１１１３ｃと、送信データ１１１３ｄと、送信データ１１１３ｅと呼ぶ。
【００６２】
通信部１２からの指示はリングバス１１６上を流れるため、各コントローラは、該指示が来た順にメモリモジュール１１４から対応する送信データ１１１３を取り出し、取り出した送信データ１１１３をリングバス１１６上に送信する。送信データ１１１３は、リングバス１１６を介し、通信部１２に送信される。
【００６３】
このとき、本実施形態においてリングバス１１６上でのデータの追い越しは発生しないため、記憶部１１から通信部１２に送信される送信データ１１１３の順序と、通信部１２が送信データ１１１３を受信する順序とは同じである。
【００６４】
通信部１２は、受信した送信データ１１１３から順に、外部装置１００に送信する。そして、通信部１２は、全ての送信データ１１１３を外部装置１００に送信した後、要求テーブル１１２１に送信データ１１１３のエントリを書き込む。つまり、通信部１２は、記憶部１１に送信データ１１１３を送信するという要求に対応する送受信リクエストＩＤ１１７と、完了ステータス１１８と、完了フラグ１１９とを記憶部１１に送信する。通信部１２は、上述した順番でデータを記憶部１１に送信する。
【００６５】
しかしながら、図８に示すように記憶部１１では、完了ステータス１１８が格納される前に、完了フラグ１１９が格納されている。このように、記憶部１１にデータが格納される順序と記憶部１１にデータが送信される順序とは、一致しない場合がある。
【００６６】
以上のように、本開示の第１実施形態に係る通信装置１においては、通信部１２から記憶部１１に送信されるデータの順序と、記憶部１１に格納されるデータの順序とにずれが生じる可能性がある。
【００６７】
よって、本開示の第１実施形態に係る通信装置１に、決定されたフレームフォーマットの順番通りに受信を行うことを前提としている特許文献１に記載の技術を適用することは難しい。
【００６８】
例えば、図６に示す時点Ｔ１において処理部１３が、受信データ１１１１を参照しようとした場合、完了フラグ１１９は、記憶部１１に格納されているものの、受信データ１１１１ｄは記憶部１１に格納されていない。よって、処理部１３は実際には格納されていない受信データ１１１１の参照を行い、誤動作するという問題が生じてしまう可能性がある。
【００６９】
このような問題を解消するために、通信部１２から記憶部１１へ送信されたデータが、メモリモジュール１１４に格納されていることを保証する必要がある。そこで、保証部１６は、完了確認部１５からの保証処理の指示に基づき、保証処理を行う。
【００７０】
図９は、保証部１６が行う保証処理の動作を説明するための図である。図９に示すように、保証部１６は、コントローラ１１５−６に接続されている。保証部１６は保証処理の指示を受け付けた時点において、リングバス１１６上にあるデータが、メモリモジュール１１４に格納されることを待ち合わせる。
【００７１】
例えば、図６の時点Ｔ１において、保証部１６が完了確認部１５から送信された保証処理の指示を受信した場合、保証部１６は、受信データ１１１１ｄと、完了ステータス１１８と、受信データ１１１２ａとがメモリモジュール１１４に格納されることを待ち合わせる。
【００７２】
具体的に、保証部１６は完了確認部１５からの指示に基づき、保証処理の命令１６１がコントローラ１１５−６、コントローラ１１５−１、コントローラ１１５−２、…、コントローラ１１５−５といった順に進むように、保証処理の命令１６１をリングバス１１６に送信する。
【００７３】
また、保証部１６は、保証処理の命令１６２がコントローラ１１５−６、コントローラ１１５−５、コントローラ１１５−４、…、コントローラ１１５−１といった順に進むように、保証処理の命令１６２をリングバス１１６に送信する。つまり、保証処理の命令１６１は、リングバス１１６上を反時計回りに流れ、保証処理の命令１６２は、リングバス１１６上を時計回りに流れる。
【００７４】
なお、リングバス１１６上ではアクセス命令等の命令の追い越しは発生しない。そのため、保証処理の命令１６１と、保証処理の命令１６２とが少なくともリングバス１１６上を２周した時点において、受信データ１１１１ｄと、完了ステータス１１８と、受信データ１１１２ａとがいずれかのメモリモジュール１１４に格納されたことが保証される。
【００７５】
そして、保証部１６は、保証処理の命令１６１と、保証処理の命令１６２とが少なくともリングバス１１６上を２周したことを確認した時点、かつ受信データ１１１１ｄと完了ステータス１１８と受信データ１１１２ａとがメモリモジュール１１４に格納される時点Ｔ２以降において、完了確認部１５に保証処理が完了したことを示す通知を送信する。
【００７６】
メモリモジュール１１４と、コントローラ１１５との数は、それぞれ６つに限定されず、７つ以上でもよいし、６つ未満でもよい。
【００７７】
図４と、図１０と、図１１とを用いて通信装置１の動作説明を行う。具体的に、完了確認部１５が完了確認処理を複数回実行する場合について説明する。
【００７８】
図１０は完了確認部１５が行う完了確認処理の一例を示すフローチャートである。完了確認部１５は、送受信要求が所定の条件を満たす場合、以下に示す完了確認処理を行う。所定の条件とは、例えば、処理部１３が送信する送受信要求の数が閾値より多い場合である。
【００７９】
完了確認部１５は処理部１３が送信する送受信要求の数が閾値より多い場合、完了確認処理を行うため、送受信要求ごとに完了確認処理を行う場合に比べて、完了確認処理を減らすことができる。
【００８０】
なお、本実施形態において完了確認部１５が図１０に示す完了確認処理を実行する時、図４に示すように次エントリ番号１１２２は０であり、完了確認済みエントリ番号１１２３は−１であるとする。また、処理部１３は要求送受信部１４を介してデータの送受信を４回行っており、４回の送受信は全て完了しているものとする。また、要求テーブル１１２１は図４の状態になっているものとする。さらに、完了確認部１５は、以下に示す完了確認処理を初めて実行するものとする。
【００８１】
完了確認部１５は、次エントリ番号１１２２が完了確認済みエントリ番号１１２３以下か否か判定する（ステップＳ２０１）。
【００８２】
ここで図４を参照すると、次エントリ番号１１２２は０であり、完了確認済みエントリ番号１１２３は−１であるため、次エントリ番号１１２２は完了確認済みエントリ番号１１２３より大きい。このように次エントリ番号１１２２が完了確認済みエントリ番号１１２３より大きい場合（ステップＳ２０１にてＮＯ）、処理はステップＳ２０２に進む。一方で、次エントリ番号１１２２が完了確認済みエントリ番号１１２３以下である場合（ステップＳ２０１にてＹＥＳ）、処理はステップＳ２１０に進む。
【００８３】
完了確認部１５は、次エントリ番号１１２２の完了フラグ１１９に１が設定されているか否か判定する（ステップＳ２０２）。具体的に、完了確認部１５は、エントリ番号が０の完了フラグ１１９の項目に１が設定されているか否か判定する。図４を参照すると、エントリ番号が０の完了フラグ１１９は１となっている。
【００８４】
このように、次エントリ番号１１２２の完了フラグ１１９に１が設定されている場合（ステップＳ２０２にてＹＥＳ）、具体的に、エントリ番号が０の完了フラグ１１９の項目に１が設定されている場合、完了確認部１５は、エントリ番号が０の送受信要求に対する通信部１２の処理が完了したと判定する。このとき、通信部１２の処理とは、エントリ番号が０の送受信要求に関連するデータを記憶部１１に送信することである。
【００８５】
そして、完了確認部１５は、ループカウンタｉの初期値を次エントリ番号１１２２に設定し（ステップＳ２０４）、ループカウンタｉを１つ増加させる（ステップＳ２０５）。今回の場合、ループカウンタｉは１となる。
【００８６】
その後、完了確認部１５は、ループカウンタｉと同じ値をもつエントリ番号の完了フラグ１１９を取得する（ステップＳ２０６）。そして、完了確認部１５は取得した完了フラグ１１９に０が設定されているか否か判定する（ステップＳ２０７）。完了確認部１５は、ループカウンタｉと同じ値をもつエントリ番号の完了フラグ１１９に０が設定されていることを確認するまで（ステップＳ２０７にてＹＥＳ）、ステップＳ２０５とステップＳ２０６との処理を繰り返す。
【００８７】
具体的に、完了確認部１５は、エントリ番号が１の完了フラグ１１９を確認する（ステップＳ２０６）。図４を参照すると、エントリ番号が１の完了フラグ１１９には１が設定されている（ステップＳ２０７にてＮＯ）。したがって、完了確認部１５は、ループカウンタｉを１つ増加させる（ステップＳ２０５）。ここで、ループカウンタｉが２となる。
【００８８】
その後、完了確認部１５はエントリ番号が２の完了フラグ１１９を確認する（ステップＳ２０６）。図４を参照すると、エントリ番号が２の完了フラグ１１９には１が設定されている（ステップＳ２０７にてＮＯ）。したがって、完了確認部１５は、ループカウンタｉを１つ増加させる（ステップＳ２０５）。ここで、ループカウンタｉが３となる。
【００８９】
さらに、完了確認部１５はエントリ番号が３の完了フラグ１１９を確認する（ステップＳ２０６）。図４を参照すると、エントリ番号が３の完了フラグ１１９には１が設定されている（ステップＳ２０７にてＮＯ）。したがって、完了確認部１５は、ループカウンタｉを１つ増加させる（ステップＳ２０５）。ここで、ループカウンタｉが４となる。
【００９０】
そして、完了確認部１５は、エントリ番号が４の完了フラグ１１９を確認する（ステップＳ２０６）。図４を参照すると、エントリ番号が４の完了フラグ１１９には０が設定されている（ステップＳ２０７にてＹＥＳ）。そのため、処理はステップＳ２０８へ進む。
【００９１】
そして、完了確認部１５は、完了確認済みエントリ番号１１２３をｉ−１に設定する（ステップＳ２０８）。具体的に、ループカウンタｉは４であるため、完了確認済みエントリ番号１１２３は３となる。
【００９２】
また、完了確認部１５は、保証部１６に保証処理の指示を送信する。保証部１６は、完了確認部１５からの指示を受信し、受信した指示に基づき、保証処理を行う（ステップＳ２０９）。保証処理の具体的な説明は図１１を用いて行う。
【００９３】
図１１は、保証処理の一例を示すフローチャートである。まず保証部１６は、完了確認部１５からの指示を受信した時点において、送受信要求に関連するデータがメモリモジュール１１４に格納されているか否か確認する。言い換えると、送受信要求に関連するデータがリングバス１１６上にあるか否か判定する（ステップＳ３０１）。送受信要求に関連するデータがリングバス１１６上にない場合（ステップＳ３０１にてＮＯ）、処理はステップＳ３０２に進む。
【００９４】
一方で、送受信要求に関連するデータがリングバス１１６上にある場合（ステップＳ３０１にてＹＥＳ）、保証部１６は、リングバス１１６上にある送受信要求に関連するデータがメモリモジュール１１４に格納されるまで、ステップＳ３０１の処理を繰り返す。
【００９５】
つまり保証部１６は、保証処理の命令１６１が保証処理の命令１６１と、保証処理の命令１６２とをリングバス１１６上に送信し、保証処理の命令１６１と保証処理の命令１６２とが少なくともリングバス１１６上を２周するまで、待機する。
【００９６】
そして、保証部１６は、保証処理の命令１６１と保証処理の命令１６２とが少なくともリングバス１１６上を２周したことを確認した後、完了確認部１５に、送受信要求に関連するデータが格納されたことを示す通知を送信する。言い換えると、保証部１６は、保証処理が完了したことを示す通知を完了確認部１５に送信する（ステップＳ３０２）。完了確認部１５は、保証部１６から保証処理が完了したことを示す通知を受信する。そして処理は、図１０に示すステップＳ２１０に進む。
【００９７】
図１０に戻り、完了確認部１５は次エントリ番号１１２２が完了確認済みエントリ番号１１２３より大きい場合、または保証処理が完了したことを示す通知を受信したことを契機に、完了確認部１５は処理部１３に次エントリ番号１１２２のエントリを送信する（ステップＳ２１０）。ここでは具体的に次エントリ番号１１２２が０なので、完了確認部１５は処理部１３にエントリ番号が０のエントリを送信する。
【００９８】
そして、完了確認部１５は、次エントリ番号１１２２を１つ増加させる（ステップＳ２１１）。具体的には、ステップＳ２１２の段階における次エントリ番号１１２２は０であるため、ステップＳ２１１の処理によって、次エントリ番号１１２２は１となる。その後処理は終了する。
【００９９】
その後、完了確認部１５は、再び完了確認処理を実行する。完了確認部１５は、次エントリ番号１１２２が完了確認済みエントリ番号１１２３以下か否か判定する（ステップＳ２０１）。具体的に、次エントリ番号１１２２は１であり、完了確認済みエントリ番号１１２３は３である（ステップＳ２０１にてＹＥＳ）。そのため、処理は、ステップＳ２１０に進む。
【０１００】
完了確認部１５は処理部１３にエントリ番号が１のエントリを送信する（ステップＳ２１０）。その後、完了確認部１５は、エントリ番号を１つ増加させる（ステップＳ２１１）。このとき、次エントリ番号１１２２は２となる。そして処理は終了する。
【０１０１】
その後、完了確認部１５は、再び完了確認処理を実行する。完了確認部１５は、次エントリ番号１１２２が完了確認済みエントリ番号１１２３以下か否か判定する（ステップＳ２０１）。このとき、次エントリ番号１１２２は２であり、完了確認済みエントリ番号１１２３は３である。したがって、次エントリ番号１１２２は完了確認済みエントリ番号１１２３以下である（ステップＳ２０１にてＹＥＳ）。
【０１０２】
そして、完了確認部１５は処理部１３にエントリ番号が２のエントリを送信する（ステップＳ２１０）。その後、完了確認部１５は、エントリ番号を１つ増加させる（ステップＳ２１１）。このとき、次エントリ番号１１２２は３となる。そして処理は終了する。
【０１０３】
さらに、完了確認部１５は、再び完了確認処理を実行する。完了確認部１５は、次エントリ番号１１２２が完了確認済みエントリ番号１１２３以下か否か判定する（ステップＳ２０１）。このとき、次エントリ番号１１２２は３であり、完了確認済みエントリ番号１１２３は３である。したがって、次エントリ番号１１２２は完了確認済みエントリ番号１１２３以下である（ステップＳ２０１にてＹＥＳ）。
【０１０４】
その後、完了確認部１５は処理部１３にエントリ番号が３のエントリを送信する（ステップＳ２１０）。その後、完了確認部１５は、次エントリ番号を１つ増加させる（ステップＳ２１１）。このとき、次エントリ番号１１２２は４となる。そして処理は終了する。
【０１０５】
さらに、完了確認部１５は、再び完了確認処理を実行する。完了確認部１５は、次エントリ番号１１２２が完了確認済みエントリ番号１１２３以下か否か判定する（ステップＳ２０１）。このとき、次エントリ番号１１２２は４であり、完了確認済みエントリ番号１１２３は３である。したがって、次エントリ番号１１２２は完了確認済みエントリ番号１１２３より大きい（ステップＳ２０１にてＮＯ）。そのため、処理はステップＳ２０２に進む。
【０１０６】
完了確認部１５は、次エントリ番号１１２２の完了フラグ１１９に１が設定されているか否か判定する（ステップＳ２０２）。次エントリ番号１１２２の完了フラグ１１９に０が設定されている場合（ステップＳ２０２にてＮＯ）、完了確認部１５は、処理部１３に未完了であることを示す通知を送信する（ステップＳ２０３）。例えば、次エントリ番号１１２２が４である場合、図４を参照すると、エントリ番号が４の完了フラグ１１９には０が設定されている。この場合、完了確認部１５は、処理部１３にエントリ番号が４であるエントリの送受信リクエストＩＤ１１７と、送受信リクエストＩＤ１１７を持つ送受信要求が未完了であることを示す通知とを送信する。そして、処理は終了する。
【０１０７】
このように、完了確認部１５は、処理部１３に送受信リクエストＩＤ１１７と、送受信リクエストＩＤ１１７を持つ送受信要求が未完了であることを示す通知を処理部１３に送信する。これによって、処理部１３は、リクエストキュー１１３および完了バッファ１１２を参照せずに、どの送受信要求が未完了なのかわかる。
【０１０８】
また、上述したように、完了確認部１５は、エントリ番号が０から３までのエントリを処理部１３に送信する。これによって、処理部１３は送信されたエントリ番号が０から３の送受信要求が完了したことがわかる。
【０１０９】
また、完了確認部１５が、エントリ番号が０から３までのエントリを送信する間、保証部１６は保証処理を１回しか行っていない。つまり、保証部１６は、４つの送受信要求に対する保証処理を１回にまとめて行っている。
【０１１０】
したがって、１つの送受信要求ごとに１回の保証処理を行う場合と比較すると、本実施形態において、１つの送受信要求に対する保証処理のコストは、１／４となる。例えば、保証処理のコストが高い場合であっても、本実施形態に係る通信システム１０は、複数の送受信要求に対し、１回にまとめて保証処理を行うことができるため、１つの送受信要求ごとに１回の保証処理を行う場合と比較すると、１つの送受信要求に対する保証処理のコストを削減することができる。
【０１１１】
また、完了確認部１５は、完了フラグ１１９に１が設定されている場合に、実際に記憶部１１に送受信要求に関連するデータが、メモリモジュール１１４に格納されているか否か確認するために保証部１６に保証処理の指示を送信する。
【０１１２】
これによって、送受信要求に関連するデータがメモリモジュール１１４に格納されていない場合、保証部１６が保証処理を行う。具体的に、保証部１６は、送受信要求に関連するデータがメモリモジュール１１４に格納されるまで待機し、記憶部１１に送受信要求に関連するデータがメモリモジュール１１４に格納されたことを確認後、完了確認部１５に保証処理が完了したことを通知する。
【０１１３】
この動作によって、記憶部１１に送受信要求に関連するデータが格納されていることが保証される。言い換えると、実際に記憶部１１のメモリモジュールに格納されたデータと管理上の記憶部１１内のデータとに生じる差がなくなる。
【０１１４】
以上のことから、本実施形態に係る通信装置１は、通信性能を低下させず、かつ記憶部１１のメモリモジュールに格納されたデータと管理上の記憶部１１内のデータとに生じる差をなくすことができる。
【０１１５】
（変形例１）
ここで第１実施形態に適用できる変形例を説明する。図１２は、第１実施形態に係る通信システム１０の変形例の一例を示す図である。変形例では、通信システム１０は、通信装置１とストレージ装置２００とを含む。通信装置１とストレージ装置２００とはネットワークインタフェースを介さずに接続している。
【０１１６】
通信装置１は、通信部１２に代わり入出力制御部２０１を備える。入出力制御部２０１は、要求送受信部１４からの指示に基づき、リクエストキュー１１３を参照し、ＤＭＡを用いてストレージ装置２００との通信を制御する。
【０１１７】
具体的に、入出力制御部２０１は、ストレージ装置２００との送受信が完了した場合、通信部１２と同様に、要求テーブル１１２１に送受信が完了した送受信データ１１１のエントリを書き込む。このように、変形例１に係る通信システム１０によれば、通信装置１とストレージ装置２００とがＲＤＭＡではなくＤＭＡを用いて通信を行うことで、ＣＰＵを介さずに直接データのやり取りを行うことができる。
【０１１８】
＜第２実施形態＞
図１３は、第２実施形態に係る通信装置２の構成の一例を示す機能ブロック図である。本実施形態に係る通信装置２は、本開示が解決しようとする課題を解決するための基本の構成である。
【０１１９】
通信装置２は、記憶部２１と、通信部２２と、完了確認部２５と、保証部２６とを備える。通信部２２は、通信部１２の機能を有する。また、通信部２２は、送受信データの送信または受信の要求である送受信要求に応じて、前記送受信データをＤＭＡ（Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ）転送する。
【０１２０】
記憶部２１は、記憶部１１の機能を有する。また記憶部２１は、送受信要求に関連するデータを通信部２２から受信する。また、記憶部２１は、送受信要求に関連するデータが格納される記憶領域２１４を含む。
【０１２１】
完了確認部２５は、完了確認部１５の機能を有する。また、完了確認部２５は、送受信要求が所定の条件を満たす場合、通信部２２における送受信要求に応じた処理が完了したか否かを確認する。
【０１２２】
所定の条件を満たす場合とは、例えば、送受信要求の送信元が送信する送受信要求の数が閾値より多い場合を示す。また、所定の条件とは、例えば、送受信要求のうち、通信部２２が送受信要求に関連するデータを記憶部２１に送信したものの、保証部２６が記憶領域２１４に該受信要求に関連するデータが格納されたか否かを確認していない送受信要求の数が閾値より多い場合を示す。また例えば、所定の条件を満たす場合とは、送受信要求のうち、通信部２２が送受信要求に関連するデータを記憶部１１に送信したものの、保証部２６が記憶領域２１４に該受信要求に関連するデータが格納されたか否かを確認していない送受信要求に含まれる送受信データ１１１のサイズが閾値より大きい場合を示す。
【０１２３】
保証部２６は、保証部１６の機能を有する。保証部２６は、完了確認部２５が、通信部２２における送受信要求に応じた処理が完了したと確認した場合、記憶領域２１４に該送受信要求に関連するデータが格納されるまで待機する。
【０１２４】
保証部２６が記憶領域２１４に、該送受信要求に関連するデータが格納されるまで待機することによって、記憶部２１の記憶領域２１４に送受信要求に関連するデータが格納されたことが保証される。言い換えると、実際に記憶部２１の記憶領域２１４に格納されたデータと管理上の記憶部２１内のデータとに生じる差がなくなる。
【０１２５】
また、保証部２６は、１つの送受信要求ごとに保証処理を行うわけでなく、例えば、送受信要求が所定の条件を満たす場合、保証処理を行う。したがって、例えば保証部２６は、複数の送受信要求に対し１回にまとめて保証処理を行うことも可能である。
【０１２６】
以上のことから、本実施形態に係る通信装置２は、通信性能を低下させず、かつ記憶部２１に格納されたデータと管理上の記憶部２１内のデータとに生じる差をなくすことができる。
【０１２７】
また、各実施形態に係る通信装置の各構成要素の一部又は全部は、その他の汎用または専用の回路、プロセッサ等やこれらの組み合わせによって実現される。これらは、単一のチップによって構成されてもよいし、バスを介して接続される複数のチップによって構成されてもよい。
【０１２８】
各実施形態に係る通信装置の各構成要素の一部又は全部が複数の情報処理装置や回路等により実現される場合には、複数の情報処理装置や回路等は、集中配置されてもよいし、分散配置されてもよい。例えば、情報処理装置や回路等は、クライアントアンドサーバシステム、クラウドコンピューティングシステム等、各々が通信ネットワークを介して接続される形態として実現されてもよい。
【０１２９】
以上、各実施形態を参照して本開示を説明したが、本開示は上記各実施形態に限定されものではない。本開示の構成や詳細には、本開示のスコープ内で当業者が理解し得る様々な変更をすることができる。
【符号の説明】
【０１３０】
１    通信装置
２    通信装置
１０    通信システム
１１    記憶部
１２    通信部
１３    処理部
１４    要求送受信部
１５    完了確認部
１６    保証部
２１    記憶部
２２    通信部
２５    完了確認部
２６    保証部
１００    外部装置
１１１    送受信データ
１１２    完了バッファ
１１３    リクエストキュー
１１４    メモリモジュール
１１５    コントローラ
１１６    リングバス
１１７    送受信リクエストＩＤ
１１８    完了ステータス
１１９    完了フラグ
１６１    保証処理の命令
１６２    保証処理の命令
２００    ストレージ装置
２０１    入出力制御部
２１４    記憶領域
９００    情報処理装置
９０１    ＣＰＵ
９０２    ＲＯＭ
９０３    ＲＡＭ
９０４    プログラム
９０５    記憶装置
９０８    通信インターフェース
９０９    通信ネットワーク
９１０    入出力インターフェース
９１１    バス
１１１１    受信データ
１１１１ａ    受信データ
１１１１ｂ    受信データ
１１１１ｃ    受信データ
１１１１ｄ    受信データ
１１１１ｅ    受信データ
１１１２    受信データ
１１１２ａ    受信データ
１１１２ｂ    受信データ
１１１２ｃ    受信データ
１１１２ｄ    受信データ
１１１２ｅ    受信データ
１１１３    送信データ
１１１３ａ    送信データ
１１１３ｂ    送信データ
１１１３ｃ    送信データ
１１１３ｄ    送信データ
１１１３ｅ    送信データ
１１２１    要求テーブル
１１２２    次エントリ番号
１１２３    完了確認済みエントリ番号
【図１】
2018147430.tif 000003
【図２】
2018147430.tif 000004
【図３】
2018147430.tif 000005
【図４】
2018147430.tif 000006
【図５】
2018147430.tif 000007
【図６】
2018147430.tif 000008
【図７】
2018147430.tif 000009
【図８】
2018147430.tif 000010
【図９】
2018147430.tif 000011
【図１０】
2018147430.tif 000012
【図１１】
2018147430.tif 000013
【図１２】
2018147430.tif 000014
【図１３】
2018147430.tif 000015