Improve caching and downloading methods to solve the issue of bandwidth mismatching

[mljack]

a. Use blocks in a ring buffer to cache the streaming with bounded memory consumption. b. Increase the streaming bandwidth by concurrent downloading requests.

The major changes are in the commit 407660b. Also try to just limit the memory usage of downloading in the first 3 commits. It's still fragile when bandwidth of up/down stream don't match. The server will disconnect if the proxy holds off the response too long.

BTW, I'm using a router to run this. Now, memory is not a problem, but CPU pressure is still quite high, esp. for HD videos.

[binux]

Great, I had tried to add this feature but it need a lot of patches. I will test it at weekend.

[binux]

I found that when download failed, it will become deadlock:

A partial block(0/0) is downloaded. Retry.  0 vs 1000000
Block: 0/0  Range: [bytes=754586-1754585]   0.0 KB/s    0 mins  0 seconds
Block: 1/1  response code: 599   bytes_recevied: 0
A partial block(1/1) is downloaded. Retry.  0 vs 1000000
Block: 1/1  Range: [bytes=1754586-2754585]  0.0 KB/s    0 mins  0 seconds
Block: 0/0  response code: 599   bytes_recevied: 0
A partial block(0/0) is downloaded. Retry.  0 vs 1000000
Block: 0/0  Range: [bytes=754586-1754585]   0.0 KB/s    0 mins  0 seconds
Block: 1/1  response code: 599   bytes_recevied: 0
A partial block(1/1) is downloaded. Retry.  0 vs 1000000
Block: 1/1  Range: [bytes=1754586-2754585]  0.0 KB/s    0 mins  0 seconds
Block: 0/0  response code: 599   bytes_recevied: 0
A partial block(0/0) is downloaded. Retry.  0 vs 1000000
Block: 0/0  Range: [bytes=754586-1754585]   0.0 KB/s    0 mins  0 seconds

and using MultiHTTPProxyClient has some problem here:

• MultiHTTPProxyClient only support GET request with url and headers as its parameters, not fully compatible with tornado HTTPClient. well, as for xunlei it's fine.
• multiple connect and Range is always used. when remote server is not support it, responsed content is not complete. say this.

I thought to patch tcp buffer to do that, it may fully compatible with the origin HTTPClient. anyway, using Range to control download buffer may better then tcp buffer in this case. I would happy to merge if deadlock fixed.

[mljack]

The log you listed is not a deadlock. The proxy just keeps requesting the same block from the server if it failed. It only stops when all is done or the client disconnects. It will ask the next block, if a block gets what it wants.

For other 2 problems, you're right. It's just tested to support xunlei and there's no fallback for single connection full range download yet. For xunlei lixian servers, it doesn't support HEAD request to query the whole content length, so I have to use GET and only use its headers.

[binux]

it is keep trying in microseconds and not success for minutes.

[mljack]

ok, I'll test more. I have seen some similar logs before, but seldom now. Does it happen more with range(eg: bytes=754586-) ?