Restarting is done in terms of offsets of uncompressed file. For example:
Let's assume deflate compresses file A by 50%. The file is 100Bytes. And the
packet size is 1 bytes.
After 25 packets which is 50 bytes, transfer is aborted by client. Then when
he returns back, he sends the command:
The server then starts compression (deflate works by packet-by-packet way)
of the rest 50 bytes and there is 25 bytes more to go for compressed
transfer. The bad thing is that you cannot cache compressed content because
of this REST problem. So everything is on-the-fly!
I would give you my code but it's in C++.
----- Original Message -----
From: "Angus Robertson - Magenta Systems Ltd" <[EMAIL PROTECTED]>
Sent: Monday, November 21, 2005 5:55 PM
Subject: Re: [twsocket] HTTP compression
>> > FYI, in FTP servers, Mode Z is used for ZLib'ed (deflate)
>> > transfers.
>> One question could be: should the client automatically decormpress
>> the downloaded file or it should be done by the application?
> Compression is transparent to the user when Mode Z is used, the client
> sees an uncompressed file, this is all explained at:
> The fun part seems to be resumed transfers, part way through a
> compressed file, not quite sure how that's implemented, particularly
> when decompressing a partially downloaded file. Also whether the file
> is totally compressed before transfer.
> I was downloading some 250 meg text files last week, that would have
> been a lot less painful with compression.
> To unsubscribe or change your settings for TWSocket mailing list
> please goto http://www.elists.org/mailman/listinfo/twsocket
> Visit our website at http://www.overbyte.be
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be