Whatever happened to ZLIF?
Posted: 16 May 2011, 07:36
You know last night speaking with FlipFlop he brought up the ADC extension for ZLIF, so me being curious by nature I began looking into it and no more than 15 minutes later I had DiCe!++ (my DC++ "mod" if you will, although it's taken on its own identity in my own eyes) fully supporting ZLIF.
I began testing in the FlexHub test hub and wouldn't you know it, it worked like a charm, so with all the talk by the DC++ devs about how ADC is so much more bandwidth effective than why was ZLIF never implemented it literally took no more than 15 lines or so of code to factor into my client. All this talk about saving bandwidth with ADC and you leave out one of the biggest bandwidth savers? I mean seriously guys, what is up with that (and where the hell is the support in ADCH++ ?). If you want people to catch on to a protocol that is so much better than NMDC then why do you set yourself up for failure by bypassing an extremely useful extension like this? Where's the love for ADC at?
For those who do not know what ZLIF is and how awesome it really is, let me give you a basic breakdown on its entirety. Basically what ZLIF does is it allows the hub to send data (let's go with BINF's of everyone in the hub for instance), the hub sends a signal to the client (of course the client sends ADZLIF in the HSUP on connection) in the form of ZON which from that initial ZON everything becomes compressed and as well know when information or "data" is compressed it consumes less bandwidth to send that data because it is essentially smaller than the plaintext which was sent before the compression (an easy way to think of it is a trash compactor which basically takes all of this garbage and crunches it all down to a size much smaller than originally... yes I know the whole subject of compression is much more complex but you get the idea...) and obviously using compression has its disadvantages mainly in the form of CPU usage but for reference in 2003 DC++ had added support for using Zlib to compress data in Client to Client transfers ... so my point being is the cpu usage is so miniscule by today's standards that the benefit far outweighs the drawback.
Anyways when the hub wants to stop sending compressed data it basically sends the ZOF command and communications go back to being "normal" (in the sense that the data is uncompressed), the benefit of all this is it saves bandwidth, and usually a lot of it, which is great for hubowners.
Well that's pretty much the gist of it for a more detailed explanation check the spefication under "ZLIB-FULL"
I began testing in the FlexHub test hub and wouldn't you know it, it worked like a charm, so with all the talk by the DC++ devs about how ADC is so much more bandwidth effective than why was ZLIF never implemented it literally took no more than 15 lines or so of code to factor into my client. All this talk about saving bandwidth with ADC and you leave out one of the biggest bandwidth savers? I mean seriously guys, what is up with that (and where the hell is the support in ADCH++ ?). If you want people to catch on to a protocol that is so much better than NMDC then why do you set yourself up for failure by bypassing an extremely useful extension like this? Where's the love for ADC at?
For those who do not know what ZLIF is and how awesome it really is, let me give you a basic breakdown on its entirety. Basically what ZLIF does is it allows the hub to send data (let's go with BINF's of everyone in the hub for instance), the hub sends a signal to the client (of course the client sends ADZLIF in the HSUP on connection) in the form of ZON which from that initial ZON everything becomes compressed and as well know when information or "data" is compressed it consumes less bandwidth to send that data because it is essentially smaller than the plaintext which was sent before the compression (an easy way to think of it is a trash compactor which basically takes all of this garbage and crunches it all down to a size much smaller than originally... yes I know the whole subject of compression is much more complex but you get the idea...) and obviously using compression has its disadvantages mainly in the form of CPU usage but for reference in 2003 DC++ had added support for using Zlib to compress data in Client to Client transfers ... so my point being is the cpu usage is so miniscule by today's standards that the benefit far outweighs the drawback.
Anyways when the hub wants to stop sending compressed data it basically sends the ZOF command and communications go back to being "normal" (in the sense that the data is uncompressed), the benefit of all this is it saves bandwidth, and usually a lot of it, which is great for hubowners.
Well that's pretty much the gist of it for a more detailed explanation check the spefication under "ZLIB-FULL"