Win a copy of Rust Web Development this week in the Other Languages forum!

Rene Krell

Greenhorn
+ Follow
since Apr 13, 2011
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Rene Krell

That's what I wanted to say in a particular example.
For practical usage, see this example: http://luugiathuy.com/2011/03/download-manager-java/ .

William Brogden wrote:Note that HTTP has headers already defined that will let you specify the range of bytes in the resource that you want to get in the response.

Therefore your request for a resume can tell the server where to start.

Bill

8 years ago
Does this make sense? According to the code, this is not a clear resume, but the client skips just the portion it has already received. But in each case you re-read the file from the beginning. So if you're connection is interrupted after transferring n GB, you got the retransmit them all in each case, just the client picks the the bytes it needs from that big piece already retransferred. This doesn't save neither time nor bandwith. Am I wrong here?

IMHO, the only approach of resuming a download can be initiated by the server, by giving it the start position in the target file it should start sending at.

Rene


Charles Mulloy wrote:Found the problem.

First off, line 31 is useless. It is from a past attempt and I forgot to remove it, so ignore it altogether.

Second, the error is in line 24. I constructed the FileOutputStream wrong. I used...

This will delete the file if it exists. But this...

... will make it append to the end.

The final product (before I start adding stuff):


@Amit: I only wanted to give credit where it was due. I had code before seeing this link, but it wasn't working like I wanted. What I have now is a derivative of the code found there.

8 years ago
I have a simple test case producing a sure ArrayOutOfBoundException in jzlib 1.0.7 depending on the data subsequently written to one and the same instance of ZOutputStream.

Stacktrace:



The problem occurs very rarely and depends on the data subsequentially written to an open ZOutputStream from jzlib.

Do you have a hint how to fix this? Have you ever heard of this?