How long do you think connection multiplexing will take to impliment? Current unstable -> stable merge first, then multiplexing on unstable branch with a split network between unstable and stable might be one way to handle this.
Things I can think of that make multiplexing the way to go right now: -Reduce CPU overhead by massively reducing connections -Reduce network overhead for new connections -Allow firewalled nodes to be fully functional parts of the network just without ARK insertion. This will give us some of the scalability advantages of Gnutella's Ultrapeer technique -Allow us to go back to queueing messages on connections rather than on peers, this is probably a good thing as it should help get rid of the HUGE message send times that have become a problem on latest unstable. Problems: -Having to reset the network -Other bugfixes take a backseat while this is being worked on. --Brandon On Wed, 10/15/03 at 19:52:34 +0100, Toad wrote: > Suggestion: > I implement multiplexing and test it on a local testbed of a few nodes. > I don't implement any kind of backward compatibility. > Followed by a larger testbed of a few volunteers' nodes. > Followed by a network reset - wide deployment, without backward > compatibility. > -- > Matthew J Toseland - [EMAIL PROTECTED] > Freenet Project Official Codemonkey - http://freenetproject.org/ > ICTHUS - Nothing is impossible. Our Boss says so. > _______________________________________________ > Devl mailing list > [EMAIL PROTECTED] > http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
