> > Still the stuff I personally(or close neighbors) > > request will be from all over the key space. > > But your node will have seen some references from > keys > near to the ones you are requesting, so it will send > it to > a node that hopefully knows more about that area of > the > keyspace. > ***** Better Illustration: Say I have a neighbor that's really specialized in X and that I'm less specialized around X, less than 1 of his 100 neighbors. I have a piece of data in X he doesn't have. If someone asks him for the data he'll ask his 1st choice, and since that node will ask its 100 neighbors before he'll ever recurse back to me, there's no chance I'll ever see the request (unless I'm his nieghbor too). Chances are that the request will shoot off into never never land. The query "got close" but then shot off. This maybe one of the issues of having too many neighbors, Ian seems to be nervous of.
Think about the latency benifits if nodes knew what thier 1storder nieghbors had. Instead of having to ask all thier first order neighbors for X, they would know which ones had X. They might be able to load balance too. Think about how small the cost would be. The key should be way smaller than the data. The message would be about the same size as a request for the data. It can be sent when not much is going on. Compare it to the cost to the system of downloading/uploading the data, usually several times. > > Consider this: for every item I have if I just > picked > > my first choice to route to in finding that key > and > > made sure he knew about it, he'd have a way better > way > > of knowing to ask me than if he had to guess just > > based on previous requests. Maybe I got the data > from > > a node he doesn't know about, which died after. > > There is a security issue with node telling other > nodes, > "this is what I know". Consider what would happen > if a > hostile node lied.... > > > OK, I know that that kind of a one hop solution > would > > break security, but just consider it from a > routing > > point of view. Yes, the problem of a hostil node lieing about being good at something and then performing poorly would have to be solved. Still you can solve this by using whatever old analysis (NG,current,SVM, prize winner of contest, ect) to see if a neighbor is lieing. Of coarse you'll always have the posiblity of nodes built to specialize in an area in order to censor it. The issue that I was more worried about was with telling your nieghbors what's in your store. It would seem that they could use some statistics to guess if I had been looking at particular material. This problem may be solvable by sending out the messages with a small but random HTL. There is a security upside: if every now and then nodes are sending these kinds of ads and the ads look like regular insertion messages, real inserters may be harder to locate. > > > > Perhaps my idea is just part of a bigger > suggestion: > > Instead of letting my neighbors learn of my > > specialization the hard way, why not just tell > them > > about it? Theoretically I could send them a > summary > > of my specialization, if it's not too big. This > would > > be especially useful for giving new Nodes > something to > > start with. > > One part of NG routing may add some of the function > you > suggest but in a safer way. Yeah, I noticed when Ian was writting up requirements for NG, one of them was that it had to be serilizable. I immediatly thought "hey are they going to try sending the things to each other?" http://www.freenetproject.org/index.php?page=ngrouting Tell me something: I read here that N would typically only be 10 points. Is this acurate? It seems like awefully small. Are nodes still going to store a table of exact results per node and key? At any rate 10 points could easily be sent out to all your nieghbors; in fact you might be able to send it out a couple levels. One idea would be to have nodes calculate thier own specialization from those of the neighbors. When one node dies it's neighbors could instantly adjust the spec and send it out, so the other nodes wouldn't have to re-train to figuar it out. __________________________________________________________________ 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://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
