Function List

Funtion List Target Module
Client Server
Send/Receive Send (Upload)
Receive (Download)
Send Folder(Upload)
Recived Folder(Download)
Chasing transmission ×
Control Bandwidth measurement ×
Encrypted communication control
File integrity check control
Bandwidth limit
Command line
Automatic program activation at reception ×
Auto-resume ×
Optional add-on functions Options
Multi-stage transfer option
(Server designation)
For using multi-stage transfer. (Optional)
Receive Gbit option
(Gigabit line option)
For transferring large files using over Giga line. Enables 100Mbps to unlimited line bandwidth specification. (Optional)

Operating Environment

Server and Client

OS Windows 32bit Vista、7、8、8.1、10
64bit 7、8、8.1、10、11、2008Server R2、2012Sever R2、2016Server ~
Mac OS 32bit 10.X~(PowerPC is not available)
Linux ※1 x86 CentOS 5.8、6.X、7.X
System Requirements
  • ・Memory (Server): 2GB~ (Recommended) ※2
  • ・Memory (Client): 1GB~ (Recommended) ※2
  • ・CPU : core2 or better (Recommended))
  • ・HDD Capacity: 50MB or more free space required for application installation.
  • ※1 For Linux, we verify and implement the OS that will be used for each project.
  • ※2 For memory, 1 session 300M or memory is used.
  • ※3 High-speed wireless file transfer requires high-speed Wi-Fi spot and Wi-Fi devices at Client side (sender).

Wi-Fi devices at the Client (server) must meet the flowing requirements:

  • ・Wi-Fi devices must support wireless LAN standard IEEE802.11n
  • ・It should be about to transmit and receive at “2 streams” or higher (This is referred to as 2×2 MIMO (Multi-In Multi-Out) in the product specifications. 3×3 MIMO is also accepted.)
  • ・The speed per 1 stream of IEEE802.11n must exceed 150Mbps

STORM® Protocol Charasteristics

Differences from Conventional Technologies and Products

Since TCP does not increase speed, there is a multi-session method that bundles multiple TCPs. This improves the effects of delay, but still has the problem of being vulnerable to packet loss. Next, there is a method that uses UDP for data transfer and uses highly reliable TCP for control. In this case, since the bandwidth for TCP must be kept, the transfer efficiency is reduced accordingly. In addition, there is a method called FEC that compensates for data lost on the receiving side by calculation. However, since the data is enlarged by FEC, it is inefficient in a high quality environment. It is also vulnerable to large amounts of packet loss.

STORM® is a solution that solves these technical problems. Only UDP can be used for both transfer and control, and the communication line can be used up to the maximum. There is no problem even if packet loss occurs. There is almost no slowdown in poor environments.

>Multi-session method

Because TCP is slow, there is a multi-session method that bundles multiple TCPs. Although this method improves latency, the problem of vulnerability to packet loss remains. →Although the delay is small, the speed does not increase on a line where packet loss occurs frequently.

>Method uses UDP for data transfer and TCP for control

There is a method that uses UDP for data transfer and TCP for control, which is more reliable. This method must leave the bandwidth for TCP, which results in lower transfer efficiency. → It becomes uncontrollable without bandwidth of TCP for control.

>Method using FEC (forward error correction) to reduce retransmission of packet loss

FEC is a method to supplement lost data on the receiving side by calculation. This method is inefficient in high quality environment because FEC results in bloated data. It is also vulnerable to a large amount of packet loss. → Inefficient on high quality lines. It cannot cope with a larger amount of packet loss and may fail.

>Academic Software

As a premise, this method assumes a super high-speed, high-quality network for academic use. →Communication is not stable on general lines where packet loss frequently occurs.


Since only the UDP1 port is used for both transfer and control, the line bandwidth can be used without waste. STORM® is premised on the occurrence of packet loss, so the speed does not decrease even in a poor environment.

STORM® Protocol Charasteristics

> Defines as “Packet loss ≠ Congestion”

Conventional protocols, such as TCP, define packet loss as “Congestion,” so that when packet loss occurs, the transfer rate drops significantly.

STORM® Protocol does not reduce the transfer rate due to packet loss. The optimal transfer rate is calculated based on how many packets the receiver receives in a given time.

refers to a situation that calls and communications that would normally be possible cannot be made due to the concentration of user access to a specific destination on a telephone line or Internet line.

> Defines as “Delay Fluctuation is Inevitable”

In addition, conventional protocols identify it as packet loss when a response is not received even after a certain time after sending the packet. This delay fluctuation causes a phenomenon of retransmitting packets that have already arrived, resulting in poor transfer efficiency.

STORM® Protocol defines delay fluctuation as frequently occurring. In determining packet loss, excluding the concept of time for response eliminates the impact of delay.

Delay fluctuation
 occurs due to network congestion, etc. Fluctuations of several hundred milliseconds or more occur in a severe case, and conventionally cause adverse effects in communication control, such as erroneous determination of packet loss.

> Transfers and Controls Only on UDP1 Port

The line capacity can be fully used, by using UDP including control. Since only UDP1 port is required, it is easy to configure routers and firewalls, and works well even in a NAT environment.

> Increases the Probability of Entering the Switch Buffer

In order to use the line efficiently, it is necessary to increase the frequency with which packets enter the switch buffer. By sending packets at a rate faster than the line capacity, it uses up to its capacity. It is important to have a system that does not interfere other users.

> Simultaneous transfer to Multiple Locations

The multi-stage transfer option allows for simultaneous file transfers to multiple sites using the STORM® application. Each site with a STORM® server (server for receiving files) makes a connection and simultaneously transfers incoming files to other sites. When using multi-stage transfer, packets are transferred by connecting the bases in a chain. By transferring packet itself instead of retransmitting files after they are received, it is possible to transfer files to multiple locations at about the same time as a one-to-one transfer. Even if the line is cut off during multi-stage transfer, the auto-resume function enables automatic retransmission from the middle of transmission.

Our Proprietary Protocol Using UDP

TCP is limited in high-speed data transmission, because it requires more procedures such as error checks and retransmission requests in order to ensure reliable data transmission and stable communication.

On the other hand, UDP is used as a high-speed protocol instead of omitting the transmission assuring functions, such as transceiving confirmation and retransmission request, which TCP uses. Due to this reason, UDP is considered less reliable than TCP.

STORM®, in addition to the high-speed of UDP, has implemented its own flow control in the upper layer of UDP which improves the transmission, assuring functions such as transceiving confirmation and retransmission request. This protocol successfully achieved complete and

  • ・Traffic Check
  • ・Receipt Confirmation
  • ・Retransmission Request
  • ・Route Confirmation

Developed with native program, C ++, the proprietary protocol using UDP controls communication on the OSI model Layer 4, the transport layer through Layer 6, and the presentation layer. In addition, TBS Television, Inc. conducted verification tests with transmitting their coverage data from around the world and optimized the protocol to enable high-speed communications over various communication lines.

About "Error Correction"

>Determining Packet Loss

STORM® determines packet loss from observing the continuity of response information. (The time for packet return is not adopted. The concept of time is removed.) Also, after sending packets consecutively, the packets that were sent earlier than the packet that responded are defined as packet loss.

That is to say, the response time of each packet is not defined, but the state of the response to the previous and next packet which transmitted together are observed to determine packet loss. (In other words, since the other packets sent together are responding, it is determined that the packet that has not yet responded is packet loss.) However, a simple comparison made it impossible to handle packet reorders that change the order, so we added some margin to the timing of determining packet loss. This method makes it possible to determine packet loss appropriately and achieve efficient transmission.

>the File inspection by hash value calculation

In order to check whether the transferred file has correctly arrived at the server or not, the file is checked by calculating the hash value.There are two types of file inspection: "CRC-32-IEEE 802.3" and "SHA-256". Setting without inspection is also possible. All can be switched only by the STORM® screen settings.

> the Encryption

STORM® can use AES-256 to perform encrypted communication when it is necessary to securely transfer files in business or internal exchanges using a global network. In addition, when communicating via the internal LAN environment or a dedicated line, switching can be performed using only the STORM® screen settings so that encryption can be easily removed.