|
Alex Skinner |
at Jul 1, 2014 at 2:47 am
|
⇧ |
| |
But it doesn't seem to be the Flush() call that's messing up but the read.
The reader has a 32768B history buffer that is read from...hence why your
33rd read only has only 768 bytes. If you call read again it fills up
fine. Honestly, the reader source is too hard for my tired brain to
follow tonight, but not sure what the 'correct' behavior is on the read
call in this situation.
Thanks,
Alex
On Monday, June 30, 2014 4:43:49 PM UTC-4, Pepe Aracil wrote:I think deflate.Flush() MUST send all remaining data and it works well the
first 32 iterations. I suspect the cause is flate dictionary size is 32K
and the blocks are 1000 byte length.
This link explains flush methods and how must work:
http://www.bolet.org/~pornin/deflate-flush.htmlEl lunes, 30 de junio de 2014 22:31:32 UTC+2, jasdel escribió:
From looking at your code, it looks like the problem is because you're
read from inflate expects the full data. Whereas Read can actually return
early, and you need to keep reading until there are no more data.
On Monday, June 30, 2014 12:28:43 PM UTC-7, Pepe Aracil wrote:Hi All.
I need to send data chunks over a tcp socket, the size of the chunks are
variable and I want to compress this chunks in stream mode to get the best
compression ratio.
Zlib/deflate algorithm supports streaming compression but I detected
this issue:
In this example:
http://play.golang.org/p/Fz8BilOYET the compression
stream using compress/flate, fails after iteration 32 ¿Why?
Tanks.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
[email protected].
For more options, visit
https://groups.google.com/d/optout.