(57)【要約】【課題】通信エラーとなったリクエスト信号以外の複数のリクエスト信号を速やかに受信サーバに処理させることで、通信システムの信頼性の低下を防ぐことが可能な送信サーバ、送信サーバの通信方法、及び、送信サーバの通信プログラムを提供すること。【解決手段】一実施の形態によれば、送信サーバ１１の通信方法は、リクエスト信号の受信を拒否した場合に通信エラー情報を非同期で送信サーバ１１に通知したのちセッションを切断する受信サーバ１２、に対し、複数のリクエスト信号を通知し、複数のリクエスト信号の何れかのリクエスト信号の受信を拒否したことを示す通信エラー情報を受信サーバ１２から受け取った場合に、セッションを再接続して、複数のリクエスト信号のうちセッション切断後に通知したリクエスト信号を再通知する。【選択図】図３
2016031633.tif 000002
【特許請求の範囲】
【請求項１】
リクエスト信号の受信を拒否した場合に通信エラー情報を非同期で送信サーバに通知したのちセッションを切断する受信サーバ、に対し、複数のリクエスト信号を通知するステップと、
前記複数のリクエスト信号の何れかのリクエスト信号の受信を拒否したことを示す通信エラー情報を前記受信サーバから受け取った場合に、セッションを再接続して、前記複数のリクエスト信号のうちセッション切断後に通知したリクエスト信号を再通知するステップと、を備えた、送信サーバの通信方法。
【請求項２】
前記再通知するステップでは、
前記複数のリクエスト信号の何れかのリクエスト信号の受信を拒否したことを示す前記通信エラー情報を前記受信サーバから受け取った場合に、当該通信エラー情報に含まれるリクエスト信号の情報と、前記複数のリクエスト信号の情報と、から、前記複数のリクエスト信号のうちセッション切断後に通知したリクエスト信号を抽出し、
セッションを再接続し、
抽出された前記セッション切断後に通知したリクエスト信号を再通知する、請求項１に記載の送信サーバの通信方法。
【請求項３】
リクエスト信号の受信を拒否した場合に通信エラー情報を非同期で送信サーバに通知したのちセッションを切断する受信サーバ、に対し、複数のリクエスト信号を通知する送信部と、
前記受信サーバにより前記複数のリクエスト信号の何れかのリクエスト信号の受信が拒否されたことを示す通信エラー情報、を受信する受信部と、
前記複数のリクエスト信号の情報と、前記通信エラー情報に含まれるリクエスト信号の情報と、から、前記複数のリクエスト信号のうちセッション切断後に通知したリクエスト信号を抽出する抽出部と、
前記セッション切断後に通知したリクエスト信号を前記送信部に再通知させる制御部と、を備えた送信サーバ。
【請求項４】
請求項３に記載の前記送信サーバと、
前記受信サーバと、を備えた通信システム。
【請求項５】
リクエスト信号の受信を拒否した場合に通信エラー情報を非同期で送信サーバに通知したのちセッションを切断する受信サーバ、に対し、複数のリクエスト信号を通知する通知処理と、
前記複数のリクエスト信号の何れかのリクエスト信号の受信を拒否したことを示す通信エラー情報を前記受信サーバから受け取った場合に、セッションを再接続して、前記複数のリクエスト信号のうちセッション切断後に通知したリクエスト信号を再通知する再通知処理と、をコンピュータに実行させる送信サーバの通信プログラム。
【請求項６】
前記再通知処理は、
前記複数のリクエスト信号の何れかのリクエスト信号の受信を拒否したことを示す前記通信エラー情報を前記受信サーバから受け取った場合に、当該通信エラー情報に含まれるリクエスト信号の情報と、前記複数のリクエスト信号の情報と、から、前記複数のリクエスト信号のうちセッション切断後に通知したリクエスト信号を抽出する処理と、
セッションを再接続する処理と、
抽出された前記セッション切断後に通知したリクエスト信号を再通知する処理と、を含む、請求項５に記載の送信サーバの通信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、送信サーバ、送信サーバの通信方法、及び、送信サーバの通信プログラムに関する。
【背景技術】
【０００２】
スマートフォン等の普及に伴い、ＯＴＴ(Over The Top)プレーヤ等の第３者によるクラウドサービスの提供が増加傾向にある。それに伴い、自社で構築されたサーバ（送信サーバ）と、第３者により構築されたクラウド上のサーバ（受信サーバ）と、を連携することで実現されるエンドユーザ向けサービスの提供も増加傾向にある。
【０００３】
ところで、受信サーバの中には、例えばＡＰＮＳ(Apple Push Noticifaction Service)で用いられる受信サーバのように、送信サーバから通知されたリクエスト信号に不正がある場合、そのリクエスト信号の受信を拒否し、それに関する通信エラー情報を非同期で送信サーバに通知した後、セッションを切断するものがある。ＡＰＮＳに関する記載は、例えば特許文献１等に開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特表２０１３−５３１９０４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上記したように、受信サーバの中には、送信サーバから通知されたリクエスト信号に不正がある場合、通信エラー情報を非同期で送信サーバに通知した後、セッションを切断するものがある。この受信サーバを備えた通信システムには、以下のような問題がある。
【０００６】
図８は、上記通信システムによる通信方法を示すシーケンス図である。
図８に示す通信方法では、送信サーバは、セッションを接続した後、複数のリクエスト信号Ａ，Ｂ，Ｃ，Ｄを順に受信サーバに通知する。ここで、受信サーバは、不正が無いリクエスト信号Ａを受信するが、不正があるリクエスト信号Ｂの受信を拒否する。そして、受信サーバは、リクエスト信号Ｂの受信が拒否されたことを示す通信エラー情報を非同期で送信サーバに通知した後、セッションを切断する。そのため、受信サーバは、リクエスト信号Ｂの後に送信サーバから通知されたリクエスト信号Ｃ，Ｄの受信を行わない。
【０００７】
このように、この受信サーバは、送信サーバから通知される複数のリクエスト信号のうち何れかのリクエスト信号に不正があった場合、当該リクエスト信号の受信を拒否するだけでなく、その後に送信サーバから通知されるすべてのリクエスト信号の受信を行わない。そのため、この受信サーバを備えた通信システムは、通信エラーとなったリクエスト信号以外の複数のリクエスト信号を速やかに処理することができず、その結果、通信システムの信頼性を低下させてしまうという問題があった。送信サーバ及び受信サーバが大規模サーバである場合、この問題は顕著になる。
【０００８】
本発明は、このような問題点を解決するためになされたものであり、通信エラーとなったリクエスト信号以外の複数のリクエスト信号を速やかに受信サーバに処理させることで、通信システムの信頼性の低下を防ぐことが可能な送信サーバ、送信サーバの通信方法、及び、送信サーバの通信プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
一実施の形態によれば、送信サーバは、リクエスト信号の受信を拒否した場合に通信エラー情報を非同期で送信サーバに通知したのちセッションを切断する受信サーバ、に対し、複数のリクエスト信号を通知する送信部と、前記受信サーバにより前記複数のリクエスト信号の何れかのリクエスト信号の受信が拒否されたことを示す通信エラー情報、を受信する受信部と、前記複数のリクエスト信号の情報と、前記通信エラー情報に含まれるリクエスト信号の情報と、から、前記複数のリクエスト信号のうちセッション切断後に通知したリクエスト信号を抽出する抽出部と、前記セッション切断後に通知したリクエスト信号を前記送信部に再通知させる制御部と、を備える。
【００１０】
一実施の形態によれば、送信サーバの通信方法は、リクエスト信号の受信を拒否した場合に通信エラー情報を非同期で送信サーバに通知したのちセッションを切断する受信サーバ、に対し、複数のリクエスト信号を通知するステップと、前記複数のリクエスト信号の何れかのリクエスト信号の受信を拒否したことを示す通信エラー情報を前記受信サーバから受け取った場合に、セッションを再接続して、前記複数のリクエスト信号のうちセッション切断後に通知したリクエスト信号を再通知するステップと、を備える。
【００１１】
一実施の形態によれば、送信サーバの通信プログラムは、リクエスト信号の受信を拒否した場合に通信エラー情報を非同期で送信サーバに通知したのちセッションを切断する受信サーバ、に対し、複数のリクエスト信号を通知する通知処理と、前記複数のリクエスト信号の何れかのリクエスト信号の受信を拒否したことを示す通信エラー情報を前記受信サーバから受け取った場合に、セッションを再接続して、前記複数のリクエスト信号のうちセッション切断後に通知したリクエスト信号を再通知する再通知処理と、をコンピュータに実行させる。
【発明の効果】
【００１２】
前記一実施の形態によれば、通信エラーとなったリクエスト信号以外の複数のリクエスト信号を速やかに受信サーバに処理させることで、通信システムの信頼性の低下を防ぐことが可能な送信サーバ、送信サーバの通信方法、及び、送信サーバの通信プログラムを提供することができる。
【図面の簡単な説明】
【００１３】
【図１】実施の形態１に係る通信システムを示すブロック図である。
【図２】実施の形態１に係る送信サーバの概略を示すブロック図である。
【図３】実施の形態１に係る通信方法を示すシーケンス図である。
【図４】実施の形態１に係る送信サーバのハードウエア構成の一例を示すブロック図である。
【図５】実施の形態１に係る通信システムの適用事例を説明するための図である。
【図６】実施の形態１に係る通信方法の詳細を示すシーケンス図である。
【図７】実施の形態１に係る通信方法の詳細を示すシーケンス図である。
【図８】発明に至る前の構想に係る通信方法を示すシーケンス図である。
【発明を実施するための形態】
【００１４】
以下、図面を参照しつつ、実施の形態について説明する。なお、図面は簡略的なものであるから、この図面の記載を根拠として実施の形態の技術的範囲を狭く解釈してはならない。また、同一の要素には、同一の符号を付し、重複する説明は省略する。
【００１５】
以下の実施の形態においては便宜上その必要があるときは、複数のセクションまたは実施の形態に分割して説明するが、特に明示した場合を除き、それらはお互いに無関係なものではなく、一方は他方の一部または全部の変形例、応用例、詳細説明、補足説明等の関係にある。また、以下の実施の形態において、要素の数等（個数、数値、量、範囲等を含む）に言及する場合、特に明示した場合および原理的に明らかに特定の数に限定される場合等を除き、その特定の数に限定されるものではなく、特定の数以上でも以下でもよい。
【００１６】
さらに、以下の実施の形態において、その構成要素（動作ステップ等も含む）は、特に明示した場合および原理的に明らかに必須であると考えられる場合等を除き、必ずしも必須のものではない。同様に、以下の実施の形態において、構成要素等の形状、位置関係等に言及するときは、特に明示した場合および原理的に明らかにそうでないと考えられる場合等を除き、実質的にその形状等に近似または類似するもの等を含むものとする。このことは、上記数等（個数、数値、量、範囲等を含む）についても同様である。
【００１７】
＜実施の形態１＞
図１は、実施の形態１にかかる通信システム１を示すブロック図である。
【００１８】
図１に示すように、通信システム１は、送信サーバ１１と受信サーバ１２とを備える。送信サーバ１１は、例えば自社で構築されたサーバであって、同一セッションにて複数のリクエスト信号を受信サーバ１２に通知することが可能である。受信サーバ１２は、例えば第３者等により構築されたクラウド上のサーバであって、送信サーバ１１からの複数のリクエスト信号を受信して所定の処理を実行する。ここで、受信サーバ１２は、複数のリクエスト信号の何れかのリクエスト信号に不正がある場合、そのリクエスト信号の受信を拒否し、それに関する通信エラー情報を非同期で送信サーバ１１に通知した後、セッションを切断する。
【００１９】
なお、通信システム１にて通信エラーを生じさせる要因としては、主に次の３つがある。１つ目は、送信サーバ１１の障害によるものである。２つ目は、送信サーバ１１と受信サーバ１２との間を結ぶ信号経路の障害によるものである。３つ目は、受信サーバ１２の障害によるものである。
【００２０】
例えば、送信サーバ１１の障害により通信エラーが発生した場合には、送信サーバ１１の通信状態を監視し、送信サーバ１１復旧後にリクエスト信号を再送することで対応可能である。また、送信サーバ１１と受信サーバ１２との間を結ぶ信号経路の障害により通信エラーが発生した場合には、送信サーバ１１側から当該信号経路の状態を監視し、信号経路復旧後にリクエスト信号を再送することで対応可能である。また、通常ブラックボックス化されている受信サーバ１２の障害により通信エラーが発生した場合でも、受信サーバ１２が送信サーバ１１に同期して通信エラー情報を通知する構成であれば、受信サーバ１２復旧後にリクエスト信号を再送することで対応可能である。
【００２１】
しかしながら、受信サーバ１２は、通信エラー情報を非同期で送信サーバ１１に返した後、セッションを切断する構成であるため、送信サーバ１１は、単にリクエスト信号を再送するだけでは当該リクエスト信号を受信サーバ１２に処理させることはできない。そこで、送信サーバ１１は、通信エラー情報を受信サーバ１２から非同期で受け取った場合に、セッションを再接続して、セッション切断後に受信サーバ１２に通知したリクエスト信号を再通知することにより、不正があるリクエスト信号以外の複数のリクエスト信号を速やかに処理させている。
【００２２】
図２は、送信サーバ１１の概略を示すブロック図である。
図２に示すように、送信サーバ１１は、制御部１１１と、送信部１１２と、受信部１１３と、抽出部１１４と、を少なくとも備える。
【００２３】
送信部１１２は、制御部１１１からの指示に基づきリクエスト信号を通知又は再通知する。受信部１１３は、受信サーバから通知された通信エラー情報を受信する。抽出部１１４は、送信部１１２が通知したリクエスト信号の情報と、通信エラー情報に含まれる受信拒否されたリクエスト信号の情報と、から、セッション切断後に受信サーバ１２に通知したリクエスト信号を抽出する。制御部１１１は、抽出部１１４の検出結果を受け取ると、送信部１１２に対し、セッション切断後に受信サーバ１２に通知したリクエスト信号を再通知するように指示する。
【００２４】
図３は、通信システム１による通信方法を示すシーケンス図である。
図３に示すように、まず、送信サーバ１１は、セッションを接続した後、送信スレッドにて、複数のリクエスト信号Ａ，Ｂ，Ｃ，Ｄを順に受信サーバ１２に通知する。本例では、リクエスト信号Ａ，Ｃ，Ｄに不正がなく、リクエスト信号Ｂに不正があるものとする。この場合、受信サーバ１２は、不正がないリクエスト信号Ａを受信するが、不正があるリクエスト信号Ｂの受信を拒否する。そして、受信サーバ１２は、リクエスト信号Ｂの受信が拒否されたことを示す通信エラー情報を非同期で送信サーバ１１に通知した後、セッションを切断する。そのため、受信サーバ１２は、リクエスト信号Ｂの後に送信サーバ１１から通知されたリクエスト信号Ｃ，Ｄの受信を行わない。
【００２５】
送信サーバ１１は、通信エラー情報を受け取ると、送信スレッドにて受信サーバ１２に通知したリクエスト信号の情報と、通信エラー情報に含まれる受信拒否されたリクエスト信号の情報と、に基づいて、セッション切断後に受信サーバ１２に通知したリクエスト信号を抽出する。具体的には、送信サーバ１１は、通信エラー情報を受け取ると、送信スレッドにて受信サーバ１２に通知したリクエスト信号Ａ，Ｂ，Ｃ，Ｄの情報と、受信拒否されたリクエスト信号Ｂの情報と、から、セッション切断後に受信サーバ１２に通知したリクエスト信号Ｃ，Ｄを抽出する。
【００２６】
そして、送信サーバ１１は、セッションを再接続した後、再送スレッドにて、セッション切断後に受信サーバ１２に通知したリクエスト信号Ｃ，Ｄを受信サーバ１２に再通知する。それにより、不正があるリクエスト信号Ｂ以外のリクエスト信号Ａ，Ｃ，Ｄを速やかに受信サーバ１２に処理させることができるため、通信システム１の信頼性の低下を防ぐことができる。
【００２７】
（送信サーバ１１のハードウエア構成）
なお、送信サーバ１１は、例えば、汎用的なコンピュータシステムにより実現可能である。以下、図４を用いて簡単に説明する。
【００２８】
図４は、送信サーバ１１のハードウエア構成の一例を示すブロック図である。コンピュータ１００は、例えば、制御装置であるＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１０１と、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）１０２と、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）１０３と、外部とのインターフェースであるＩＦ（Ｉｎｔｅｒ  Ｆａｃｅ）１０４と、不揮発性記憶装置の一例であるＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）１０５と、を備える。さらに、コンピュータ１００は、その他図示しない構成として、キーボードやマウス等の入力装置やディスプレイ等の表示装置を備えていても良い。
【００２９】
ＨＤＤ１０５には、ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）（不図示）と、送信処理プログラム（通信プログラム）１０６と、が記憶されている。送信処理プログラム１０６は、本実施の形態に係るリクエスト信号通知処理が実装されたコンピュータプログラムである。
【００３０】
ＣＰＵ１０１は、コンピュータ１００における各種処理、ＲＡＭ１０２，ＲＯＭ１０３，ＩＦ１０４及びＨＤＤ１０５へのアクセス等を制御する。コンピュータ１００は、ＣＰＵ１０１がＨＤＤ１０５に記憶されたＯＳ及び送信処理プログラム１０６を読み込み、実行する。これにより、コンピュータ１００は、本実施の形態にかかる送信サーバ１１を実現する。
【００３１】
（通信システム１の適用事例）
続いて、通信システム１の適用事例について説明する。
【００３２】
図５は、通信システム１の適用事例を説明するための図である。
図５に示すように、通信システム１は、例えば、送信サーバ１１からＡｐｐｌｅ製の受信サーバ１２にリクエスト信号をプッシュ通知するＡＰＮＳ(Apple Push Notification Service)に適用される。
【００３３】
ＡＰＮＳでは、受信サーバ１２は、送信サーバ１１から通知されるリクエスト信号に不正がある場合、当該リクエスト信号の受信を拒否し、それに関する通信エラー情報を非同期で送信サーバ１１に通知した後、セッションを切断する。
【００３４】
図６及び図７は、ＡＰＮＳに適用された通信システム１による通信方法の詳細を示すシーケンス図である。なお、図６は、正常時の通信方法を示し、図７は、通信エラー発生時の通信方法を示している。
【００３５】
図６に示すように、正常時では、送信サーバ１１は、プッシュ通知指示スレッドにて、プッシュ通知の指示、及び、データベースの状態更新を行う。本例では、送信サーバ１１は、リクエスト信号Ａ＿１〜Ａ＿ｎ，Ｂ＿１〜Ｂ＿ｎ，Ｃ＿１〜Ｃ＿ｎ，Ｄ＿１〜Ｄ＿ｎ（ｎは自然数）のプッシュ通知を指示するとともに、データベースに格納された各リクエスト信号の状態情報を「処理前」から「処理中」に更新する。
【００３６】
その後、送信サーバ１１は、プッシュ管理スレッドにて、複数のプッシュ通知スレッドのそれぞれに対して複数のリクエスト信号Ａ＿１〜Ａ＿ｎ，Ｂ＿１〜Ｂ＿ｎ，Ｃ＿１〜Ｃ＿ｎ，Ｄ＿１〜Ｄ＿ｎを割り当てる。
【００３７】
その後、送信サーバ１１は、複数のプッシュ通知スレッドにて、リクエスト信号Ａ＿１〜Ａ＿ｎ，Ｂ＿１〜Ｂ＿ｎ，Ｃ＿１〜Ｃ＿ｎ，Ｄ＿１〜Ｄ＿ｎのプッシュ通知を行うとともに、データベースに格納された各リクエスト信号の状態情報を「処理中」から「処理済」に更新する。なお、送信サーバ１１がダウンしたり、ネットワーク障害により通信エラーが発生したりした場合には、送信サーバ１１は、データベースに格納された各リクエスト信号の状態情報に基づいて、未通知のリクエスト信号の再通知を行う。
【００３８】
ここで、図７に示すように、例えばリクエスト信号Ｂ＿１に不正があった場合、受信サーバ１２は、リクエスト信号Ｂ＿１の受信を拒否し、それに関する通信エラー情報を非同期で送信サーバ１１に通知した後、セッションを切断する。
【００３９】
このとき、送信サーバ１１は、受信サーバ１２からの通信エラー情報を受け取り、データベースに格納されたリクエスト信号Ｂ＿１の状態情報を「処理済」から「エラー」に更新するとともに、セッション切断後に通知されたリクエスト信号Ｂ＿２〜Ｂ＿ｎの状態情報を「処理済」から「要再送」に更新する。
【００４０】
その後、送信サーバ１１は、プッシュ管理スレッドにて、データベースに格納された各リクエスト信号の状態情報に基づいて、要再送となっているリクエスト信号Ｂ＿２〜Ｂ＿ｎを対応するプッシュ通知スレッドに割り当てる。
【００４１】
その後、送信サーバ１１は、プッシュ通知スレッドにて、リクエスト信号Ｂ＿２〜Ｂ＿ｎのプッシュ通知を行うとともに、データベースに格納されたリクエスト信号Ｂ＿２〜Ｂ＿ｎの状態情報を「要再送」から「再送済」に更新する。これにより、プッシュ配信の処理が完了する。
【００４２】
以上のように、本実施の形態に係る送信サーバは、通信エラー情報を通知したのちセッションを切断する受信サーバから通信エラー情報を受け取った場合に、セッションを再接続し、セッション切断後に受信サーバに通知したリクエスト信号を再通知する。それにより、通信エラーとなったリクエスト信号以外の複数のリクエスト信号を速やかに受信サーバに処理させることができるため、通信システムの信頼性の低下を防ぐことができる。
【００４３】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【符号の説明】
【００４４】
１  通信システム
１１  送信サーバ
１２  受信サーバ
１００  コンピュータ
１０１  ＣＰＵ
１０２  ＲＡＭ
１０３  ＲＯＭ
１０４  ＩＦ
１０５  ＨＤＤ
１０６  送信処理プログラム
１１１  制御部
１１２  送信部
１１３  受信部
１１４  抽出部
【図１】
2016031633.tif 000003
【図２】
2016031633.tif 000004
【図３】
2016031633.tif 000005
【図４】
2016031633.tif 000006
【図５】
2016031633.tif 000007
【図６】
2016031633.tif 000008
【図７】
2016031633.tif 000009
【図８】
2016031633.tif 000010