Developers.Refactor.Compress

From Shareaza Wiki
Revision as of 20:09, 20 June 2009 by Kevogod (talk | contribs) (1 revision)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

How the Shareaza Code Uses Compression

if the remote computer is sending us compressed data, we save it in m_pInput (which contains compressed bytes) and then decompress it into m_pZInput (which contains readable data)

if we're sending the remote computer compressed data, we write it first in m_pZOutput, (which contains readable data) and then compress it into m_pOutput (which contains compressed bytes)

match that up with

onread source is m_pInput, destination is m_pZInput, call is decompress so it decompresses compressed bytes in m_pInput into readable bytes in m_pZInput

onwrite source is m_pZOutput, destination is m_pOutput, call is compress so it compresses readable bytes in m_pZOutput into compressed bytes in m_pOutput


CBuffer:Deflate calls CZLib:Compress calls compress in the ZLib library this compresses all the data in the buffer in place

CBuffer:Inflate calls CZLib:Decompress which calls uncompress in the ZLib library this uncompresses all the data in the buffer in place

CNeighbour:OnWrite has a z_stream structure and calls deflate this deflates the data as a stream from one buffer to another

CNeighbour:OnRead has a z_stream structure and calls inflate this inflates the data as a stream from one buffer to another


this is a mess, it should be refactored to methods of CBuffer

CBuffer:Compress uses compress CBuffer:Decompress uses decompress CBuffer:CompressStream uses z_stream and deflate CBuffer:DecompressStream uses z_stream and inflate

no, z_stream has to hold state and be wrapped in an object, CCompress, keep all the calls into ZLib there, and have its methods take access to a CBuffer object to write data safely and easily

Compress and Decompress are static since they don't have to hold state

the existing design is for a strong central CBuffer. if you continue in that design, CBuffer will get huge. it will want to gobble up everything that has to do with socket transfers, encoding, compression, encryption, hashing, text conversion. so, don't do it that way. make it a very small and simple class that even has a lowercase name, buffer, then have classes take access to one, like this

CCompression:Compress(buffer *b, BYTE *memory, DWORD size);

this would look at size bytes at memory, and compress them into the buffer b.