JP2014236453A - 情報処理装置、情報処理システム及び情報処理システムの制御方法 - Google Patents

情報処理装置、情報処理システム及び情報処理システムの制御方法 Download PDF

Info

Publication number
JP2014236453A
JP2014236453A JP2013118439A JP2013118439A JP2014236453A JP 2014236453 A JP2014236453 A JP 2014236453A JP 2013118439 A JP2013118439 A JP 2013118439A JP 2013118439 A JP2013118439 A JP 2013118439A JP 2014236453 A JP2014236453 A JP 2014236453A
Authority
JP
Japan
Prior art keywords
packet
transmission
buffer
transmitted
retransmission
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.)
Pending
Application number
JP2013118439A
Other languages
English (en)
Inventor
輝夫 谷本
Teruo Tanimoto
輝夫 谷本
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2013118439A priority Critical patent/JP2014236453A/ja
Priority to US14/258,194 priority patent/US9509623B2/en
Publication of JP2014236453A publication Critical patent/JP2014236453A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/32Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/26Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
    • H04L47/266Stopping or restarting the source, e.g. X-on or X-off
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/30Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Communication Control (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Abstract

【課題】共有受信バッファに溢れが発生した場合において、パケットの再送を効率的に行う。
【解決手段】情報処理装置は、複数の送信元から受信したパケットを処理する。そして、複数の送信元から受信したパケットを格納するバッファと、バッファに、受信した第1のパケットを格納するための空き領域が無い場合、パケットの送信を停止することを要求する停止要求を第1のパケットの送信元に送信すると共に、第1のパケットを廃棄する第1処理部と、バッファに空き領域が生じた場合、第1のパケットの送信元に、第1のパケットを再送することを要求する再送要求を送信する第2処理部とを有する。
【選択図】図2

Description

本発明は、情報処理装置、情報処理システム及び情報処理システムの制御方法に関する。
例えばInfinibandにおけるSRQ(Shared Receive Queue)等、複数のノード又はプロセス等から受信したパケットを格納するバッファ(以下、共有受信バッファと呼ぶ)が知られている。
図1に、共有受信バッファを用いたシステムの一例を示す。図1の例では、受信ノードが共有受信バッファ1000を有している。受信ノードは、送信ノード#1及び送信ノード#2から受信したパケットを共有受信バッファ1000に一旦格納する。そして、受信ノードは、共有受信バッファ1000に格納されたパケットを順次処理する。
例えば送信ノード及び受信ノードの数がいずれも1であるようなシステムにおいては、パケットの送信元は、自身が送信したパケットの数及びサイズ等に基づきバッファに空き領域が有るか否かを推定できる。しかし、図1に示したようなシステムにおいては複数の送信元からのパケットが共有受信バッファに格納されるため、パケットの送信元は、共有受信バッファに空き領域が有るかわからない。そのため、共有受信バッファに空き領域が無いにも関わらず送信元がパケットを送信した結果、共有受信バッファに溢れが発生し、送信されたパケットが廃棄されるという事態が生じ得る。
従って、共有受信バッファを用いたシステムにおいては、共有受信バッファに溢れが発生した場合に備え、送信元のノード又はプロセス等がパケットを再送する仕組みを備えることが求められる。
送信装置と受信装置とを含むシステムにおけるパケットの再送に関して、以下のような技術が存在する。具体的には、受信装置は、パケットに記された順序番号と、欠落なくデータパケットが送達されたと仮定した場合における順序番号である受信期待順序番号とを送信装置に送信する。送信装置は、受信装置から受信した情報に基づき欠落パケットを特定すると共に、欠落パケットを再送する。
しかし、上記の技術においては、パケットが伝送路上のビット誤り或いは輻輳等により廃棄された場合に発生する欠落を想定しており、バッファ溢れによるパケットの廃棄に対して対処を行うことは想定されていない。バッファ溢れが発生した場合には、廃棄されたパケットをすぐに再送したとしてもバッファ溢れが解消していないことがあるため、パケットを再び廃棄することになる可能性がある。また、上記の技術における受信装置は、共有受信バッファに相当するようなバッファを備えていない。
従って、上記の従来技術は、共有受信バッファに溢れが発生した場合における再送には対処することができない。
特開2001−168907号公報
従って、本発明の目的は、1つの側面では、共有受信バッファに溢れが発生した場合において、パケットの再送を効率的に行うための技術を提供することである。
本発明に係る情報処理装置は、複数の送信元から受信したパケットを処理する情報処理装置である。そして、本情報処理装置は、複数の送信元から受信したパケットを格納するバッファと、バッファに、受信した第1のパケットを格納するための空き領域が無い場合、パケットの送信を停止することを要求する停止要求を第1のパケットの送信元に送信すると共に、第1のパケットを廃棄する第1処理部と、バッファに空き領域が生じた場合、第1のパケットの送信元に、第1のパケットを再送することを要求する再送要求を送信する第2処理部とを有する。
共有受信バッファに溢れが発生した場合において、パケットの再送を効率的に行えるようになる。
図1は、共有受信バッファを用いたシステムの一例を示す図である。 図2は、本実施の形態におけるシステムの概要を示す図である。 図3は、再送テーブルのデータ構造の一例を示す図である。 図4は、Typeフィールドの値とパケットの種類との対応を示す図である。 図5は、停止要求の一例を示す図である。 図6は、再送要求の一例を示す図である。 図7は、通常のパケットの一例を示す図である。 図8は、ACK及びNAKの一例を示す図である。 図9は、パケットを送信するノードにおいて行われる処理の処理フローを示す図である。 図10は、パケットを受信するノードにおけるネットワークアダプタが行う処理の処理フローを示す図である。 図11は、パケットを受信するノードにおける受信プロセスによって行われる処理の処理フローを示す図である。 図12は、本実施の形態の処理シーケンスを示す図である。 図13は、本実施の形態の処理を具体的に説明するための図である。 図14は、本実施の形態の処理を具体的に説明するための図である。 図15は、本実施の形態の処理を具体的に説明するための図である。 図16は、本実施の形態の処理を具体的に説明するための図である。 図17は、本実施の形態の処理を具体的に説明するための図である。 図18は、本実施の形態の効果を具体的に説明するための図である。 図19は、本実施の形態の効果を具体的に説明するための図である。 図20は、本実施の形態の効果を具体的に説明するための図である。 図21は、コンピュータの機能ブロック図である。
図2に、本実施の形態のシステム概要を示す。例えばレイヤ2スイッチであるネットワークスイッチ3には、ノード100と、ノード110と、ノード120とが接続されている。図2において、ノードの数は3であるが、数に限定は無い。
ノード100は、CPU(Central Processing Unit)101と、バッファ管理部103及び停止要求生成部104を含むネットワークアダプタ102と、1又は複数のプロセス用領域106を含むメインメモリ105とを有する。ネットワークアダプタ102は、ネットワークスイッチ3に接続されている。CPU101は、ネットワークアダプタ102及びメインメモリ105に接続されている。プロセス用領域106は、プロセス毎に用意される領域である。従って、プロセスの数がN(Nは自然数)である場合にはプロセス用領域106の数もNである。
バッファ管理部103は、プロセス用領域106におけるバッファ107及び再送テーブル108を管理する。停止要求生成部104は、バッファ管理部103の指示に従い、パケットを受信することができない旨を通知し且つパケットの送信を停止することを要求する停止要求(NAK−RNR(Non-AcKnowledgement-Receiver Not Ready))を生成する。プロセス用領域106は、CPU101により実行されるプログラムのプロセスのためのメモリ領域である。バッファ107は共有受信バッファ(例えばSRQ)である。再送テーブル108には、再送を管理するためのデータが格納される。処理部109は、バッファ107に格納されているパケットの処理及び再送要求を生成する処理等を実行する。
ノード110及びノード120の構成はノード100の構成と同様であるので、説明を省略する。なお、ノード100乃至120は、パケットの送信者及び受信者のいずれにもなり得る。
図3に、再送テーブルのデータ構造の一例を示す。図3の例では、再送テーブルには、ノードIDとプロセスIDとの組み合わせ毎に、停止要求の送信が有るか否かを示すフラグが格納される。停止要求の送信が無い(すなわち、パケットの再送をしない)場合には、フラグは「1」に設定される。停止要求の送信が有る場合(すなわち、パケットの再送をする)場合には、フラグは「0」に設定される。例えば、ノードの数がN(Nは自然数)であり、各ノードにおけるプロセスの最大値がM(Mは自然数)である場合には、N*Mのフラグ格納領域が用意される。
図4に、ノード間で送受信されるパケットに含まれるTypeフィールドの値とパケットの種類との対応を示す。本実施の形態においては、5種類のパケットが使用される。パケットにおけるTypeフィールドの値が「000」である場合は通常のパケットであり、Typeフィールドの値が「001」である場合はACK(ACKnowledgement)であり、Typeフィールドの値が「010」である場合はNAK(Non-AcKnowledgement、本実施の形態においてはNAK−RNR以外のNAKを指す)であり、Typeフィールドの値が「011」である場合は停止要求(NAK−RNR)であり、Typeフィールドの値が「100」である場合は再送要求である。
図5に、停止要求の一例を示す。停止要求には、パケット長を示す情報(10ビット)と、宛先バッファID(宛先プロセスIDであってもよい。9ビット)と、宛先ノードID(12ビット)と、送信元バッファID(送信元プロセスIDであってもよい。8ビット)と、送信元ノードID(12ビット)と、Typeの値(3ビット)と、廃棄したパケットのシーケンス番号(16ビット)とが含まれる。停止要求は、停止要求生成部104乃至124により、廃棄したパケットに含まれる情報に基づき生成される。
図6に、再送要求の一例を示す。再送要求には、パケット長を示す情報(10ビット)と、宛先バッファID(宛先プロセスIDであってもよい。9ビット)と、宛先ノードID(12ビット)と、送信元バッファID(送信元プロセスIDであってもよい。8ビット)と、送信元ノードID(12ビット)と、Typeの値(3ビット)とが含まれる。再送要求は、処理部109乃至129により、再送テーブル108乃至128に基づき生成される。
図7に、通常のパケットの一例を示す。通常のパケットには、パケット長を示す情報(10ビット)と、宛先バッファID(宛先プロセスIDであってもよい。9ビット)と、宛先ノードID(12ビット)と、送信元バッファID(送信元プロセスIDであってもよい。8ビット)と、送信元ノードID(12ビット)と、Typeの値(3ビット)と、シーケンス番号(16ビット)と、ペイロード(可変長)とが含まれる。
図8に、ACK及びNAKの一例を示す。通常のパケットには、パケット長を示す情報(10ビット)と、宛先バッファID(宛先プロセスIDであってもよい。9ビット)と、宛先ノードID(12ビット)と、送信元バッファID(送信元プロセスIDであってもよい。8ビット)と、送信元ノードID(12ビット)と、Typeの値(3ビット)と、最後に受信したパケットのシーケンス番号(16ビット)と、ペイロード(可変長)とが含まれる。
次に、図9を用いて、パケットを送信するノードにおいて行われる処理について説明する。説明を簡単にするため、パケットを送信するノードはノード100であるとする。
まず、ノード100のプロセス用領域106における処理部109は、パケットを生成し、パケットを処理するプロセス(以下、受信プロセスと呼ぶ)に送信する(図9:ステップS1)。なお、生成されるパケットは、例えば図7に示したようなパケットである。
処理部109は、受信プロセスから完了通知を受信するまで待機する(ステップS3)。そして、処理部109は、受信プロセスから完了通知を受信する(ステップS5)。なお、受信した完了通知は、バッファ管理部103によってバッファ107に格納される。本実施の形態における完了通知は、ACK、NAK又はNAK−RNR(すなわち、停止要求)のいずれかである。
処理部109は、完了通知がACKであるか判断する(ステップS7)。完了通知はACKである場合(ステップS7:Yesルート)、パケットを再送しなくてもよいので、処理を終了する。
完了通知がACKではない場合(ステップS7:Noルート)、処理部109は、完了通知はNAK−RNRであるか判断する(ステップS9)。
完了通知がNAK−RNRではない場合(ステップS9:Noルート)、完了通知はNAK−RNR以外のNAKでありすぐに再送できるため、ステップS15の処理に移行する。
完了通知がNAK−RNRである場合(ステップS9:Yesルート)、処理部109は、受信プロセスから再送要求を受信するまで待機する(ステップS11)。そして、処理部109は、受信プロセスから再送要求を受信する(ステップS13)。なお、受信したNAK−RNRはバッファ管理部103によってバッファ107に格納される。
処理部109は、ステップS1において送信したパケットを受信プロセスに再度送信する(ステップS15)。そして処理を終了する。
以上のように、NAK−RNR(すなわち、停止要求)を受信した場合にはすぐには再送をせず、再送要求を受信した後に再送をする。これにより、再送されたパケットが共有受信バッファの溢れにより再び廃棄されることを防げるようになる。
一方、NAK−RNR以外のNAKを受信した場合には、すぐにパケットを再送しても問題は無いので、すぐにパケットを再送する。すなわち、タイムアウトを待ってから再送を行うわけではない。これにより、再送までの時間を短縮できるようになる。
次に、図10を用いて、パケットを受信するノードにおけるネットワークアダプタが行う処理について説明する。説明を簡単にするため、パケットを受信するノードはノード110であるとする。
まず、ノード110のネットワークアダプタ112におけるバッファ管理部113は、パケットを送信するプロセス(以下、送信プロセスと呼ぶ)からパケットを受信するまで待機する(図10:ステップS21)。
バッファ管理部113は、送信プロセスからパケットを受信する(ステップS23)。そして、バッファ管理部113は、受信したパケットをバッファ117に書き込み可能である(すなわち、バッファ117に空き領域が有る)か判断する(ステップS25)。
受信したパケットをバッファ117に書き込み可能である場合(ステップS25:Yesルート)、バッファ管理部113は、受信したパケットをバッファ117に書き込み(ステップS27)、ステップS21の処理に戻る。
一方、受信したパケットをバッファ117に書き込み可能ではない場合(ステップS25:Noルート)、バッファ管理部113は、停止要求生成部114に、パケットの送信を停止することを要求するNAK−RNR(すなわち、停止要求)を生成させる。そして、バッファ管理部113は、停止要求生成部114により生成されたNAK−RNRを、受信したパケットの送信元の送信プロセスに送信する(ステップS29)。
バッファ管理部113は、再送テーブル118を更新する(ステップS31)。具体的には、バッファ管理部113は、送信プロセスのノードのIDと送信プロセスのIDとの組み合わせに対応するフラグを「0」に設定する。そして、バッファ管理部113は、受信したパケットを廃棄する(ステップS33)。
バッファ管理部113は、処理を終了するか判断する(ステップS35)。処理を終了する場合(ステップS35:Yesルート)、処理を終了する。例えば、ノード110の電源オフをノード110の操作者により指示された場合には、処理を終了する。
一方、処理を終了しない場合(ステップS35:Noルート)、次のパケットについて処理するため、ステップS21の処理に戻る。
以上のように停止要求を送信すれば、バッファに空き領域が無いにも関わらずパケットが再送されるのを抑制できるので、無駄な再送パケットを減らすことができる。
次に、図11を用いて、パケットを受信するノードにおける受信プロセス(ここでは、処理部129)によって行われる処理について説明する。
まず、処理部129は、バッファ127におけるパケットを処理する(図11:ステップS41)。ステップS41においては、(1)バッファ127に格納されている全パケットを処理してもよいし、(2)予め定められた数のパケットを処理してもよいし、(3)バッファ127に格納されているパケットの数が予め定められた数になるまで処理してもよい。
処理部129は、再送テーブル128において、フラグが「0」であるノードID及びプロセスIDの組合せが有るか判断する(ステップS43)。フラグが「0」であるノードID及びプロセスIDの組合せが無い場合(ステップS43:Noルート)、パケットの再送をしなくてもよいので、処理を終了する。
一方、フラグが「0」であるノードID及びプロセスIDの組合せが有る場合(ステップS43:Yesルート)、処理部129は、そのプロセスIDが表す送信プロセスに、パケットを再送することを要求する再送要求を送信する(ステップS45)。
処理部129は、再送テーブル128において、ステップS43において特定された組合せに対応するフラグを「0」から「1」に変更する(ステップS47)。そしてステップS43の処理に戻る。
なお、パケットを受信するノードが、パケットを送信する可能性がある送信プロセスに対し、マルチキャストによって停止要求を送信するという方法も考えられる。しかし、マルチキャストにコストがかかる場合(例えば、ハードウェアによるマルチキャストを行うことができないためハードウェアによる複数回のユニキャストによりマルチキャストと同等の送信を行う場合)があるため、このような方法が適切ではない場合もある。
これに対し、本実施の形態においては、実際にパケットを送信した送信プロセスに対してのみ停止要求及び再送要求を送信するので、マルチキャストによって停止要求及び再送要求を送信する場合と比較して、無駄な要求を減らせるようになる。
また、空き領域が生じた場合に再送要求を送信するので、タイムアウトを待ってから再送をする場合と比較して、迅速に再送を行えるようになる。
図12に、本実施の形態の処理シーケンスを示す。図12には、パケットを送信する送信プロセス、パケットを受信するノードにおけるネットワークアダプタ(以下、受信側ネットワークアダプタと呼ぶ)、及び受信パケットを処理する受信プロセスの処理が示されている。
まず、送信プロセスが、パケットを受信するノードに対してパケットを送信する。受信側ネットワークアダプタは、送信プロセスからのパケットを受信する。受信側ネットワークアダプタは、受信プロセス用領域に設けられたバッファに受信パケットを格納することを試みるが、受信パケットをバッファに格納するとバッファ溢れが発生することを検出する。
そこで、受信側ネットワークアダプタは、送信プロセスに対し停止要求を送信すると共に、受信パケットを廃棄する。また、受信側ネットワークアダプタは、メインメモリにおける受信プロセス用領域に設けられた再送テーブルを更新する。具体的には、送信プロセスのノードのIDと送信プロセスのIDとの組み合わせに対応するフラグを「0」に設定する。
受信プロセスは、受信プロセス用領域に設けられたバッファに格納されているパケットを処理する。例えば、FIFO(First In First Out)によりパケットを処理する。処理によってバッファに空き領域が生じた場合には、受信プロセスは、再送要求を生成し、受信側ネットワークアダプタに出力する。受信側ネットワークアダプタは、受け取った再送要求を送信プロセスに送信する。
送信プロセスは、受信側ネットワークアダプタから再送要求を受信する。送信プロセスは、停止要求を受信する直前に送信したパケット(すなわち、受信側ネットワークアダプタが廃棄したパケット)を、受信側ネットワークアダプタに送信する。受信側ネットワークアダプタは、再送されたパケットを、受信プロセス用領域におけるバッファに書き込む。
以上のような処理を実行すれば、共有受信バッファに空き領域が無いにも関わらずパケットが再送されることを防げるので、無駄な再送パケットを減らすことができる。すなわち、共有受信バッファの溢れが生じた場合において、効率的にパケットの再送を行えるようになる。
次に、図13乃至図17を用いて、本実施の形態の処理をより具体的に説明する。図13乃至図17には、パケットの送信、バッファ溢れの検出、停止要求の送信、再送要求の送信及びパケットの再送という一連の処理が示されている。
図13を用いて、ノード110における処理部119がパケットP1を送信した場合における処理を説明する。ノード110のプロセス用領域116におけるパケットP1は、バッファ管理部113を介してネットワークに送信される。パケットP1は、ネットワークスイッチ3によってノード100に転送される。ノード100におけるバッファ管理部103は、パケットP1を受信すると、バッファ107に空き領域が有るか判断し、空き領域が有る場合にはパケットP1をバッファ107に格納する。バッファ107に格納されたパケットP1は、処理部109によって処理される。
図14を用いて、ノード120における処理部129がパケットP2を送信した場合における処理を説明する。ノード120のプロセス用領域126におけるパケットP2は、ネットワークアダプタ122を介してネットワークに送信される。パケットP2は、ネットワークスイッチ3によってノード100に転送される。ノード100におけるバッファ管理部103は、パケットP2を受信すると、バッファ107に空き領域が有るか判断する。ここでは、バッファ107に空き領域が無い(すなわち、バッファ溢れが発生した)と判断される。そのため、パケットP2はバッファ107には格納されず、バッファ管理部103によって廃棄される。
図15を用いて、停止要求がノード100からノード120に送信された場合における処理を説明する。停止要求生成部104によって生成された停止要求Sは、バッファ管理部103によってネットワークに送信される。停止要求Sは、ネットワークスイッチ3によってノード120に転送される。ノード120におけるバッファ管理部123は、停止要求Sを受信すると、バッファ127に格納する。停止要求Sを受信したため、処理部129は、停止要求において指定されている送信プロセスに対してパケットを送信することを停止する。
図16を用いて、再送要求がノード100からノード120に送信された場合における処理を説明する。処理部109によって生成された再送要求Rは、バッファ管理部103によってネットワークに送信される。再送要求Rは、ネットワークスイッチ3によってノード120に転送される。ノード120におけるバッファ管理部123は、再送要求Rを受信すると、バッファ127に格納する。
図17を用いて、ノード120における処理部129がパケットP2を再送した場合における処理を説明する。ノード120のプロセス用領域126におけるパケットP2は、ネットワークアダプタ122を介してネットワークに再送される。パケットP2は、ネットワークスイッチ3によってノード100に転送される。ノード100におけるバッファ管理部103は、パケットP2を受信すると、バッファ107に空き領域が有るか判断する。ここでは、バッファ107に空き領域が有ると判断される。そのため、パケットP2はバッファ107には格納され、処理部109によって処理される。
次に、図18乃至図20を用いて、本実施の形態の効果を具体的に説明する。
図18に、説明に利用するシステムを示す。図18に示したシステムにおいては、1キロ(k)台の送信ノードと、1台の受信ノードとがネットワークスイッチに接続されている。各送信ノードには32の送信プロセスがあるため、本システムには合計で32kの送信プロセスが受信プロセスに対してパケットを送信する。受信プロセスにより使用されるバッファには、4kのパケットを格納できる。
ここで、32kの送信プロセス(以下、送信プロセス群と呼ぶ)の各々が、受信プロセスに対して1つのパケットを同時に送信し、送信されたパケットを受信プロセスが処理する場合を考える。前提として、以下では、バッファに格納されたパケットは、次に送信プロセス群が送信するパケットがバッファに格納されるまでに処理される(すなわち、バッファは空になる)とする。
図18に示したシステムにおいて本実施の形態の処理を実行しない場合、図19に示すような結果になる。図19には、送信プロセス群からの送信パケット数と、受信プロセスから送信プロセス群に送信されるACKの数と、受信プロセスから送信プロセス群に送信されるNAKの数とが時系列で示されている。時刻t0は初期の時刻であり、時刻t15は処理が完了する時刻である。
図19に示すように、送信プロセス群からの送信パケットは2単位時間毎に受信プロセスに送信され、その数は4kずつ減っている。これは、受信プロセスによって4kずつパケットが処理されるからである。時刻t0から時刻t15までの間に送信されるパケットの合計は144kである。
受信プロセスからのACKは、2単位時間毎に送信プロセス群に送信され、その数は4kである。時刻t0から時刻t15までの間に送信されるACKの合計は32kである。
受信プロセスからのNAKの数は、直前に送信プロセス群から送信されたパケットの数から、2単位時間毎に処理されるパケットの数である4kを引いた数である。時刻t0から時刻t15までの間に送信されるNAKの合計は112kである。
よって、ネットワークにおいて転送されるパケットの数の合計は144k+32k+112k=288kである。
一方、図18に示したシステムにおいて本実施の形態の処理を実行する場合、図20に示すような結果になる。図20には、送信プロセス群からの送信パケット数と、受信プロセスから送信プロセス群に送信されるACKの数と、受信プロセスから送信プロセス群に送信される停止要求の数と、受信プロセスから送信プロセス群に送信される再送要求の数とが時系列で示されている。時刻t0は初期の時刻であり、時刻t15は処理が完了する時刻である。
図20に示すように、送信プロセス群からの送信パケットは2単位時間毎に受信プロセスに送信される。その数は、時刻t0においては32kであるが、t0以外の時刻においては4kである。時刻t0から時刻t15までの間に送信されるパケットの合計は60kである。
受信プロセスからのACKは、2単位時間毎に送信プロセス群に送信され、その数は4kである。時刻t0から時刻t15までの間に送信されるACKの合計は32kである。
受信プロセスからの停止要求は、時刻t1において28k送信されるが、それ以降は送信されることはない。時刻t0から時刻t15までの間に送信される停止要求の合計は28kである。
受信プロセスからの再送要求は、2単位時間毎に送信プロセス群に送信され、その数は4kである。時刻t0から時刻t15までの間に送信される再送要求の合計は28kである。よって、ネットワークにおいて転送されるパケットの数の合計は60k+32k+28k+28k=148kである。
バッファに格納できるパケットの数のm倍のプロセスと通信する場合、パケットの数の削減率は、(m−4m+3)/(m+m)*100(単位は%)で求めることができる。上の例の場合、m=8であるから、パケットの数の削減率は35/72*100≒49(%)になる。
また、図20を図19と比較すると、処理の完了までに要するステップ数は同じであるが、本実施の形態の処理はタイムアウトを待ってから処理を行うわけではないため、1ステップに要する時間が短い。従って、処理の完了までに要する時間は、図19の場合より短い。
以上本発明の一実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、上で説明したノード100乃至120の機能ブロック構成は実際のプログラムモジュール構成に一致しない場合もある。
また、上で説明した各テーブルの構成は一例であって、上記のような構成でなければならないわけではない。さらに、処理フローにおいても、処理結果が変わらなければ処理の順番を入れ替えることも可能である。さらに、並列に実行させるようにしても良い。
なお、上で述べたノード100乃至120は、コンピュータ装置であって、図21に示すように、メモリ2501とCPU(Central Processing Unit)2503とハードディスク・ドライブ(HDD:Hard Disk Drive)2505と表示装置2509に接続される表示制御部2507とリムーバブル・ディスク2511用のドライブ装置2513と入力装置2515とネットワークに接続するための通信制御部2517とがバス2519で接続されている。オペレーティング・システム(OS:Operating System)及び本実施例における処理を実施するためのアプリケーション・プログラムは、HDD2505に格納されており、CPU2503により実行される際にはHDD2505からメモリ2501に読み出される。CPU2503は、アプリケーション・プログラムの処理内容に応じて表示制御部2507、通信制御部2517、ドライブ装置2513を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ2501に格納されるが、HDD2505に格納されるようにしてもよい。本発明の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク2511に格納されて頒布され、ドライブ装置2513からHDD2505にインストールされる。インターネットなどのネットワーク及び通信制御部2517を経由して、HDD2505にインストールされる場合もある。このようなコンピュータ装置は、上で述べたCPU2503、メモリ2501などのハードウェアとOS及びアプリケーション・プログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
以上述べた本発明の実施の形態をまとめると、以下のようになる。
本実施の形態に係る情報処理装置は、複数の送信元から受信したパケットを処理する情報処理装置である。そして、本情報処理装置は、(A)複数の送信元から受信したパケットを格納するバッファと、(B)バッファに、受信した第1のパケットを格納するための空き領域が無い場合、パケットの送信を停止することを要求する停止要求を第1のパケットの送信元に送信すると共に、第1のパケットを廃棄する第1処理部と、(C)バッファに空き領域が生じた場合、第1のパケットの送信元に、第1のパケットを再送することを要求する再送要求を送信する第2処理部とを有する。
このようにすれば、バッファ(例えば共有受信バッファ)に空き領域が無いにも関わらずパケットが再送されるのを抑制できるので、無駄な再送パケットを減らすことができる。すなわち、バッファに溢れが発生した場合にパケットの再送を効率的に行えるようになる。また、実際にパケットを送信した送信元に対してのみ停止要求及び再送要求を送信するので、マルチキャストによって停止要求及び再送要求を送信する場合と比較して、無駄な要求を減らすことができるようになる。さらに、空き領域が生じた場合に再送要求を送信するので、タイムアウトを待ってから再送をする場合と比較して、迅速に再送を行えるようになる。
また、本情報処理装置が、(D)パケットの送信元を表す送信元情報と停止要求を送信したか否かを表すデータとを対応付けて格納する第1データ格納部をさらに有してもよい。そして、上で述べた第1処理部は、(b1)第1のパケットの送信元情報と停止要求を送信したことを表すデータとを対応付けて第1データ格納部に格納し、上で述べた第2処理部は、(c1)バッファに空き領域が生じた場合、第1のパケットの送信元情報を第1データ格納部から読み出し、当該送信元情報が表す送信元に、再送要求を送信してもよい。上で述べたように送信元情報を保存しておけば、廃棄されたパケットを漏れなく再取得できるようになる。また、複数の送信元が存在するような場合にも対処できるようになる。
また、上で述べた送信元情報は、ノードの識別情報とプロセスの識別情報とを含んでもよい。このようにすれば、1つのノードにおいて複数のプロセスが実行されており、複数のプロセスの各々がパケットを送信するような場合にも対処できるようになる。
なお、上記方法による処理をコンピュータに行わせるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブルディスク、CD−ROM、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。尚、中間的な処理結果はメインメモリ等の記憶装置に一時保管される。
以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。
(付記1)
複数の送信元から受信したパケットを処理する情報処理装置において、
前記複数の送信元から受信したパケットを格納するバッファと、
前記バッファに、受信した第1のパケットを格納するための空き領域が無い場合、パケットの送信を停止することを要求する停止要求を前記第1のパケットの送信元に送信すると共に、前記第1のパケットを廃棄する第1処理部と、
前記バッファに空き領域が生じた場合、前記第1のパケットの送信元に、前記第1のパケットを再送することを要求する再送要求を送信する第2処理部と、
を有する情報処理装置。
(付記2)
パケットの送信元を表す送信元情報と前記停止要求を送信したか否かを表すデータとを対応付けて格納する第1データ格納部
をさらに有し、
前記第1処理部は、
前記第1のパケットの送信元情報と前記停止要求を送信したことを表すデータとを対応付けて前記第1データ格納部に格納し、
前記第2処理部は、
前記バッファに空き領域が生じた場合、前記第1のパケットの送信元情報を前記第1データ格納部から読み出し、当該送信元情報が表す送信元に、前記再送要求を送信する
ことを特徴とする付記1記載の情報処理装置。
(付記3)
前記送信元情報は、ノードの識別情報とプロセスの識別情報とを含む
ことを特徴とする付記2記載の情報処理装置。
(付記4)
複数の送信装置と、前記複数の送信装置から受信したパケットを処理する受信装置とを含む情報処理システムにおいて、
前記受信装置は、
前記複数の送信装置から受信したパケットを格納するバッファと、
前記バッファに、受信した第1のパケットを格納するための空き領域が無い場合、パケットの送信を停止することを要求する停止要求を、前記複数の送信装置のうち前記第1のパケットを送信した送信装置に送信すると共に、前記第1のパケットを廃棄する第1処理部と、
前記バッファに空き領域が生じた場合、前記複数の送信装置のうち前記第1のパケットを送信した送信装置に、前記第1のパケットを再送することを要求する再送要求を送信する第2処理部と、
を有し、
前記複数の送信装置の各々は、
前記受信装置から前記停止要求を受信した場合、前記受信装置へのパケットの送信を停止し、前記受信装置から前記再送要求を受信した場合、前記第1のパケットを前記受信装置に送信する第3処理部と、
を有する情報処理システム。
(付記5)
複数の送信装置と、前記複数の送信装置から受信したパケットを処理する受信装置とを含む情報処理システムの制御方法において、
前記受信装置は、前記複数の送信装置から受信したパケットを格納するバッファに、受信した第1のパケットを格納するための空き領域が無い場合、パケットの送信を停止することを要求する停止要求を、前記複数の送信装置のうち前記第1のパケットを送信した第1の送信装置に送信すると共に、前記第1のパケットを廃棄し、
前記第1の送信装置は、前記受信装置から前記停止要求を受信した場合、前記受信装置へのパケットの送信を停止し、
前記受信装置は、前記バッファに空き領域が生じた場合、前記第1の送信装置に、前記第1のパケットを再送することを要求する再送要求を送信し、
前記第1の送信装置は、前記受信装置から前記再送要求を受信した場合、前記第1のパケットを前記受信装置に送信する
ことを特徴とする情報処理システムの制御方法。
100,110,120 ノード 101,111,121 CPU
102,112,122 ネットワークアダプタ 103,113,123 バッファ管理部
104,114,124 停止要求生成部 105,115,125 メインメモリ
106,116,126 プロセス用領域 107,117,127 バッファ
108,118,128 再送テーブル 109,119,129 処理部
3 ネットワークスイッチ

Claims (4)

  1. 複数の送信元から受信したパケットを処理する情報処理装置において、
    前記複数の送信元から受信したパケットを格納するバッファと、
    前記バッファに、受信した第1のパケットを格納するための空き領域が無い場合、パケットの送信を停止することを要求する停止要求を前記第1のパケットの送信元に送信すると共に、前記第1のパケットを廃棄する第1処理部と、
    前記バッファに空き領域が生じた場合、前記第1のパケットの送信元に、前記第1のパケットを再送することを要求する再送要求を送信する第2処理部と、
    を有する情報処理装置。
  2. パケットの送信元を表す送信元情報と前記停止要求を送信したか否かを表すデータとを対応付けて格納する第1データ格納部
    をさらに有し、
    前記第1処理部は、
    前記第1のパケットの送信元情報と前記停止要求を送信したことを表すデータとを対応付けて前記第1データ格納部に格納し、
    前記第2処理部は、
    前記バッファに空き領域が生じた場合、前記第1のパケットの送信元情報を前記第1データ格納部から読み出し、当該送信元情報が表す送信元に、前記再送要求を送信する
    ことを特徴とする請求項1記載の情報処理装置。
  3. 複数の送信装置と、前記複数の送信装置から受信したパケットを処理する受信装置とを含む情報処理システムにおいて、
    前記受信装置は、
    前記複数の送信装置から受信したパケットを格納するバッファと、
    前記バッファに、受信した第1のパケットを格納するための空き領域が無い場合、パケットの送信を停止することを要求する停止要求を、前記複数の送信装置のうち前記第1のパケットを送信した送信装置に送信すると共に、前記第1のパケットを廃棄する第1処理部と、
    前記バッファに空き領域が生じた場合、前記複数の送信装置のうち前記第1のパケットを送信した送信装置に、前記第1のパケットを再送することを要求する再送要求を送信する第2処理部と、
    を有し、
    前記複数の送信装置の各々は、
    前記受信装置から前記停止要求を受信した場合、前記受信装置へのパケットの送信を停止し、前記受信装置から前記再送要求を受信した場合、前記第1のパケットを前記受信装置に送信する第3処理部と、
    を有する情報処理システム。
  4. 複数の送信装置と、前記複数の送信装置から受信したパケットを処理する受信装置とを含む情報処理システムの制御方法において、
    前記受信装置は、前記複数の送信装置から受信したパケットを格納するバッファに、受信した第1のパケットを格納するための空き領域が無い場合、パケットの送信を停止することを要求する停止要求を、前記複数の送信装置のうち前記第1のパケットを送信した第1の送信装置に送信すると共に、前記第1のパケットを廃棄し、
    前記第1の送信装置は、前記受信装置から前記停止要求を受信した場合、前記受信装置へのパケットの送信を停止し、
    前記受信装置は、前記バッファに空き領域が生じた場合、前記第1の送信装置に、前記第1のパケットを再送することを要求する再送要求を送信し、
    前記第1の送信装置は、前記受信装置から前記再送要求を受信した場合、前記第1のパケットを前記受信装置に送信する
    ことを特徴とする情報処理システムの制御方法。
JP2013118439A 2013-06-05 2013-06-05 情報処理装置、情報処理システム及び情報処理システムの制御方法 Pending JP2014236453A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2013118439A JP2014236453A (ja) 2013-06-05 2013-06-05 情報処理装置、情報処理システム及び情報処理システムの制御方法
US14/258,194 US9509623B2 (en) 2013-06-05 2014-04-22 Information processing device, information processing system, and method for processing packets from transmitting devices

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2013118439A JP2014236453A (ja) 2013-06-05 2013-06-05 情報処理装置、情報処理システム及び情報処理システムの制御方法

Publications (1)

Publication Number Publication Date
JP2014236453A true JP2014236453A (ja) 2014-12-15

Family

ID=52005436

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013118439A Pending JP2014236453A (ja) 2013-06-05 2013-06-05 情報処理装置、情報処理システム及び情報処理システムの制御方法

Country Status (2)

Country Link
US (1) US9509623B2 (ja)
JP (1) JP2014236453A (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105391567B (zh) * 2014-09-05 2019-05-24 华为技术有限公司 流量管理实现方法、装置和网络设备
US9876727B2 (en) * 2015-03-23 2018-01-23 Mellanox Technologies Tlv Ltd. Physical-layer signaling of flow control updates
JP6477111B2 (ja) * 2015-03-24 2019-03-06 富士ゼロックス株式会社 情報処理装置及び情報処理プログラム
US10038509B2 (en) * 2015-03-24 2018-07-31 Sony Corporation Data reception apparatus, data transmission system, data reception method, and data transmission method
CN113411370A (zh) * 2020-07-06 2021-09-17 丰疆智能(深圳)有限公司 终端、服务端、物联网数据传输方法以及数据传输***

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05334104A (ja) * 1992-05-29 1993-12-17 Nec Corp データグラム型マルチプロセス間ソケット通信でのデータ制御装置
JPH0697983A (ja) * 1992-09-10 1994-04-08 Toshiba Corp ネットワークシステム
JPH06276206A (ja) * 1993-03-23 1994-09-30 Nippon Telegr & Teleph Corp <Ntt> 中継バッファオーバフロー回避方式
JPH07115431A (ja) * 1993-10-15 1995-05-02 Fujitsu Ltd パケット再送方法
JP2001257696A (ja) * 2000-03-13 2001-09-21 Fuji Electric Co Ltd マスタスレーブ間の通信方式
JP2005057482A (ja) * 2003-08-04 2005-03-03 Fujitsu Fip Corp データ転送方法、データ転送用プログラムおよび記録媒体
WO2011129363A1 (ja) * 2010-04-15 2011-10-20 日本電気株式会社 伝送装置、伝送方法及びコンピュータプログラム

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2871704B2 (ja) * 1988-12-29 1999-03-17 キヤノン株式会社 画像通信方法
US5255268A (en) * 1992-02-04 1993-10-19 International Business Data distribution network with improved broadcast feature
US6067408A (en) * 1993-05-27 2000-05-23 Advanced Micro Devices, Inc. Full duplex buffer management and apparatus
JPH11112722A (ja) 1997-09-30 1999-04-23 Minolta Co Ltd 画像形成装置および画像形成システム
US7171464B1 (en) * 1999-06-23 2007-01-30 Microsoft Corporation Method of tracing data traffic on a network
JP2001168907A (ja) 1999-12-06 2001-06-22 Nippon Telegr & Teleph Corp <Ntt> 通信装置
US6598174B1 (en) * 2000-04-26 2003-07-22 Dell Products L.P. Method and apparatus for storage unit replacement in non-redundant array
US6973071B1 (en) * 2001-03-06 2005-12-06 Rfmd Wpan, Inc. Method and apparatus for controlling the flow of data in a wireless communication system
US7324535B1 (en) * 2003-04-10 2008-01-29 Cisco Technology, Inc. Methods and apparatus for maintaining a queue
BRPI0719540A2 (pt) * 2006-10-02 2014-01-14 Lg Electronics Inc Método de retransmissão para sistema multiportadora
TWI330964B (en) * 2007-01-29 2010-09-21 Via Tech Inc Packet processing method and a network device using the method
ES2478018T3 (es) * 2007-12-20 2014-07-18 Ntt Docomo, Inc. Estación móvil, dispositivo de estación base, método de control de comunicación y sistema de comunicación móvil
US8248936B2 (en) * 2009-04-01 2012-08-21 Lockheed Martin Corporation Tuning congestion control in IP multicast to mitigate the impact of blockage

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05334104A (ja) * 1992-05-29 1993-12-17 Nec Corp データグラム型マルチプロセス間ソケット通信でのデータ制御装置
JPH0697983A (ja) * 1992-09-10 1994-04-08 Toshiba Corp ネットワークシステム
JPH06276206A (ja) * 1993-03-23 1994-09-30 Nippon Telegr & Teleph Corp <Ntt> 中継バッファオーバフロー回避方式
JPH07115431A (ja) * 1993-10-15 1995-05-02 Fujitsu Ltd パケット再送方法
JP2001257696A (ja) * 2000-03-13 2001-09-21 Fuji Electric Co Ltd マスタスレーブ間の通信方式
JP2005057482A (ja) * 2003-08-04 2005-03-03 Fujitsu Fip Corp データ転送方法、データ転送用プログラムおよび記録媒体
WO2011129363A1 (ja) * 2010-04-15 2011-10-20 日本電気株式会社 伝送装置、伝送方法及びコンピュータプログラム

Also Published As

Publication number Publication date
US9509623B2 (en) 2016-11-29
US20140362867A1 (en) 2014-12-11

Similar Documents

Publication Publication Date Title
US10430374B2 (en) Selective acknowledgement of RDMA packets
US9577791B2 (en) Notification by network element of packet drops
US20190342225A1 (en) Methods and apparatus for early delivery of data link layer packets
CN103905300B (zh) 一种数据报文发送方法、设备及***
US10594442B2 (en) End-to-end negative acknowledgment
US20140254351A1 (en) Enhanced acknowledgement and retransmission mechanism
JP2014236453A (ja) 情報処理装置、情報処理システム及び情報処理システムの制御方法
WO2014063370A1 (zh) 一种实现pcie交换网络的报文传输方法、设备、***和存储介质
WO2014092779A1 (en) Notification by network element of packet drops
US8935329B2 (en) Managing message transmission and reception
US11888960B2 (en) Packet processing method and apparatus
US9692560B1 (en) Methods and systems for reliable network communication
JP2015012570A (ja) 中継装置
JP2010011296A (ja) 送受信回路、送信回路及び送受信方法
JP6206465B2 (ja) 通信装置および通信方法
JP2015027100A (ja) パケット通信の伝送制御方法及びパケット通信システム
US9130740B2 (en) Variable acknowledge rate to reduce bus contention in presence of communication errors
WO2013029509A1 (zh) 一种基于令牌环的网络流量控制方法、节点及***
CN109347674B (zh) 一种数据传输的方法、装置及电子设备
TW200947957A (en) Non-block network system and packet arbitration method thereof
BR112019015070A2 (pt) Método e aparelhos de transmissão de dados e equipamento das instalações do cliente
CN109586931B (zh) 组播方法及终端设备
WO2023230193A1 (en) Chip-to-chip interconnect with a layered communication architecture
JP5636574B2 (ja) 通信装置、パケット転送方法及びそのプログラム
CN102904764A (zh) 一种数据传输装置及其传输方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20160310

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20161207

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170110

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170306

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170912

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20180313