JP2015046706A - 中継プログラム、中継装置、及び中継方法 - Google Patents

Abstract

【課題】同じネットワーク内のクライアント機器に代わって、外部ネットワークに配置されたサーバに対してパケット再送信の要求を可能にする。【解決手段】中継プログラムは、ネットワークを介して接続される第１の情報処理装置から第１の通信方式で送信されたデータを受信し、受信したデータを第２の通信方式で第２の情報処理装置に送信し、第１の情報処理装置との通信、または、第２の情報処理装置との通信におけるエラーを検出し、エラーを検出したときに、エラーに係るデータの再送信を第１の情報処理装置に要求する処理をコンピュータに実行させる。【選択図】図７

Description

本発明は、中継プログラム、中継装置、及び中継方法に関する。

従来技術として、例えば、自身の使用に加えて他への貸し出しを可能とするだけの計算資源を持つ情報機器と、自身で使用されるのに足るだけの計算資源を持つ情報機器とが混在して接続される、範囲を限定されて構成されるネットワーク上で計算資源を有効に活用するようにしたデータ処理装置がある。

上記データ処理装置は、範囲を限定されて構成されるネットワークに接続する接続手段と、上記ネットワークに接続されたクライアント機器に対して計算資源を貸し出す計算資源貸し出し手段と、上記クライアント機器の物理的状態を通知する状態通知手段とを備える。

また、上記データ処理装置は、上記状態通知手段の通知に基づき、上記クライアント機器の物理的状態がクライアント機器が上記ネットワークに接続されていない状態であるとされれば、該クライアント機器へのサービスを、上記計算資源貸し出し手段により該クライアント機器に上記貸し出された上記計算資源に対して提供する（例えば、「特許文献１」参照）。

特開２００２−２９７５５９号公報

従来技術のデータ処理装置では、家庭内の外側に配置されたサーバに記憶されたデータをクライアント機器にダウンロードする場合は、データ処理装置にデータを一次保存する。

しかし、例えば、通信障害に対応した再送制御機能を有するＯＳ（Operating System）を持たないクライアント機器に対し、サブネットの外側のサーバに記憶されたシステムイメージを用いて復元する作業を行う場合、前記サーバのデータを一次保存する必要があり、データ処理装置におけるシステムイメージの保存容量が大きくなる問題がある。

そこで、一側面では、同じネットワーク内のクライアント機器に代わって、外部ネットワークに配置されたサーバに対してパケット再送信の要求を可能にすることを目的とする。

一つの案では、中継プログラムは、ネットワークを介して接続される第１の情報処理装置から第１の通信方式で送信されたデータを受信し、受信した前記データを第２の通信方式で第２の情報処理装置に送信し、前記第１の情報処理装置との通信、または、前記第２の情報処理装置との通信におけるエラーを検出し、前記エラーを検出したときに、前記エラーに係るデータの再送信を前記第１の情報処理装置に要求する処理をコンピュータに実行させる。

一態様によれば、サブネットの内側のクライアント機器に代わって、サブネットの外側に配置されたサーバに対してパケット再送信の要求を可能にすることができる。

システム全体の構成を示す図 中継装置のハードウェア構成を示す図 中継アプリの機能ブロックを示す図 状態遷移テーブル（Ｔａｂｌｅ１）を示す図 状態遷移テーブル（Ｔａｂｌｅ２）を示す図 Ｔａｂｌｅ１の状態遷移を示す図 中継アプリの動作を説明するフローチャート ユーザ認証の画面を示す図 クライアントＰＣと配信イメージの選択画面を示す図 ＥＮＤパケット受信時のＴａｂｌｅ２の状態遷移を示す図 パケット受信時のＴａｂｌｅ２の状態遷移を示す図 配信サーバとの通信エラー時のＴａｂｌｅ２の状態遷移を示す図 クライアントＰＣとの通信エラー時のＴａｂｌｅ２の状態遷移を示す図 クライアントＰＣの動作を説明するフローチャート 配信サーバの動作を説明するフローチャート ネットワークの再接続画面を示す図

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本実施の形態におけるシステム全体の構成例を示す図である。

図１において、「第１の情報処理装置」としての配信システム１は、中継装置と、「第２の情報処理装置」としてのクライアントＰＣ（Personal Computer）２０と、配信サーバ３０とを備える。中継装置１０は、ネットワーク４０を介して複数のクライアントＰＣ（２０ａ、２０ｂ、２０ｃ等）と接続されている。

中継装置１０とクライアントＰＣ２０は、例えば図示しないルーターによって同一のセグメントに区切られた同一のサブネットに配置されている。したがって、中継装置１０はクライアントＰＣに対してブロードキャスト送信が可能である。

中継装置１０は、ネットワーク４０、Ｆ／Ｗ（Firewall）５０、さらにはネットワーク６０を介して、配信サーバ３０に接続される。Ｆ／Ｗ５０は、ネットワーク４０とネットワーク６０との通信を監視して所定のＩＰパケットをブロックする。ネットワーク６０は、ネットワーク４０内に構築されるサブネットの外側にあるネットワークであり、例えばインターネットである。

クライアントＰＣ２０は配信サーバ３０に記憶されたデータを送付するターゲットであり、クライアントＰＣ２０ａ、２０ｂ、２０ｃ等は、同一の機種であってもよいし、異なる機種であってもよい。

配信サーバ３０は、ネットワーク６０に接続されるサーバであり、記憶されたデータをネットワーク６０を介して接続する他の装置に対して配信する。データの配信は、例えばクラウド上に構築されるSaaS（Software as a Service）型のサービスとして実施することができる。配信サーバ３０には、例えばクライアントＰＣ２０のシステムイメージを記憶しておき、配信の要求に基づいてデータを送信する。

ここで、システムイメージとは、コンピュータの記憶部に記憶されコンピュータを動作させるためのソフトウエアの状態を表すデータである。システムイメージは、記憶部のプログラムやデータをイメージとして表したものである。例えば、記憶部に記憶されたプログラムやデータファイルをシステムイメージとして保存しておくことにより、保存されたシステムイメージからコンピュータの記憶部を保存したときの状態に復元することができる。

配信サーバ３０に記憶されるシステムイメージは、復元するクライアントＰＣ２０のシステム全体であってもよいし、特定の記憶部に記憶されたデータであってもよい。また、特定のプログラムやデータのみであってもよい。また、クライアントＰＣ２０の初期状態におけるシステムイメージであってもよいし、クライアントＰＣ２０が使用された後の所定の時点でのシステムイメージであってもよい。

クライアントＰＣ２０ａ、２０ｂ、２０ｃ等がそれぞれ別の機種である場合は、配信サーバ３０には機種毎のシステムイメージが記憶される。クライアントＰＣ２０の機種が多い場合には、システムイメージの記憶容量が膨大になる。したがって、配信サーバ３０に機種毎のシステムイメージを保存しておくことにより、例えばサブネット毎に配置される中継装置１０のすべてに機種毎のシステムイメージを保存するよりも合計の記憶容量が小さくなる。また、中継装置１０の記憶容量を小さくすることができる。

さらに、配信サーバ３０でシステムイメージを一元的に管理することにより、例えばクライアントＰＣの機種に変更があった場合やシステムイメージにバージョンアップがあった場合にシステムイメージの管理が容易になる。また、クライアントＰＣ毎に送信履歴を残すこともできるため、クライアントＰＣのバージンアップ履歴等の管理が容易になる。

次に、中継装置１０の詳細を図２から図１６を用いて説明する。

図２は、本実施の形態における中継装置１０のハードウェア構成例を示す図である。図２において、中継装置１０は、ＣＰＵ１０１、メモリ１０２、ハードディスク１０３、操作表示部１０４、ネットワーク制御部１０５、及びそれらが接続されるバス１０９を備える。

ハードディスク１０３に記憶されたプログラム及びデータは、メモリ１０２に読み出されて、ＣＰＵ１０１によって実行される。中継装置１０では、「中継プログラム」として中継アプリケーション（以下、「中継アプリ」と省略する。）がハードディスク１０３に記憶され、メモリ１０２に読み出されて、ＣＰＵ１０１によって実行される。中継アプリの詳細は、図３等を用いて後述する。

操作表示部１０４は、例えば、タッチパネル、キーボード、マウス、ディスプレイ等であり、ユーザによって入力操作がされ、又ユーザに情報を表示する機能を有する。

ネットワーク制御部１０５は、ネットワーク４０を介した通信の制御を行う。本実施形態においては、ネットワーク制御部１０５は、「第１の通信方式」と「第２の通信方式を制御する。

第１の通信方式は、トランスポート層でパケットの送受信制御を行う通信プロトコルである。第１の通信方式では、データの送受信前に通信相手とのセッションを確立して、送受信するデータを分割したパケットの制御を行う。パケットの制御としては、例えば、受信パケットが通信途中に喪失した場合には、送信側に対して、喪失したパケットのブロック番号を基に受信確認（ACK（acknowledgment））を応答して返信することにより、喪失パケットの再送を送信側に要求する。パケットの受信側においては、ｎ番目のブロックのパケットが受信できなかった場合には、ｎ−１番目のブロック番号のパケットに対応する受信確認を返信することにより、送信側はｎ番目のブロックのパケットの再送を行うことができる。第１の通信方式は、例えば、ＴＣＰ（Transmission Control Protocol）である。

一方、第２の通信方式は、トランスポート層では分割されたＩＰパケットをハンドシェイク無しの無手順にて送受信する。第２の通信方式は、例えば、ＵＤＰ（User Datagram Protocol）である。

本実施形態においてネットワーク制御部１０５は、例えばＴＦＴＰ（Trivial File Transfer Protocol）を用いて通信の制御を行う。ＴＦＴＰにおいては、第２の通信方式であるＵＤＰ上で送受信されるＩＰパケットに対してアプリケーション層にて受信確認を返信することができる。

ネットワークＩ／Ｆ１０５は、図１で説明した配信サーバ３０との通信には、第１の通信方式であるＴＣＰを使用する。これにより、ネットワーク６０を経由した通信において信頼性の高いパケット通信を行うことができる。

一方、ネットワークＩ／Ｆ１０５は、クライアントＰＣとの通信には、第２の通信方式であるＵＤＰ上で動作するＴＦＴＰを使用する。

なお、ＯＳ（Operating System）がインストールされていないクライアントＰＣであっても、ＤＨＣＰ（Dynamic Host Configuration Protocol）Discoverが可能なＢＩＯＳ（Basic Input/Output System）によって、所定のＩＰアドレスのサーバに記憶されているＴＦＴＰサーバのシステムイメージを取得することができる。クライアントＰＣ２０はＴＦＴＰサーバのシステムイメージを取得することにより、ＴＦＴＰの通信が可能となる。なお、ＴＦＴＰサーバのシステムイメージは、例えば中継装置１０に記憶させておくことができる。

次に、中継プログラムの一例として、中継アプリの機能を、図３を用いて説明する。図３は、中継アプリ１００の機能ブロックの一例を説明した図である。中継アプリ１００は、図２で説明したメモリ１０２に読み出されて、ＣＰＵ１０１によって実行される。

図３において、中継アプリ１００は、データ受信部１１１、データ送信部１１２、エラー検出部１１３、受信確認送信部１１４、状態遷移管理部１１５、マジックパケット送信部１１６、およびＴＦＴＰサーバイメージ送信部１１７を備える。

データ受信部１１１は、ネットワーク４０及びネットワーク６０を介して接続された配信サーバ３０から、例えばＴＣＰを用いて、ＩＰパケットに分割されたデータを受信する。ＴＣＰにおけるパケットは、図２のネットワーク制御部１０５によって制御されて、受信したデータはデータ受信部１１１に渡される。データ受信部１１１は、受信したデータをメモリ１０２に一時的に記憶する。

データ送信部１１２は、データ受信部１１１で受信したデータをメモリ１０２から読み出して、第２の通信方式であるＵＤＰ上で動作するＴＦＴＰを用いて、クライアントＰＣ２０に送信する。以下、第２の通信方式はＴＦＴＰも含むものとして説明する。

送信するデータは、データ受信部１１１で受信したデータの一部であっても全部であってもよい。データ受信部１１１で受信するデータがＴＣＰによるＩＰパケットの場合、パケットサイズは送信側と受信側で設定されたＭＴＵ（Maximum Transmission Unit）の値によって決まる。例えば、ＭＴＵが１５００の場合は、最大パケット長は１５００バイトとなる。

一方、データ送信部１１２が送信するデータは、ネットワーク制御部１０５によって、新たにＩＰパケットに分割されて、ＴＦＴＰにてクライアントＰＣ２０に送信される。ＴＦＴＰでは、送信するファイルを５１２バイトで分割する。データ送信部１１２はメモリ１０２から読み出したデータを第２の通信方式に適したパケットサイズに分割して送信することとなる。

エラー検出部１１３は、第１の通信方式または第２の通信方式の通信のエラーを検出する。

第１の通信方式の通信エラーは、中継装置１０と配信サーバ３０との間の通信エラーである。例えば、第１の通信方式で配信サーバ３０から受信したパケットに対する受信確認（ACK）を後述する受信確認送信部１１４が配信サーバ３０に送信し、受信確認が配信サーバ３０に届かずに喪失する場合、または、受信確認送信部１１４が送信した受信確認に対して、配信サーバ３０が送信した次の順番のパケットデータが受信できない場合である。エラー検出部１１３は、いずれの場合においても、受信確認を配信サーバ３０に送信してから所定時間以内に次の順番のパケットを受信できない場合第１の通信方式の通信エラーを検出する。

第２の通信方式の通信エラーは、中継装置１０とクライアントＰＣ２０との間の通信エラーである。例えば、データ送信部１１２が第２の通信方式で送信したパケットがクライアントＰＣ２０に届かずに喪失した場合、また、パケットを受信したクライアントＰＣからの受信確認（ACK）が中継装置に届かずに喪失した場合である。エラー検出部１１３は、いずれの場合においても、データ送信部１１２がクライアントＰＣ２０にパケットを送信指定から、所定時間以内に受信確認を受信できない場合第２の通信方式の通信エラーを検出する。

受信確認送信部１１４は、送信部１１２が第２の通信方式でクライアントＰＣ２０に送信したデータに対する受信確認をクライアントＰＣ２０から受信したときに、第１のプロトコルで配信サーバ３０に受信確認を送信する。

ここで、データ受信部１１１が第１のプロトコルで受信したｎ番目のパケットに含まれるデータをデータ送信部１１２がクライアントに送信した後にエラー検出部１１３が第２の通信方式の通信エラーを検出したときには、受信確認送信部１１４は、ｎ番目のパケットの直前に受信した、ｎ−１番目のパケットに対する受信確認を配信サーバ３０に送信する。ｎ−１番目のパケットの受信確認を受信した配信サーバ３０は、ｎ番目のパケットを中継装置１０に再送する。

中継アプリ１００は、再送されたｎ番目のパケットのデータを第２の通信方式でクライアントＰＣ２０に再送することにより、クライアントＰＣ２０に代わってネットワーク６０を介して配信サーバ３０との第１の通信方式によるｎ番目のパケットの再送要求を行うことができる。

一方、データ受信部１１１が第１の通信方式でｎ番目のパケットを受信し、受信確認送信部１１４が配信サーバ３０にｎ番目のパケットに対する受信確認を送信し、その後にエラー検出部１１３が第１の通信方式の通信エラーを検出したとする。このとき、受信確認送信部１１４は、ｎ番目のパケットに対する受信確認を再送信する。ｎ番目のパケットの受信確認を受信した配信サーバ３０は、ｎ＋１番目のパケットを中継装置１０に再送する。

つまり、中継アプリ１００は、クライアントＰＣ２０に代わって、第１の通信方式によるｎ＋１番目のパケットの再送信要求を行うことができる。

中継アプリ１００が、パケットデータの送受信を中継して、クライアントＰＣ２０に代わって配信サーバ３０に対してパケットの再送信を要求することにより、中継装置１０は記憶容量が大きいシステムイメージを内部に保存する必要がなくなる。なお、中継装置１０は、パケットデータの中継時に一時的にパケットデータの保存を行うが、システムイメージ全部を保存する場合に比べて、必要な記憶容量を小さくすることができる。

状態遷移管理部１１５は、後述する状態遷移テーブルの管理を行う。状態遷移管理部１１５は、第１の通信方式による通信状態の遷移と第２の通信方式による通信状態の遷移を状態遷移テーブルに記録していく。受信確認送信部１１４は状態遷移テーブルを参照してパケットの再送要求を行う。

マジックパケット送信部１１６は、ネットワーク４０に接続された同一サブネット内にあるクライアントＰＣ２０に対して、リモートで電源をＯＮにするＷＯＬ（Wake On LAN）に使用するマジックパケットを送信する。マジックパケットは、ＷＯＬの対象となるクライアントＰＣのＭＡＣアドレスと、所定のＷＯＬコードを含むパケットを、例えばＵＤＰによってブロードキャストする。クライアントＰＣの図示しないネットワークＩ／Ｆ（Interface）は、自機のＭＡＣアドレスを監視して、クライアントＰＣ２０の図示しないＢＩＯＳがＷＯＬコードに基づき自機の電源をＯＮにする。

マジックパケットには、ＴＦＴＰサーバのイメージを送信する、中継装置１０のＩＰアドレスが記載されている。クライアントＰＣ２０のＢＩＯＳは、電源がＯＮになった後にマジックパケットによって通知されたＩＰアドレスの中継装置に対してＴＦＴＰサーバイメージの送信を要求する。

ＴＦＴＰサーバイメージ送信部１１７は、マジックパケット送信部１１６によってリモートで電源がＯＮとなったクライアントＰＣ２０からの要求に対して、ＴＦＴＰサーバのプログラムイメージを送信する。ＴＦＴＰサーバのプログラムイメージを受信したクライアントＰＣ２０のＢＩＯＳは、受信したイメージを内部のメモリに記憶することによって、ＴＦＴＰの通信が可能になる。したがって、例えばＯＳがインストールされていないクライアントＰＣであっても、ＴＦＴＰの通信が可能となる。

本実施形態において中継アプリ１００の各機能は、それぞれの機能ブロックをＣＰＵ１０１によって実行されるソフトウエアとして説明した。ただし、中継アプリ１００の機能の一部を、ハードウェアやミドルウエアによって実装することもできる。

次に、中継装置１０の状態遷移管理部１１５が管理する状態遷移テーブルの詳細を図４及び図５を用いて説明する。図４は、中継装置１０の内部状態を管理する状態遷移テーブル（Ｔａｂｌｅ１）の一例を説明する図である。また、図５は、パケット送受信の状態を管理する状態遷移テーブル（Ｔａｂｌｅ２）の一例を説明する図である。

図４において、Ｔａｂｌｅ１は、中継装置１０と配信サーバ３０とのセッションが確立されて、クライアントＰＣ２０との間でＴＦＴＰの通信が可能となった時点でクライアントＰＣ毎に作成される。Ｔａｂｌｅ１は、「Server IP」、「Target IP」、「Target MAC」、「Status」、及び「Session No」の状態情報を有する。

「Server IP」は、配信サーバ３０のＩＰアドレスである。配信サーバ３０のＩＰアドレスは、予め中継アプリに設定しておいてもよい。

「Target IP」は、ターゲットとなるクライアントＰＣのＩＰアドレスである。ＤＨＣＰ環境においては、クライアントＰＣ２０のＢＩＯＳは、ＷＯＬで電源がＯＮされた後にＤＨＣＰサーバに対してＩＰアドレスを要求して、ＤＨＣＰサーバからＩＰアドレスが通知される。クライアントＰＣ２０のＢＩＯＳは、ＴＦＴＰサーバイメージの取得をする際に、自身のＩＰアドレスを中継装置に通知する。状態遷移管理部１１５は、通知されたクライアントＰＣのＩＰアドレスを「Target IP」に記録する。

「Target MAC」は、ターゲットとなるクライアントＰＣ２０のＭＡＣアドレスである。ＭＡＣアドレスの設定は、操作表示部１０４からユーザが設定入力可能である。

「Status」は、中継アプリ１００のステータスを表す。例えば、「ON」は中継アプリが起動状態であることを示す。「OFF」はアプリが起動していない、又は終了している状態を示す。また、「Pend」は、エラー検出部１１３によって通信プロトコルのエラーが検出されて通信が中断し、通信の再接続待ち状態であることを示す。

「Session No」は、配信サーバ３０とのセッションが確立した場合の認識番号を示す。配信サーバ３０は、ネットワーク６０を経由して複数の中継装置と通信することができるため、配信サーバ３０との通信にはセッション確立時に配信サーバ３０から割り振られる識別番号が利用される。

図５において、Ｔａｂｌｅ２は、Ｔａｂｌｅ１の「Session No」の認識番号で表されるセッションに対応して、配信サーバ３０から第１の通信方式で受信するそれぞれのパケットに対応してパケット毎に作成される。Ｔａｂｌｅ２は、「Block_No」、「Recv_SV」、「Send_TG」、「Recv_TG」、「Send_SV」、「End_Flag」、「RetryCount1」、及び「RetryCount2」の状態情報を有する。

「Block_No」は、第１の通信方式において分割されたパケットの順番を表すブロック番号である。パケットのブロック数は、送信されるデータのサイズとＭＴＵの大きさによって変動する。

「Recv_SV」は、中継装置１０が配信サーバ３０からパケットデータを受信したことを示すフラグである。ＯＮでパケット受信、ＯＦＦで未受信を示す。

「Send_TG」は、中継装置１０がクライアントＰＣ２０に第２の通信方式によってデータを送信したことを示すフラグである。ＯＮで送信済み、ＯＦＦで未送信を表す。

「Recv_TG」は、中継装置１０がクライアントＰＣから第２の通信方式によるデータの受信確認（ACK）を受けたことを示すフラグである。ＯＮで受信済み、ＯＦＦで未受信を表す。
「Send_SV」は、中継装置１０が配信サーバ３０へ第１の通信方式で受信確認（ACK）を送信したことを示すフラグである。ＯＮで送信済み、ＯＦＦで未送信を表す。

「End_Flag」は、受信したパケットが、分割された最終パケットであることを示すフラグである。ＯＮで最終パケット、ＯＦＦで最終パケット以外を表す。

「RetryCount1」は、配信サーバ３０へ第１の通信方式で受信確認（ACK）を送信後、次のパケットを受信するまでのタイマ値であり、例えばインクリメントされる整数が入力される。

「RetryCount2」は、中継装置１０がクライアントＰＣ２０に第２の通信方式でデータを送信後、クライアントＰＣから受信確認（ACK）を受信するまでのタイマ値であり、例えばインクリメントされる整数が入力される。

次に、図４で説明したＴａｂｌｅ１の中継アプリ１００の状態による遷移を、図６を用いて説明する。図６は、Ｔａｂｌｅ１の状態遷移の一例を説明する図である。

図６において、（ａ）から（ｄ）は、Ｔａｂｌｅ１の状態を示す。

（ａ）は、中継アプリ１００が起動されたときのＴａｂｌｅ１の状態であり、初期状態を表している。「Server IP」、「Target IP」、「Target MAC」、「Status」、及び「Session No」の値は、それぞれ、「NULL」である。

（ｂ）は、中継アプリ１００が配信サーバ３０と接続してセッションを確立した後のＴａｂｌｅ１の状態を示す。「Server IP」には、配信サーバ３０のＩＰアドレス「10.50.x.x」が入り、「Target IP」及び「Target MAC」には、クライアントＰＣ２０のＩＰアドレスとＭＡＣアドレス「192.168.x.x」及び「aa.bb.cc.dd」が入る。「Status」はアプリが起動しているためＯＮとなり、「*Session No」は、「１」が入力される。

（ｂ）はクライアントＰＣ２０の数ｎに対してそれぞれ作成される。（ａ）はＴａｂｌｅ１の「型」であるとすれば、（ｂ）は、（ａ）と１：ｎの関係を有する「実態」を表している。

（ｃ）は、例えば配信サーバ３０との接続が中断して第１の通信方式による通信がエラーとなった場合のＴａｂｌｅ１の状態を示す。（ｃ）では（ｂ）の状態から「Status」が「Pend」に変わる。

（ｄ）は、クライアントＰＣ２０にデータ転送が完了した状態を示す。「Target IP」が「NULL」となり、「Status」が「OFF」になる。但し、配信サーバ３０との通信は切れておらずセッションは確立したままなので「Session No」の値はそのままとなる。

中継アプリ１００が終了するとＴａｂｌｅ１は消滅する。

次に、中継アプリ１００の動作の詳細を、図７を用いて説明する。図７は、中継アプリ１００の動作の一例を説明するフローチャートである。

図７において、中継アプリ１００は、ターゲットとなるクライアントＰＣと、第２の通信方式であるＴＦＴＰで接続する（Ｓ１１）。ＴＦＴＰはトランスポート層ではＵＤＰが使用される。

次に、配信サーバ３０と第１の通信方式であるＴＣＰで接続する（Ｓ１２）。ＴＣＰの上の階層で動作する通信プロトコルは、例えばＨＴＴＰが使用される。配信サーバ３０とのセッションが確立された場合には、例えばＳＳＬ（Secure Sockets Layer）で通信を暗号化してもよい。また、配信サーバ３０側にＳＳＬ−ＶＰＮ（Virtual Private Network）機能を有している場合には、中継装置１０側でＳＳＬに対応可能であればＳＳＬ−ＶＰＮ通信を行ってシステムイメージの送受信を行ってもよい。

次に、配信サーバ３０に対するユーザ認証と、ターゲットであるクライアントＰＣに送信するデータの選択を行う（Ｓ１３）。配信サーバ３０は、中継装置１０に対してＷｅｂが面によるユーザ認証のＵＩ（User Interface）を提供する。

図８は、中継装置１０の操作表示部１０４に表示されるユーザ認証の画面の一例を示す図である。図８において、配信サーバ３０は、システムイメージを配信するサービスのログイン画面を表示するＷｅｂページを提供する。ログイン画面では、ユーザＩＤとパスワードが入力される。

図９は、中継アプリ１００が提供するクライアントＰＣと配信イメージの選択画面の一例を示す図である。図９において、ユーザは、クライアントＰＣのＭＡＣアドレスと配信する配信イメージの選択を行う。配信イメージの選択は、リストボックスによって行う。配信イメージの情報は、接続した配信サーバ３０から送信される。

ユーザが「新規」のボタンを押すことにより、Ｔａｂｌｅ１は図６（ｂ）で説明した状態となる。本実施形態では、選択できる配信イメージとして、クライアントＰＣ２０を復元する、システムイメージを選択できるようにしている。但し、配信イメージは、他のデータであってもよい。

図７に戻り、中継アプリ１００は、配信サーバ３０からパケットデータを受信すると（Ｓ１４）、受信したパケットがＥＮＤパケットであるか否かを判断する（Ｓ１７）。なお、受信したパケットがＥＮＤパケットであるか否かは、パケットのヘッダの「フラグ」フィールをチェックすることにより行うことができる。受信したパケットがＥＮＤパケットであった場合（Ｓ１５でＹＥＳ）、図５で説明した「End_Flag」をＯＮにする。

受信したパケットがＥＮＤパケットであった場合のＴａｂｌｅ２の遷移を、図１０と合わせて説明する。図１０は、ＥＮＤパケット受信時のＴａｂｌｅ２の状態遷移の一例を示す図である。

図１０において、（ａ）は、図５で説明したＴａｂｌｅ２の初期状態であり、それぞれの状態には、「OFF」又は「NULL」が入力されている。（ｂ）はステップＳ１５でＹＥＳの場合のＴａｂｌｅ２の状態を示す。（ｂ）において、「Block_No」は「1」、「Recv_SV」は「ON」、また「End_Flag」は「ON」になる。

図７に戻り、受信したパケットがＥＮＤパケットでない場合（Ｓ１５でＮＯ）、「End_Flag」は「OFF」のままである。

受信したパケットがＥＮＤパケットでない場合、つまり次のパケットが存在する場合のＴａｂｌｅ２の遷移を、図１１と合わせて説明する。図１１は、ＥＮＤパケット受信時のＴａｂｌｅ２の状態遷移の一例を示す図である。

図１０において、（ａ）は、図５で説明したＴａｂｌｅ２の初期状態であり、それぞれの状態には、「OFF」又は「NULL」が入力されている。

（ｂ）はステップＳ１５でＹＥＳの場合のＴａｂｌｅ２の状態を示す。（ｂ）において、「Block_No」は「1」、「Recv_SV」は「ON」となるが、「End_Flag」は「OFF」のままである。

図７に戻り、タイマ１がＯＮの場合（Ｓ１７でＹＥＳ）、タイマ１をＯＦＦしすることにより、タイマ１をリセットする（Ｓ１８）。ここで、タイマ１は、配信サーバ３０との通信エラーを検出するためのタイマであり、タイマ１がＯＮの場合は、図５で説明したＴａｂｌｅ２の「RetryCount1」でカウントがされる。

次に、パケットデータをターゲットのクライアントＰＣ２０に送信して（Ｓ１９）、タイマ２をＯＮにする。パケットデータをターゲットのクライアントＰＣ２０に送信にすると、Ｔａｂｌｅ２は、図１０及び図１１の（ｃ）の状態に遷移する。（ｃ）では、「Send_TG」の状態がＯＮでなる。

次に、タイマ２が所定の閾値を超えたか否かを判断する（Ｓ２１）。タイマ２が閾値を超えていない場合（Ｓ２１でＮＯ）、ターゲットのクライアントＰＣから受信確認のACKを受信したか否かを判断し（Ｓ２２）、タイマ２が閾値超えるか、ACKを受信するまでフローチャートはループする。

ターゲットからACKを受信すると（Ｓ２２でＹＥＳ）、タイマ２をＯＦＦにする（Ｓ２３）。ACKを受信すると、Ｔａｂｌｅ２は、図１０の（ｄ）の状態に遷移して、「Recv_TG」の状態がＯＮになる。

次に配信サーバ３０に対してACKを送信する（Ｓ２４）。ACKの送信にて、Ｔａｂｌｅ２は、図１０の（ｅ）の状態に遷移して、「Send_SV」の状態がＯＮになる。

次に、ステップＳ１６で操作した「End_Flag」がＯＮか否かを判断する（Ｓ２５）。「End_Flag」がＯＮで無い場合（Ｓ２５でＮＯ）、タイマ１をＯＮにする。つまり、次のパケットが存在する場合にタイマ１による計時を開始する。

次に、タイマ１が所定の閾値を超えたか否かを判断する（Ｓ２９）。タイマ１が所定の閾値を超えていない場合は（Ｓ２９でＮＯ）、配信サーバ３０からのデータを受信したかを判断し（Ｓ３０）、タイマ１が所定の閾値を超えるか（Ｓ２９でＹＥＳ）、配信サーバ３０からのデータを受信するまでフローチャートがループする。配信サーバ３０からのデータを受信すると（Ｓ３０でＹＥＳ）、ステップＳ１４に戻り、次のパケットデータについての処理を行う。

タイマ１が所定の閾値を超えた場合（Ｓ２９でＹＥＳ）、「RetryCount1」を１インクリメントして（Ｓ３１）、Ｔａｂｌｅ２の「Block_No」に記載されたパケットの受信確認を配信サーバ３０に再送する。

タイマ１が所定の閾値を超えた場合の（Ｓ２９でＹＥＳ）、Ｔａｂｌｅ２の状態遷移を、図１２を用いて説明する。図１２は、配信サーバ３０との通信エラー発生時のＴａｂｌｅ２の状態遷移の一例を示す図である。

図１２において、（ａ）〜（ｅ）の状態は、図１１で説明した（ａ）〜（ｅ）の状態に準ずる。但し、図１２では、「Block_No」として、「n+i」が入力されているものとする。ｎはｎ番目のパケットを表し、ｉはパケットの番号を１インクリメントする変数である。（ｅ）の状態において、図７のステップ３０で配信サーバ３０から、次のパケットデータを受信した場合（Ｓ３０でＹＥＳ）、ｉはｉ＋１にインクリメントして、状態（ｂ）に遷移する。

一方、タイマ１が所定の閾値を超えた場合の（Ｓ２９でＹＥＳ）、（ｆ）の状態に遷移して、上述の通り「RetryCount1」を１インクリメントして（Ｓ３１）、ｎ＋ｉ番目のパケットに対する受信確認を配信サーバ３０に再送する。

図７に戻り、ステップ２１でタイマ２が所定の閾値を超えた場合（Ｓ２１でＹＥＳ）、「RetryCount2」を１インクリメントして（Ｓ２７）、配信サーバ３０に一つ前のブロックのパケットに対する受信確認を再送する（Ｓ２８）。ステップ２１でタイマ２が所定の閾値を超えた場合におけるＴａｂｌｅ２の状態遷移を、図１３を用いて説明する。図１３は、ＰＣとの通信エラー時のＴａｂｌｅ２の状態遷移の一例を示す図である。

図１３において、（ａ）〜（ｃ）の状態は、図１１で説明した（ａ）〜（ｃ）の状態に準ずる。但し、図１３では、「Block_No」として、「n+1」が入力されているものとする。タイマ１が所定の閾値を超えた場合、状態（ｃ）から状態（ｄ）に遷移する。「RetryCount2」には１がインクリメントされて入力される。配信サーバ３０には、「Block_No」がｎ＋１の一つ前のブロックである、「Block_No」がｎのブロックに対する受信確認を再送する。

図７に戻り、ステップＳ２５で、「End_Flag」がＯＮの場合（Ｓ２５でＹＥＳ）、次のパケットは存在しないため、配信サーバ３０との接続を切断する（Ｓ３３）。さらにターゲットであるクライアントＰＣ２０との接続を切断して（Ｓ３４）、図７のフローチャートで説明する動作を終了する。

次に、ターゲットとなるクライアントＰＣ２０の動作を、図１４を用いて説明する。図１４は、クライアントＰＣの動作の一例を説明するフローチャートである。

図１４において、クライアントＰＣ２０は、中継装置１０と接続する（Ｓ４１）。本実施形態においては、中継装置１０がターゲットとなるクライアントＰＣに対してＭＡＣアドレスを指定してマジックパケットをブロードキャストして、ＴＦＴＰサーバのシステムイメージを送信し、ＴＦＴＰによる通信を可能とする。

次に、中継装置１０は、システムイメージを取得するためのＩＰアドレスを通知して、クライアントＰＣ２０は取得したＩＰアドレスに対してＴＦＴＰによるシステムイメージの送信をリクエストする（Ｓ４２）。中継装置１０からパケットデータを受信すると（Ｓ４３）、受信したデータをディスクに書き込み（Ｓ４４）、中継装置１０に対して受信確認のACKを送信する（Ｓ４５）。

クライアントＰＣ２０は、受信したパケットがＥＮＤパケットか否かを判断して（Ｓ４６）、ＥＮＤパケットで無ければ（Ｓ４６でＮＯ）、ステップＳ４３〜Ｓ４５を繰り返す。一方、ＥＮＤパケットであれば（Ｓ４６でＹＥＳ）、中継装置１０との通信を切断し（Ｓ４７）、図１４のフローチャートで説明する動作を終了する。

次に、配信サーバ３０の動作を、図１５を用いて説明する。図１５は、配信サーバ３０の動作の一例を説明するフローチャートである。

図１５において、中継装置１０は、配信サーバ３０のＩＰアドレス又はＵＲＬ（Uniform Resource Locator）を指定して配信サーバ３０に接続する（Ｓ５１）。

次に、配信サーバ３０は、中継装置１０に対して配信サーバ３０のＷｅｂサーバによって図８で説明した認証用のＷｅｂページを提供し、また、図９で説明した送信するシステムイメージの選択用のＷｅｂページを提供する（Ｓ５２）。

配信サーバ３０は、システムイメージのパケットデータを中継装置１０に送信し（Ｓ５３）、中継装置１０から受信確認のACKを受信する（Ｓ５４）。

配信サーバ３０は、データを分割したパケットで次に送信すべきパケットがあるか否かを判断し（Ｓ５５）、送信すべきパケットがある場合は（Ｓ５５でＮＯ）、ステップＳ５３〜Ｓ５４を繰り返す。一方、送信すべきパケットが無くなれば（Ｓ５５でＹＥＳ）、中継装置１０との通信を切断し（Ｓ５６）、図１５のフローチャートで説明する動作を終了する。

なお、配信サーバ３０は、通信エラーで送信すべきパケットが残ってしまった場合、ステップＳ５２で中継装置１０に対して処理再開のＷｅｂページを提供する。図１６は、配信サーバ３０のＷｅｂサーバが提供する、ネットワークの再接続画面の一例を示す図である。

図１６において、再接続の画面には、ターゲットのクライアントＰＣのＭＡＣアドレスの入力部と配信するイメージを選択するリストボックスを有する。ユーザによって「再開」ボタンが押されたときには、配信サーバ３０が受信確認を受け取っていないパケットについてのデータから送信が再開される。一方、「新規」ボタンが押されたときには、配信イメージを最初から送信する。

本実施形態においては、配信サーバ３０が未送信のパケットの情報を管理してもよい。また、中継装置の状態遷移テーブルの情報を基に中継装置１０が配信サーバ３０に対して送信を再開すべきパケットを指定してもよい。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

以上の説明に関し、更に以下の項を開示する。
（付記１）
ネットワークを介して接続される第１の情報処理装置から第１の通信方式で送信されたデータを受信し、
受信した前記データを第２の通信方式で第２の情報処理装置に送信し、
前記第１の情報処理装置との通信、または、前記第２の情報処理装置との通信におけるエラーを検出し、
前記エラーを検出したときに、前記エラーに係るデータの再送信を前記第１の情報処理装置に要求する処理をコンピュータに実行させる中継プログラム。
（付記２）
前記第１の情報処理装置から受信したｎ番目のパケットに含まれるデータを前記第２の情報処理装置に送信した後に前記第２の情報処理装置との通信におけるエラーを検出したときに、前記ｎ番目のパケットの直前に受信したパケットに係るデータの再送信を前記第１の情報処理装置に要求する処理をコンピュータに実行させる、付記１に記載の中継プログラム。
（付記３）
受信した前記ｎ番目のパケットに対する受信確認を前記第１の情報処理装置に送信した後に前記第１の情報処理装置との通信におけるエラーを検出したときに、前記ｎ番目のパケットに係るデータの再送信を前記第１の情報処理装置に要求する処理をコンピュータに実行させる、付記１又は２に記載の中継プログラム。
（付記４）
前記第２の情報処理装置を起動するパケットを前記第２の通信方式でブロードキャストする処理をコンピュータに実行させる、付記１乃至３のいずれか一に記載の中継プログラム。
（付記５）
ネットワークを介して接続される第１の情報処理装置から第１の通信方式で送信されたデータを受信するデータ受信部と、
前記データ受信部で受信したデータを第２の通信方式で第２の情報処理装置に送信するデータ送信部と、
前記第１の情報処理装置との通信、または、前記第２の情報処理装置との通信におけるエラーを検出するエラー検出部と、
前記エラー検出部がエラーを検出したときに、前記エラーに係るデータの再送信を前記第１の情報処理装置に要求する受信確認送信部と
を備える中継装置。
（付記６）
前記受信確認送信部は、前記データ受信部が受信したｎ番目のパケットに含まれるデータを前記データ送信部が前記第２の情報処理装置に送信した後に前記エラー検出部が前記第２の情報処理装置との通信におけるエラーを検出したときに、前記ｎ番目のパケットの直前に受信したパケットに係るデータの再送信を前記第１の情報処理装置に要求する、付記５に記載の中継装置。
（付記７）
前記受信確認送信部は、前記データ受信部が受信したｎ番目のパケットに対する受信確認を前記第１の情報処理装置に送信した後に前記エラー検出部が前記第１の情報処理装置との通信におけるエラーを検出したときには、前記ｎ番目のパケットに係るデータの再送信を前記第１の情報処理装置に要求する、付記５又は６に記載の中継装置。
（付記８）
前記データ送信部は、前記第２の情報処理装置を起動するパケットを前記第２の通信方式でブロードキャストする、付記５乃至７のいずれか一に記載の中継装置。
（付記９）
ネットワークを介して接続される第１の情報処理装置から第１の通信方式で送信されたデータを受信し、
受信した前記データを第２の通信方式で第２の情報処理装置に送信し、
前記第１の情報処理装置との通信、または、前記第２の情報処理装置との通信におけるエラーを検出し、
前記エラーを検出したときに、前記エラーに係るデータの再送信を前記第１の情報処理装置に送信する処理をコンピュータが実行する中継方法。
（付記１０）
受信したｎ番目のパケットに含まれるデータを第２の情報処理装置に送信した後に前記第２の情報処理装置との通信におけるエラーを検出したときには、前記ｎ番目のパケットの直前に受信したパケットに係るデータの再送信を前記第１の情報処理装置に要求する処理をコンピュータが実行する、付記９に記載の中継方法。
（付記１１）
受信した前記ｎ番目のパケットに対する受信確認を前記第１の情報処理装置に送信した後に前記第１の情報処理装置との通信におけるエラーを検出したときには、前記ｎ番目のパケットに係るデータの再送信を前記第１の情報処理装置に要求する処理をコンピュータが実行する、付記９又は１０に記載の中継方法。
（付記１２）
前記第２の情報処理装置を起動するパケットを前記第２の通信方式でブロードキャストする処理をコンピュータが実行する、付記９乃至１１のいずれか一に記載の中継方法。

１ 配信システム
１０ 中継装置
１０１ ＣＰＵ
１０２ メモリ
１０３ ハードディスク
１０４ 操作表示部
１０５ ネットワーク制御部
１０９ バス
１００ 配信アプリ
１１１ データ受信部
１１２ データ送信部
１１３ エラー検出部
１１４ 受信確認送信部
１１５ 状態遷移管理部
１１６ マジックパケット送信部
１１７ ＴＦＴＰサーバイメージ送信部
２０ クライアントＰＣ
３０ 配信サーバ
４０、６０ ネットワーク
５０ Ｆ／Ｗ

Claims (6)

1. ネットワークを介して接続される第１の情報処理装置から第１の通信方式で送信されたデータを受信し、
   受信した前記データを第２の通信方式で第２の情報処理装置に送信し、
   前記第１の情報処理装置との通信、または、前記第２の情報処理装置との通信におけるエラーを検出し、
   前記エラーを検出したときに、前記エラーに係るデータの再送信を前記第１の情報処理装置に要求する処理をコンピュータに実行させる中継プログラム。
2. 前記第１の情報処理装置から受信したｎ番目のパケットに含まれるデータを前記第２の情報処理装置に送信した後に前記第２の情報処理装置との通信におけるエラーを検出したときに、前記ｎ番目のパケットの直前に受信したパケットに係るデータの再送信を前記第１の情報処理装置に要求する処理をコンピュータに実行させる、請求項１に記載の中継プログラム。
3. 受信した前記ｎ番目のパケットに対する受信確認を前記第１の情報処理装置に送信した後に前記第１の情報処理装置との通信におけるエラーを検出したときに、前記ｎ番目のパケットに係るデータの再送信を前記第１の情報処理装置に要求する処理をコンピュータに実行させる、請求項１又は２に記載の中継プログラム。
4. 前記第２の情報処理装置を起動するパケットを前記第２の通信方式でブロードキャストする処理をコンピュータに実行させる、請求項１乃至３のいずれか一項に記載の中継プログラム。
5. ネットワークを介して接続される第１の情報処理装置から第１の通信方式で送信されたデータを受信するデータ受信部と、
   前記データ受信部で受信したデータを第２の通信方式で第２の情報処理装置に送信するデータ送信部と、
   前記第１の情報処理装置との通信、または、前記第２の情報処理装置との通信におけるエラーを検出するエラー検出部と、
   前記エラー検出部がエラーを検出したときに、前記エラーに係るデータの再送信を前記第１の情報処理装置に要求する受信確認送信部と
   を備える中継装置。
6. ネットワークを介して接続される第１の情報処理装置から第１の通信方式で送信されたデータを受信し、
   受信した前記データを第２の通信方式で第２の情報処理装置に送信し、
   前記第１の情報処理装置との通信、または、前記第２の情報処理装置との通信におけるエラーを検出し、
   前記エラーを検出したときに、前記エラーに係るデータの再送信を前記第１の情報処理装置に送信する処理をコンピュータが実行する中継方法。

Images