On Thu, Oct 16, 2003 at 12:22:40PM +0300, Costas Dokolas wrote: > > >> It would certainly be possible to implement multiplexing > > in a backwards > > >> compatible way. HOWEVER, at some point we would want to make > > >> multiplexing mandatory, because the old way of dealing > > with connections > > >> is so damaging. And for various other reasons it seems a network > > >> fork/reset would not be a bad thing at this point in time. > > > > One possible idea, though not necessarily a very good one, is to make > > the default freenet installation two separate nodes, one > > stable and one > > unstable (with standard ports to distinguish them). > > Encourage people to > > use both for insertions (possibly simultaneously), and indeed to try > > both for accessing data (probably sequentially), but make > > them work on > > two mutually incompatible networks. Configuration operations > > that made > > them small enough in resource terms to both fit on the > > average computer > > would be necessary, but this must be possible. If the > > current Fred uses > > 120 to 300 MB rather than 12GB of memory, it must be possible > > to cut it > > to 50MB or so. > > Making freenet work like that is way out of current objectives, but... > > Why not implement multiplexing and make it "forward compatible" ?? > - Set a "first mux implementing build" to the first build that supports it. > - Accept only one connection per peer (whatever the build). > - Enable multiplexing only on connections to nodes that are after the "first > mux implementing build" number.
It's a presentation protocol version change. We don't need to worry about lastGoodBuild. It is possible to implement it back-compatibly and that was the original gameplan: merge unstable to stable, then implement muxing backwards compatibly on unstable, debug it, merge it to stable, then some time later (say a month), make muxing mandatory and remove the non-mux compatibility code from new builds. However, we were discussing whether it would be more sensible to implement muxing without any backwards compatibility and fork the network. That mainly depends on whether we can get unstable to a mergeable level of quality without multiplexing. > > At some point in time after this is merged into stable and the Last Good > Build becomes the same number as "first mux implementing build", we will be > able to declare non-MUXing dead (in code) and completely move into > multiplexing. This will "throttle down" the older (non-MUXing) nodes > somewhat during the transition period but they'll still be part of the > network. There is also a small possibility that the network may fragment > into MUXing and (many?) non-MUXing parts if NGR decides that non-MUXing > nodes are not worth a MUXing node's trouble, but as long as there is still a > central seeding mechanism (Ian's), it won't be final. > > It's mostly an implementation problem, as I don't know if multiplexing can > be switched on/off per connection in the current design. > > Doc -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
