JP2014209796A - Client device and server device - Google Patents
Client device and server device Download PDFInfo
- Publication number
- JP2014209796A JP2014209796A JP2014156741A JP2014156741A JP2014209796A JP 2014209796 A JP2014209796 A JP 2014209796A JP 2014156741 A JP2014156741 A JP 2014156741A JP 2014156741 A JP2014156741 A JP 2014156741A JP 2014209796 A JP2014209796 A JP 2014209796A
- Authority
- JP
- Japan
- Prior art keywords
- confirmation request
- survival confirmation
- timer
- packet
- tunnel
- 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.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
Landscapes
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
Abstract
Description
本発明は、通信ネットワークにおける生存確認技術に関連するものである。 The present invention relates to a survival confirmation technique in a communication network.
企業内ネットワークや家庭内ネットワーク等のプライベートネットワークと、インターネット等の外部ネットワークとの間には、通信のセキュリティを確保するためのファイアウォール装置(NAT装置等も含む)が設置されるのが一般的である。 Firewall devices (including NAT devices) are generally installed between private networks such as corporate networks and home networks and external networks such as the Internet to ensure communication security. is there.
このようなファイアウォール装置では、ネットワーク管理のポリシーに応じて、通信を許可するプロトコルが設定されるが、例えば、多くの場合、プライベートネットワーク内のクライアント装置からの要求に係るHTTP/HTTPS通信は許容されている。 In such a firewall device, a protocol for permitting communication is set according to a network management policy. For example, in many cases, HTTP / HTTPS communication related to a request from a client device in a private network is allowed. ing.
そこで、プライベートネットワーク内のクライアント装置と、外部の装置との間で、IP電話や映像会議等の通信を行うために、HTTPのように通信が許容されているプロトコルのヘッダで、目的とする通信のパケットをカプセリングすることにより、仮想的な通信路であるトンネルを形成し、当該トンネルを通して、IP電話や映像会議等の目的とする通信を行うトンネリング技術が用いられている。 Therefore, in order to perform communications such as IP phone calls and video conferencing between a client device in a private network and an external device, the target communication is performed using a protocol header that allows communication such as HTTP. A tunneling technique is used in which a tunnel, which is a virtual communication path, is formed by encapsulating these packets, and communication for a purpose such as an IP phone or video conference is performed through the tunnel.
図1は、上記のようなトンネリング技術を利用したファイアウォール越え通信の例を示す図である。図1に示すように、トンネリング技術では、トンネルクライアント機能を備えたクライアント装置(図1の例ではPC)と、外部ネットワーク(インターネット)に設置されたトンネルサーバ装置との間でトンネルを形成し、通信を行う。 FIG. 1 is a diagram illustrating an example of communication across a firewall using the tunneling technique as described above. As shown in FIG. 1, in the tunneling technology, a tunnel is formed between a client device having a tunnel client function (PC in the example of FIG. 1) and a tunnel server device installed in an external network (Internet). Communicate.
トンネリングを用いた通信を行う場合に、途中経路で通過するファイアウォール装置やプロクシサーバ装置の機能により、長時間無通信の場合に、強制的に切断させられてしまう場合や、切断状態にならないまでも信号が疎通しなくなっている、いわゆるトンネルが詰まった状態が生じる場合がある。このような状態を回避するために、クライアント装置がトンネルサーバ装置に生存確認要求を定期的に送信し、クライアント装置がサーバ装置から生存確認要求応答を受信することにより、クライアント装置がトンネル状態の判断や再接続等を行う疎通確認技術が従来からある。 When performing communication using tunneling, the firewall device or proxy server device that passes through the route may cause the device to be forcibly disconnected if there is no communication for a long time, or it may not be in a disconnected state. There may be a so-called tunnel clogged state where signals are not communicated. In order to avoid such a state, the client device periodically transmits a survival confirmation request to the tunnel server device, and the client device receives a survival confirmation request response from the server device, so that the client device determines the tunnel status. Conventionally, there is a communication confirmation technique for performing reconnection and the like.
上記の技術では、生存確認要求の送信間隔が短いと、本来のデータパケット以外の無駄なパケットが増加し、無通信クライアントを含む多数のクライアントのトラフィックが集中するトンネルサーバ装置やそのネットワークにおいて、処理負荷が増加し、性能低下を招く恐れがある。逆に、送信間隔を長くしてしまうと、詰まり状態を長時間検出できず、通信が長時間途切れたりする問題が生じる。つまり、従来の疎通確認のための技術では、処理負担軽減と異常状態検出時間の短縮という相反する条件を同時に満たすことは困難であった。 In the above technology, if the transmission interval of the survival confirmation request is short, the number of useless packets other than the original data packet increases, and processing is performed in the tunnel server device and its network where many clients including non-communication clients concentrate. There is a possibility that the load increases and the performance is reduced. Conversely, if the transmission interval is lengthened, the clogged state cannot be detected for a long time, causing a problem that communication is interrupted for a long time. That is, with the conventional technology for confirming communication, it has been difficult to simultaneously satisfy the conflicting conditions of reducing the processing load and shortening the abnormal state detection time.
一方、TCP/IP等の技術により実現される信頼性が担保された通信路では、通信路上のパケットドロップ等の外乱によりパケットの再送等が発生し、結果として遅延が生じることで通信が安定しない場合がある。これを解消するため、複数本のトンネル接続を束ねて1本の論理的なトンネル接続を構成し、その中にパケットを分散して送信することで通信の安定化を図る従来技術がある。 On the other hand, in communication channels that are guaranteed reliability realized by technologies such as TCP / IP, retransmission of packets occurs due to disturbances such as packet drops on the communication channel, resulting in delays that result in unstable communication. There is a case. In order to solve this problem, there is a conventional technique for stabilizing communication by bundling a plurality of tunnel connections to form one logical tunnel connection and distributing and transmitting packets therein.
上記の技術では、より安定した通信を実現するために、複数本のトンネル接続の各々について、例えば上述した疎通確認技術を適用することにより、無通信切断防止及び疎通確認を行うとともに、複数本のトンネル接続経由でパケットを流す際に、通信状態の悪いトンネル接続を避けてパケットを流すことが望ましい。 In the above technology, in order to realize more stable communication, for example, by applying the above-described communication confirmation technology to each of a plurality of tunnel connections, non-communication disconnection prevention and communication confirmation are performed, and When sending a packet via a tunnel connection, it is desirable to send the packet while avoiding a tunnel connection having a poor communication state.
本発明は上記の問題点に鑑みてなされたものであり、処理負担軽減と異常状態検出時間の短縮という相反する条件を満たすとともに、複数本のトンネル接続を束ねて通信を行う通信方式において通信状態の悪いトンネル接続を避ける動作を迅速に行うことを可能とした生存確認の技術を提供することを目的とする。 The present invention has been made in view of the above-described problems, satisfying the conflicting conditions of reducing the processing burden and shortening the abnormal state detection time, and in the communication system in which communication is performed by bundling a plurality of tunnel connections. An object of the present invention is to provide a survival confirmation technique that can quickly perform an operation to avoid a bad tunnel connection.
ここで、複数本のトンネル接続を束ねてパケットを通すことで通信を安定化させる従来技術を用いる場合、送信側で順次送信しても途中経路の外乱等の影響で受信側では順序性が担保されない場合があり、その結果、パケットが順序逆転するため、電話やテレビ会議等のリアルタイム性が要求される場合など、アプリケーションの特性によりアプリケーションが正常に動作しない等の影響が出ていた。本発明の一実施形態では、このような順序逆転を防止する技術を提供することも目的としている。 Here, when using the conventional technology that stabilizes communication by bundling multiple tunnel connections and passing packets, the ordering is guaranteed on the receiving side due to disturbances on the way even if it is transmitted sequentially on the transmitting side. As a result, the order of the packets is reversed, and there is an influence that the application does not operate normally depending on the characteristics of the application, such as when real-time property such as telephone or video conference is required. Another object of the present invention is to provide a technique for preventing such order reversal.
上記の課題を解決するために、本発明は、サーバ装置と、前記サーバ装置とデータ通信を行うクライアント装置とを備える通信システムにおいて用いられる前記クライアント装置であって、
第1の時間経過内に前記クライアント装置が備えるアプリケーション部からのデータパケット送信がない場合に、生存確認要求を前記サーバ装置に送信し、
第1の時間経過内に前記アプリケーション部からのデータパケット送信がある場合に、生存確認要求付きデータパケットを前記サーバ装置に送信するクライアント装置として構成される。
In order to solve the above problem, the present invention is the client device used in a communication system including a server device and a client device that performs data communication with the server device,
When there is no data packet transmission from the application unit included in the client device within the first time period, a survival confirmation request is transmitted to the server device,
When there is a data packet transmission from the application unit within the first time, it is configured as a client device that transmits a data packet with a survival confirmation request to the server device.
前記クライアント装置は、
前記クライアント装置が備えるアプリケーション部からのデータパケット送信がない場合に、第1の時間間隔で生存確認要求を前記サーバ装置に送信し、
前記アプリケーション部からのデータパケット送信がある場合において、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の第2の時間経過内に、生存確認要求応答受領をデータパケットのヘッダに含めて前記サーバ装置に送信し、
生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の当該第2の時間経過後に、生存確認要求をデータパケットのヘッダに含めて前記サーバ装置に送信する、ように構成されてもよい。
The client device is
When there is no data packet transmission from the application unit provided in the client device, a survival confirmation request is transmitted to the server device at a first time interval,
When there is a data packet transmission from the application unit, the existence confirmation request response is received within a second time after the existence confirmation request response or the existence confirmation request response-attached data packet is received from the server device. And send it to the server device,
A configuration in which a survival confirmation request is included in a header of a data packet and transmitted to the server device after the second time has elapsed after receiving a survival confirmation request response or a data packet with a survival confirmation request response from the server device. May be.
また、本発明は、前記通信システムにおいて用いられる前記サーバ装置であって、
前記サーバ装置からのデータパケット送信がない場合において、生存確認要求を前記クライアント装置から受信した場合に、生存確認要求応答を前記クライアント装置に送信し、前記サーバ装置からのデータパケット送信がある場合において、生存確認要求付きデータパケットを前記クライアント装置から受信した場合に、生存確認要求応答をデータパケットのヘッダに含めて前記クライアント装置に送信する、サーバ装置として構成される。
The present invention is the server device used in the communication system,
When there is no data packet transmission from the server device, when a survival confirmation request is received from the client device, a survival confirmation request response is transmitted to the client device, and when there is a data packet transmission from the server device. When a data packet with a survival confirmation request is received from the client device, the server device is configured to include a survival confirmation request response in the header of the data packet and transmit it to the client device.
本発明の実施の形態によれば、処理負担軽減と異常状態検出時間の短縮という相反する条件を満たすとともに、複数本のトンネル接続を束ねて通信を行う通信方式において通信状態の悪いトンネル接続を避ける動作を迅速に行うことを可能とした生存確認の技術を提供することが可能となる。 According to the embodiment of the present invention, the conflicting conditions of reducing the processing load and shortening the abnormal state detection time are satisfied, and a tunnel connection with a poor communication state is avoided in a communication method in which a plurality of tunnel connections are bundled for communication. It is possible to provide a survival confirmation technique that enables quick operation.
以下、図面を参照して本発明の実施の形態を説明する。 Embodiments of the present invention will be described below with reference to the drawings.
<第1の実施の形態>
(システム構成)
図2に、第1の実施の形態におけるシステムの全体構成を示す。図2に示すように、本実施の形態のシステムは、インターネット5と、企業内ネットワーク等のプライベートネットワーク6との境界に設置されるファイアフォール装置4、ファイアウォール装置4配下にあるトンネルクライアント機能を有するクライアント装置1、トンネルサーバ機能を有するサーバ装置2、及び、クライアント装置1と通信を行う通信相手装置3とを含む。本実施の形態では、サーバ装置2と、通信相手装置3は、インターネット5に接続されている。
<First Embodiment>
(System configuration)
FIG. 2 shows the overall configuration of the system in the first embodiment. As shown in FIG. 2, the system of the present embodiment has a
図2に示すように、クライアント装置1は、クライアント側のトンネル接続に係る処理を行うトンネル機能部11と、本発明に係るクライアント側の生存確認処理を行う生存確認機能部12と、IP電話や映像会議等の目的の通信を行うアプリケーション部13を備える。サーバ装置2は、サーバ側のトンネル接続に係る処理を行うトンネル機能部21と、本発明に係るサーバ側の生存確認処理を行う生存確認機能部22を備える。
As shown in FIG. 2, the
本実施の形態におけるクライアント装置1は、OS(オペレーティングシステム)と、上記機能部に対応するプログラム等を備えるコンピュータ(PC、携帯端末等)である。また、本実施の形態におけるサーバ装置2は、OS、上記機能部に対応するプログラム等を備えるコンピュータである。
The
図3に、クライアント装置1の生存確認機能部12の機能構成を示す。図3に示すように、生存確認機能部12は、生存確認用パケット送受信制御部121、情報格納部122、タイマー1C、タイマー2C、タイマー3C、タイマー4Cを有する。
FIG. 3 shows a functional configuration of the survival
生存確認用パケット送受信制御部121は、生存確認のためにパケットの送受信を制御する機能部であり、タイマーを参照しながら後述するような処理動作を行う。情報格納部122は、状態(良好、応答悪化)、生存確認要求応答受領送信済みフラグを格納する。
The existence confirmation packet transmission /
タイマー1Cは再接続発動タイマーであり、クライアント装置1が最終パケットを送信してから、再接続を実施するまでの時間を計測する。本実施の形態では、タイマー1Cが計測する時間として5秒程度の値を想定している。
The
タイマー2Cは状態悪化判定タイマーであり、クライアント装置1が最終パケットを送信してから、その応答が返るまでの基準となる時間を計測する。本実施の形態では、タイマー2Cが計測する時間として3秒程度の値を想定している。
The
タイマー3Cは生存確認要求送信兼応答受領タイマーであり、連続パケット送信時に「生存確認要求」を載せて送信する最低時間間隔を計測すると同時に、「生存確認要求応答受領」の送信までの期限を計測する。本実施の形態では、タイマー3Cが計測する時間として0.5秒程度の値を想定している。
タイマー4Cは生存確認要求最長送信タイマーであり、長時間パケットの送信が無い場合等に単独の「生存確認要求」を送信する期限を計測する。本実施の形態では、タイマー4Cが計測する時間として10秒程度の値を想定している。
The
図4に、サーバ装置2の生存確認機能部22の機能構成を示す。図4に示すように、生存確認機能部22は、生存確認用パケット送受信制御部221、情報格納部222、タイマー2S、タイマー5Sを有する。
FIG. 4 shows a functional configuration of the survival
生存確認用パケット送受信制御部221は、生存確認のためにパケットの送受信を制御する機能部であり、タイマーを参照しながら後述するような処理動作を行う。情報格納部222は、状態(良好、応答悪化)を格納する。
The existence confirmation packet transmission /
タイマー2Sは状態悪化判定タイマーであり、サーバ装置2が「生存確認要求応答」を送信してから、「生存確認要求応答受領」をクライアント装置1から受信するまでの期限を計測する。本実施の形態では、タイマー2Sが計測する時間として3秒程度の値を想定している。
The
タイマー5Sは「生存確認要求応答」タイマーであり、サーバ装置2が「生存確認要求」(単独のものを除く)を受信してから「生存確認要求応答」を送信するまでの期限を計測する。本実施の形態では、タイマー5Sが計測する時間として1秒程度の値を想定している。
The
なお、「生存確認要求」と「生存確認要求応答受領」はクライアント装置1からサーバ装置2に伝達される信号であり、「生存確認要求応答」は逆にサーバ装置2からクライアント装置1に伝達される信号である。
The “survival confirmation request” and “acknowledgment confirmation request response received” are signals transmitted from the
本実施の形態に係るクライアント装置1及びサーバ装置2のそれぞれは、CPU、記憶装置等を有するコンピュータに上記の各機能を実現するためのプログラムを実行させることにより実現できる。当該プログラムは可搬メモリ等の記録媒体からコンピュータにインストールすることとしてもよいし、ネットワーク上のサーバからダウンロードすることとしてもよい。
Each of the
また、トンネル接続を実現する方式には種々のものあるが、本発明においてトンネル接続を実現する方式は特定の方式に限定されるわけではなく、本発明は様々なトンネル接続の方式に適用可能である。 Although there are various methods for realizing tunnel connection, the method for realizing tunnel connection in the present invention is not limited to a specific method, and the present invention can be applied to various tunnel connection methods. is there.
(システムの動作)
以下では、第1の実施の形態におけるシステムの動作を説明する。以下の動作は、基本的に、クライアント装置1の生存確認機能部12と、サーバ装置2の生存確認機能部22により実行されるものである。
(System operation)
Below, the operation | movement of the system in 1st Embodiment is demonstrated. The following operations are basically executed by the survival
図5は、システムの動作イメージを示す図である。図5に示すように、単独の生存確認用のメッセージ(パケット)、もしくは、本来の通信データ(アプリケーションプログラムにより送受信されるデータ)であるデータパケットに付された形での生存確認用のメッセージがクライアント装置1とサーバ装置2間で送受信される。
FIG. 5 is a diagram showing an operation image of the system. As shown in FIG. 5, there is a single survival confirmation message (packet) or a survival confirmation message attached to a data packet that is original communication data (data transmitted / received by an application program). Data is transmitted and received between the
図6(a)〜(e)は、本実施の形態で用いられるメッセージのフォーマット例を示す図である。なお、ここで示すフォーマットは一例に過ぎず、他の種々のフォーマット、サイズ、メッセージ種別を示す値を使用可能である。 FIGS. 6A to 6E are diagrams showing examples of message formats used in the present embodiment. The format shown here is only an example, and values indicating various other formats, sizes, and message types can be used.
本実施の形態では、ヘッダは1バイトのサイズとなっている。図6(a)に示すように、「23h」が上りトンネルに流れた場合、単独の生存確認要求とみなし、下りトンネルに流れた場合、単独の生存確認要求応答とみなす。図6(b)に示すように、ヘッダ「24h」は単独の生存確認要求応答受領とみなす。 In this embodiment, the header has a size of 1 byte. As shown in FIG. 6A, when “23h” flows through the upstream tunnel, it is regarded as a single survival confirmation request, and when it flows through the downstream tunnel, it is regarded as a single survival confirmation request response. As shown in FIG. 6B, the header “24h” is regarded as a single existence confirmation request response reception.
図6(c)〜(e)に示すように、データパケットを表すヘッダは「30h」となっており、これに生存確認要求または生存確認要求応答を重畳させた場合のヘッダは「31h」となる。また、生存確認要求応答受領を重畳させた場合のヘッダは「32h」となる。 As shown in FIGS. 6C to 6E, the header representing the data packet is “30h”, and the header when the survival confirmation request or the survival confirmation request response is superimposed on this is “31h”. Become. In addition, the header when the existence confirmation request response reception is superimposed is “32h”.
このように、ヘッダの一部ビットを利用することにより、オーバーヘッド無しに生存確認が可能となる。 In this way, by using some bits of the header, it is possible to confirm the existence without overhead.
次に、図7〜図15のフローチャートを参照して、クライアント装置1、及びサーバ装置2の動作を説明する。
Next, operations of the
図7は、クライアント装置1におけるトンネル接続時の処理、及び生存確認要求応答受信時の処理を示すフローチャートである。図7に示すように、クライアント装置1では、トンネル接続開始直後に、状態を「良好」に設定し(ステップ1)、生存確認要求応答受領送信済みフラグを「未送信」にセットする(ステップ2)。続いて、タイマー3C(生存確認要求送信兼応答受領タイマー)、タイマー4C(生存確認要求最長送信タイマー)をスタートさせ、タイマー1C(再接続発動タイマー)、タイマー2C(状態悪化判定タイマー)を停止させる。以降、クライアント装置1における生存確認機能部12は、パケット到着やタイマー動作(タイムアウト)のイベントを契機に動作する。
FIG. 7 is a flowchart showing processing at the time of tunnel connection in the
図8は、データパケット送信時の処理、及びタイマー4C(生存確認要求最長送信タイマー)のタイムアウト時の処理を示すフローチャートである。
FIG. 8 is a flowchart showing processing at the time of data packet transmission and processing at the time of timeout of the
図8に示すように、クライアント装置1がデータパケットを送信する際に、先ずタイマー3C(生存確認要求送信兼応答受領タイマー)がタイムアウトしているか否かを判定する(ステップ11)。タイマー3Cがタイムアウトしている場合(ステップ11のYes)、生存確認要求を送付すべきと判断し、生存確認要求をデータパケットに重畳して送信し(ステップ12)、タイマー3Cを停止する(ステップ13)。
As shown in FIG. 8, when the
一方、ステップ11の判定がNo、すなわちタイマー3C(生存確認要求送信兼応答受領タイマー)がタイムアウトしていなかった場合、必要に応じ、生存確認要求応答受領を送信すべきと判断し、生存確認要求応答受領送信済みフラグを検証し(ステップ14)、未送信の場合(ステップ14のNo)に限り、生存確認要求応答受領をデータパケットに重畳して送信する(ステップ15)し、生存確認要求応答受領送信済みフラグを「送信済み」にセットする。ステップ14の判定がYes、すなわち生存確認要求応答受領を送信済みであった場合、何も重畳せず、単独のデータパケットとして送信する(ステップ17)。
On the other hand, if the determination in
ステップ13、16、17の後、タイマー4Cを停止し、タイマー1C、2Cをスタートする(ステップ19)。
After
サーバ装置2から生存確認要求応答を受信した場合のクライアント装置1の処理を図7を参照して説明する。図7に示すとおり、サーバ装置2から生存確認要求応答を受信した場合、タイマー2C(状態悪化判定タイマー)がタイムアウトしているか否かをチェックし(ステップ4)、タイマー2Cがタイムアウトしていない場合(ステップ4のNo)に限り、状態を「良好」に設定し(ステップ1)、その後、クライアント装置1における状態をトンネル接続直後と同様に初期化する(ステップ2、3)。タイマー2Cがタイムアウトしている場合(ステップ4のYes)、状態は「状態悪化」に設定されており、その設定のまま、クライアント装置1におけるフラグ等をトンネル接続直後と同様に初期化する(ステップ2、3)。
Processing of the
タイマー4C(生存確認要求最長送信タイマー)がタイムアウトした場合の処理を図8を参照して説明する。タイマー4Cがタイムアウトした場合、これはデータパケット送信がしばらく無かったことを意味するため、生存確認要求を単独パケットとして送信する(ステップ18)。その後、タイマー4Cを停止し、タイマー1C(再接続発動タイマー)、タイマー2C(状態悪化判定タイマー)をスタートする(ステップ19)。
Processing when the
図9はタイマー3C(生存確認要求送信兼応答受領タイマー)がタイムアウトした場合のクライアント装置1における処理を示すフローチャートである。タイマー3C(生存確認要求送信兼応答受領タイマー)がタイムアウトした場合、生存確認要求応答受領の送信タイミングであるから、生存確認要求応答受領送信済みフラグをチェックして送信済みか否かをチェックし(ステップ21)、送信済みでなければ(ステップ21のNo)、生存確認要求応答受領を単独パケットとして送信し(ステップ22)、生存確認要求応答受領送信済みフラグを「送信済み」にセットする(ステップ23)。
FIG. 9 is a flowchart showing processing in the
図10はタイマー2C(状態悪化判定タイマー)がタイムアウトした場合のクライアント装置1における処理を示すフローチャートである。図10に示すように、タイマー2C(状態悪化判定タイマー)がタイムアウトした場合、状態が悪化したと判断され、状態を「応答悪化」に設定する(ステップ31)。
FIG. 10 is a flowchart showing processing in the
図11はタイマー1C(再接続発動タイマー)がタイムアウトした場合のクライアント装置1における処理を示すフローチャートである。図11に示すように、タイマー1C(再接続発動タイマー)がタイムアウトした場合、新規に1本トンネル接続を行い(ステップ51)、トンネル接続時処理を行って(ステップ52)、旧トンネル接続を切断し(ステップ53)、新トンネル接続に制御を渡す。
FIG. 11 is a flowchart showing processing in the
図12はトンネル接続時等におけるサーバ装置2の処理を示すフローチャートである。図12に示すように、サーバ装置2では、トンネル接続時に状態を「良好」に設定し(ステップ61)、以降、以下で説明するようにイベントベースで動作する。
FIG. 12 is a flowchart showing processing of the
図13は、生存確認要求付きデータパケットをクライアント装置1から受信した場合におけるサーバ装置2の処理を示すフローチャートである。図13に示すように、生存確認要求付きデータパケットをクライアント装置1から受信した場合、タイマー5S(生存確認要求応答タイマー)をスタートする(ステップ71)。
図14は、生存確認要求を単独パケットとしてクライアント装置1から受信した場合等におけるサーバ装置2の処理を示すフローチャートである。図14に示すように、生存確認要求を単独で受信した場合、サーバ装置2は、生存確認要求応答を単独でクライアント装置1に送信し(ステップ81)、タイマー2S(状態悪化判定タイマー)を(再)スタートし、タイマー5Sを停止する(ステップ84)。
FIG. 13 is a flowchart showing processing of the
FIG. 14 is a flowchart showing processing of the
また、図14に示すように、クライアント装置1へデータパケットを送信する時には、タイマー5S(生存確認要求応答送信タイマー)が動作中か否かを判断し(ステップ82)、動作中(ステップ82のYes)であれば、生存確認要求応答付きのデータパケットをクライアント装置1に送信し(ステップ83)、タイマー2S(状態悪化判定タイマー)を(再)スタートし、タイマー5Sを停止する(ステップ84)。タイマー5S(生存確認要求応答送信タイマー)が動作中でない場合(ステップ82のNo)、通常のデータパケット送信を行う(ステップ85)。
As shown in FIG. 14, when a data packet is transmitted to the
図12に示すように、生存確認要求応答受領をクライアント装置1から受信した場合、タイマー2S(状態悪化判定タイマー)がタイムアウトしていない場合(ステップ62のNo)に限り、状態を「良好」に設定する(ステップ61)。
As shown in FIG. 12, when the receipt of the survival confirmation request response is received from the
図14に示すように、タイマー5S(生存確認要求応答送信タイマー)がタイムアウトした場合、単独の生存確認要求応答をクライアント装置1に送信し(ステップ81)、ステップ84を行う。
As shown in FIG. 14, when the
また、図15に示すように、タイマー2S(状態悪化判定タイマー)がタイムアウトした場合、状態を「応答悪化」に設定する(ステップ91)。
Further, as shown in FIG. 15, when the
次に、上述した各装置における処理手順に対応する状態の遷移について説明する。 Next, the state transition corresponding to the processing procedure in each apparatus described above will be described.
図16は、クライアント装置1における生存確認要求処理の状態遷移図である。図16に示すように、「良好」の状態からタイマー2C(状態悪化判定タイマー)の経過で「応答悪化」になる(ステップ101)。タイマー1C(再接続発動タイマー)経過前でのパケット送信を契機にタイマー2Cがスタートし、タイマー2C経過前のパケット到着により「良好」の状態になる(ステップ102)。
FIG. 16 is a state transition diagram of the survival confirmation request process in the
「応答悪化」の状態からタイマー1C(再接続発動タイマー)が経過すると、「接続不良」(※1)となり、「切断」(※2)となる(ステップ103、104)。そして、初期接続、もしくは再接続を経て「良好」の状態になる(ステップ105)。ただし、本発明の実施の形態では、接続不良と判断された場合(タイマー1Cが経過した場合)、直ちに切断するため「接続不良」状態は実効上存在しない。また、本実施の形態の構成上、「切断」状態を扱う必要がないため、フローチャート上は「切断」状態を示していない。
When the
図17は、サーバ装置2における生存確認要求処理の状態遷移図である。図17に示すように、「良好」の状態からタイマー2S(状態悪化判定タイマー)の経過で「応答悪化」になる(ステップ201)。タイマー2S再スタート後、タイマー2S経過前のパケット到着により「良好」の状態になる(ステップ202)。また、「良好」もしくは「応答悪化」の状態から切断された場合に「切断」となり、その後、接続がなされる(ステップ203、204、205)。なお、前述したとおり、本実施の形態の構成上、「切断」状態を扱う必要がないため、フローチャート上は「切断」状態を示していない。
FIG. 17 is a state transition diagram of the survival confirmation request process in the
図18は、クライアント装置1とサーバ装置2を1セットのシステムとみなし、系全体の状態遷移を表した状態遷移図である。図18では、概ね、単独または重畳で受信する制御信号を「状態」として、タイマーのタイムアウトやパケット送信を状態遷移の条件という形で表記している。
FIG. 18 is a state transition diagram showing state transition of the entire system, assuming that the
上記のフローチャートや状態遷移に従った処理動作を行うサーバ装置2とクライアント装置1間における生存確認動作シーケンスの一例を図19に示す。図19に示す例は、データパケットの通信がない場合の動作を示している。
FIG. 19 shows an example of a survival confirmation operation sequence between the
図19の場合、クライアント装置1においてデータパケットの送信がされないので、図7のステップ3でスタートしたタイマー4C(生存確認要求最長送信タイマー)は、データパケットの送信を契機として停止されることはなく、タイムアウトになり、図8のステップ18に示すとおり、単独での生存確認要求が送信される(図19のステップ501)。生存確認要求を受信したサーバ装置2において、図14のステップ81、84に示すとおり、単独の生存確認要求応答をクライアント装置1に送信し(図19のステップ502)、タイマー2S(状態悪化判定タイマー)を(再)スタートする。
In the case of FIG. 19, since the data packet is not transmitted in the
生存確認要求応答を受信したクライアント装置1は、図7に示す生存確認要求応答受信時の処理を行い、タイマー3C、4Cをスタートする。図19の例では、データパケットに付される生存確認要求応答を受信することはないので、タイマー3Cはタイムアウトし、図8に示すように、クライアント装置1は単独の生存確認要求応答受領をサーバ装置2に送信する(図19のステップ503)。生存確認要求応答受領を受信したサーバ装置1では、図12に示すように、タイマー2Sのタイムアウト確認を行うが、本例ではタイマー2Sはタイムアウトしておらず、状態は「良好」であると判断する。
The
その後、クライアント装置1においてタイマー4C(生存確認要求最長送信タイマー)がタイムアウトし、生存確認要求を送信し(ステップ504)、サーバ装置2から生存確認要求応答が送信される(ステップ505)。
Thereafter, the
このようにデータパケットの送受信がない場合、タイマー4Cにより決定される最長間隔で生存確認が繰り返される。
When there is no data packet transmission / reception in this way, the survival check is repeated at the longest interval determined by the
生存確認動作シーケンスの他の例を図20に示す。図20に示す例は、データパケットの送受信がある場合の動作を示している。 Another example of the survival confirmation operation sequence is shown in FIG. The example shown in FIG. 20 shows an operation when there is data packet transmission / reception.
本例において、データパケットがないときには、上述した処理と同様にして、生存確認要求、生存確認要求応答、生存確認要求応答受領の送受信がなされる(ステップ601〜603)。
In this example, when there is no data packet, transmission / reception of a survival confirmation request, a survival confirmation request response, and a survival confirmation request response reception is performed in the same manner as the above-described processing (
クライアント装置1において送信するデータパケットがある場合、図8に示すとおり、タイマー3C(生存確認要求送信兼応答受領タイマー)をチェックし、ここではタイムアウトしているので、生存確認要求付きデータパケットを送信する(ステップ604)。
When there is a data packet to be transmitted in the
一方、サーバ装置2からは順次データパケットが送信されるが、図20の例において、ステップ605に示すデータパケットは、タイマー5S(生存確認要求応答タイマー)が動作中でないため、通常のデータパケットとして送信される(図14のステップ85)。
On the other hand, data packets are sequentially transmitted from the
ステップ604の生存確認要求付きデータパケットを受信したサーバ装置2において、図13のステップ71に示すとおり、タイマー5S(生存確認要求応答タイマー)がスタートし、図14のステップ83に示すとおり、データパケット送信を契機として生存確認要求応答付きデータパケットが送信され(図20のステップ606)、タイマー5Sが停止し、タイマー2S(状態悪化判定タイマー)が再スタートされる。
In the
クライアント装置1からも順次データパケットが送信されるが、図20の例において、ステップ607、612に示すデータパケットについては、タイマー3Cが停止されている(タイムアウトしていない)とともに、生存確認要求応答受領を送信済みなので、生存確認要求なしのデータパケットとして送信される(図8のステップ17)。
Although data packets are also transmitted sequentially from the
ステップ606の生存確認要求応答付きデータパケットを受信したクライアント装置1は、図7に示すとおり、タイマー3C、4Cをスタートさせるとともに、データパケット送信時に、生存確認要求応答受領付きデータパケットを送信する(図20のステップ608、図8のステップ15)。
Receiving the data packet with the survival confirmation request response in step 606, the
ステップ609、610で示すデータパケットについては、タイマー5Sが動作中でないので、そのままサーバ装置2からクライアント装置1に送信される。
The data packets shown in
ステップ608の生存確認要求応答受領付きデータパケットを送信した後、クライアント装置1では、データパケット送信時に、生存確認要求付きデータパケットを送信する(図20のステップ611、図8のステップ12)。
After transmitting the data packet with receipt of the survival confirmation request response in step 608, the
ステップ611の生存確認要求付きデータパケットを受信したサーバ装置2において、タイマー5S(生存確認要求応答タイマー)がスタートするが、ここではタイマー5Sがタイムアウトし、単独の生存確認要求応答が送信される(ステップ613)。それを受けたクライアント装置1からはタイマー3Cのタイムアウトを契機として単独の生存確認要求応答受領が送信される(ステップ614)。
In the
このようにデータパケットの送受信がある場合、タイマー2S(状態悪化判定タイマー)とクライアント装置1からの上りパケット送信間隔で決まる短い時間間隔での生存確認が繰り返される。これにより状態監視が頻繁になるため、より短期間に状態悪化を検出できる。
When data packets are transmitted and received in this manner, the survival confirmation is repeated at a short time interval determined by the
本実施の形態において、クライアント装置1とサーバ装置2間のトンネルの本数は特に限定されないが、これまでの説明はトンネルが1本である場合を想定している。
In the present embodiment, the number of tunnels between the
後述する第2の実施の形態にように、複数本のトンネルを使用する場合は、本実施の形態で説明する生存確認処理をトンネル毎に行う。 When using a plurality of tunnels as in a second embodiment to be described later, the survival confirmation process described in this embodiment is performed for each tunnel.
また、本実施の形態に係る構成は、以下のように表すこともできる。 The configuration according to the present embodiment can also be expressed as follows.
サーバ装置2との間に構築されたトンネルを介してデータ通信を行うクライアント装置1は、前記サーバ装置2との間で前記トンネルを構築し、当該トンネルを経由してパケットの送受信を行うクライアント側トンネル通信手段11と、前記トンネルを介して生存確認のためのパケット送受信を行うクライアント側生存確認手段12と、を備え、前記クライアント側生存確認手段12は、前記クライアント装置1が備えるアプリケーション部13からのデータパケット送信がない場合に、第1の時間(タイマー4C)間隔で生存確認要求を前記サーバ装置2に送信し、当該生存確認要求を受信した前記サーバ装置2から生存確認要求応答を受信した場合に、生存確認要求応答受領を前記サーバ装置2に送信し、前記アプリケーション部13からのデータパケット送信がある場合において、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置2から受信した後の第2の時間(タイマー3C)経過内に、生存確認要求応答受領付きデータパケットを前記サーバ装置2に送信し、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の当該第2の時間経過後に、生存確認要求付きデータパケットを前記サーバ装置2に送信し、前記生存確認要求応答又は前記生存確認要求応答付きデータパケットを前記サーバ装置から受信しないで第3の時間(タイマー2C)が経過した場合に、前記トンネルの状態が悪化したと判定する。
The
また、前記サーバ装置2は、前記サーバ装置2との間で前記トンネルを構築し、当該トンネルを経由してパケットの送受信を行うサーバ側トンネル通信手段21と、前記トンネルを介して生存確認のためのパケット送受信を行うサーバ側生存確認手段22と、を備え、前記サーバ側生存確認手段22は、前記サーバ装置2からのデータパケット送信がない場合において、生存確認要求を前記クライアント装置1から受信した場合に、生存確認要求応答を前記クライアント装置1に送信し、前記サーバ装置2からのデータパケット送信がある場合において、生存確認要求付きデータパケットを前記クライアント装置1から受信した場合に、生存確認要求応答付きデータパケットを前記クライアント装置1に送信し、前記生存確認要求応答又は前記生存確認要求応答付きデータパケットを前記クライアント装置1に送信後、第4の時間(タイマー2S)経過内に生存確認要求応答受領又は生存確認要求応答受領付きデータパケットを前記クライアント装置1から受信しない場合に、前記トンネルの状態が悪化したと判定する。
Further, the
<第2の実施の形態>
次に、本発明の第2の実施の形態について説明する。本実施の形態でのシステム構成は図2〜4で説明した第1の実施の形態と同様である。ただし、本実施の形態では、クライアント装置1のトンネル機能部11、及びサーバ装置2のトンネル機能部21のそれぞれが、複数本のトンネル接続を束ねてパケット送受信を行う機能を備えている。また、生存確認機能部12、22は、複数本のトンネル接続を用いる構成に対応した機能を含む。
<Second Embodiment>
Next, a second embodiment of the present invention will be described. The system configuration in this embodiment is the same as that of the first embodiment described with reference to FIGS. However, in the present embodiment, each of the
図21は、パケット送信側とパケット受信側におけるトンネル機能部11、21の構成を示す図である。図21は、本実施の形態の機能を分かりやすく示すために、片方向の通信構成を示すものであるが、実際には、クライアント装置1とサーバ装置2の各々において、図21に示すパケット送信側の機能とパケット受信側の機能を備える。つまり、図21は、クライアント装置1からサーバ装置2への上り方向の通信構成、または、サーバ装置2からクライアント装置1への下り方向の通信構成を示している。
FIG. 21 is a diagram illustrating the configuration of the
図21に示すように、パケット送信側のトンネル機能部は、分配部101、カウンター102、トンネル接続リスト格納部103を含む。パケット受信側のトンネル機能部は、集約受信部201、最終送信番号格納部202、タイマー203を含む。もちろん、各トンネル機能部は、複数本のトンネル接続を行う機能も含む。
As illustrated in FIG. 21, the tunnel function unit on the packet transmission side includes a
パケット送信側では、トンネル接続リスト格納部103に接続中のトンネルのリストであるトンネル接続リストが格納される。図21の例では、トンネル接続0〜Nが示されている。分配部101は、トンネル接続リスト及びカウンターを利用して、送信対象のパケットに対して順次番号を付与し、複数のトンネルに対して順次パケットを送信する。送信に用いるトンネルを複数リストとして順に用いて送信する構成となっている。また、各トンネルの状態が悪化した場合、リストから取り除き、良好に復帰した場合、再度リストに加える。
On the packet transmission side, a tunnel connection list which is a list of tunnels being connected is stored in the tunnel connection
パケット受信側では、最後に再送信したパケットの番号が、最終送信番号格納部202に格納される。集約受信部201はパケットを格納するキュー(バッファメモリ)を備え、以下の処理を行う。なお、以下のような制御を行う集約受信部201は、再送信順序制御手段の一例である。
On the packet receiving side, the last retransmitted packet number is stored in the final transmission
集約受信部201は、最終送信パケット番号と受信したパケットのパケット番号とを比較し、受信したパケットのパケット番号が最終送信パケット番号+1以下であれば直ちに送信し、+2以上であれば、集約受信部201におけるキューの中を確認し、既に待ち合わせのパケットがあればキューの中のパケットに引き続き受信したパケットを再送信する。キューにパケットが無ければ、受信したパケットをキューに格納してタイマー203を始動する。タイマー203がタイムアウトするまで次のパケットがこなかった場合は、キューに格納されたパケットを送信する。
以下では、上記の処理をより詳細にフローチャートを参照して説明する。 Hereinafter, the above process will be described in more detail with reference to flowcharts.
図22は、パケット送信側トンネル機能部における初期化処理を示すフローチャートである。図22に示すように、カウンター値を0にし(ステップ111)、トンネル接続リストを空にし(ステップ112)、トンネル接続をN本オープンする(ステップ113)。 FIG. 22 is a flowchart showing an initialization process in the packet transmission side tunnel function unit. As shown in FIG. 22, the counter value is set to 0 (step 111), the tunnel connection list is emptied (step 112), and N tunnel connections are opened (step 113).
図23は、パケット送信側トンネル機能部における分配部101が行う分配送信処理を示すフローチャートである。図23に示すように、パケットにカウンター値を付加し(ステップ121)、トンネル接続リストの先頭にあるトンネルにパケットを送信する(ステップ122)。そして、カウンター値に1を加算し(ステップ123)、トンネル接続リストの先頭の要素をリストの末尾に移動する(ステップ124)。
FIG. 23 is a flowchart showing a distribution transmission process performed by the
図24は、パケット送信側トンネル機能部における、トンネル状態「良好」化時、もしくはトンネル接続時の処理を示すフローチャートである。ここで、トンネル状態「良好」化時とは、生存確認部(12、22)において、トンネル接続が「応答悪化」の状態から、「良好」の状態になったことが検知された時のことである。 FIG. 24 is a flowchart showing processing when the tunnel state is “good” or when the tunnel is connected in the packet transmission side tunnel function unit. Here, when the tunnel state is “good”, the existence confirmation unit (12, 22) detects when the tunnel connection is changed from “response deteriorated” to “good”. It is.
ここでは、トンネル接続の末尾に、接続した(又は良好になった)トンネルを追加する(ステップ131)。 Here, the connected (or improved) tunnel is added to the end of the tunnel connection (step 131).
図25は、パケット送信側トンネル機能部における、トンネル状態「応答悪化」時、もしくはトンネル切断時の処理を示すフローチャートである。ここで、トンネル状態「応答悪化」時とは、生存確認部(12、22)において、トンネル接続が「良好」の状態から、「応答悪化」の状態になったことが検知された時のことである。 FIG. 25 is a flowchart showing processing at the time of tunnel state “response deterioration” or tunnel disconnection in the packet transmission side tunnel function unit. Here, the tunnel state “response deterioration” is when the survival confirmation unit (12, 22) detects that the tunnel connection is changed from “good” to “response deterioration”. It is.
ここでは、トンネル接続リストから該当するトンネルを削除する(ステップ141)。 Here, the corresponding tunnel is deleted from the tunnel connection list (step 141).
図26は、パケット受信側トンネル機能部における初期化処理を示すフローチャートである。初期化時において、最終送信番号を−1にする(ステップ151)。 FIG. 26 is a flowchart showing the initialization process in the packet receiving side tunnel function unit. At the time of initialization, the final transmission number is set to -1 (step 151).
図27は、パケット受信側トンネル機能部における集約受信部201が実行する集約受信処理を示すフローチャートである。
FIG. 27 is a flowchart showing the aggregate reception process executed by the
パケットを受信すると、受信したパケットのパケット番号が最終送信番号+1以下かどうかをチェックする(ステップ161)。最終送信番号+1以下である場合(ステップ161のYes)、受信したパケットを再送信し、最終送信番号を当該パケットの番号とする(ステップ162)。 When a packet is received, it is checked whether the packet number of the received packet is equal to or less than the final transmission number + 1 (step 161). If it is equal to or less than the final transmission number + 1 (Yes in step 161), the received packet is retransmitted, and the final transmission number is set as the number of the packet (step 162).
ステップ161において、受信したパケットのパケット番号が最終送信番号+1以下でない場合(+2以上の場合)、キューの中に既に待ち合わせ中のパケットが存在するか否かを確認する(ステップ163)。待ち合わせ中のパケットが存在する場合(ステップ163のYes)、キューの中のパケットを全て送信し、タイマーを停止し、最終送信番号を更新する(ステップ164)。その後、受信したパケットを再送信し、最終送信番号を当該パケットの番号とする(ステップ162)。ステップ163において待ち合わせ中のパケットが存在しない場合、パケットをキューに投入し(ステップ165)、タイマーをスタートする(ステップ166)。 In step 161, if the packet number of the received packet is not less than or equal to the final transmission number +1 (+2 or more), it is checked whether there is a packet already waiting in the queue (step 163). If there is a waiting packet (Yes in step 163), all the packets in the queue are transmitted, the timer is stopped, and the final transmission number is updated (step 164). Thereafter, the received packet is retransmitted, and the final transmission number is set as the number of the packet (step 162). If there is no waiting packet in step 163, the packet is put into the queue (step 165), and the timer is started (step 166).
図28は、パケット受信側トンネル機能部におけるタイマータイムアウト処理を示すフローチャートである。図28に示すとおり、タイマーがタイムアウトになると、キューの中のパケットを、パケットを受信した順番で全て送信し、タイマーを停止し、最終送信番号を更新する(ステップ171)。 FIG. 28 is a flowchart showing a timer timeout process in the packet receiving side tunnel function unit. As shown in FIG. 28, when the timer times out, all the packets in the queue are transmitted in the order in which the packets are received, the timer is stopped, and the final transmission number is updated (step 171).
本実施の形態では、送信に用いるトンネル接続について、接続状態であると同時に、トンネル状態が「良好」であることも条件としている。つまり、状態が悪化したと判定されたトンネル接続を使用しないこととしている。これにより、パケット再送等により一時的に応答の悪化したトンネル接続を回避して良好な応答を保つことができる。 In the present embodiment, it is a condition that the tunnel connection used for transmission is in the connection state and the tunnel state is “good”. In other words, the tunnel connection determined to have deteriorated is not used. Thereby, it is possible to avoid a tunnel connection whose response has been temporarily deteriorated due to packet retransmission or the like and maintain a good response.
上記のように動作するトンネル機能部を備えるサーバ装置2(送信側)からクライアント装置1(受信側)への通信処理例を図29、図30を参照して説明する。 An example of communication processing from the server apparatus 2 (transmission side) having the tunnel function unit operating as described above to the client apparatus 1 (reception side) will be described with reference to FIGS.
図29は、サーバ装置2からクライアント装置1への伝送路におけるジッターが小さい場合の処理例を示す。図29に示すように、パケット#0〜#15がサーバ装置2から各トンネル接続経由で順番に送信される。本例では、パケット#4がパケット#5よりも少し遅れてクライアント装置1に到達する。この場合、受信側の処理を示す図27に示すように、クライアント装置1では、パケット#3の次に受信するパケット#5をキューに格納し、タイマータイムアウト前にパケット#4を受信することにより、パケット#4をアプリケーションプログラム(アプリケーション部13)に送信し、次に、キューの中のパケット#5をアプリケーションプログラムに送信する。パケット#8、#9についても同様である。
FIG. 29 shows a processing example when the jitter in the transmission path from the
このように、ジッターが小さい場合、順序が入れ替わって到着したパケットも順序通り並べ替えて送信することができる。 In this way, when jitter is small, packets that arrive after the order has been changed can be rearranged in order and transmitted.
図30は、サーバ装置2からクライアント装置1への伝送路におけるジッターが大きい場合の処理例を示す。
FIG. 30 shows a processing example when the jitter in the transmission path from the
本例では、パケット#6が大きく遅れてクライアント装置1に到達する。この場合、クライアント装置1において、パケット#5の次に受信したパケット#7はキューに格納されるが、続くパケットを受信する前にタイマーがタイムアウトになり、キューの中のパケット#7が送信される。従って、パケット#7については少し遅延する。
In this example,
パケット#6はパケット#9の次に受信され、パケット#11がその次に受信される。この場合、パケット#9の次に受信したパケット#6についての図27のステップ161の判定はYesになるので、パケット#6はすぐにアプリケーションプログラムに送信される。次に受信するパケット#11については、キューに格納される(ステップ161のNo、ステップ163、165)。タイマータイムアウト前にパケット#10を受信することにより、パケット#10をアプリケーションプログラムに送信し、次に、キューの中のパケット#11をアプリケーションプログラムに送信する。
ジッターが大きい場合、大きい遅延を受けたパケットについての順序入れ替わりは防止できないものの他のパケットまでが大きく遅延することなく処理される。 When the jitter is large, it is impossible to prevent the change of the order of the packet subjected to a large delay, but other packets are processed without a large delay.
ここで、従来技術による複数トンネリング通信での受信処理の一例(ジッター小の場合)を図31に示す。図31に示すように、ジッターが小であっても、従来技術では順序逆転が発生してしまうが、本実施の形態に係る技術では順序逆転を防止できる。これにより、リアルタイムコミュニケーション系などパケットの順序性が問題になるアプリケーションでも、順序逆転を防止することにより、品質低下を抑制できる。 Here, FIG. 31 shows an example of reception processing (in the case of small jitter) in the multiple tunneling communication according to the conventional technique. As shown in FIG. 31, even if the jitter is small, the order inversion occurs in the conventional technique, but the technique according to the present embodiment can prevent the order inversion. Thereby, even in an application where the order of packets is a problem such as a real-time communication system, it is possible to suppress a deterioration in quality by preventing the order reversal.
<実施の形態の効果>
第1、第2の実施の形態で説明した技術によれば、データパケットが送受信されているときに、データパケットに重畳して生存確認用の信号を送受信する構成をとるので、処理負担軽減と異常状態検出時間の短縮という相反する条件を満たした生存確認を行うことができるとともに、サーバ装置側でも通信状態の安定性判定をすることでより短い時間で状態判定が行うことができ、クライアント装置1からサーバ装置2への上り方向の状態判定と同様にサーバ装置2からクライアント装置1への下り方向の状態判定も可能となる。そのため、トンネルのコネクションが切断されてしまった等の異常事態をいち早く検出し、他の正常なトンネル接続に振り分けることでトンネル経由の通信への影響時間を短縮することができる。
<Effect of Embodiment>
According to the techniques described in the first and second embodiments, when a data packet is transmitted / received, a configuration for transmitting and receiving a survival confirmation signal superimposed on the data packet is adopted. It is possible to perform a survival check that satisfies the conflicting condition of shortening the abnormal state detection time, and also to perform the state determination in a shorter time by determining the stability of the communication state on the server device side, and the client device Similarly to the state determination in the up direction from 1 to the
また、一定時間内のパケット順序入れ替り補正により、ほとんどのパケット順序を保ったままで、かつ遅延時間を小さく伝送できるため、VoIPや映像コミュニケーションなどリアルタイム通信でかつパケット順序が通信品質に影響を与える通信プロトコルに対しても安定的に利用可能となる。 In addition, by correcting packet order change within a certain period of time, it is possible to transmit with little delay time while maintaining almost all packet orders. Can be used stably.
以下、本明細書に開示される構成を例示的に列挙する。
(第1項)
サーバ装置との間に構築されたトンネルを介してデータ通信を行うクライアント装置であって、
前記サーバ装置との間で前記トンネルを構築し、当該トンネルを経由してパケットの送受信を行うクライアント側トンネル通信手段と、
前記トンネルを介して生存確認のためのパケット送受信を行うクライアント側生存確認手段と、を備え、
前記クライアント側生存確認手段は、
前記クライアント装置が備えるアプリケーション部からのデータパケット送信がない場合に、第1の時間間隔で生存確認要求を前記サーバ装置に送信し、当該生存確認要求を受信した前記サーバ装置から生存確認要求応答を受信した場合に、生存確認要求応答受領を前記サーバ装置に送信し、
前記アプリケーション部からのデータパケット送信がある場合において、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の第2の時間経過内に、生存確認要求応答受領付きデータパケットを前記サーバ装置に送信し、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の当該第2の時間経過後に、生存確認要求付きデータパケットを前記サーバ装置に送信し、
生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信しないで第3の時間が経過した場合に、前記トンネルの状態が悪化したと判定する
ことを特徴とするクライアント装置。
(第2項)
前記第1の時間は前記第3の時間より長く、当該第3の時間は前記第2の時間より長いことを特徴とする第1項に記載のクライアント装置。
(第3項)
第1項又は2項に記載のクライアント装置と、前記サーバ装置とを備える通信システムであって、
前記サーバ装置は、
前記サーバ装置との間で前記トンネルを構築し、当該トンネルを経由してパケットの送受信を行うサーバ側トンネル通信手段と、
前記トンネルを介して生存確認のためのパケット送受信を行うサーバ側生存確認手段と、を備え、
前記サーバ側生存確認手段は、
前記サーバ装置からのデータパケット送信がない場合において、生存確認要求を前記クライアント装置から受信した場合に、生存確認要求応答を前記クライアント装置に送信し、前記サーバ装置からのデータパケット送信がある場合において、生存確認要求付きデータパケットを前記クライアント装置から受信した場合に、生存確認要求応答付きデータパケットを前記クライアント装置に送信し、
生存確認要求応答又は生存確認要求応答付きデータパケットを前記クライアント装置に送信後、第4の時間経過内に生存確認要求応答受領又は生存確認要求応答受領付きデータパケットを前記クライアント装置から受信しない場合に、前記トンネルの状態が悪化したと判定する
ことを特徴とする通信システム。
(第4項)
第3項に記載の通信システムにおいて、
前記サーバ側トンネル通信手段は、
前記クライアント側トンネル通信手段との間に構築された複数のトンネルに対して順次、送信順を示す送信番号を付したパケットを送信する分配送信手段を備え、
前記クライアント側トンネル通信手段は、
最後に再送信を行った第1のパケットの送信番号と、前記サーバ側トンネル通信手段から受信した第2のパケットの送信番号とを比較し、当該第2のパケットの送信番号が前記第1のパケットの送信番号+1以下である場合に、当該第2のパケットを再送信し、当該第2のパケットの送信番号が前記第1のパケットの送信番号+2以上である場合において、キューの中にパケットが既に存在しない場合に、当該第2のパケットをキューに格納し、所定の時間経過後に、当該第2のパケットを再送信する再送信順序制御手段を備える
ことを特徴とする通信システム。
(第5項)
第4項に記載の通信システムにおいて、
前記サーバ側トンネル通信手段は、前記サーバ側生存確認手段により状態が悪化したと判定されたトンネルを使用しない
ことを特徴とする通信システム。
(第6項)
第3ないし5項のうちいずれか1項に記載の通信システムにおいて、
前記クライアント側トンネル通信手段は、
前記サーバ側トンネル通信手段との間に構築された複数のトンネルに対して順次、送信順を示す送信番号を付したパケットを送信する分配送信手段を備え、
前記サーバ側トンネル通信手段は、
最後に再送信を行った第1のパケットの送信番号と、前記クライアント側トンネル通信手段から受信した第2のパケットの送信番号とを比較し、当該第2のパケットの送信番号が前記第1のパケットの送信番号+1以下である場合に、当該第2のパケットを再送信し、当該第2のパケットの送信番号が前記第1のパケットの送信番号+2以上である場合において、キューの中にパケットが既に存在しない場合に、当該第2のパケットをキューに格納し、所定の時間経過後に、当該第2のパケットを再送信する再送信順序制御手段を備える
ことを特徴とする通信システム。
(第7項)
第6項に記載の通信システムにおいて、
前記クライアント側トンネル通信手段は、前記クライアント側生存確認手段により状態が悪化したと判定されたトンネルを使用しない
ことを特徴とする通信システム。
(第8項)
サーバ装置との間に構築されたトンネルを介してデータ通信を行うクライアント装置と、前記サーバ装置とを備える通信システムにより実行される生存確認方法であって、
前記クライアント装置は、
前記クライアント装置が備えるアプリケーション部からのデータパケット送信がない場合に、第1の時間間隔で生存確認要求を前記サーバ装置に送信し、当該生存確認要求を受信した前記サーバ装置から生存確認要求応答を受信した場合に、生存確認要求応答受領を前記サーバ装置に送信し、
前記アプリケーション部からのデータパケット送信がある場合において、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の第2の時間経過内に、生存確認要求応答受領付きデータパケットを前記サーバ装置に送信し、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の当該第2の時間経過後に、生存確認要求付きデータパケットを前記サーバ装置に送信し、
生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信しないで第3の時間が経過した場合に、前記トンネルの状態が悪化したと判定し、
前記サーバ装置は、
前記サーバ装置からのデータパケット送信がない場合において、生存確認要求を前記クライアント装置から受信した場合に、生存確認要求応答を前記クライアント装置に送信し、前記サーバ装置からのデータパケット送信がある場合において、生存確認要求付きデータパケットを前記クライアント装置から受信した場合に、生存確認要求応答付きデータパケットを前記クライアント装置に送信し、
生存確認要求応答又は生存確認要求応答付きデータパケットを前記クライアント装置に送信後、第4の時間経過内に生存確認要求応答受領又は生存確認要求応答受領付きデータパケットを前記クライアント装置から受信しない場合に、前記トンネルの状態が悪化したと判定する
ことを特徴とする生存確認方法。
(第9項)
コンピュータを、サーバ装置との間に構築されたトンネルを介してデータ通信を行うクライアント装置として機能させるためのプログラムであって、コンピュータを、
前記サーバ装置との間で前記トンネルを構築し、当該トンネルを経由してパケットの送受信を行うクライアント側トンネル通信手段、
前記トンネルを介して生存確認のためのパケット送受信を行うクライアント側生存確認手段、として機能させ、
前記クライアント側生存確認手段は、
前記クライアント装置が備えるアプリケーション部からのデータパケット送信がない場合に、第1の時間間隔で生存確認要求を前記サーバ装置に送信し、当該生存確認要求を受信した前記サーバ装置から生存確認要求応答を受信した場合に、生存確認要求応答受領を前記サーバ装置に送信し、
前記アプリケーション部からのデータパケット送信がある場合において、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の第2の時間経過内に、生存確認要求応答受領付きデータパケットを前記サーバ装置に送信し、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の当該第2の時間経過後に、生存確認要求付きデータパケットを前記サーバ装置に送信し、
生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信しないで第3の時間が経過した場合に、前記トンネルの状態が悪化したと判定する
ことを特徴とするプログラム。
Hereinafter, the configurations disclosed in this specification are listed as examples.
(Section 1)
A client device that performs data communication via a tunnel established with a server device,
Client-side tunnel communication means for constructing the tunnel with the server device and transmitting and receiving packets via the tunnel;
A client side survival confirmation means for performing packet transmission and reception for survival confirmation through the tunnel,
The client side survival confirmation means is:
When there is no data packet transmission from the application unit included in the client device, a survival confirmation request is transmitted to the server device at a first time interval, and a survival confirmation request response is received from the server device that has received the survival confirmation request. If received, send a survival confirmation request response receipt to the server device,
When there is a data packet transmission from the application unit, a data packet with receipt of a survival confirmation request response within a second time after receiving a survival confirmation request response or a data packet with a survival confirmation request response from the server device Is transmitted to the server device, and after the second time has elapsed after receiving a survival confirmation request response or a data packet with a survival confirmation request response from the server device, a data packet with a survival confirmation request is transmitted to the server device. ,
A client device, wherein when the third time has elapsed without receiving a survival confirmation request response or a data packet with a survival confirmation request response from the server device, the client device determines that the state of the tunnel has deteriorated.
(Section 2)
2. The client device according to
(Section 3)
A communication system comprising the client device according to
The server device
Server-side tunnel communication means for constructing the tunnel with the server device and transmitting and receiving packets via the tunnel;
Server side survival confirmation means for performing packet transmission and reception for survival confirmation through the tunnel,
The server side survival confirmation means
When there is no data packet transmission from the server device, when a survival confirmation request is received from the client device, a survival confirmation request response is transmitted to the client device, and when there is a data packet transmission from the server device. When a data packet with a survival confirmation request is received from the client device, a data packet with a survival confirmation request response is transmitted to the client device,
When a survival confirmation request response or a data packet with a survival confirmation request response is transmitted to the client device, and a survival confirmation request response is received or a data packet with a survival confirmation request response is not received from the client device within a fourth time period. And determining that the state of the tunnel has deteriorated.
(Section 4)
In the communication system according to
The server side tunnel communication means includes:
Distributing transmission means for transmitting a packet with a transmission number indicating a transmission order sequentially to a plurality of tunnels established between the client side tunnel communication means,
The client side tunnel communication means includes:
The transmission number of the first packet that was retransmitted last time is compared with the transmission number of the second packet received from the server-side tunnel communication means, and the transmission number of the second packet is When the packet transmission number is equal to or less than +1, the second packet is retransmitted. When the transmission number of the second packet is equal to or greater than the transmission number of the
(Section 5)
In the communication system according to
The server-side tunnel communication means does not use a tunnel determined to have deteriorated by the server-side survival confirmation means.
(Section 6)
In the communication system according to any one of
The client side tunnel communication means includes:
Distributing transmission means for sequentially transmitting a packet with a transmission number indicating a transmission order for a plurality of tunnels established between the server side tunnel communication means,
The server side tunnel communication means includes:
The transmission number of the first packet that was retransmitted last time is compared with the transmission number of the second packet received from the client side tunnel communication means, and the transmission number of the second packet is When the packet transmission number is equal to or less than +1, the second packet is retransmitted. When the transmission number of the second packet is equal to or greater than the transmission number of the
(Section 7)
In the communication system according to
The client-side tunnel communication means does not use a tunnel determined to have deteriorated by the client-side existence confirmation means.
(Section 8)
A survival check method executed by a communication system including a client device that performs data communication via a tunnel established between the server device and the server device,
The client device is
When there is no data packet transmission from the application unit included in the client device, a survival confirmation request is transmitted to the server device at a first time interval, and a survival confirmation request response is received from the server device that has received the survival confirmation request. If received, send a survival confirmation request response receipt to the server device,
When there is a data packet transmission from the application unit, a data packet with receipt of a survival confirmation request response within a second time after receiving a survival confirmation request response or a data packet with a survival confirmation request response from the server device Is transmitted to the server device, and after the second time has elapsed after receiving a survival confirmation request response or a data packet with a survival confirmation request response from the server device, a data packet with a survival confirmation request is transmitted to the server device. ,
When a third time has elapsed without receiving a survival confirmation request response or a data packet with a survival confirmation request response from the server device, it is determined that the state of the tunnel has deteriorated,
The server device
When there is no data packet transmission from the server device, when a survival confirmation request is received from the client device, a survival confirmation request response is transmitted to the client device, and when there is a data packet transmission from the server device. When a data packet with a survival confirmation request is received from the client device, a data packet with a survival confirmation request response is transmitted to the client device,
When a survival confirmation request response or a data packet with a survival confirmation request response is transmitted to the client device, and a survival confirmation request response is received or a data packet with a survival confirmation request response is not received from the client device within a fourth time period. And determining that the state of the tunnel has deteriorated.
(Section 9)
A program for causing a computer to function as a client device that performs data communication via a tunnel established with a server device,
Client-side tunnel communication means for constructing the tunnel with the server device and transmitting and receiving packets via the tunnel,
Function as client side survival confirmation means for sending and receiving packets for survival confirmation through the tunnel,
The client side survival confirmation means is:
When there is no data packet transmission from the application unit included in the client device, a survival confirmation request is transmitted to the server device at a first time interval, and a survival confirmation request response is received from the server device that has received the survival confirmation request. If received, send a survival confirmation request response receipt to the server device,
When there is a data packet transmission from the application unit, a data packet with receipt of a survival confirmation request response within a second time after receiving a survival confirmation request response or a data packet with a survival confirmation request response from the server device Is transmitted to the server device, and after the second time has elapsed after receiving a survival confirmation request response or a data packet with a survival confirmation request response from the server device, a data packet with a survival confirmation request is transmitted to the server device. ,
A program for determining that the state of the tunnel has deteriorated when a third time has elapsed without receiving a survival confirmation request response or a data packet with a survival confirmation request response from the server device.
本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。 The present invention is not limited to the above-described embodiments, and various modifications and applications are possible within the scope of the claims.
1 クライアント装置
11 トンネル機能部
12 生存確認機能部
13 アプリケーション部
2 サーバ装置
21 トンネル機能部
22 生存確認機能部
3 通信相手装置
4 ファイアウォール装置
5 インターネット
6 プライベートネットワーク
121 生存確認用パケット送受信制御部
1C、2C、3C、4C タイマー
122 情報格納部
221 生存確認用パケット送受信制御部
2S、5S タイマー
222 情報格納部
101 分配部
102 カウンター
103 トンネル接続リスト格納部
201 集約受信部
202 最終送信番号格納部
203 タイマー
DESCRIPTION OF
Claims (3)
第1の時間経過内に前記クライアント装置が備えるアプリケーション部からのデータパケット送信がない場合に、生存確認要求を前記サーバ装置に送信し、
第1の時間経過内に前記アプリケーション部からのデータパケット送信がある場合に、生存確認要求付きデータパケットを前記サーバ装置に送信する、
ことを特徴とするクライアント装置。 The client device used in a communication system including a server device and a client device that performs data communication with the server device,
When there is no data packet transmission from the application unit included in the client device within the first time period, a survival confirmation request is transmitted to the server device,
When there is a data packet transmission from the application unit within the first time, a data packet with a survival confirmation request is transmitted to the server device.
A client device.
前記クライアント装置が備えるアプリケーション部からのデータパケット送信がない場合に、第1の時間間隔で生存確認要求を前記サーバ装置に送信し、
前記アプリケーション部からのデータパケット送信がある場合において、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の第2の時間経過内に、生存確認要求応答受領をデータパケットのヘッダに含めて前記サーバ装置に送信し、
生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の当該第2の時間経過後に、生存確認要求をデータパケットのヘッダに含めて前記サーバ装置に送信する、
ことを特徴とするクライアント装置。 The client device used in the communication system according to claim 1,
When there is no data packet transmission from the application unit provided in the client device, a survival confirmation request is transmitted to the server device at a first time interval,
When there is a data packet transmission from the application unit, the existence confirmation request response is received within a second time after the existence confirmation request response or the existence confirmation request response-attached data packet is received from the server device. And send it to the server device,
A survival confirmation request is included in the header of the data packet and transmitted to the server device after the second time has elapsed after receiving the survival confirmation request response or the data packet with a survival confirmation request response from the server device.
A client device.
前記サーバ装置からのデータパケット送信がない場合において、生存確認要求を前記クライアント装置から受信した場合に、生存確認要求応答を前記クライアント装置に送信し、前記サーバ装置からのデータパケット送信がある場合において、生存確認要求付きデータパケットを前記クライアント装置から受信した場合に、生存確認要求応答をデータパケットのヘッダに含めて前記クライアント装置に送信する、
ことを特徴とするサーバ装置。 The server device used in the communication system according to claim 1 or 2,
When there is no data packet transmission from the server device, when a survival confirmation request is received from the client device, a survival confirmation request response is transmitted to the client device, and when there is a data packet transmission from the server device. When a data packet with a survival confirmation request is received from the client device, a survival confirmation request response is included in the header of the data packet and transmitted to the client device.
The server apparatus characterized by the above-mentioned.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2014156741A JP5813835B2 (en) | 2014-07-31 | 2014-07-31 | Client device and communication system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2014156741A JP5813835B2 (en) | 2014-07-31 | 2014-07-31 | Client device and communication system |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2011080178A Division JP5592301B2 (en) | 2011-03-31 | 2011-03-31 | Client device, communication system, survival confirmation method, and program |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2014209796A true JP2014209796A (en) | 2014-11-06 |
JP5813835B2 JP5813835B2 (en) | 2015-11-17 |
Family
ID=51903687
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2014156741A Active JP5813835B2 (en) | 2014-07-31 | 2014-07-31 | Client device and communication system |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP5813835B2 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2016144057A (en) * | 2015-02-03 | 2016-08-08 | コニカミノルタ株式会社 | Communication system, control device, communication method, and computer program |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006524453A (en) * | 2003-04-23 | 2006-10-26 | コバロ ネットワークス インク. | Built-in management channel for SONET path terminator connectivity |
JP2007213129A (en) * | 2006-02-07 | 2007-08-23 | Iwatsu Electric Co Ltd | PPPoE COMMUNICATION SYSTEM |
JP2010109733A (en) * | 2008-10-30 | 2010-05-13 | Iwatsu Electric Co Ltd | Packet communication method |
-
2014
- 2014-07-31 JP JP2014156741A patent/JP5813835B2/en active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006524453A (en) * | 2003-04-23 | 2006-10-26 | コバロ ネットワークス インク. | Built-in management channel for SONET path terminator connectivity |
JP2007213129A (en) * | 2006-02-07 | 2007-08-23 | Iwatsu Electric Co Ltd | PPPoE COMMUNICATION SYSTEM |
JP2010109733A (en) * | 2008-10-30 | 2010-05-13 | Iwatsu Electric Co Ltd | Packet communication method |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2016144057A (en) * | 2015-02-03 | 2016-08-08 | コニカミノルタ株式会社 | Communication system, control device, communication method, and computer program |
Also Published As
Publication number | Publication date |
---|---|
JP5813835B2 (en) | 2015-11-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6319608B2 (en) | Transmission control method, apparatus and system | |
JP5816718B2 (en) | Communication apparatus, communication system, and data communication relay method | |
US9531846B2 (en) | Reducing buffer usage for TCP proxy session based on delayed acknowledgement | |
JP5020076B2 (en) | High performance TCP suitable for low frequency ACK system | |
US8750109B2 (en) | Inferring TCP initial congestion window | |
US8072898B2 (en) | Method for managing a transmission of data streams on a transport channel of a tunnel, corresponding tunnel end-point and computer-readable storage medium | |
US7693058B2 (en) | Method for enhancing transmission quality of streaming media | |
EP2930899B1 (en) | Tcp link configuration method and apparatus | |
JP5867188B2 (en) | Information processing apparatus, congestion control method, and congestion control program | |
WO2014194616A1 (en) | Systems and methods for data transmission | |
JP2007527170A (en) | System and method for parallel communication | |
US9917871B2 (en) | Optimizing media bitrate with explicit network feedback on one client only | |
WO2013108676A1 (en) | Multiple gateway device, multiple line communication system, multiple line communication method and program | |
WO2022017529A1 (en) | Data transmission method and system, electronic device, and storage medium | |
CN111147573A (en) | Data transmission method and device | |
JP5592301B2 (en) | Client device, communication system, survival confirmation method, and program | |
JP7067544B2 (en) | Communication systems, communication devices, methods and programs | |
CN108462612B (en) | Method, device, electronic equipment and storage medium for adjusting RTP media stream transmission | |
JP5813835B2 (en) | Client device and communication system | |
US9130843B2 (en) | Method and apparatus for improving HTTP adaptive streaming performance using TCP modifications at content source | |
US9544249B2 (en) | Apparatus and method for aligning order of received packets | |
CN115632748A (en) | Data processing method and device, electronic equipment and storage medium | |
JP6200870B2 (en) | Data transfer control device, method and program | |
Psaras et al. | On the properties of an adaptive TCP Minimum RTO | |
US20140369189A1 (en) | Method of controlling packet transmission in network system and network system transmitting packet using pseudo-tcp agent |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20150408 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20150414 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20150615 |
|
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: 20150901 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20150916 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 5813835 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |