On Sat, Mar 29, 2008 at 10:12:20PM -0700, David White wrote: > We send network data in gzip format (Note: NOT zlib format, though we > probably should. gzip is similar to zlib format but the headers work > differently). > I checked RFC1950, RFC1951 and RFC1952 and I really suggest not to use gzip on the server. > If you gzip a file 'x', and then gzip a file, 'y', and then concatenate > the two gzipped files together, and then gunzip the resulting file, its > contents will be equal to the files 'x' and 'y' concatenated together. > > The same can be found with Wesnoth saves: get two of them produced by > Wesnoth that are compressed, concatenate them together, then gunzip > them, and you will find the result is the same as the two uncompressed > equivalents concatenated. > > However, the routines we use within Wesnoth to uncompress do not seem to > work like this. If you compress two buffers, concatenate, and then > decompress, you'll only get the first buffer back. > > Does anyone have any idea why this is? It is most unfortunate, because I > could make the server's handling of game history substantially more > efficient if our compression code worked the same way gzip does. > Well gzip just keeps looping until it reaches end of input or another error, this behaviour could just be transfered on the zlib format. One would just assume that if there are more bytes after an ADLER32 checksum it is the next zlib streams compression method and flags. I don't know about the current compress functions in use maybe I should check.
Jon Daniel _______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
