On Monday 22 September 2003 12:18 pm, Ian Clarke wrote:
> On Mon, Sep 22, 2003 at 12:13:13PM +0200, Some Guy wrote:
> > Two ideas:
> > 1) Reuse NGR code to let the node keep statistics on
> > itself like it's neighbors do.  The quality of this
> > estimate would be far better than that a neighbor can
> > make, because it knows about all the queries it
> > handles, and it has a long time to same data, since it
> > can't disconnect from itself :-).
>
> What would that be useful for apart from drawing pretty pictures (which
> we already do).

If there are other nodes on the network that you trust, you could exchange 
this information with them, and have a much better idea of their 
specialization. Also this could also provide a basis for a non-alchemistic 
gage for what data should put in the store and what should be removed.

> > Reject queries for things outside your specialization
> > first.
>
> Terrible idea - specialization should occur naturally, it doesn't have
> to be forced artificially, and doing so will be harmful.

Well, if you can only accept so many queries it is better to accept those 
that: A. You already have the data to answer. B. You have previously seen the 
data that you will have to return. (it is nearby) and C. You are likely to 
see requests for in the feature.

I assume that we are already doing A and B. However this would let us do C.

> > 2) On every rejection message send some feedback
> > giving a quota for how many queries max should be
> > sent.  Then the other node could just "prereject"
> > queries for you.
> >
> > This number could be in queries per second or perhaps
> > better queries outstanding QS.  For example: if QS=10,
> > I can send you 10 queries, but after that I have to
> > wait until you reject, accept, say something about them.
>
> That might be interesting - although other nodes should be able to
> figure out for themselves what their neighbors capabilities are.
>
> Ian.

_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to