On Sunday 20 July 2003 05:07 pm, Ian Clarke wrote: > > Why not make it go both ways? Make Routing Table == Open Connections - > > Transients. > > Well, I am not necessarily sure that it is wise to route messages to > nodes that initiated the connection to us since that could pose a > security threat (it would make it easier for an attacker to get my node > to send messages through his node).
I don't see how it is a security threat. Ether it will respond to your requests or not. If it is trying to monitor your traffic, what difference does it matter who connected to who. Although it might not be as good, because we don't know anything about it's store. However it would be good for firewalled users and would allow you to decrease your total number of connections. Although now that we have NIO that is not a huge concern. If you are going to the trouble of insuring that each node in the routing table has an open connection, you can't accumulate lots of information about a node, and then decide whether or not it is worth connecting to it for a request. This means that you can't really know more than one key a node contains before connecting to it. So, you'd connect right away. If that is the situation, why not have it connect to you. If it connects to you, gives you the data you requested, and is added to your routing table, it means the node that connected you to it is not in the return path of the data. I proposed this a while back. http://hawk.freenetproject.org:8080/pipermail/tech/2003-June/000430.html This could give better load balancing, and provides a small security measure that one malicious node could not feed you other malicious nodes who never had the data. > > This is exactly why node stereotyping is important. What is the point of > > having 500+ connections open if you know nothing about them? Please tell > > me something like it will be done once NGrouting is in. > > What do you mean by "node stereotyping"? Basically taking probabilistic caching one step further. Come up with a ngrouting algorithm to perdict our incoming data requests, and if the item that is currently being processed is more likely to be requested then our current least likely to be requested data, it replaces it. _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
