> > Good to hear. Wonder if it is because of working NGR or > simply because > > the unstable network is smaller.. I believe that this isn't > known yet. > Don't things work better when it's bigger? :-)
It should do.. If routing was working well and able to cope with the growth and load balancing. > > Hmm.. Well.. Actually they both speak exactly the same > language.. The > Then, no reason why 'stable' couldn't actually talk well with > other stable > nodes and ngr ones? And just keep the unstable only dealing > with ngr for > testing? As of yesterday there where three types of nodes.. Stable, all non-NGR Unstable, anti-NGR (build <6281) Unstable, NGR (build 6281+) The previous two types could talk to each other.. The last type could only talk to its siblings > > Hmmm.. Not play really.. The intention is to make it work... > Perception skewers reality. I don't know WHY unstable works, > but I see that > it does. I tested again yesterday with stable (getting new > seednodes) and I > still couldn't *do* anything. Ie, couldn't retrieve any > 'known' keys. So, > either all the linked content just isn't there any more on > 'stable', or > something is still broke. Whether by luck or talent, it > seems that they have gotten unstable 'working'. Possibly anti-NGR... > > Probabilistic caching. > > Prevent nodes from caching data whose source they aren't > routing-wise > > close to. > Why? I don't understand this... ideally, shouldn't a node > cache *everything* > that runs through it, given enough space? It does, until the DS is 90% full.. After that it tries to enhance specialization by selectively accept stuff into its store.. > > NGR > > Keep track of not only which nodes have what data.. Also > keep track of > > how fast they can supply it. > Err, um... keep track of what nodes have what data? That > doesn't sound like a > good idea at all. Hopefully, you mean, "keep track of what > nodes can GET > what data". I hope, at least, that would be the way it works. > "No, I don't > have the GPL, but I know someone who can get it for ya... I'm > just passing > your request on..." Right, my mistake.. > > Problem #8: > > OCO. > > Massive amounts of CPU is used for connection negotiations due to > > heavy encryption stuff used in there. OCO amplified this > latent issue. > I read Toad's roadmap, and it seems that at least udp is > being considered. > Great. This is how it SHOULD be done: Or, at least, an > option. If you're on > lower bandwidth, udp should be fine, no? And solves having a ton of > connections always open. It'd put more load on the machine, > but, probably > still acceptable. The problem is not the TCP connections.. It is all about FNP connections (currently over TCP but they would have the same problem even over UDP). The problem is that two nodes has to autheticate with each other to verify that the Peer is who he says he is.. This is true no matter if the underlying transport would be TCP or UDP. > > 1. Multiplexing, would allow a single connections to send multiple > > messages simultaneously thereby enabling us to keep only one single > > connection open to each node, compared to keeping one free > connection > > the each node. > Ah, so THAT is why I see so multiple instances of a node in > the OC window? > Because this is yet to be done? Yep. > > If someone wants to add missing things to the list then > feel free to > > do so. > That's a pretty nice list, and certainly gives me a new perspective. Good, that was the intention :) There is no play involved.. Most everything is done for a quite good reason :) > > Nahh.. They don't really dismiss it.. They just want things > to start > > working at all first :) Any help would be very appreciated. > I think they're doing a good job with unstable. It just is > non-intuitive > that your best hope is NOT to get the stable release: I think > it'd be helpful > for the main page to reflect that unstable isn't really so > much 'broken' as 'in need of constant update'. Meaning, if > you are downloading the latest build each day, chances are > you're probably be better off than downloading the stable at > all. But, that's just my experience so far. Usually stable is the best hope.. It is just that here has been a rough couple of months lately.. /N _______________________________________________ Support mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support
