On Fri, 04 Jun 2010 19:33:09 +0400, VolodyA! V Anarhist wrote: > Dennis Nezic wrote: > > On Thu, 3 Jun 2010 23:56:46 -0400, Dennis Nezic wrote: > >> Is it possible to explicitly state the compression used with > >> GETCHK or GETCHKFILE or GETCHKDDIR from telnet? (I don't think > >> these commands are even possible in fproxy -- getting chk keys > >> without inserting?) > >> > >> When inserting files via fproxy, I think you have to explicitly > >> decide whether to compress or not, but that would easily lead to a > >> different chk key for the same file, if the GETCHK* commands don't > >> do the same thing. > > > > Oh, why do we have arbitrary compression anyways, btw? :) (Arbitrary > > because there is no explicit standard in the specs, as far as I > > know, which can easily lead to completely different CHKs for the > > same file across different versions, if the settings are even > > slightly changed (ie. slightly different compression > > algorithm/level, or threshold for using it, or explicit user > > choice, etc.)) Is the massive computer and time overhead really > > necessary to reduce filesizes by 1%? (I assume jpeg and zip and > > mpeg4 etc compression algorithms are already good enough? And why > > the heck is all this massive overhead done THREE times? Are gzip > > bzip and lzma really all /that/ different??) > > This question is being asked over and over and over again, mostly by > the people who don't bother look for the answer (in the future please > at least say that you didn't look for it). > > Think about the implications of 1% in the network that does not do > path folding? This is 1% on every download by every person that goes > out multiple hops. So you will be downloading 1% more, but your node > will also have to carry 1% more from all the traffic that comes > through it. This will also amount to the constant garbage flood > attack on the network equivalent to 1% of all the data that is > currently being inserted, pushing more content off the network, > causing people to retry, and then reinsert more often (with the > effects discussed above). > > In addition to all that, the truth of the matter is that the CPU time > is very cheap when it is compared to the network latency.
I suppose I can accept that logic -- one end user (the author) suffers while everyone else benefits. But, actually, I think more often then not all that intense cpu-work is completely ignored since none of those general-purpose algorithms can do better than the specific-purpose jpeg/zip/mpeg4/etc. (Assuming a few bytes could be compressed, the metadata overhead negates it.) > > And as for the reason why there's no standard so far, it's probably > because things are still being tweaked. That's probably my biggest complaint. If it was standardized and completely transparent, I might grudgingly accept having to wait an hour to get a chk key, without inserting. But as it currently exists, depending on how you insert, (ie. via telnet, fproxy w or w/o compression, etc) will result in differing CHKs. Personally I'd trash all the compression stuff -- that is not the node's responsibility, IMHO. Like you said in your other email, people already compress their archives, and probably at even higher compression levels? _______________________________________________ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
