Couldn't we just consider local node's storage as a compressible filesystem with the added benefit that when nodes happen to support (the same) compression, they can just exchange the compressed data. If a node requests the information and doesn't support compression, it has to be decompressed before it is shipped. This way you don't break backward compatibility (at least not immediately, a later policy to enforce compression is an option).
My node is generally appears network IO bound, and it's a 450MHz P3 laptop. I'm sure NGR topology improvements could help, but given the need to maintain some amount of spare bandwidth (the marital harmony issue thing) on a modest cable modem connection I don't think I can really up the bandwidth... On Fri, 2003-08-01 at 06:04, Gordan wrote: > On Thursday 31 Jul 2003 21:39, Menno Jonkers wrote: > > > I don't think it'll be worth it. Stick to the compression algorithm > > that's readily available in Java. Focus the scarce development resources > > on things that can really make a difference, e.g. routing. Once the core > > functionality is okay, you can start looking at these kind of > > optimizations. > > The probem with "looking at these kind of optimizations" is that every time > the compression algorithm is changed, the network will break for all the > people who have nodes that don't support it. This means that there would have > to be a potentially rather long transition period where both methods would > have to be supported, at least on the decompression side. But even if the new > nodes are restricted to zip instead of bzip2, the old nodes that haven't been > updated will find the content compressed with the new algorithm unreadable. > > This effectively means it would require all the nodes to be updated and all > the data to be re-inserted, effectively tearing down the network and starting > from scratch. > > Granted, with a long transition period, it would probably work out without too > much disruption, but at the same time, I must say that I am in favour of > getting it right the first time, rather than having to either fix things > later at an increased cost or just putting up with the sub-optimal > performance. > > Gordan > _______________________________________________ > devl mailing list > [EMAIL PROTECTED] > http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl -- Joe _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
