ZLIF support
Bug #783516 reported by
iceman50
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
DC++ |
Fix Released
|
Wishlist
|
Unassigned |
Bug Description
I have created a patch for adding ZLIF support in DC++ I tested it on FlipFlop's test flexhub and works
Related branches
Changed in dcplusplus: | |
status: | New → Fix Committed |
importance: | Undecided → Wishlist |
To post a comment you must log in.
the patch is good as is. but i have a few questions:
1) what happens to ZLIB-GET now, do we keep using it for binary transfers or can it be merged with ZLIB-FULL? the doc seems to suggest, although vaguely, that the latter could be possible.
2) TLS encryption: how useful is it to compress data that will later be encrypted?
3) why does ADC need a ZOF message to mark the end of a compressed stream but NMDC doesn't?
4) error handling: at the moment, decompression errors are silently ignored. they may however occur, either because DC++ doesn't have enough memory to create the zlib decompressor, or during decompression when the Adler-32 checksum doesn't match the contents.
perhaps an STA should be sent to the hub, requesting it to send the messages it just sent in uncompressed form (this would require book-keeping from hubs that they may not want to do)? or a SUP with RMZLIF ("remove ZLIB-FULL support")? or, easier, just close the connection and reconnect without ZLIB-FULL support?
hubs will most likely compress the initial INF pack and i don't think it would be sane to continue a hub connection if these INFs couldn't be fetched.