SkeedDelivery™の技術

同じファイルを多拠点に配信するとき、サーバークライアント方式による配信では、配信先の拠点数が増えるに従って、データセンターなどの配信元のサーバーと回線を増強する必要があります。 SkeedDelivery™による配信では、拠点間での受送信も行うことにより、データセンターなどの配信元の負荷集中を抑制し、効率の良い配信を行えます。そのため、拠点数の増加に伴ってインフラを増強する必要はありません。配信元と全ての拠点間の下りと上りの実効帯域が同一である場合、1つの拠点に配信する相当の時間にオーバーヘッドの時間を加えた時間で全ての拠点に配信することができます。 拠点間の受送信は、ファイル全体を単位として繰り返すものではなく、ファイルの一部分ごとにブロック化して、その単位で拠点間でマルチパスで多段転送（バケツリレー方式）の送受信を繰り返します。

多段転送とは、バケツリレーのように、拠点間でデータを送受信する方法です。

ファイルをブロックに分割し、その単位で送受信を次々に繰り返します。
帯域の利用の集中を避けることができ、効率よく配信を行えます。

マルチパス転送とは、送受信の際に、複数の拠点と同時に通信を行う方法です。

複数の拠点から異なるブロックを同時に受信します。
複数のブロックを同時に送受信することにより、高速に通信を行えます。（いくつの拠点と送受信するかは回線状況を見ながら自動的に判断します）

SkeedDelivery™では、各拠点の通信ソフトウェア同士が協調しながら、自動的に最適な順序と経路を見つけて配信する技術を利用しています。管理サーバーによる大域的な経路制御と、各拠点による細かな経路の自律的な制御の組み合わせによって実現されています。＜特許第5724154号＞
すべての経路をあらかじめ事前に決めておくのではなく、その時々の拠点の回線状況に応じて順序がシステムによって自律的に決定されます。各拠点の回線能力の差を動的に判定し、過去の転送実績などを鑑みながら、回線状況のよい拠点から優先的に配信されます。一時的に他の通信が多く行われている拠点は後回しにする、などといった経路制御が自動的に行われます。
拠点間のブロックの送受信の相手は、ファイル全体を通して同じとは限らず、必要に応じて変更されます。

通信中の拠点の回線、機器、ソフトウェア等に障害が発生して通信不能になったとき、それぞれの拠点がそれを検知して、自動的に通信可能な迂回経路を見つけて通信を再開します。管理サーバーからの指示を待ってから転送を再開するわけではないので、すぐに通信を再開することができます。
また、拠点が通信不能になったことは管理サーバー側でも検知することができます。

管理サーバーからの指示によって配信や拠点を管理します。
配信の開始や停止などの操作は管理サーバーからのみ指示できます。配信先となる拠点から任意のファイルを発信することや、管理サーバーが配信を指示していないファイルが混入して配信されることはできません。管理サーバーで配信停止やキャッシュの削除などを命令すると、それらは各拠点ですぐに実行されます。
全ての拠点の情報は管理サーバーに通知され、管理サーバーで全ての拠点の状況を確認できます。管理サーバーでは各拠点の情報（拠点の死活状態、配信の進捗状況、どの拠点同士でどの程度の速度で通信しているか、など）を常時把握することができます。

全ての通信はSSLによって暗号化されて保護されます。
各拠点の自律的な動作は、全て管理サーバーによって管理された制約の中でのみ動作します。拠点間での通信は、配信対象とされた拠点間でのみ受送信され、配信対象ではない拠点を経由してファイルが配信されることはありません。
各拠点では、他拠点から受信したデータをブロック単位で整合性の確認を行います。データの破損や改ざんを検出できるため、正しいデータ以外は受信時に破棄されます。

配信先の拠点に一時的に保存されるキャッシュは、管理サーバーからの指示により削除されます。または、保存されているキャッシュは配信の期限と連動して削除されます。拠点にキャッシュがいつまでも残り続けるようなことはありません。
キャッシュは暗号化されてファイルに保存されます。そのファイルが持ち出されたとしてもそれを利用することはできません。また、保存されたキャッシュは読み出し時に整合性をチェックしてから利用されます。キャッシュファイルが破損したり改ざんされた場合は、そのデータは読み出し時に破棄するため、誤ったデータが利用されることはありません。