On Tue, Sep 23, 2003 at 12:18:45PM +0200, Some Guy wrote: > 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
How do we know what the node's specialization is? Convince ian! > > > 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. I have actually suggested using NGRouting estimates in pcaching occasionally, Ian doesn't seem to think it's a good idea. > > 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 -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
