That's exactly what I was look for, thanks so much! I've prefixed each message with its original size and it works perfectly.
On Sunday, November 27, 2016 at 6:52:30 PM UTC-5, thebroke...@gmail.com wrote: > > This is entirely proper behavior of the gzip implementation (or more > specifically, compress/flate). At the edges of the LZ77 window > (approximately 32KiB), you are not guaranteed that you can simply for loop > over the gzip.Reader until the input buffer is zero since the > implementation of the decompressor tries to avoid ever returning from Read > with (0, nil), which is discouraged in the io.Reader implementation. Since > it avoids returning (0, nil), it tries to read the next byte, which causes > the io.ErrUnexpectedEOF error you see. > > If you want to use Write+Flush in conjunction with Read, you must provide > some type of framing such that the decompressor knows how many bytes to > read before it had hit the flush point. > > See this example: > https://tip.golang.org/pkg/compress/flate/#example__synchronization > > On Sunday, November 27, 2016 at 2:04:09 PM UTC-8, kortschak wrote: >> >> I don't see anywhere that you are closing the gzip.Writer. Does doing >> that fix the problem? >> >> On Fri, 2016-11-25 at 05:12 -0800, Connor wrote: >> > Hi all. >> > >> > I'm trying to implement a structure which gzips multiple >> > individually-inflatable messages in the same data stream. I've built >> > an >> > example implementation here: https://play.golang.org/p/hwdrVtI29t. >> > While >> > this works initially, eventually the gzip reader throws an >> > "unexpected EOF" >> > at me. I've tracked the problem down to L609 in >> > compress/flate/inflate.go >> > <https://golang.org/src/compress/flate/inflate.go#L609>; the value >> > returned >> > by f.dict.availWrite() reaches zero, causing the reader to transition >> > from >> > the nextBlock "state" to reading huffmanBlock, ending in an >> > unexpected EOF. >> > For what it's worth, I've also tested it with this >> > <https://github.com/pierrec/lz4> LZ4 package which provides almost >> > the same >> > API as compress/gzip, and it works flawlessly. >> > >> > Could someone provide some pointers here? Is this the result of my >> > own >> > limited understanding of gzip/DEFLATE's mechanics, or is this >> > possible a >> > flaw in compress/(flate|gzip)? >> > >> > -- 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 golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
