JPWO2008105032A1 - クライアント装置と複数のサーバ装置からなるシステムの通信方法、その通信プログラム、クライアント装置及びサーバ装置 - Google Patents

クライアント装置と複数のサーバ装置からなるシステムの通信方法、その通信プログラム、クライアント装置及びサーバ装置 Download PDF

Info

Publication number
JPWO2008105032A1
JPWO2008105032A1 JP2009501034A JP2009501034A JPWO2008105032A1 JP WO2008105032 A1 JPWO2008105032 A1 JP WO2008105032A1 JP 2009501034 A JP2009501034 A JP 2009501034A JP 2009501034 A JP2009501034 A JP 2009501034A JP WO2008105032 A1 JPWO2008105032 A1 JP WO2008105032A1
Authority
JP
Japan
Prior art keywords
packet
sequence number
server
ack
udp packet
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
Application number
JP2009501034A
Other languages
English (en)
Other versions
JP4851585B2 (ja
Inventor
松本　剛
松本　　剛
毅 山崎
毅 山崎
眞子 河口
眞子 河口
修一 北口
修一 北口
雄介 島田
雄介 島田
耕太郎 岡崎
耕太郎 岡崎
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
Publication of JPWO2008105032A1 publication Critical patent/JPWO2008105032A1/ja
Application granted granted Critical
Publication of JP4851585B2 publication Critical patent/JP4851585B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1868—Measures taken after transmission, e.g. acknowledgments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/143—Termination or inactivation of sessions, e.g. event-controlled end of session
    • H04L67/145—Termination or inactivation of sessions, e.g. event-controlled end of session avoiding end of session, e.g. keep-alive, heartbeats, resumption message or wake-up for inactive or interrupted session
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/164—Adaptation or special uses of UDP protocol
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Communication Control (AREA)
  • Maintenance And Management Of Digital Transmission (AREA)
  • Hardware Redundancy (AREA)

Abstract

本発明の課題は、障害が発生して待機系の装置に切り換えるときに、クライアント装置と待機系のサーバ装置のアプリケーションプログラム間の通信の継続性を確保することである。クライアント装置の通信処理部は、ＵＤＰパケットを複数のサーバ装置にマルチキャストして、複数のサーバ装置との間で同時にコネクションを確立する。コネクションを確立した後、アプリケーションのデータを複数のサーバ装置にマルチキャストする。障害発生時には、待機系のサーバ装置が、クライアント装置からマルチキャストされたデータパケットを受信してアプリケーション間通信を継続する。

Description

本発明は、クライアント装置と複数のサーバ装置とからなるシステムの通信方法、その通信プログラム、そのシステムに用いられるクライアント装置及びサーバ装置に関する。
基幹システムにおけるアプリケーション間通信は、高い信頼性が要求されるため再送制御機能等を有するＴＣＰ（Transmission Control Protocol）が用いられている。また、装置に障害が発生した場合にも処理が継続できるように現用系の装置と待機系の装置が設けられている。
上記のシステムでは、障害発生時に現用装置のＴＣＰコネクション情報（ＩＰアドレス、ポート番号、シーケンス番号）と転送されるデータを待機装置に引き継ぐ必要があるが、この引き継ぎが以下の理由から困難であった。
（１）ＩＰアドレス、ポート番号については２台の装置間で共通のＩＰアドレス、ポート番号を用いることで引き継ぎが可能となるが、シーケンス番号並びに転送データについては、通信中に随時流れるパケットの中で変化していくために確実な引き継ぎが困難である。
（２）ＴＣＰコネクションは、送信者と受信者が１対１のポイントツーポイント接続であり、同時に複数の装置間で同一のＴＣＰコネクション情報を用いてコネクションの確立を行うことはＴＣＰ上で許されない。
（３）上記の問題を解決する方法として、受信者がパケットの送受信の都度、そのシーケンス番号、データも含めて待機装置に情報を送信し、その後受信データの上位アプリケーションへの通知・送信データの相手装置への送信を行うことで理論的には可能である。しかし、この方法はＴＣＰの転送性能が著しく劣化することと、ＴＣＰの実装レイヤがＯＳ（カーネル）であるため、このような実装を行うことが難しい。
従って、現状では、現用装置の障害が発生した時点で待機装置に切り換えた後、クライアントと待機装置との間で再度ＴＣＰコネクションを確立し、アプリケーション間でのデータの到達の確認を行った後、業務を再開する必要がある。そのため業務の中断時間が長くなるという問題点があった。
ＵＤＰ（User Datagram Protocol）のマルチキャスト通信機能を用いることで同一データを同時に複数の装置に送信することは可能であるが、ＵＤＰには送達確認・再送制御等の信頼性機能が無いため、基幹システムのアプリケーション間通信には使用することができなかった。
他の方法として、アプリケーション自身が独自にコネクション制御機能を実装し、かつ複数の通信相手装置とのコネクションを管理することで、障害発生時に待機装置に切り換えたときの業務の継続性を確保することが考えられる。
しかしながら、この方法はアプリケーション毎にコネクション制御機能と複数の通信相手装置とのコネクションを管理する機能を有する必要があり、アプリケーション側の処理を大幅に変更する必要がある。
特許文献１には、アプリケーションに、単一の応答パケットで複数のデータパケットに対する確認応答情報を送信する機能を設けることで、確認応答パケットの送信に使用される帯域を削減することが記載されている。
特許文献１には、マルチキャスト通信においてデータパケットの送達確認を行うことについては記載されていない。
特許文献２には、マルチキャスト通信において、サーバがパケット毎に代表クライアントを指定する代表識別情報を付加してパケットを送信し、代表識別情報を有するパケットを受信したクライアントのみが応答パケットを送信することで、応答パケット数を減らすことが記載されている。
特許文献２には、マルチキャスト通信において、ＴＣＰと同等な信頼性を確保することについては記載されていない。
特開２００４−８００７０号公報 特開２００４−１２０１３７号公報
本発明の課題は、障害発生時に待機系の装置に切り換えるときに、クライアント装置と現用系に切り換えたサーバ装置のアプリケーションプログラム間の通信の継続性を確保することである。
本発明は、クライアント装置と複数のサーバ装置とかなるシステムの通信方法であって、シーケンス番号を付加したＵＤＰパケットをマルチキャストで複数のサーバ装置に送信してクライアント装置と前記複数のサーバ装置との間で同時にコネクションを確立し、コネクションを確立した後、アプリケーションプログラムのデータを含むＵＤＰパケットに後続のシーケンス番号を付加してマルチキャストで前記複数のサーバ装置に送信し、送信済のＵＤＰパケットのシーケンス番号を記憶手段に記憶し、送信した前記ＵＤＰパケットに対するＡＣＫパケットが前記複数のサーバ装置の内の少なくとも１つ以上から返送されたとき、前記ＡＣＫパケットに付加されているシーケンス番号と、前記記憶手段に記憶されている送信済の前記ＵＤＰパケットのシーケンス番号を比較してＵＤＰパケットの送達を確認する。
上記のコネクションの確立とは、最初のシーケンス番号を付加してＵＤＰパケットをマルチキャストされたことに対して複数のサーバ装置の内の１つ以上からＡＣＫパケットがクライアント装置に返信されたことを言う。
この発明によれば、ＵＤＰパケットを用いて高速で、かつ信頼性の高いアプリケーション間通信を実現できる。また、クライアント装置と複数のサーバ装置との間で同時にコネクションを確立してデータ送信することができるので、クライアント装置と通信中のサーバ装置に障害が発生し、他のサーバ装置に切り換えた場合でも、クライアント装置とそのサーバ装置のアプリケーションプログラム間の通信を継続することができる。
上記の発明の通信方法において、前記複数のサーバ装置がそれぞれ受信済のＵＤＰパケットのシーケンス番号を記憶し、新たに受信したＵＤＰパケットのシーケンス番号と、記憶してある受信済の前記ＵＤＰパケットのシーケンス番号を比較してパケットの送達を確認し、前記ＵＤＰパケットの送達を確認したとき、各サーバ装置が受信した前記ＵＤＰパケットのシーケンス番号をＡＣＫ番号として付加した前記ＡＣＫパケットを前記クライアント装置に返送する。
このように構成することで、クライアント装置側で、送信したＵＤＰパケットが各サーバ装置に送達されたか否かを確認することができる。
上記の発明の通信方法において、前記複数のサーバ装置は現用系と待機系のサーバ装置からなり、現用系の前記サーバ装置の障害が検出され、待機系の前記サーバが現用系に切り換えられたとき、現用系に切り換えられた前記サーバ装置を含む前記複数のサーバ装置に前記ＵＤＰパケットをマルチキャストして、前記クライアント装置のアプリケーションプログラムと現用系となった前記サーバ装置のアプリケーションプログラムとの間の通信を継続させる。
このように構成することで、現用系のサーバ装置に障害が発生して待機系のサーバ装置に切り換えたときに、クライアント装置のアプリケーションプログラムと現用系に切り換えたサーバ装置のアプリケーションプログラムとの間の通信の継続性を確保できる。従って、障害が発生して待機系の装置に切り換えたときにアプリケーションプログラムの処理が中断するのを回避できる。
上記の発明の通信方法において、前記ＵＤＰパケットは、データ部にデータパケットか、ＡＣＫパケットか、ＮＡＣＫパケットかのパケットの種別を示すＦＬＡＧ情報と、連番で設定されるシーケンス番号と、ＡＣＫ番号とが付加されて送信される。
このように構成することで、ＵＤＰパケットを用いてパケットの送達確認を簡単に実現できる。
上記の発明の通信方法において、未送達のＵＤＰパケットのシーケンス番号を付加したＮＡＣＫパケットを前記クライアント装置に送信して、未送達の前記ＵＤＰパケットの再送を要求する。
このように構成することで、ＮＡＣＫパケットに付加されているシーケンス番号により未送達のパケットを特定できるので、そのパケットを再送することができる。
上記の発明の通信方法において、前記ＵＤＰパケットのデータ部に、前記ＵＤＰパケットを受信したときに、アプリケーションプログラムからの指示に基づいてネットワークレイヤが前記ＡＣＫパケットを返送するアプリケーションモードと、前記ＵＤＰパケットを受信したとき、前記ネットワークレイヤの判断で前記ＡＣＫパケットを返送するネットワークモードの何れであるかを指定する情報を付加する。
このように構成することで、アプリケーションプログラムがデータを確認した後、ＡＣＫを返送する必要がある場合には、アプリケーションプログラムからの指示に基づいてネットレイヤからクライアント装置にＡＣＫパケットを返送することができる。これによりネットワーク上を流れるＡＣＫパケットの数を減らすことができる。
本発明の他の態様は、クライアント装置と複数のサーバ装置とからなるシステムに用いられるクライアント装置であって、シーケンス番号を付加したＵＤＰパケットを前記複数のサーバ装置にマルチキャストで送信して前記複数のサーバ装置との間で同時にコネクションを確立するコネクション確立手段と、アプリケーションプログラムのデータを含むＵＤＰパケットに後続のシーケンス番号を付加して前記複数のサーバ装置にマルチキャストで送信する送信手段と、送信した前記ＵＤＰパケットに対するＡＣＫパケットが前記複数のサーバ装置の内の少なくとも１つ以上から返送されたとき、前記ＡＣＫパケットに付加されているシーケンス番号と、前記記憶手段に記憶されている送信済の前記ＵＤＰパケットのシーケンス番号を比較してパケットの送達を確認する確認手段とを備える。
この発明によれば、ＵＤＰパケットを用いて高速で、かつ信頼性の高いアプリケーション間の通信を実現できる。また、クライアント装置と複数のサーバ装置との間で同時にコネクションを確立してデータを送信することができるので、クライアント装置と通信中のサーバ装置に障害が発生し、他のサーバ装置に切り換えた場合でも、クライアント装置とそのサーバ装置のアプリケーションプログラム間の通信を継続することができる。
上記の発明のクライアント装置において、前記複数のサーバ装置は現用系と待機系のサーバ装置からなり、前記送信手段は、現用系の前記サーバ装置の障害が検出され、待機系の前記サーバ装置が現用系に切り換えられたとき、現用系に切り換えられた前記サーバ装置を含む前記複数のサーバ装置に前記ＵＤＰパケットをマルチキャストして、前記クライアント装置の前記アプリケーションプログラムと現用系に切り換えられた前記サーバ装置のアプリケーションプログラムとの間の通信を継続させる。
このように構成することで、障害が発生して待機系のサーバ装置を現用系に切り換えたときに、クライアント装置のアプリケーションプログラムと現用系に切り換えられたサーバ装置のアプリケーションプログラム間の通信の継続性を確保できる。
本発明の他の態様は、クライアント装置と複数のサーバ装置とからなるシステムに用いられるサーバ装置であって、前記クライアント装置からマルチキャストで送信され、シーケンス番号が付加されたＵＤＰパケットを受信したとき、ＡＣＫを返信して前記クライアント装置との間でコネクションを確立するコネクション確立手段と、受信済のＵＤＰパケットのシーケンス番号を記憶する記憶手段と、新たに受信したＵＤＰパケットのシーケンス番号と、前記記憶手段に記憶されている受信済の前記ＵＤＰパケットのシーケンス番号を比較してパケットの送達を確認する確認手段と、前記ＵＤＰパケットの送達を確認したとき、受信した前記ＵＤＰパケットのシーケンス番号を付加したＡＣＫパケットを前記クライアント装置に送信するＡＣＫ送信手段とを備える。
この発明によれば、ＵＤＰパケットを用いて高速で、かつ信頼性の高いアプリケーション間の通信を実現できる。また、クライアント装置と複数のサーバ装置との間で同時にコネクションを確立してデータを送信することができるので、クライアント装置と通信中のサーバ装置に障害が発生し、他のサーバ装置に切り換えた場合でも、クライアント装置とそのサーバ装置のアプリケーションプログラム間の通信を継続することができる。
実施の形態のシステム構成図である。 実施の形態の通信処理部が実装されるレイヤを示す図である。 実施の形態のＵＤＰパケットのフォーマットを示す図である。 動作モードの説明図である。 サーバ装置の通信処理部の受信処理のフローチャートである。 シーケンス番号チェック処理のフローチャートである。 ＡＣＴＩＶＥ装置とＳＴＡＮＤＢＹ装置の制御表を示す図である。 サーバ装置のＡＣＫ返信処理のフローチャートである。 クライアント装置の送信処理のフローチャートである。 クライアント装置の制御表と受信者リストを示す図である。 クライアント装置のＡＣＫ受信処理（１）のフローチャートである。 クライアント装置のＡＣＫ受信処理（２）のフローチャートである。 クライアント装置の再送処理のフローチャートである。 再送タイマの説明図である。 タイムアウト時の通信処理部と状態管理部の動作説明図である。 クライアントとサーバ装置の通信シーケンス（１）を示す図である クライアントとサーバ装置の通信シーケンス（２）を示す図である。 ＡＰＩ関数の説明図である。 ＡＰＩ関数を用いた通信シーケンスを示す図である。 障害発生時の動作説明図である。 アプリケーション・セーフモードの送達確認方法の説明図である。 アプリケーション・クイックモードの送達確認方法の説明図である。 ネットワーク・セーフモードの送達確認方法の説明図である。 ネットワーク・クイックモードの送達確認方法の説明図である。
以下、本発明の実施の形態について図面を参照して説明する。図１は、実施の形態のクライアント装置と複数のサーバ装置からなる基幹系のシステムのシステム構成図である。
このシステムは、クライアント装置（または中継装置）１１と現用系（ＡＣＴＩＶＥ）のサーバ装置１２と、待機系（ＳＴＡＮＤBＹ）の複数のサーバ装置１３、１４と、状態管理装置１５とからなる。
状態管理装置１５は、サーバ装置１２〜１４の状態を監視して、現用系のサーバ装置１２に障害が発生したとき、待機系のサーバ装置１３または１４に切り換える制御等を行う。また、状態管理装置１５は、クライアント装置１１の状態管理部２１に対して、サーバ装置の異常を通知する機能も持っている。
各サーバ装置１２、１３、１４の状態管理部２２、２３、２４は、状態管理装置１５と同様の機能を有しており、複数のサーバ装置の中の１台をＡＣＴＩＶＥ装置、他の装置をＳＴＡＮＤＢＹ装置として管理し、各装置のハードウェア、ソフトウェアの状態を監視する。そして、ＡＣＴＩＶＥ装置の障害を検出すると、ＳＴＡＮＤＢＹ装置に切り換える機能を有する。
クライアント装置１１の状態管理部２１は、通信処理部３１がサーバ装置１２〜１４との通信異常を検出した場合に、状態管理装置１５と連携して、サーバ装置の故障の診断を行う。診断の結果、特定のサーバ装置が故障と判断した場合には、通信処理部３１で管理しているサーバの監視対象リストから故障となったサーバ装置をはずすことを行う。
図１の矢印ａは、各サーバ装置１２〜１４の状態管理部２２〜２４が互いに他のサーバ装置のハードウェア及びソフトウェアの状態を監視し、障害の発生を検出する動作を示している。
クライアント装置１１の通信処理部３１は、ＵＤＰ（User Datagram Protocol）に基づいてシーケンス番号として初期値（例えば、「１」）を設定したＵＤＰパケットを複数のサーバ装置１２〜１４にマルチキャストで送信して、複数のサーバ装置１２〜１４との間で同時にコネクションを確立する機能（コネクション確立手段に対応する）を有する。
通信処理部３１は、アプリケーションプログラムからの送信要求に基づいてデータパケットを現用系及び待機系のサーバ装置１２〜１４にマルチキャスト通信で送信する機能（送信手段に対応する）を有する。
また、通信処理部３１は、マルチキャスト送信したＵＤＰパケットに対する各サーバ装置１２〜１４の確認応答ＡＣＫ（Acknowledgment）を受信したか否かにより、ＵＤＰパケットの送達の確認する機能（確認手段に対応する）を有する。通信処理部３１は、ＵＤＰパケットをマルチキャストで送信するときに、パケットの到着順序を保証するために、連番のシーケンス番号をデータ部にヘッダとして付加する。
通信処理部３１は、現用系と待機系の全てのサーバ装置１２〜１４から、最初に送信したＵＤＰパケット（シーケンス番号として初期値「１」が設定されたパケット）に対するＡＣＫパケットを受信したことを確認した後、アプリケーションプログラム（以下、アプリケーションと呼ぶ）に対してコネクションの確立を通知する。
図１の矢印ｂは、例えば、コネクション確立時にクライアント装置１１から複数のサーバ装置１２〜１４にマルチキャスト送信されるＵＤＰパケットの流れを示している。
クライアント装置１１の通信処理部３１は、各サーバ装置１２〜１４からのパケットの未送達を知らせる否定応答パケットＮＡＣＫ（Negative Acknowledgment）を受信したとき、未送達のパケットを再送する機能を有する。
サーバ装置１２〜１４の通信処理部３２〜３４は、クライアント装置１１から、例えば、シーケンス番号１のＵＤＰパケットを受信すると、ＡＣＫパケットをクライアント装置１１にユニキャストで送信し、さらにそのＵＤＰパケットをアプリケーションに渡してコネクションを確立する機能を有する（サーバ装置のコネクション確立手段に対応する）。アプリケーションは、例えば、パケットのデータ部のシーケンス番号が「１」であることからコネクション確立用のパケットであることを認識できる。
また、サーバ装置１２〜１４の各通信処理部３２〜３４は、受信済のＵＤＰパケットのシーケンス番号をメモリ等の記憶手段に記憶する機能と、新たに受信したＵＤＰパケットのシーケンス番号と、メモリ等に記憶してある受信済のＵＤＰパケットのシーケンス番号を比較してパケットの抜けがないか否かを確認する機能（確認手段に対応する）を有する。さらに、受信したＵＤＰパケットのシーケンス番号が、受信済のＵＤＰパケットのシーケンス番号と連番になっていない場合には、パケットが未送達と判断し、未送達パケットのシーケンス番号を付加したＮＡＣＫパケットをユニキャストでクライアント装置１１に送信してパケットの再送を要求する機能（ＮＡＣＫ送信手段に対応する）を有する。
図１の矢印ｃは、各サーバ装置１２〜１４からクライアント装置１１に送信されるＡＣＫパケットの流れを示している。
図２は、実施の形態のクライアント装置１１及びサーバ装置１２〜１４のレイヤの構成を示す図である。アプリケーションレイヤの下位層のネットワークレイヤには、ＴＣＰ、ＵＤＰのプロトコルが実装されており、実施の形態の通信機能（通信処理部）は、このＵＤＰベースにしたプログラムとして実装される。
次に、図３は、実施の形態の通信方法で使用されるＵＤＰパケットのフォーマットを示す図である。
実施の形態のＵＤＰパケットは、図２に示すように通常のＵＤＰパケットのデータ部に、ＦＬＡＧ、ＳＥＱ、ＡＣＫ、ＭＯＤＥ、ＳＴＡＴＵＳがヘッダとして付加されている。
ＦＬＡＧには、そのパケットがデータパケット、ＮＡＣＫ、ＡＣＫの何れであるかを示すパケット種別が格納される。ＦＬＡＧには、例えば、データパケットのとき「１」が、ＮＡＣＫパケットのとき「２」が、ＡＣＫパケットのとき「３」が格納される。
ＳＥＱは、連番のシーケンス番号が格納される。なお、同一のセッションであっても、動作モードが異なると（例えば、セーフモードとクイックモード）、ＳＥＱには異なるシーケンス番号が設定される。
ＡＣＫには、ＡＣＫ番号が格納される。ＡＣＫ番号は、ＡＣＫまたはＮＡＣＫパケットがどのシーケンス番号のパケットに対する応答パケットであるかを示すための情報であり、対象となるパケットのシーケンス番号が格納される。また、データパケットのＡＣＫ番号は、パケットの送信元からの受信済みシーケンス番号が格納される。
ＭＯＤＥには、パケットの送信元がどの動作モードで応答を待っているかを示すモード情報が格納される。本実施の形態では、動作モードとして、ノーウェイト（no-wait）モード、ネットワーク・クイック（network-quick）モード、ネットワーク・セーフ（network-safe）モード、アプリケーション・クイック（application-quick）モード、アプリケーション・セーフ（application-safe）モードの５種類のモードが設けられており、それらのモードの内の１つを指定する情報がＭＯＤＥに格納される。ＭＯＤＥには、例えば、ノーウェイト・モードのとき「１」、ネットワーク・クイックモードのとき「２」、ネットワーク・セーフモードのとき「３」、アプリケーション・クイックモードのとき「４」、アプリケーション・セーフモードのとき「５」が格納される。
ＳＴＡＴＵＳには、応答パケットの送信元のサーバ装置のステータスが格納される。例えば、サーバ装置１２が現用系であれば、サーバ装置１２からの応答パケットにはＳＴＡＴＵＳとして「ＡＣＴＩＶＥ」が格納され、待機系のサーバ装置１３からの応答パケットには、ＳＴＡＴＵＳとして「ＳＴＡＮＤＢＹ」が格納される。クライアント装置１１側では、このＳＴＡＴＵＳを参照することで、送信元のサーバ装置がＡＣＴＩＶＥか、ＳＴＡＮＤＢＹかを知ることができる。パケットの残りのデータ部には、アプリケーションのデータが格納される。
図４は、上記の５種類のモードの説明図である。ノーウェイト（no-wait）モードは、パケットをマルチキャスト送信したときに、応答送信者からのＡＣＫ返信を待たないモードである。
ネットワーク・セーフ（network-safe）モードは、ネットワークレイヤがＡＣＫの返送レイヤで、かつ全てのサーバ装置からのＡＣＫ返信を待つモードである。ネットワーク・クイック（network-quick）モードは、ネットワークレイヤが返送レイヤで、かつ特定の応答送信者からのＡＣＫ返信のみを待つモードである。
アプリケーション・セーフ（application-safe）モードは、アプリケーションレイヤが返送レイヤで、かつ全ての応答送信者からのＡＣＫ返信を待つモードである。アプリケーション・クイック（application-quick）モードは、アプリケーションレイヤが返送レイヤで、かつ特定の応答送信者からのＡＣＫ返信のみを待つモードである。
動作モードをネットワーク・セーフまたはクイックに設定し、返送レイヤをネットワークレイヤにした場合には、ＯＳに近いレイヤで素早くＡＣＫを返送することができる。本実施の形態で、アプリケーションレイヤを返送レイヤにするモードを設けたのは、受信側のアプリケーションが送信側のアプリケーションからのデータが正常であることを確認した後、ＡＣＫを返す場合があるからである。この場合、アプリケーションモードに設定されれば、受信側のアプリケーションからＡＣＫの送信の指示があった段階でＡＣＫが送信されるので、ネットワーク上を流れるＡＣＫパケットの数を減らすことができる。
次に、実施の形態のクライアント・サーバシステムにおいて、サーバ装置１２〜１４の受信処理について、図５及び図６のフローチャートを参照して説明する。
図５は、サーバ装置１２〜１４の通信処理部３２〜３４における受信処理のフローチャートである。
この処理の前提としてクライアント装置１１から複数のサーバ装置１２〜１４に対して、シーケンス番号として初期値が設定されたＵＤＰパケットがマルチキャストで送信され、クライアント装置１１と複数のサーバ装置１２〜１４間でコネクションが確立されているものとする。
各サーバ装置１２〜１４の通信処理部３２〜３４は、ＯＳ（Operating System）に対して受信待ちデータがあるかを確認し（図５，Ｓ１１）、受信待ちデータがあるか否かを判定する（Ｓ１２）。
受信待ちデータが存在するときには（Ｓ１２、ＹＥＳ）、ステップＳ１３に進み、ＯＳからパケットを受信する。そして、ステップＳ１４のシーケンス番号チェック処理を実行する。このシーケンス番号チェック処理では、受信したＵＤＰパケットのヘッダに格納されているシーケンス番号と、制御表４１に格納されている受信済パケットのシーケンス番号が連番になっているかを調べ、パケットの欠落があるか否かを判断する。
図６は、図５のステップＳ１４のシーケンス番号チェック処理の詳細なフローチャートである。
受信パケットのヘッダにあるシーケンス番号Ａと、制御表４１に格納されている受信済パケットのシーケンス番号Ｂを比較する（図６、Ｓ２１）。
ここで、制御表４１について簡単に説明する。現用系のサーバ装置（ＡＣＴＩＶＥ装置）と待機系のサーバ装置（ＳＴＡＮＤＢＹ装置）は、コネクションが確立された段階でそれぞれ図７（Ａ）、（Ｂ）に示すような制御表４１ａ、４１ｂを作成する。
制御表４１ａ、４１ｂは、マルチキャストＩＰアドレスと、サーバ装置で使用するポート番号と、受信したパケットの動作モード（アプリケーション・セーフモードなど）と、クイックモード（ネットワーク・クイックモードまたはアプリケーション・クイックモード）時の受信済シーケンス番号と、セーフモード（ネットワーク・セーフモードまたはアプリケーション・セーフモード）時の受信済シーケンス番号と、自装置がＡＣＴＩＶＥ、ＳＴＡＮＤＢＹの何れであるかを示す状態情報と、クライアント装置１１のＩＰアドレスと、クライアント装置１１のポート番号で構成されている。この制御表（テーブル）４１ａ、４１ｂは、サーバ装置のメモリ等に記憶される。
本実施の形態においては、クイックモード時のシーケンス番号とセーフモード時のシーケンス番号を別々に管理し、同一マルチキャストＩＰアドレス及びポートに対する通信に対してパケット毎にモードを切り換えられるようになっている。そのため上記の制御表４１ａ、４１ｂには、クイックモード時のシーケンス番号と、セーフモード時のシーケンス番号が別々に記憶されている。
また、シーケンス番号がクライアント単位で一意に設定されているので、同一のマルチキャストＩＰアドレスでサーバ装置の同一のポート番号に対してパケットの送信者が複数存在する場合を考慮して、サーバ装置側の制御表４１ａ、４１ｂには、クライアント装置１１のＩＰアドレスとクライアント装置１１のポート番号を記憶するようにしている。
図６に戻り、ステップＳ２２において、パケットのヘッダに格納されているＭＯＤＥがｎｏ−ｗａｉｔか否かを判別する。ｎｏ−ｗａｉｔの場合には、ＡＣＫを返信する必要が無いのでそこで処理を終了する。
ＭＯＤＥがｎｏ−ｗａｉｔでないときには（Ｓ２２，ＮＯ）、ステップＳ２３に進み、受信パケットのシーケンス番号Ａが、制御表４１に格納されている該当するモードのシーケンス番号Ｂに「１」を加算した値と等しいか否かを判定する。受信パケットのシーケンス番号Ａが、制御表４１に格納されているシーケンス番号Ｂに「１」を加算した値と等しいとき、つまり、シーケンス番号が連続しているときには（Ｓ２３，ＹＥＳ）、パケットの抜けがないものと判断してそこで処理を終了する。
受信パケットのシーケンス番号Ａが制御表４１に格納されているシーケンス番号Ｂと連番でないときには（Ｓ２３、ＮＯ）、次のステップＳ２４に進み、受信パケットのシーケンス番号Ａが制御表４１のシーケンス番号Ｂと等しいか、それより小さいかを判別する。
受信パケットのシーケンス番号Ａが、制御表４１のシーケンス番号Ｂと等しいか、それより小さいときには（Ｓ２４，ＹＥＳ）、ステップＳ２８に進み、受信したパケットを破棄する。
ステップＳ２４において、受信パケットのシーケンス番号Ａが、制御表４１のシーケンス番号Ｂと一致せず、かつシーケンス番号Ｂより大きいと判定されたときには（Ｓ２４、ＮＯ）、ステップＳ２５に進み、自装置がＳＴＡＮＤＢＹ装置か否かを判別する。
自装置がＳＴＡＮＤＢＹ装置ではない場合（Ｓ２５，ＮＯ）、またはＳＴＡＮＤＢＹ装置で（Ｓ２５、ＹＥＳ）、かつステップＳ２６において、受信パケットに設定されている動作モードがセーフ（ｓａｆｅ)モードと判定されたときには（Ｓ２６，ＹＥＳ）、ステップＳ２７の処理を実行する。ステップＳ２７では、パケットの欠落があることを知らせるＮＡＣＫパケットを作成し、受信パケットの送信元ＩＰアドレス及びポート番号に対してそのＮＡＣＫパケットを返信する。ＮＡＣＫパケットには、例えば、欠落しているシーケンス番号をＡＣＫ番号として付加する。そして、次のステップＳ２８で、受信したパケットを破棄する。
自装置がＳＴＡＮＤＢＹ装置で、かつ受信パケットの動作モードがセーフモードでないときには（Ｓ２６，ＮＯ）、応答パケットを返信する必要がないのでそこで処理を終了する。
図６のシーケンス番号チェック処理が終了したなら、次に、図５のステップＳ１５の処理を実行する。
図５のステップＳ１５は、受信パケットのＭＯＤＥで決まる処理内容を示すものである。動作モードがネットワーク・セーフモードのときには、ＡＣＴＩＶＥ装置とＳＴＡＮＤＢＹ装置が両方ともＡＣＫまたはＮＡＣＫを返信する。
動作モードがネットワーク・クイックのときには、ＡＣＴＩＶＥ装置のみがＡＣＫまたはＮＡＣＫを返信する。ＳＴＡＭＤＢＹ装置は、ＡＣＫを返信する必要が無い。また、アプリケーションモードのときには、この時点ではＡＣＫを返信しない。
次に、受信パケットのシーケンス番号が連続しているときには、新たに受信したパケットのシーケンス番号を制御表４１の該当する動作モードの欄に格納する（Ｓ１６）。
次に、受信パケットにユーザデータが付加されているか否かを判定する（Ｓ１７）。ユーザデータが付加されている場合には（Ｓ１７，ＹＥＳ）、ステップＳ１８に進み、受信したデータを受信キュー（待ち行列）に入れ、受信データが存在することをアプリケーションに通知する。
次に、図８は、動作モードがアプリケーション・セーフまたはアプリケーション・クイックモードのときに、上位のアプリケーションからの応答指示に従ってサーバ装置１２〜１４の通信処理部３２〜３４が、ＡＣＫまたはＮＡＣＫパケットを返信する場合のフローチャートである。
最初に、上位のアプリケーションの指示内容と制御表４１との整合性をチェックし（図８、Ｓ３１）、チェック結果が正常か否かを判定する（Ｓ３２）。チェック結果が異常と判定された場合には（Ｓ３２，ＮＯ）、ステップＳ３３に進み、上位のアプリケーションにエラーを通知する。この処理は、アプリケーションからの指示が制御表４１に格納されている動作モードと整合するか否かを判定することで、アプリケーション側で発生するエラーを検出するためのものである。
ステップＳ３２において、整合性チェックが正常と判定されたときには（Ｓ３２，ＹＥＳ）、ステップＳ３４に進み、制御表４１に格納されているクライアントＩＰアドレス、ポート番号等を取得して送信パケットを作成する。そして、ＯＳに対して作成したパケットのユニキャストでの送信を依頼する（Ｓ３５）。
次に、クライアント装置１１の通信処理部３１の処理動作について、図９，図１１〜図１３のフローチャートを参照して説明する。
先ず、マルチキャスト用送信パケットを作成し、制御表４２のシーケンス番号を更新する（図９，Ｓ４１）。
ここで、クライアント装置１１の通信処理部３１により作成される制御表４２について図１０を参照して説明する。
制御表４２は、図１０（Ａ）に示すように、マルチキャストＩＰアドレスと、ポート番号と、パケット再送の初期値（タイマ時間の初期値）、パケットの再送の回数と、パケット再送の最大値（タイマ時間の最大値）と、前回送信したパケットの動作モードと、クイックモード時の送信済シーケンス番号と、セーフモード時の送信済シーケンス番号と、受信者リスト４２ａとで構成されている。
受信者リスト４２ａには、各サーバ装置のＩＰアドレスと、それぞれの装置がＡＣＴＩＶＥ、ＳＴＡＮＤＢＹの何れであるかを示す情報（状態１）と、それぞれの装置が正常に動作しているか否かを示す情報（状態２）と、クイックモード時に各サーバ装置から受信した受信済ＡＣＫ番号と、セーフモード時に各サーバ装置から受信した受信済ＡＣＫ番号が格納されている。
図１０（Ａ）の制御表４２から、クイックモード時の送信済シーケンス番号が「１００」で、セーフモード時の送信済シーケンス番号が「２００」であることが分かる。また、図１０（Ｂ）の受信者リスト４２ｂのクイックモード時の受信済ＡＣＫ番号が１００であることから、シーケンス番号「１００」の送信パケットに対するＡＣＫがＡＣＴＩＶＥ装置から返信済であることが分かる。また、全受信者（サーバ装置）のセーフモード時の受信済ＡＣＫ番号が「１９９」であることから、シーケンス番号「２００」のパケットに対するＡＣＫは、どの受信者からも返信されていないことが分かる。
クライアント装置１１の通信処理部３１は、送信済シーケンス番号と、受信者リスト４２ａの受信済ＡＣＫ番号から、ＵＤＰパケットの送達確認を行うことができる。また、パケット再送の初期値、再送回数等に基づいてタイマの再送時間間隔等を決めることができる。
図９に戻り、ステップＳ４２において、受信パケットの動作モードがｎｏ−ｗａｉｔモードか否かを判別する。動作モードがｎｏ−ｗａｉｔモードのときには、サーバ装置１２〜１４からの応答パケットを待つ必要がないので、ステップＳ４３に進み、ＯＳに対してＵＤＰパケットのマルチキャスト送信を依頼する。
他方、動作モードがｎｏ−ｗａｉｔではないときには（Ｓ４２，ＮＯ）、パケットを一定時間毎に再送信する必要があるので、再送用パケットを作成し、動作モードに応じた送信キューに入れ、再送タイマを起動させる。その後、上記のステップＳ４３に進み、ＯＳに対してＵＤＰパケットのマルチキャスト送信を依頼する。
次に、クライアント装置１１の通信処理部３１のＡＣＫ受信処理及び再送処理について、図１１〜図１３のフローチャートを参照して説明する。
図１１は、サーバ装置１２〜１４からのＡＣＫを受信するＡＣＫ受信処理（１）のフローチャートである。
クライアント装置１１の通信処理部３１は、ＯＳに対して受信待ちデータがあるか否かを確認し（図１１、Ｓ４１）、その結果により受信待ちのデータがあるか否かを判断する（Ｓ４２）。
受信待ちのデータが存在しないときには（Ｓ４２，ＮＯ）、ステップＳ４１に戻り、上記の処理を繰り返す。
受信待ちのデータが存在する場合には（Ｓ４２、ＹＥＳ）、ステップＳ４３に進み、ＯＳからパケットを受信する。
次に、受信したパケットのＡＣＫ番号と、制御表４２に格納されている該当するモードの送信済シーケンス番号や受信リスト４２ａの受信者ＩＰアドレスに対応する受信済ＡＣＫ番号と照合する（Ｓ４４）。
受信したパケットのヘッダ部のＦＬＡＧからＡＣＫパケットか否かを判別する（Ｓ４５）。ＡＣＫパケットでなければ（Ｓ４５，ＮＯ）、ステップＳ４６に進み、ＮＡＣＫパケットか否かを判別する。ＮＡＣＫパケットであれば（Ｓ４６，ＹＥＳ）、ステップ４７で、ＮＡＣＫパケットのＡＣＫ番号で指定されるパケットの再送をＯＳに依頼する。その後、次のステップＳ４８で受信パケット（ＮＡＣＫパケット）を破棄する。また、ステップ４６で、ＮＡＣＫパケットでないと判定されたときには（Ｓ４６，ＮＯ）、ステップＳ４８に進み受信パケットを破棄する。
ステップＳ４５で、受信した応答パケットがＡＣＫパケットであると判定された場合には（Ｓ４５，ＹＥＳ）。ステップＳ４９のＡＣＫ受信処理（２）を実行する。
図１２は、図１１のステップＳ４９のＡＣＫ受信処理（２）の詳細なフローチャートである。
最初に、ＡＣＫパケットのＭＯＤＥがクイックモードか否かを判別する（図１２，Ｓ５１）。動作モードとしてクイックモードが指定されているときには（Ｓ５１、ＹＥＳ）、ステップＳ５２に進み、そのＡＣＫパケットをＡＣＴＩＶＥ装置から受信したか否かを判別する。ＡＣＴＩＶＥ装置から受信したパケットか否かは、ＡＣＫパケットに付加されているＳＴＡＴＵＳ情報により判断できる。
ＡＣＴＩＶＥ装置からのＡＣＫパケットを受信した場合には（Ｓ５２，ＹＥＳ）、ステップＳ５３の処理を実行する。ステップＳ５３では、再送タイマを解除し、送信キューから再送パケットを削除し、さらに制御表４２の受信者リストの該当する受信者（ＡＣＴＩＶＥ装置）の受信済ＡＣＫ番号を更新する。ＡＣＫ番号の更新は、その受信者の最新のＡＣＫパケットのＡＣＫ番号を受信者リストに書き込むことで行う。
他方、クイックモードで、かつＡＣＴＩＶＥ装置以外からのＡＣＫパケットを受信した場合には（Ｓ５２，ＮＯ）、ステップＳ５４に進み、受信パケットを破棄する。これは、クイックモードでは、ＡＣＴＩＶＥ装置に対する送達確認のみを行えば良いからである。
ステップＳ５１において、動作モードがクイックモードではないと判別された場合には（Ｓ５１，ＮＯ）、つまりセーフモードのときには、ステップＳ５５に進み、全サーバ装置からＡＣＫパケットを受信したか否かを判別する。
全サーバ装置からのＡＣＫパケットを受信していない場合には（Ｓ５５，ＮＯ）、ステップＳ５６に進み、制御表４２の受信者リスト４２ａの今回ＡＣＫパケットを受信した受信者（サーバ装置）の受信済ＡＣＫ番号を更新した後処理を終了する。
ステップ５５で、全サーバ装置のＡＣＫパケットを受信したと判定された場合には（Ｓ５５，ＹＥＳ）、ステップＳ５７に進み、再送タイマを解除し、送信キューから再送パケットを削除し、さらに制御表４２の受信者リスト４２ａの該当する受信者の受信済ＡＣＫ番号を更新する。
次のステップＳ５８において、ＡＣＫパケットのＭＯＤＥがアプリケーション・セーフモードまたはアプリケーション・クイックモードであれば、ＡＣＫパケットのヘッダを削除し、データを上位のアプリケーションに渡す。
次に、クライアント装置１１の通信処理部３１における再送処理について、図１３のフローチャートを参照して説明する。
最初に、設定したタイマ時間内にＡＣＫパケットを受信したか否かを判別する（図１３，Ｓ６１）。タイマ時間の初期値としては、例えば、図１０の制御表４２のパケット再送の初期値（例えば、２００ｍｓ）が設定され、そのタイマ時間内にＡＣＫパケットを受信したか否かを判断する。
タイマ時間内にＡＣＫパケットを受信しなかった場合には（Ｓ６１，ＹＥＳ）、ステップＳ６２に進み、タイマ時間が再送のリトライ時間をオーバしたか否かを判別する。リトライ時間としては、図１０の制御表４２のパケット再送の最大値がリトライ時間の上限値として用いられる。
タイマで計測された時間がリトライ時間をオーバしていないときには（Ｓ６２，ＮＯ）、ステップＳ６３に進み、ＯＳに対してパケットの再送依頼を行う。そして、次のステップＳ６４で、再送のためのタイマの設定時間を更新する。この実施の形態では、パケットの再送時間間隔を徐々に長くするようにしているので、再送タイマ値を毎回更新している。
ステップＳ６２において、リトライ時間をオーバしたと判定された場合には（Ｓ６２，ＹＥＳ）、ステップＳ６５に進み、状態管理部２１にパケットの送信先の装置異常を通知する。さらに、次のステップＳ６６で、上位のアプリケーションにエラー通知を行い、特定のサーバ装置からＡＣＫパケットが返信されないことを知らせる。
ステップＳ６１において、タイマの設定時間内にＡＣＫパケットが返送されと判定された場合には（Ｓ６１、ＮＯ）、ステップＳ６７に進み、タイマをキャンセルする。これにより再送が中止される。
ここで、クライアント装置１１において、サーバ装置１２〜１４からのＡＣＫの返送を監視する処理について、図１４を参照して説明する。
クライアント装置１１の通信処理部３１は、パケットを送信したとき、タイマの上限値として、制御表４２のパケット再送の初期値、例えば、２００ｍｓを設定し、その時間内に応答パケットが返送されるか否かを監視する。
設定したタイマ時間の２００ｍｓの間に応答パケットが返送されない場合には、タイマの上限値として、例えば、初期値の２倍の４００ｍｓを設定する。図１４の例では、パケットの再送時間として、再送回数が増える毎に、制御表４２のパケットの再送の最大値の範囲内で、タイマの上限値が初期値ａの２倍、４倍、８倍・・・に増加するように定めている。
４００ｍｓの間に応答パケットが返送されないときには、制御表４２のパケット再送の回数の上限値（例えば、３回）以下で、かつパケット再送の最大値（例えば、５００ｍｓ）以下の時間をタイマの上限値として設定する。
設定したタイマの上限値が、制御表４２のパケット再送の最大値（リトライアウト時間）を過ぎても応答パケットが返送されないときには、通信処理部３１は、パケットの送信先のサーバ装置に異常が発生したものと判断して状態管理部２１に異常を通知する。
図１５は、ＵＤＰに基づいてパケットの再送制御を行うときのクライアント装置１１の通信処理部３１と状態管理部２１の動作説明図である。
上位のアプリケーションから再送制御のリトライ時間が設定されると（図１５，（１））、通信処理部３１は、監視対象リストを参照してタイマ監視を行う。そして、最大リトライ時間を過ぎても応答パケットが返送されないときには、対象となるサーバ装置を特定して状態管理部２１に装置の異常を通知する（図１５，（２））。
状態管理部２１は、各サーバ装置１２〜１４の状態管理部２２〜２４に障害の発生を通知し、障害が発生したと思われるサーバ装置に関する情報を収集して故障か否かの診断を行う（図１５，（３））。なお、故障の診断は、外部の状態管理装置１５が行い、その結果を、クライアント装置１１に通知するようにして良い。
状態管理部２１は、診断によりサーバ装置の故障と判断した場合には、該当するサーバ装置を監視対象リストから削除するように通信処理部３１に指示する（図１５，（４））。
上述したクライアント装置１１の通信処理部３１の処理により、特定の初期値がシーケンス番号として設定されているＵＤＰパケットを複数のサーバ装置１２〜１４にマルチキャストで送信して、ＡＣＴＩＶＥ装置とＳＴＡＮＤＢＹ装置の双方と同時にコネクションを確立することができる。また、アプリケーションデータのＵＤＰパケットを複数のサーバ装置１２〜１４にマルチキャストで送信することで、ＡＣＴＩＶＥ装置とＳＴＡＮＤＢＹ装置の双方に同一のアプリケーションデータを送信し、そのパケットの送達を確認できる。
次に、実施の形態の通信方法による、クライアント装置１１とサーバ装置１２〜１４との間の通信動作を、図１６及び図１７を参照して説明する。図１６及び図１７は、縦軸が時間軸であり、図面の上から下方向に時間が経過することを表している。
サーバ装置１２〜１４は、それぞれの状態管理部２２〜２４間で通信を行い、ＡＣＴＩＶＥ装置とＳＴＡＮＤＢＹ装置を決める。今、サーバ装置１２がＡＣＴＩＶＥ装置、サーバ装置１３，１４がＳＴＡＮＤＢＹ装置と決められたとする。
クライアント装置１１の通信処理部３１は、サーバ装置１２〜１４との間で同時にコネクションを確立するために、コネクション確立用のＵＤＰパケットにシーケンス番号、動作モードを指定するＭＯＤＥ等の情報を付加してマルチキャストで各サーバ装置１２〜１４に送信する（図１６の（１））。
各サーバ装置１２〜１４の通信処理部３２〜３４は、クライアント装置１１からシーケンス番号として初期値（例えば、「１」）が設定されているＵＤＰパケットを受信すると、それに対するＡＣＫパケットをユニキャストでクライアント装置１１に送信する。このとき、各サーバ装置１２〜１４が送信するＡＣＫパケットには、シーケンス番号と、ＡＣＫ番号と、それぞれの装置がＡＣＴＩＶＥか、ＳＴＡＮＤＢＹかを示すＳＴＡＵＳ情報が付加されている。
クライアント装置１１の通信処理部３１は、最初に送信したＵＤＰパケットに対するＡＣＫパケットを各サーバ装置１２〜１４から受信すると、制御表４２の受信者リスト４２ａに各サーバ装置１２〜１４のＩＰアドレスと、ＳＴＡＵＳ情報と、受信済ＡＣＫ番号を格納する。
クライアント装置１１の通信処理部３１は、アプリケーションの処理データを、ＡＣＴＩＶＥ装置（サーバ装置１２）とＳＴＮＤＢＹ装置（サーバ装置１３，１４）にＵＤＰパケットにシーケンス番号を付加してマルチキャストで送信する。また、ＡＣＴＩＶＥ装置とＳＴＡＮＤＢＹ装置の双方から、その送信パケットに対するＡＣＫを受信したなら、各サーバ装置のＡＣＫパケットのＡＣＫ番号を制御表４２の受信者リスト４２ａに書き込む（図１６，（２））。
次に、ＡＣＴＩＶＥ装置で障害が発生した場合の動作について図１７を参照して説明する。
サーバ装置１２〜１４の状態管理部２２〜２４間の通信により、サーバ装置（ＡＣＴＩＶＥ装置）１２の障害が検出されると、予め決めてある優先順序に従って特定の装置、例えば、サーバ装置１３がＡＣＴＩＶＥとなり、サーバ装置１４がＳＴＡＮＤＢＹの状態を維持する。なお、ＡＣＴＩＶＥ装置の切り換えは、サーバ装置１２〜１４の状態管理部２２〜２４ではなく、外部の状態管理装置１５が行っても良い。
このとき、それまでＳＴＡＮＤＢＹ状態であったサーバ装置１３にも、障害が発生したサーバ装置１２と同じアプリケーションのデータがマルチキャストで送信されているので、サーバ装置１３は、クライアント装置１１から送信されてくるアプリケーションのデータに対する処理を継続して実行することができる。
クライアント装置１１の通信処理部３１は、マルチキャストでパケットを送信しているため、この時点ではＡＣＴＩＶＥ装置が切り替わったことを分からないが、ＡＣＴＩＶＥに切り替わったサーバ装置１３のＡＣＫパケットを受信した時点で、ＡＣＫパケットのＳＴＡＴＵＳ情報からサーバ装置１３がＡＣＴＩＶＥ装置になったことを認識できる（図１７、（３））。
次に、図１８は、実施の形態においてアプリケーションに提供されるＡＰＩ関数を、ＴＣＰ−ＡＰＩ関数と対応付けた対応表である。
この実施の形態では、アプリケーションに対して、pc_socket()、pc_setsockopt()、pc_getsockopt()、pc_bind()、pc_sendmsg()、pc_recvmsg()、pc_poll()、pc_close()等のＡＰＩ関数を提供している。
pc_socket()は、ＴＣＰのsocket()に対応するものであり、高信頼マルチキャスト用のソケットを生成する機能を有する。
pc_setsockopt()は、ＴＣＰのsetsokopt()に対応するものであり、指定されたソケットに対するタイムアウト時間の設定、受信先の初期設定及び送達確認方法の設定等の機能を有する。
pc_getsockopt()は、ＴＣＰのgetsockopt()に対応するものであり、指定されたソケットに設定されたタイムアウト時間、受信先インスタンスの状態及び送達確認方法等の情報を取得する機能を有する。
pc_bind()は、ＴＣＰのbind()に対応するものであり、マルチキャスト用ソケットに対して受信開始を指示する機能を有する。
pc_sendmsg()は、ＴＣＰのsendmsg()に対応するものであり、受信先インスタンスに対してデータを送信する機能を有する。
pc_recvmsg()は、ＴＣＰのrecvmsg()に対応するものであり、データを受信する機能を有する。
pc_poll()は、ＴＣＰのpoll()に対応するものであり、送信、受信またはエラーのイベントが発生するまで待ち、指定したタイムアウト時間が経過するとエラー処理に移行する機能を有する。
pc_close()は、ＴＣＰのclose()に対応するものであり、高信頼マルチキャスト用ソケットを回収する機能を有する。この命令により送信中のデータは破棄される。
上記のＡＰＩ関数を前提にして、クライアント装置１１と複数台のサーバ装置１２〜１４間で同時にコネクションを確立するとき、データを送信するとき並びにサーバ装置１２〜１４からＡＣＫパケットを送信するときの通信手順を、図１９のシーケンス図を参照して説明する。
クライアント装置１１のアプリケーションは最初にコネクションを確立するときに、pc_sendmsg()を発行する。この最初のpc_sendmsg()の発行はＴＣＰのconnect()に相当するものであり、アプリケーションからの１回のコネクションの確立要求で、ＡＣＴＩＶＥ、ＳＴＡＮＤＢＹの全サーバ装置と同時にコネクションを確立することができる。
クライアント装置１１の通信処理部３１は、上位のアプリケーションからpc_sendmsg()を受け取ると、ＵＤＰパケットにシーケンス番号、ＭＯＤＥ、ＳＴＡＴＵＳ等を付加したＵＤＰパケットをマルチキャストで複数のサーバ装置１２〜１４に送信する。
各サーバ装置１２〜１４の通信処理部３２〜３４は、受信したＵＤＰパケットのマルチキャストＩＰアドレス、シーケンス番号等をそれぞれの制御表４２に格納し、ＡＣＫをユニキャストでクライアント装置１１に返送する。このとき、上位のアプリケーションは、pc_poll()、pc_recmsg()を発行してＵＤＰパケットを受け取る。これらのＡＰＩ関数は、ＴＣＰのaccept()等に相当する。
クライアント装置１１の通信処理部３１は、最初に送信したＵＤＰパケット（シーケンス番号が初期値「１」のパケット）に対するＡＣＫを受信したとき、コネクションを確立する。上位のアプリケーションは、pc_recvmsg()を発行してＵＤＰパケットのデータを受け取る。
次に、アプリケーションは、pc_sendmsg()を発行してアプリケーションのデータの送信を通信処理部３１に指示する。通信処理部３１は、アプリケーションのデータをＵＤＰパケットでマルチキャストにより複数のサーバ装置１２〜１４に同時に送信する。
各サーバ装置１２〜１４の通信処理部３２〜３４は、マルチキャストされたデータパケットを受信する。各サーバ装置１２〜１４のアプリケーションは、pc_recvmsg()を発行してデータパケットを受け取る。さらに、アプリケーションは、pc_sendmsg()を発行してＡＣＫの返送を指示する。各通信処理部３２〜３４は、ＡＣＫパケットをクライアント装置１１に送信する。
上記の動作が繰り返されて、クライアント装置１１のアプリケーションのデータがＡＣＴＩＶＥのサーバ装置１２とＳＴＡＮＤＢＹのサーバ装置１３〜１４に同時に送信される。また、各サーバ装置１２〜１４は、シーケンス番号によりパケットの未達を検出すると、ＮＡＣＫパケットに欠落しているシーケンス番号をＡＣＫ番号として付加してパケットの再送を要求する。クライアント装置１１は、ＮＡＣＫパケットを受信すると、そのＮＡＣＫパケットに付加されているＡＣＫ番号で指定されるパケットを再送する。これにより、ＡＣＴＩＶＥ、ＳＴＡＮＤＢＹの双方のサーバ装置のアプリケーションデータの同一性を保証することができる。
次に、図２０は、障害発生時の動作説明図である。クライアント装置１１は、ＡＣＴＩＶＥなサーバ装置１２とＳＴＡＮＤＢＹのサーバ装置１３との間で同時にコネクションを確立した後、各サーバ装置１２、１３にアプリケーションデータをＵＤＰパケットを用いてマルチキャストで送信する。
クライアント装置１１の通信処理部３１は、ＡＣＴＩＶＥのサーバ装置１２からのＡＣＫが一定時間以上返送されないことを検出すると、状態管理装置１５にサーバ装置１２の状態を問い合わせる（図２０、（１））。
状態管理装置１５は、サーバ装置１２の状態を確認し、障害を検出すると（図２０、（２））、ＡＣＴＩＶＥ装置１２を切り離し、サーバ装置１３にＡＣＴＩＶＥに移行するように指示する（図２０、（３））。このとき、クライアント装置１１に、サーバ装置１２を切り離し、サーバ装置１３をＡＣＴＩＶＥに切り換えたことを通知する（図２０、（４））。
ＡＣＴＩＶＥに移行したサーバ装置１３は、それまでＡＣＴＩＶＥであったサーバ装置１２に送信されていたアプリケーションデータを全て受信しているので、サーバ装置１２が受信していたデータとの同一性が確保されている。従って、ＳＴＡＮＤＢＹからＡＣＴＩＶＥへの切り換えが行われた直後から、クライアント装置１１のアプリケーションとの間の通信を継続し、処理を続けることができる。
従って、現用系の装置に障害が発生してもアプリケーションの処理を中断することなく待機系の装置に切り換えることができる。
次に、各動作モードにおけるパケットの送達確認方法について図２１〜図２４を参照して説明する。
図２１は、アプリケーション・セーフモードにおける送達確認方法の説明図である。アプリケーション・セーフモードは、全てのサーバ装置が、アプリケーションレイヤからＡＣＫの返信を行うモードである。図２１〜図２４において、実線の矢印はマルチキャストでのパケットの送信を示し、破線の矢印はユニキャストでのパケットの送信を示している。
クライアント装置１１の通信処理部３１は、ＵＤＰパケットをマルチキャストにより全サーバ装置１２〜１４に送信する。
各サーバ装置１２〜１４の通信処理部３２〜３４は、受信したパケットのシーケンス番号と、制御表４１に格納されている受信済パケットのシーケンス番号を比較して、パケットの抜けがあるか否かをチェックする。パケットの抜けがないと判断したときには、そのパケットのデータをアプリケーションに渡す。アプリケーションは、そのデータが正常か否かを確認し、データの処理が完了した後、ＡＣＫの返信を通信処理部３２〜３４に指示する。各サーバ装置１２〜１４の通信処理部３２〜３４は、それぞれユニキャストでＡＣＫをクライアント装置１１に送信する。
次に、図２２は、アプリケーション・クイックモードにおける送達確認方法の説明図である。アプリケーション・クイックモードは、ＡＣＴＩＶＥ装置のみがアプリケーションレイヤからＡＣＫを返信するモードである。
クライアント装置１１の通信処理部３１は、ＵＤＰパケットをマルチキャストにより全サーバ装置１２〜１４に送信する。
ＡＣＴＩＶＥなサーバ装置１２の通信処理部３２は、受信したパケットのシーケンス番号と、制御表４１に格納されている受信済パケットのシーケンス番号を比較して、パケットの抜けがあるか否かをチェックする。パケットの抜けがないと判断したときには、そのパケットのデータをアプリケーションに渡す。アプリケーションは、データが正常か否かを確認した後、ＡＣＫの返信を通信処理部３２に指示する。通信処理部３２は、ユニキャストでＡＣＫをクラインと装置１１に送信する。サーバ装置１３及び１４は、ＡＣＴＩＶＥではないのでＡＣＫは返信しない。
クライアント装置１１は、ＡＣＴＩＶＥ装置１２からのＡＣＫをアプリケーションに渡した後、他の処理を実行する。
次に、図２３は、ネットワーク・セーフモードにおける送達確認方法の説明図である。ネットワーク・セーフモードは、全てのサーバ装置がネットワークレイヤからＡＣＫを返信するモードである。
クライアント装置１１の通信処理部３１は、ＵＤＰパケットをマルチキャストにより全サーバ装置１２〜１４に送信する。
各サーバ装置１２〜１４の通信処理部３２〜３４は、受信したパケットのシーケンス番号と、制御表４１に格納されている受信済パケットのシーケンス番号を比較して、パケットの抜けがあるか否かをチェックする。パケットの抜けがないと判断したときには、各通信処理部３２〜３４がＡＣＫをクライアント装置１１にユニキャストで送信する。また、パケットの抜けがあると判断したときには、欠落しているシーケンス番号のパケットの再送を要求するＮＡＣＫをクライアント装置１１に送信する。
クライアント装置１１は、全サーバ１２〜１４からのＡＣＫ返信を待ち、一定時間以内にＡＣＫが返信されないときにはパケットを再送信する。全サーバ１２〜１４のＡＣＫを受信したなら、次の処理を実行する。
次に、図２４は、ネットワーク・クイックモードにおける送達確認方法の説明図である。ネットワーク・クイックモードは、ＡＣＴＩＶＥなサーバ装置１２のみがネットワークレイヤからＡＣＫを返信するモードである。
クライアント装置１１の通信処理部３１は、ＵＤＰパケットをマルチキャストにより全サーバ装置１２〜１４に送信する。
ＡＣＴＩＶＥなサーバ装置１２の通信処理部３２は、受信したパケットのシーケンス番号と、制御表４１に格納されている受信済パケットのシーケンス番号を比較して、パケットの抜けがあるか否かをチェックする。パケットの抜けがないと判断したときには、そのパケットのデータをアプリケーションに渡し、通信処理部３２がＡＣＫをクライアント装置１１に返信する。
クライアント装置１１の通信処理部３１は、ＡＴＩＶＥなサーバ装置１２からのＡＣＫを受信したなら、次の処理を実行する。
上述した実施の形態のクライアント装置１１と複数のサーバ装置１２〜１４とからなるシステムの通信方法によれば、以下のような効果が得られる。
（ａ）クライアント装置１１からＡＣＴＩＶＥなサーバ装置１２とＳＴＡＮＤＢＹのサーバ装置１３〜１４に、シーケンス番号として初期値（例えば、「１」）を設定したＵＤＰパケットをマルチキャストすることで、クライアント装置１１と複数のサーバ装置１２〜１４との間で同時にコネクションを確立することができる。
（ｂ）コネクションを確立した後、クライアント装置１１のアプリケーションのデータをＵＤＰパケットを用いて複数のサーバ装置１２〜１４に同時に送信し、複数のサーバ装置からＡＣＫパケットが返送されたか否かを確認することで、ＡＣＴＩＶＥ装置とＳＴＡＮＤＢＹ装置の双方に対してパケットの送達を確認できる。
（ｃ）さらに、サーバ装置がパケットの抜けを検出した場合には、欠落したパケットを特定する情報、例えば、欠落したシーケンス番号を付加したＮＡＣＫパケットをクライアント装置１１に返信し、クライアント装置１１がそのシーケンス番号で指定されるＵＤＰパケットを再送信することで、全てのサーバ装置１２〜１４の受信データの同一性を保証することができる。
実施の形態の通信方法は、ＵＤＰをベースにしてネットワークレイヤに実装するプログラム（通信処理部）により通信を行っているので、パケットの送受信を高速化し、かつＴＣＰと同等の信頼性を確保できる。また、ＡＣＴＩＶＥなサーバ装置１２とＳＴＡＮＤＢＹのサーバ装置１３，１４の双方のアプリケーションデータの同一性を保証できるので、ＡＣＴＩＶＥなサーバ装置に障害が発生し、ＳＴＡＮＤＢＹのサーバ装置１３または１４に切り換えた場合でも、クライアント装置１１のアプリケーションとサーバ装置のアプリケーション間の通信の継続性を確保できる。
従って、速い処理速度と高い信頼性が要求され、かつ障害発生時の業務処理の中断時間を短くする必要のある基幹システムに好適である。
（ｅ）上述した通信方法を実現するプログラム（通信処理部３１〜３４など）をネットワークレイヤに実装しているので、個々のアプリケーションのプログラムを大幅に変更せずに信頼性の高いデータ通信を実現できる。
本発明は上述した実施の形態に限らず、例えば、以下のように構成しても良い。
（ａ）ＵＤＰパケットのフォーマットは、図３に示した構成に限らない。例えば、動作モードが１種類で良い場合には、ＵＤＰパケットにＭＯＤＥ情報を付加する必要が無い。

Claims (21)

  1. クライアント装置と複数のサーバ装置とからなるシステムの通信方法であって、
    シーケンス番号を付加したＵＤＰパケットをマルチキャストで前記複数のサーバ装置に送信して前記クライアント装置と前記複数のサーバ装置との間で同時にコネクションを確立し、
    コネクションを確立した後、アプリケーションプログラムのデータを含むＵＤＰパケットに後続のシーケンス番号を付加してマルチキャストで前記複数のサーバ装置に送信し、
    送信済のＵＤＰパケットのシーケンス番号を記憶手段に記憶し、
    送信した前記ＵＤＰパケットに対するＡＣＫパケットが前記複数のサーバ装置の内の少なくとも１つ以上から返送されたとき、前記ＡＣＫパケットに付加されているシーケンス番号と、前記記憶手段に記憶されている送信済の前記ＵＤＰパケットのシーケンス番号を比較してＵＤＰパケットの送達を確認する通信方法。
  2. 請求項１記載の通信方法において、
    前記複数のサーバ装置がそれぞれ受信済のＵＤＰパケットのシーケンス番号を記憶し、
    新たに受信したＵＤＰパケットのシーケンス番号と、記憶してある受信済の前記ＵＤＰパケットのシーケンス番号を比較してパケットの送達を確認し、
    前記ＵＤＰパケットの送達を確認したとき、各サーバ装置が受信した前記ＵＤＰパケットのシーケンス番号をＡＣＫ番号として付加した前記ＡＣＫパケットを前記クライアント装置に返送する通信方法。
  3. 請求項１記載の通信方法において、
    前記複数のサーバ装置は現用系と待機系のサーバ装置からなり、
    現用系の前記サーバ装置の障害が検出され、待機系の前記サーバが現用系に切り換えられたとき、現用系に切り換えられた前記サーバ装置を含む前記複数のサーバ装置に前記ＵＤＰパケットをマルチキャストして、前記クライアント装置のアプリケーションプログラムと現用系となった前記サーバ装置のアプリケーションプログラムとの間の通信を継続させる通信方法。
  4. 請求項１記載の通信方法において、
    前記ＵＤＰパケットは、データ部にデータパケットか、ＡＣＫパケットか、ＮＡＣＫパケットかのパケットの種別を示すＦＬＡＧ情報と、連番で設定されるシーケンス番号と、ＡＣＫ番号とが付加されて送信される通信方法。
  5. 請求項１記載の通信方法において、
    未送達のＵＤＰパケットのシーケンス番号を付加したＮＡＣＫパケットを前記クライアント装置に送信して、未送達の前記ＵＤＰパケットの再送を要求する通信方法。
  6. 請求項１記載の通信方法において、
    前記ＵＤＰパケットのデータ部に、前記ＵＤＰパケットを受信したときに、アプリケーションプログラムからの指示に基づいてネットワークレイヤが前記ＡＣＫパケットを返送するアプリケーションモードと、前記ＵＤＰパケットを受信したとき、前記ネットワークレイヤの判断で前記ＡＣＫパケットを返送するネットワークモードの何れであるかを指定する情報を付加する通信方法。
  7. クライアント装置と複数のサーバ装置とからなるシステムの通信プログラムであって、
    シーケンス番号を付加したＵＤＰパケットをマルチキャストで送信して、前記クライアント装置と前記複数のサーバ装置との間で同時にコネクションを確立するステップと、
    アプリケーションプログラムのデータを含むＵＤＰパケットに後続のシーケンス番号を付加してマルチキャストで前記複数のサーバ装置に送信するステップと、
    送信済のＵＤＰパケットのシーケンス番号を記憶手段に記憶するステップと、
    送信したＵＤＰパケットに対するＡＣＫパケットが前記複数のサーバ装置の内の少なくとも１つ以上から返送されたとき、前記ＡＣＫパケットに付加されているシーケンス番号と、前記記憶手段に記憶されている送信済の前記ＵＤＰパケットのシーケンス番号を比較してパケットの送達を確認するステップとを、コンピュータに実行させる通信プログラム。
  8. 請求項７記載の通信プログラムにおいて、
    前記複数のサーバ装置は現用系と待機系のサーバ装置からなり、
    現用系の前記サーバ装置の障害が検出され、待機系の前記サーバが現用系に切り換えられたとき、現用系に切り換えられた前記サーバ装置を含む前記複数のサーバ装置に前記ＵＤＰパケットをマルチキャストして、前記クライアント装置のアプリケーションプログラムと現用系となった前記サーバ装置のアプリケーションプログラムとの間の通信を継続させる通信プログラム。
  9. 請求項７記載の通信プログラムにおいて、
    前記ＵＤＰパケットは、データ部にデータパケットか、ＡＣＫパケットか、ＮＡＣＫパケットかのパケット種別を示すＦＬＡＧ情報と、連番で設定されるシーケンス番号と、ＡＣＫ番号とが付加されて送信される通信プログラム。
  10. 請求項７記載の通信プログラムにおいて、
    未送達のパケットを示すＡＣＫ番号が付加されたＮＡＣＫパケットを受信したときに、前記ＡＣＫ番号で指定されるＵＤＰパケットを再送する通信プログラム。
  11. クライアント装置と複数のサーバ装置とからなるシステムの通信プログラムであって、
    クライアント装置からマルチキャストで送信され、シーケンス番号が付加されたＵＤＰパケットを受信したとき、ＡＣＫパケットを返信してコネクションを確立するステップと、
    受信済のＵＤＰパケットのシーケンス番号を記憶手段に記憶するステップと、
    新たに受信したＵＤＰパケットのシーケンス番号と、前記記憶手段に記憶してある受信済の前記ＵＤＰパケットのシーケンス番号を比較してパケットの送達を確認するステップと、
    前記ＵＤＰパケットの送達を確認したとき、受信した前記ＵＤＰパケットのシーケンス番号を付加したＡＣＫパケットを前記クライアント装置に返送するステップとを、コンピュータに実行させる通信プログラム。
  12. 請求項１１記載の通信プログラムにおいて、
    前記複数のサーバ装置は現用系と待機系のサーバ装置からなり、
    現用系の前記サーバ装置の障害が検出され、待機系の前記サーバが現用系に切り換えられたとき、現用系に切り換えられた前記サーバ装置を含む前記複数のサーバ装置に前記ＵＤＰパケットをマルチキャストして、前記クライアント装置のアプリケーションプログラムと現用系となった前記サーバ装置のアプリケーションプログラムとの間の通信を継続させる通信プログラム。
  13. 請求項１１記載の通信プログラムにおいて、
    前記ＵＤＰパケットは、データ部にデータパケットか、ＡＣＫパケットか、ＮＡＣＫパケットかのパケット種別を示すＦＬＡＧ情報と、連番で設定されるシーケンス番号と、ＡＣＫ番号とが付加されて送信される通信プログラム。
  14. 請求項１１記載の通信プログラムにおいて、
    新たに受信したＵＤＰパケットのシーケンス番号と、前記記憶手段に記憶してある受信済の前記ＵＤＰパケットのシーケンス番号が連続していないときには、欠落しているシーケンス番号をＡＣＫ番号として付加したＮＡＣＫパケットを前記クライアント装置に返送するステップを有する通信プログラム。
  15. クライアント装置と複数のサーバ装置とからなるシステムに用いられるクライアント装置であって、
    シーケンス番号を付加したＵＤＰパケットを前記複数のサーバ装置にマルチキャストで送信して前記複数のサーバ装置との間で同時にコネクションを確立するコネクション確立手段と、
    アプリケーションプログラムのデータを含むＵＤＰパケットに後続のシーケンス番号を付加して前記複数のサーバ装置にマルチキャストで送信する送信手段と、
    送信した前記ＵＤＰパケットに対するＡＣＫパケットが前記複数のサーバ装置の内の少なくとも１つ以上から返送されたとき、前記ＡＣＫパケットに付加されているシーケンス番号と、前記記憶手段に記憶されている送信済の前記ＵＤＰパケットのシーケンス番号を比較して前記ＵＤＰパケットの送達を確認する確認手段とを備えるクライアント装置。
  16. 請求項１５記載のクライアント装置において、
    前記複数のサーバ装置は現用系と待機系のサーバ装置からなり、
    前記送信手段は、現用系の前記サーバ装置の障害が検出され、待機系の前記サーバが現用系に切り換えられたとき、現用系に切り換えられた前記サーバ装置を含む前記複数のサーバ装置に前記ＵＤＰパケットをマルチキャストして、前記クライアント装置のアプリケーションプログラムと現用系となった前記サーバ装置のアプリケーションプログラムとの間の通信を継続させるクライアント装置。
  17. 請求項１５記載のクライアント装置において、
    前記ＵＤＰパケットは、データ部にデータパケットか、ＡＣＫパケットか、ＮＡＣＫパケットかのパケット種別を示すＦＬＡＧ情報と、パケットの送信順序を示すシーケンス番号と、ＡＣＫ番号とが付加されて送信されるクライアント装置。
  18. クライアント装置と複数のサーバ装置とからなるシステムに用いられるサーバ装置であって、
    前記クライアント装置からマルチキャストで送信され、シーケンス番号が付加されたＵＤＰパケットを受信したとき、ＡＣＫを返信して前記クライアント装置との間でコネクションを確立するコネクション確立手段と、
    受信済のＵＤＰパケットのシーケンス番号を記憶する記憶手段と、
    新たに受信したＵＤＰパケットのシーケンス番号と、前記記憶手段に記憶されている受信済の前記ＵＤＰパケットのシーケンス番号を比較してパケットの送達を確認する確認手段と、
    前記ＵＤＰパケットの送達を確認したとき、受信した前記ＵＤＰパケットのシーケンス番号を付加したＡＣＫパケットを前記クライアント装置に送信するＡＣＫ送信手段とを備えるサーバ装置。
  19. 請求項１８記載のサーバ装置において、
    前記複数のサーバ装置は現用系と待機系のサーバ装置からなり、
    現用系の前記サーバ装置の障害が検出され、待機系の前記サーバが現用系に切り換えられたとき、現用系に切り換えられた前記サーバ装置を含む前記複数のサーバ装置に前記ＵＤＰパケットをマルチキャストして、前記クライアント装置のアプリケーションプログラムと現用系となった前記サーバ装置のアプリケーションプログラムとの間の通信を継続させる通信手段を有するサーバ装置。
  20. 請求項１８記載のサーバ装置において、
    前記ＵＤＰパケットは、データ部にデータパケットか、ＡＣＫパケットか、ＮＡＣＫパケットかのパケット種別を示すＦＬＡＧ情報と、連番で設定されるシーケンス番号と、ＡＣＫ番号とが付加されて送信されるサーバ装置。
  21. 請求項１８記載のサーバ装置において、
    新たに受信したＵＤＰパケットのシーケンス番号と、前記記憶手段に記憶してある受信済の前記ＵＤＰパケットのシーケンス番号が連続していないときには、欠落しているシーケンス番号を付加したＮＡＣＫパケットを前記クライアント装置に送信するＮＡＣＫ送信手段を有するサーバ装置。
JP2009501034A 2007-02-28 2007-02-28 クライアント装置と複数のサーバ装置からなるシステムの通信方法、その通信プログラム、クライアント装置及びサーバ装置 Active JP4851585B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2007/000148 WO2008105032A1 (ja) 2007-02-28 2007-02-28 クライアント装置と複数のサーバ装置からなるシステムの通信方法、その通信プログラム、クライアント装置及びサーバ装置

Publications (2)

Publication Number Publication Date
JPWO2008105032A1 true JPWO2008105032A1 (ja) 2010-06-03
JP4851585B2 JP4851585B2 (ja) 2012-01-11

Family

ID=39720883

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009501034A Active JP4851585B2 (ja) 2007-02-28 2007-02-28 クライアント装置と複数のサーバ装置からなるシステムの通信方法、その通信プログラム、クライアント装置及びサーバ装置

Country Status (3)

Country Link
US (1) US8223766B2 (ja)
JP (1) JP4851585B2 (ja)
WO (1) WO2008105032A1 (ja)

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI334293B (en) * 2007-03-06 2010-12-01 Xtera Comm Taiwan Co Ltd Method for transmitting network packets
JP5018716B2 (ja) * 2008-09-29 2012-09-05 富士通株式会社 アプリケーション間通信の高信頼化技術
JP5544099B2 (ja) * 2009-02-27 2014-07-09 株式会社日立製作所 コントローラ通信方法およびコントローラ通信装置
JP5338594B2 (ja) * 2009-09-28 2013-11-13 株式会社Ｊｖｃケンウッド データ受信方法、データ送受信システム、およびデータ受信機
CN101714916B (zh) * 2009-11-26 2013-06-05 华为数字技术（成都）有限公司 一种备份方法、设备和系统
US9007181B2 (en) * 2010-01-08 2015-04-14 Tyco Fire & Security Gmbh Method and system for discovery and transparent status reporting for sensor networks
CN102158389A (zh) * 2010-06-25 2011-08-17 青岛海信传媒网络技术有限公司 异步的数据传输方法、装置及系统
US20120124431A1 (en) * 2010-11-17 2012-05-17 Alcatel-Lucent Usa Inc. Method and system for client recovery strategy in a redundant server configuration
US20120243622A1 (en) * 2011-03-23 2012-09-27 Broadcom Corporation Method and apparatus for improving the error rate of a serial/de-serial backplane connection
US9456377B2 (en) * 2011-08-19 2016-09-27 Futurewei Technologies, Inc. System and method for transmission control protocol service delivery in wireless communications systems
JP5982842B2 (ja) * 2012-02-03 2016-08-31 富士通株式会社 コンピュータ障害監視プログラム、方法、及び装置
KR101971623B1 (ko) * 2012-05-10 2019-04-23 삼성전자주식회사 컨텐츠 및 사용자 인터랙션 전송방법
EP3726451A1 (en) * 2012-09-12 2020-10-21 IEX Group, Inc. Transmission latency leveling apparatuses, methods and systems
EP2711864A1 (en) * 2012-09-25 2014-03-26 Gemalto SA Method of configuring two wireless devices for mutual communication
JP2016501464A (ja) 2012-11-08 2016-01-18 キュー ファクター コミュニケーションズ コーポレーション プロキシサーバを用いて通信ネットワークにおいてｔｃｐ及び他のネットワークプロトコルのパフォーマンスを向上させる方法及び装置
BR112015009944A2 (pt) * 2012-11-08 2017-10-03 Q Factor Communications Corp Aparelhos de transmissão de pacotes, sistema de comunicação para transmitir ou receber pacote, métodos para transferir confiavelmente dados de fonte de dados a receptor de dados, algoritmo e método para transmitir blocos de dados.
JP6132518B2 (ja) * 2012-11-21 2017-05-24 オリンパス株式会社 マルチキャスト送信端末、マルチキャストシステム、プログラムおよびマルチキャスト送信方法
US9774386B2 (en) * 2013-03-15 2017-09-26 E.F. Johnson Company Distributed simulcast architecture
JP5825689B2 (ja) * 2013-03-28 2015-12-02 Ｎｅｃソリューションイノベータ株式会社 要約筆記支援システム、要約筆記支援サーバ、要約筆記支援方法、及びプログラム
JP2015095247A (ja) 2013-11-14 2015-05-18 富士通株式会社 情報処理システム、情報処理装置、端末装置、制御プログラムおよび制御方法
US10411867B2 (en) * 2015-04-30 2019-09-10 Sony Corporation Communication apparatus and communication method
WO2017052393A1 (en) * 2015-09-25 2017-03-30 Intel Corporation Efficient error control techniques for tcp-based multicast networks
CN105245528B (zh) * 2015-10-20 2019-02-12 北京小鸟听听科技有限公司 一种基于用户数据报协议（udp）的控制命令传输方法、发送端和接收端
US10462006B2 (en) * 2015-12-18 2019-10-29 Verizon Patent And Licensing Inc. Hybrid environment to support reliable delivery of multicast traffic using an orchestration device
US10154317B2 (en) * 2016-07-05 2018-12-11 BoxCast, LLC System, method, and protocol for transmission of video and audio data
US11412272B2 (en) 2016-08-31 2022-08-09 Resi Media Llc System and method for converting adaptive stream to downloadable media
US10511864B2 (en) 2016-08-31 2019-12-17 Living As One, Llc System and method for transcoding media stream
JP7022508B2 (ja) * 2017-01-30 2022-02-18 キヤノン株式会社 通信装置、通信方法、及びプログラム

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5260933A (en) * 1992-05-15 1993-11-09 International Business Machines Corporation Acknowledgement protocol for serial data network with out-of-order delivery
AU2001238153A1 (en) * 2000-02-11 2001-08-20 Convergent Networks, Inc. Service level executable environment for integrated pstn and ip networks and call processing language therefor
US7360075B2 (en) * 2001-02-12 2008-04-15 Aventail Corporation, A Wholly Owned Subsidiary Of Sonicwall, Inc. Method and apparatus for providing secure streaming data transmission facilities using unreliable protocols
US7158486B2 (en) * 2001-03-12 2007-01-02 Opcoast Llc Method and system for fast computation of routes under multiple network states with communication continuation
JP2004080070A (ja) 2002-08-09 2004-03-11 Nippon Telegr & Teleph Corp <Ntt> データ転送方法及びデータ転送システム並びにコンテンツ配信システム
JP4015912B2 (ja) 2002-09-24 2007-11-28 東芝ソリューション株式会社 マルチキャスト配信システム、マルチキャスト配信プログラム及び装置
JP4025697B2 (ja) * 2003-07-09 2007-12-26 松下電器産業株式会社 パケット転送装置およびその制御方法
US20060291452A1 (en) * 2005-06-24 2006-12-28 Motorola, Inc. Method and apparatus for providing reliable communications over an unreliable communications channel

Also Published As

Publication number Publication date
US8223766B2 (en) 2012-07-17
WO2008105032A1 (ja) 2008-09-04
JP4851585B2 (ja) 2012-01-11
US20100014520A1 (en) 2010-01-21

Similar Documents

Publication Publication Date Title
JP4851585B2 (ja) クライアント装置と複数のサーバ装置からなるシステムの通信方法、その通信プログラム、クライアント装置及びサーバ装置
US11765082B2 (en) Data packet retransmission processing
US8612617B2 (en) Reliable multicast transport protocol
CA2706579C (en) Method for enabling faster recovery of client applications in the event of server failure
JP4153502B2 (ja) 通信装置及び論理リンク異常検出方法
WO2018149408A1 (en) High availability using multiple network elements
US20070263626A1 (en) A System for Session-Oriented Reliable Multicast Transmission.
US20110078313A1 (en) Method and system for managing a connection in a connection oriented in-order delivery environment
US8060628B2 (en) Technique for realizing high reliability in inter-application communication
JP4767336B2 (ja) メールサーバシステム及び輻輳制御方法
JP2006229399A (ja) 通信システム、中継ノード及びそれらに用いる通信方法並びにそのプログラム
JP2009253949A (ja) 通信システム、送信装置およびプログラム
JP2000022744A (ja) パケット通信システム、パケット通信装置及びパケット通信方法
JP4969421B2 (ja) 受信装置及び通信システム
KR101587332B1 (ko) 컨트롤러와 네트워크 장치 간 연결 상태 확인 방법
WO2021249651A1 (en) Device and method for delivering acknowledgment in network transport protocols
CN114070781B (zh) 一种数据通信方法、装置、系统及计算机设备
JP4015912B2 (ja) マルチキャスト配信システム、マルチキャスト配信プログラム及び装置
US20110078255A1 (en) Method and system for managing a connection in a connection oriented in-order delivery environment
JP2009065617A (ja) Ｌａｎ通信システム
WO2012043142A1 (ja) マルチキャストルータ及びマルチキャストネットワークシステム
JP4490998B2 (ja) マルチキャスト配信システム
CN116233243A (zh) 一种弱网环境下的通信系统及方法
JP2009266138A (ja) 通信システム、サーバ装置、中継装置及びそれらに用いる通信方法並びにそのプログラム
JP2007264727A (ja) 通信アダプタ

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110614

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110812

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: 20111018

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20111020

R150 Certificate of patent or registration of utility model

Ref document number: 4851585

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20141028

Year of fee payment: 3