From DCppWiki


This is aready obsolete, per Bug 834: ZPipe. Inclusion of the the z compression in the layer --GargoyleMT 12:08, 8 March 2006 (EST)


well when I tested it, my results weren't as good as the ones Jove posted, but still better on bandwidth than without... Tested it with a "flooder" built for the occasion, so my tests aren't conclusive for a client...

// Carraya

To be honest, I am not surprised. Those results are real though: the hubsoft was already optimized to collect large blocks of protocol data to minimize TCP overhead. The larger the blocks that are zipped, the better the performance.

--Jove 05:39, 31 Oct 2005 (EST)

I posted a patch in bugzilla. Patch written by Pothead.

Another patch by Pothead: this one for CZDC/StrongDC based clients!

The Extension is currently supported in:




--Jove 10:32, 31 Oct 2005 (EST)

....... Edit this section as you see fit.

This is a cool feature. But why send $zline blob| ?

Why not just let the client and hub do a $supports zline| handshake and if they both support the feature they can transmit all data simply as $blob|

This is a great feature and YnHub will want to support it. But why not loose the zline in every message and we win 6 chars per message.

Also, while I pretend to be smart I am somewhat clueless when it comes to escaping. Surely ordinal $ and | must be escaped, what have I missed?

Just my 2 cents, I'll keep an eye on this page...

- Nev .......

The $ZLine is there because I want this extension to be auxiliary. It isn't usefull to zip ALL data. The price of the cpu usage is too high to use it on a single search for example, especially since for short messages, you don't really win anything bandwidth wise.
Also, especially for large hubs, it is too expensive to zip individual buffers to all users. My hubsoft uses this to zip up larger buffers send to all (or most) users. Individual messages (like pms search results) are send unzipped.
If you really care about the extra bytes, we could shorten it to $ZL<blob>| and save 4 bytes... ( and still have something that fits in the current protocol).
- Got it. Hence both the client and the hub can decide for themselves what and what not to zip. This can make for some nifty dynamic zipping depending on traffic and cpu-strain. But why not make it shorter. Why not just '$Z blob|'. Call me silly, but if the whole idea is to lessen bandwidth I think its a crime to keep the protocol command larger than necessary. Every byte counts! =)
The escaping is discussed above. All that needs to be escaped is the | symbol, by using \ as escaping character, it itself needs escaping. Escaped characters are never used in escapes themselves. So | becomes \P, \ becomes \\ (and \P becomes \\P). I see no reason to escape $ (or \0 for that matter).
- Yep. Got it now. Thanks. Almost. Why \P? Why not escape | into \| and \ into \\ ??
-While I love this I can only almost promise this feature in YnHub 1.04. It is still Yoshis call and his time. Hence, I'll make him aware of this feature. It's looking good...
You cannot escape | to \| because the escaping is valid only for the blob of zipped data. If there was a | in it, the client would interpret this as the end of the command. We would loose a part of our zipped data.
--Jove 14:43, 7 Nov 2005 (EST)

Only got three question now.

Does and should ZLine support all compression-levels? (none, fastest, default, max) I'm not sure I'd like YnHub to handle none and max.

Is the command $ZLine, $ZL or $Z? (I vote for Z)

Is the supports ZLine?

- Nev

Zline is now almost done in YnHub. But we use '$Z <blob>|' as command. Hope that is ok. Any client that uses '$Z <blob>|' instead of '$Zline <blob>|' out there for testing?

Sorry for hijacking your protocol Jove =)

- Nev

There is now. Supports Both $ZLine and $Z. :)
ZLine is more in keeping with the NMDC style, and would be a useful aid for new people to understand what it is supposed to do. --GargoyleMT 21:16, 13 Nov 2005 (EST)

Not that it matter too much for the dying MNDC protocol, but Nev suggestion about "$Z" is disturbing me a bit. By using only one charactere for a protocol command you are blocking further extention using that as it first character. -- 01:35, 14 Nov 2005 (EST)

$Z it is. adjusted wiki above. --Jove 14:07, 18 November 2005 (EST)

Well the problem with having a one char protocol string, is only a problem for programs using identify with one char at a time, and I doubt why anyone would do that with nmdc (I know it's faster) but seriously look at the different commands, unlike ADC NMDC protocol was meant to be string based.--Carraya

Yoshi wanted me to say this instead of him.. :) He is probably just too scared :P If Client has ZLine in support. Hub will send $Z (in YnHub). If Hub has ZLine in support. Client can send $Z to hub. This was a small suggestion.

i would advise against supporting user -> hub ZLining for two reasons.
- most users don't have much data to send and thus the win would be minimal
- too easy to dump a large zline to the hub. very effective flooding.
--Jove 15:42, 17 November 2005 (EST)


I suggest limiting the amount of uncompressed data a hub will send in one ZLine to 1MB. Anything over this can be sent in additional ZLines. Clients will allow 1.1MB, to ensure that a full command is sent, instead of splitting 1 command over multiple ZLines. --Pothead

Sound sensible pothead. It can't hurt.
--Jove 15:42, 17 November 2005 (EST)

Could we definately say that a hub may never split up a Command, so every uncompressed Blob has to end on a Pipe ?