| 機能一覧 | 対象モジュール | ||
|---|---|---|---|
| クライアント | サーバー | ||
| 送受信 | 送信 | ○ | ○ |
| 受信 | ○ | ○ | |
| フォルダ送信 | ○ | ○ | |
| フォルダ受信 | ○ | ○ | |
| 追っかけ送信 | ○ | × | |
| 制御 | 帯域計測 | ○ | × |
| 通信の暗号化制御 | ○ | ○ | |
| ファイル整合性 チェック制御 |
○ | ○ | |
| 帯域制限 | ○ | ○ | |
| コマンドライン | ○ | ○ | |
| 受信時自動プログラム起動 | × | ○ | |
| 自動再開機能 | ○ | × | |
| オプション追加機能 | 内容 |
|---|---|
| 多段転送 （サーバー指定） |
複数拠点のサーバを指定し 同時送信が可能 |
| 帯域無制限 （ギガ回線オプション） |
帯域を制限なく使用可能 |
| 対応OS | Windows | 32bit | 8、8.1、10 |
|---|---|---|---|
| 64bit | 8、8.1、10、11、2008Server R2、2012Sever R2、2016Server | ||
| Mac OS | 32bit | 10.15以上（PowerPCは使用不可） | |
| 64bit | |||
| Linux ※1 | x86 | CentOS 7.X | |
| x64 | |||
| 動作環境 |
|
||
クライアント（送信側）のWifi機器は以下の要件を満たす必要があります。
TCPは速度が上がらないので、TCPを複数束ねるマルチセッション方式がある。これで遅延の影響は改善するが、パケットロスに弱いという問題が依然としてあり。
次に、データ転送にUDPを用い、制御に信頼性の高いTCPを用いる方式というのがある。これはTCP分の帯域を残しておかないといけないので、その分転送効率が落ちることになる。
その他にFECと呼ばれる受信側でロスしたデータを計算により補完する方式があるが、FECによりデータが肥大化するため、高品質環境では非効率となる。また、大量のパケットロスにも弱い。
STORM®はこうした技術の問題点を解決したソリューション。転送、制御の双方にUDPだけを使用し、通信回線の最大限に使い切ることが可能。パケットロスが発生しても問題ない。劣悪環境で速度が落ちることはほとんどない。
TCPを複数束ねて速度を稼ぐ方式。遅延には強いが、パケットロスが頻発するような回線では速度が上がらない。
制御分のTCP帯域を残しておかないと制御不能になる。
FECによりデータ量が肥大するため、高品質環境では逆に非効率となる。大量のパケットロスに対応できず、破綻する可能性あり。
学術系の超高速・高品質なネットワークを想定しており、パケットロスが頻繁に発生するような一般回線では通信が安定しない
転送も制御もUDP1ポートのみを使用。通信回線の帯域を最大限に使うことが可能。パケットロス発生を前提としており、劣悪環境でも速度低下が少ない。
ＳＴＯＲＭ®プロトコルの概念についてパケットロスは、通信回線の状態により常に発生するものと定義し、パケットロスが発生しても転送速度は落とさず、最適な転送速度は受信状況を見ながら判断。
本プロトコルでは、パケットロスを輻輳※と定義していない。
従来のプロトコルでは、パケットロスを輻輳と定義しているので、転送速度が著しく低下。つまり、STORM®ではパケットロスが発生したからといって転送速度を落とすことはしない。最適な転送速度は、受信側が一定時間にどれだけのパケットを受信できたかにより算出している。
※輻輳：ふくそう 【 congestion 】
電話回線やインターネット回線において利用者のアクセスが特定の宛先に集中することにより、通常行えるはずの通話・通信ができなくなる状況を指す。
パケットロスの判定に応答に対する時間の概念をなくし、遅延による影響を排除。
ＳＴＯＲＭ®プロトコルでは、遅延のゆらぎは発生するものと定義している。遅延のゆらぎは、ネットワークの混雑具合などにより発生するが、酷い時には数百ミリ秒以上のゆらぎが発生し、従来では、パケットロスの誤判定が発生するなど通信制御に悪影響を与えていた。
従来のような、パケットを送出後、一定時間経っても応答が届かない場合にパケットロスとみなす、といった考え方だとこの遅延のゆらぎによって、実際は届いていたパケットを再送してしまう、といった現象が発生し、効率が悪い。本プロトコルでは、パケットロスの判定に、応答に対する時間の概念をなくし、遅延による影響を排除。
転送・制御ともにUDP１ポートで行うことで、通信回線の容量を最大限に使用可能。またルーターやファイアウォールの設定も簡単であり、NAT環境下においても問題なく動作する。
類似の高速転送製品では、UDPとTCPを併用するものが多い。この場合、TCP分の帯域を残しておかないといけない。
通信回線の容量を使い切るための方式。 回線を効率よく使うためには、パケットがスイッチのバッファに入る頻度を上げる必要と合わせて他利用者に迷惑をかけない仕組みが重要。
通信回線の容量より速い速度でパケットを送信することで、回線容量以上の速度は元々出ないので、結果的に帯域をフルに利用できることになり、回線容量を最大限に利用。この場合、パケットロスが発生するが、本プロトコルでは、パケットロスは発生するという前提で開発しているため、制御上、問題無い。しかし、通信回線を占有してしまうと、周囲に対して迷惑行為となる恐れがあるので、最大転送速度の設定や、帯域使用率の設定機能を提供。
帯域使用率は、通信回線容量の何%を使うかという形で指定でき、ユーザーは特に意識しなくても、周囲に迷惑行為をしてしまうことはない。
光回線のように全二重で帯域が上下対称となっている通信回線を利用し、複数拠点を数珠つなぎにパケットを転送することで、1対1で転送するのとほぼ同じ時間で複数拠点への配信を可能。最初の送信側が、次の拠点にパケットを投げると、その拠点はその次の拠点にパケットを中継。これを最終拠点まで行う。
それぞれは1対1の通信なので、結果的に、全拠点に同時転送が可能。
TCPでは、データ伝達保証性と、通信の安定性を確保するために、エラーチェックや再送要求などの手続きが増える。
それゆえに、「高速にデータを届ける」という点において、その性能に制約を受ける。
一方、TCPの伝達保証性を省略し、その代わりに高速性を重視したプロトコルとして利用されているのがUDP。UDPでは、伝達保証機能（送受信確認や再送要求）が提供されていないため、TCPに比較して信頼性に乏しい。
我々は、UDPが高速性に優れている点に加え、UDPの上位層に独自のフローコントロールを導入することで、実用上充分な信頼性を実現することに成功。TCPで保証されている以下の項目についてもSTORM®プロトコルは同様に保証。
STORM®はネイティブ プログラムのC++で開発されており、OSI model Layer 4: transport layer ～ Layer 6: presentation layer上で、UDPを使用した独自のプロトコルで通信制御。
さらに、TBSテレビが世界各国から取材データの送信実証試験を行い、さまざまな通信回線において常に高速通信できるように本プロトコルを最適化した。
応答情報の連続性を見ながら、パケットロスを判断（パケットが返る時間を使用しない。時間の概念を外す。）
「パケットを連続送信後、応答が返ってきたパケットより、前に送信したパケットをパケットロスとする」と定義。
つまり、個々のパケットについての応答が返る時間は定義せず、送信したときの前後のパケットに対する、応答の状態を見て、パケットロスを判断する、ということになる。言い換えると、一緒に送った他のパケットの応答が来ているのだから、まだ応答が来ていないパケットはパケットロスだろう、と判断。
ただし、単純に比較をしてしまうと、順番が入れ替わるパケットリオーダーに対応できなくなるため、パケットロスと判定するタイミングに若干の遊びを持たせた。
このような方式により、適切にパケットロスが判定できるので、効率の良い転送が可能。
転送したファイルが正しくサーバーに届いたか、ファイルの整合性チェックを行うために、ハッシュ値計算によるファイル検査を行っている。ファイル検査種別は、「CRC-32-IEEE 802.3」「SHA-256」の2種類。検査なしの設定も可能。いずれもSTORM®の画面設定のみで切換えが可能。
暗号化についてSTORM®は、グローバルネットワークを使用して、ビジネスでのファイルのやり取りや内部でのやり取りにおいて、セキュアにファイル転送をおこなう必要がある場合、AES-256を用いて暗号化通信を行うことが可能。また、内部のLAN環境や専用線での通信の際には、簡単に暗号化が外せるよう、STORM®の画面設定のみで切換えが可能。