I'm going to reply to a several responses at once. ---Ian Clarke <[EMAIL PROTECTED]> wrote: > > 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. What's natural anyway? Ok, sending my neighbor a summary of my specialization would require him to test to see if I was lieing, and might open up security problems. But, just sending rejections seems pretty safe.
---Dan Merillat <[EMAIL PROTECTED]> wrote: > If I want to pick up subspace <X> on my cancer node, > I can either QR a > percentage of queries outside that subspace, or DNF > a percentage quickly > without trying. Putting the code in the stock > codebase improves > routing. Saying "It's an attack" is worthless, > since if it does indeed > teach the other node your specilization, a cancer > node can do it NOW. Yeah, that in possible combination with a few other things can let evil nodes steer into a particular area in hashspace and censor it. It does make me nervous. > How do you propose a node learn of another nodes > spec? At some point > you HAVE to make use of information returned from a > probable cancer > node. I agree 100% Dan. ---Tom Kaitchuck <[EMAIL PROTECTED]> wrote: > 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. Definately, I've suggested using the node's specialization to improve the caching a few times: http://www.mail-archive.com/[EMAIL PROTECTED]/msg10486.html > 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. I agree it seems like a rigid priority hierarchy would be good. Using the node's specialization to improve caching and/or routing will only kick in when the cache is full and/or the requests have to be dropped, respectively. How, tangled up would the code get if the pcaching code and/or the code responsible for rejection had to talk to some NGR instance? __________________________________________________________________ Gesendet von Yahoo! Mail - http://mail.yahoo.de Logos und Klingelt�ne f�rs Handy bei http://sms.yahoo.de _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
