On Sun, Jun 15, 2003 at 06:52:15PM -0700, Ian Clarke wrote: > > > I fear that your approach, while I am sure it is an improvement over > > > what we have now, it is a further step along the alchemy path - away > > > from the true and non-arbitrary path of NGrouting ;-) > > > > While there is alchemy in my changes, there is less than in the current > > code. > > I don't disagree - but the question is whether it is more productive to > work on code now that will be replaced in a few weeks, or just get on > with NGrouting itself. > > > > The idea of NGRouting is to have a consistent way to integrate all of > > > the information you talk about in a non-arbitrary and easily tested > > > manner - namely by combining all available information (including that > > > which your changes uses) into a single estimated routing time. This way > > > we aren't just arbitrarily combining this information. > > > > You have two types of routing to consider. Non cached non cached. How > > is it planned to have NG routing handle this? > > > > > This is the biggest piece of alchemy in my changes. Its also something > > that has a very good effect - without this nodes with lots of references > > are dropped as quickly as nodes with one or two. Think NG routing will > > benifit from something very much like this. > > NGrouting will, in a sense, figure this out for itself - hopefully we > won't need to use alchemy to force it to happen.
No it won't. If NGrouting favours open connections, and as a consequence a few connections stay open forever and everything else is ignored, we will get *lousy* load handling over the network as a whole. Thus we MUST NOT implement NGrouting before NIO. > > > Actually the origin version(s) of my changes used a kalman predictor > > to calculate the next CP. > > But even the CP itself is alchemy. Requests should be routed to the node > which is likely to result in the lowest request time, and CP is an > extremely crude way to take this into account. Are we going to have yet more estimators per node? A connection time estimator as well as an overall (once connected) time estimator, a probability of success estimator and our overall time estimator? Or are we just going to give new nodes a massive boost and hope we can keep connections open? I would suggest that if we are taking that strategy we will need to implement NIO and possibly even multiplexing first. > > Ian. -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ GPG key lost in last few weeks, new key on keyservers ICTHUS - Nothing is impossible. Our Boss says so.
pgp00000.pgp
Description: PGP signature
