> >> 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. 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 _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
