WO2017081673A1

WO2017081673A1 - Download acceleration using dynamic number of connections and dynamic chunk size

Info

Publication number: WO2017081673A1
Application number: PCT/IL2016/051103
Authority: WO
Inventors: Yoel ZANGER; Offer Atzitz; Rotem Epelbaum; Inbal YEFET; Keren SIMON
Original assignee: GIRAFFIC TECHNOLOGIES Ltd; GIRAFFIC Tech Ltd
Current assignee: GIRAFFIC TECHNOLOGIES Ltd; GIRAFFIC Tech Ltd
Priority date: 2015-11-12
Filing date: 2016-10-10
Publication date: 2017-05-18
Anticipated expiration: 2018-05-12

Abstract

A system for accelerating a download comprising a requester configured to request content download, a server configured to store content and an acceleration module connected with the requester and the server and configured to receive from the requester at least one request for content and to download the requested content from the server using a dynamic number of connections and a dynamic chunk size calculated for each connection.

Description

DOWNLOAD ACCELERATION USING DYNAMIC NUMBER OF CONNECTIONS AND DYNAMIC CHUNK SIZE

FIELD OF THE INVENTION The present invention generally relates to file streaming and specifically to improvement of download speed by using several download connections.

BACKGROUND

A common problem encountered by many internet users is insufficient usage of bandwidth.

This usually happens when the network capacity is close to or lower than the connection being consumed. For example, players that do not manage to fill the buffer as necessary and a video is getting into a buffering mode without playing. Reasons for this phenomenon may be:

1 . Shared Wi-Fi connections.

2. Low quality (high packet loss) links in developing countries.

3. Crowded High speed links (Cable).

In addition, communication with the server and downloading content is being done via TCP protocol or protocols similar to TCP.

Besides the above, the throughput of a TCP Protocol is also limited:

communication is limited by two windows: a congestion window and a receive window. The congestion window tries not to exceed the capacity of the network (congestion control) and the receive window tries not to exceed the capacity of the receiver to process data (flow control). Each TCP segment contains the current value of the receive window. If, for example, a sender receives an ACK which acknowledges byte 4000 and specifies a receive window of 10000 (bytes), the sender will not send packets after byte 14000, even if the congestion window allows it. Therefore, a single TCP connection does not fully use the capacity of the network.

SUMMARY

According to an aspect of the invention there is provided a system for

accelerating a download comprising: a requester configured to request content download; a server configured to store content; and an acceleration module connected with the requester and the server and configured to receive from the requester at least one request for content, start downloading the content with a downloading connection and receive from the server and send to the requester the content received via the downloading connection while gradually increasing the number of downloading connections.

The content may comprise one of a video file and a text file.

The requester may be comprised in a device.

The device may comprise one of a computer, a set-top box, a tablet, a smartphone, a smart TV and a game console.

The acceleration module may comprise a buffer configured to store the content. According to another aspect of the invention there is provided a method of accelerating a download comprising: receiving by an acceleration module, from a requester at least one request for content download from a server storing the requested content; starting to download, by the acceleration module, from the server, the requested content via a first connection; checking whether the server supports multiple connections; and if the server supports multiple connections receiving by the acceleration module, from the server, and sending by the acceleration module to the requester, the content for fulfilling the at least one request using a gradually increasing number of downloading connections.

The method may further comprise if the server does not support multiple connections receiving by the acceleration module, from the server, and sending by the acceleration module to the requester, the content for fulfilling the at least one request using the first connection. The checking whether the server supports multiple connections may comprise opening a new connection and trying to download part of the content using the new connection.

The gradually increasing may comprises checking whether the number of downloading connections is smaller than a determined number of connections and if so increasing the number of downloading connections.

The method may further comprise checking whether the number of downloading connections is bigger than a determined number of connections and if so decreasing the number of downloading connections to the determined number of connections.

The method may further comprise calculating a data chunk size for each downloading connection.

The calculating may comprise multiplying a time to first byte value by a coefficient and by a connection throughput value.

The calculating may comprise multiplying a round trip time value by a coefficient and by a connection throughput value.

BRIEF DESCRIPTION OF THE DRAWINGS

For better understanding of the invention and to show how the same may be carried into effect, reference will now be made, purely by way of example, to the accompanying drawings.

With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of the preferred embodiments of the present invention only, and are presented in the cause of providing what is believed to be the most useful and readily understood description of the principles and conceptual aspects of the invention. In this regard, no attempt is made to show structural details of the invention in more detail than is necessary for a fundamental understanding of the invention, the description taken with the drawings making apparent to those skilled in the art how the several forms of the invention may be embodied in practice. In the accompanying drawings:

Fig. 1 is a schematic representation of the system for carrying out the present invention; and

Fig. 2 demonstrates the state machine for download acceleration according to embodiments of the present invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Before explaining at least one embodiment of the invention in detail, it is to be understood that the invention is not limited in its application to the details of construction and the arrangement of the components set forth in the following description or illustrated in the drawings. The invention is applicable to other embodiments or of being practiced or carried out in various ways. Also, it is to be understood that the phraseology and terminology employed herein is for the purpose of description and should not be regarded as limiting.

The present invention solves a common problem encountered by many internet users of unutilized network capacity.

The invention's guideline is to open several connections that joined together attempting to use the maximum communication abilities.

By opening several connections in parallel, e.g. Transmission Control Protocol (TCP) connections, the maximal usage of the network bandwidth is achieved. The several connections allow, statistically, a significantly improved download speed.

In order to accelerate a download from a server storing content, the present invention:

• Checks whether the server allows multiple connections.

• Checks whether the server supports range requests. • Opens several connections till it reaches its limit.

• Gathers all data arriving from several connections and sends it to the requester.

• Reaches buffer fullness (if necessary, e.g. for video streaming).

· Calculates the best chunk size according to

o Current download speed.

o Server's response time / RTT (Round-Trip Time)

• Reuses connection, e.g. by using HTTP persistent connection. It will be appreciated that the content may be any type of file, such as for example, a video file, a text file, etc. or a set of files (like in adaptive streaming) which may be allowed, by a server storing it, to be downloaded in parts.

Fig. 1 is a schematic representation of a system 100 for carrying out the present invention, comprising a device 110 comprising a requester 115 (e.g. a native player) requesting content download and an acceleration module 120 of the present invention configured to maximize the communication abilities. The system also comprises a server or data source 130 storing the content to be downloaded.

The device 110 may be a computer, set-top box, tablet, smartphone, smart TV, game console or any other device that can connect to a network.

The acceleration module 120 uses at least a buffer 124 and may be installed in the device 110 or in any device that transfers the requested data from the device 110 to the server 130, such as for example, a router. When multiple connections are allowed, the acceleration module 120 of the present invention opens several connections each downloads an optimal calculated range of bytes (chunk) from the requested content. The present invention provides a state machine configured to determine how and when to react to network changes and server's limitations. Each state contains a different behavior and a different reaction.

There are two obstacles that may prevent the present invention from accelerating the download:

1 . If the server, storing the content, does not support range request.

2. If the server, storing the content, does not support a number of

predetermined connections.

In both cases, the present invention continues downloading the content in a single connection. Otherwise, the present invention gradually opens new connections till it reaches a predetermined number of connections

('NumOfConn') or till it finishes downloading the content.

Fig. 2 demonstrates the state machine 200 for download acceleration according to embodiments of the present invention.

In the initial state 1 , the file is downloaded with one connection and a range request of 0 to oc. In this state, the active connections are limited to one connection. When the initial state timeout has expired or a predetermined amount of data has been received (e.g. 300 bytes), the acceleration module goes to state 2.

In state 2 - verify range request state, the accelerator checks whether the server, storing the content, supports range requests. The acceleration module opens a connection with a range request. The request attempts to download e.g. 100 bytes. If the request fails or if the data does not arrive as expected, the

acceleration module concludes that the server does not support range requests. Therefore, the acceleration module goes to state 3 - No Range Request state and limits the number of connections to a single connection (the initial connection that was opened in state 1 ). Otherwise, the acceleration module continues to state 4 - Handle Startup state.

In state 4, the acceleration module knows that the server supports range requests hence the number of active connections ('ActiveConn') gradually increases. The acceleration module increases the number of active connections until it reaches the predetermined number of connections ('NumOfConn'), e.g. 10 connections. When the number of predetermined connections ('NumOfConn') equals the number of active connections ('ActiveConn'), the acceleration module goes to state 5 - Acceleration Support state. If in state 4 or 5, the acceleration module receives a signal indicating that the ('NumOfConn') has changed, (e.g. other higher priority data has to be downloaded), then if the 'ActiveConn' is larger than the changed 'NumOfConn', it goes to state 7 - Limit Acceleration state and limits the number of connections to an allowed number of connections (less than the predetermined number of connections and at least one). If the 'ActiveConn' is smaller than 'NumOfConn', it goes back to state 4 - Handle Startup, and gradually increases the number of connections till the 'ActiveConn' equals the 'NumOfConn'.

If in state 4 or 5, at least one of the active connections fails to download its chunk, the acceleration module goes to state 6 - Multiple Connection Failure state and limits the number of active connections to at least one connection or to the number of downloading connection (the ones that download more than 0 bytes).

In state 7, once the 'ActiveConn' equals the 'NumOfConn', it goes back to state 5.

Acceleration Logic

Reaching buffer fullness:

In streaming a file, in order to avoid re-buffering mode, it is best to have the buffer as full as possible close to the reading position.

Therefore, the present invention calculates the recommended buffer size, the recommended chunk size and in addition, when a connection finishes

downloading a chunk, the next chunk to be downloaded would be the chunk that is in the highest priority according to its position. Chunk size calculation 1 Option:

The chunk size for each connection is: TTFB * Co * Connection Throughput (per second),

where

TTFB: The time that has passed from sending the request till the first byte has arrived. The TTFB is based on the average TTFB of all or some of the downloads performed via a current connection.

Co - a coefficient number that improves the download time. For example, a coefficient of 5 means that the download time of the chunk will be significantly larger (x5) than the TTFB.

It will be appreciated that the Co is not limited to this number.

Connection Throughput: The average throughput of this connection.

The average throughput is calculated during a predetermined time period (e.g. the last 2 minutes).

If the resulting chunk size is smaller/larger than the Limitation window, the result is rounded up or down, in order to fit the limitation window size, where

Limitation window: TCS: Time of Chunk Size. This is the time frame for the connection to download the next chunk. TCS = TTFB * Co; according to embodiments of the invention, the TCS value is limited to be between a minimum value of 0.5-5 seconds, and a maximum value of 3-20 seconds.

It will be appreciated that the minimum and maximum values are not limited to these specific values. The first chunk size value is not based on TTFB of this new connection, but is set to a default size, e.g. 4 MB or calculated from parameters of different

connections.

It will be appreciated that the first chunk size value is not limited to this number. Chunk size calculation 2^nd Option:

The chunk size for each connection is the RTT * Co * Connection Throughput, where

RTT: is measured as the average Round Trip Time (RTT) measured by the TCP of this connection.

The Limitation Window and Co are calculated the same as in the 1 ^st option.

Claims

1. A system for accelerating a download comprising:

a requester configured to request content download;

a server configured to store content; and

an acceleration module connected with said requester and said server and configured to receive from said requester at least one request for content and to download said requested content from said server using a dynamic number of connections and a dynamic chunk size calculated for each connection.

2. The system of claim 1 , wherein said content comprises one of a video file and a text file.

3. The system of claim 1 , wherein said requester is comprised in a device.

4. The system of claim 3, wherein said device comprises one of a computer, a set-top box, a tablet, a smartphone, a smart TV and a game console.

5. The system of claim 1 , wherein said acceleration module comprises a

buffer configured to store said content.

6. A method of accelerating a download comprising:

- receiving by an acceleration module, from a requester at least one request for content download from a server storing said requested content;

- starting to download, by said acceleration module, from said server, said requested content via a first connection;

- checking whether said server supports multiple connections; and

- if said server supports multiple connections:

- downloading said requested content from said server using a dynamic number of connections and a dynamic data chunk size calculated for each connection.

7. The method of claim 6, further comprising

if said server does not support multiple connections: - receiving by said acceleration module, from said server, and sending by said acceleration module to said requester, said content for fulfilling said at least one request using said first connection.

8. The method of claim 6, wherein said checking whether said server supports multiple connections comprises:

- opening a new connection and trying to download part of said

content using said new connection.

9. The method of claim 6, wherein said using a dynamic cumber of

connections comprises gradually increasing the number of download connections.

10. The method of claim 9, wherein said gradually increasing comprises:

- checking whether said number of downloading connections is smaller than a determined number of connections and if so increasing said number of downloading connections.

1 1. The method of claim 6, further comprising:

- checking whether said number of downloading connections is bigger than a determined number of connections and if so decreasing said number of downloading connections to said determined number of connections.

12. The method of claim 6, wherein said calculating a dynamic data chunk size for each download connection comprises:

- multiplying a time to first byte value by a coefficient and by a

connection throughput value.

13. The method of claim 6, wherein said calculating a dynamic data chunk size for each download connection comprises:

- multiplying a round trip time value by a coefficient and by a

connection throughput value.