--- Gordan <[EMAIL PROTECTED]> wrote > > I think Freenet's HSK,KSK, and SSK may become a > > standard. Entropy is evidence of this. > > If that is the case, then it should not take much to > merge the networks. Even if they don't support SSKs like MNet, you can still just store them like KSKs and then check certificates on the boarders.
> How big is the overlap in FNP implementations > between Freenet and Entropy? If > the protocols are very similar, there shouldn't be > much standing in the way > of "pooling the resources" between the two networks. http://entropy.stop1984.com/en/p2p.html The question is in the routing. > > The problem is that this doesn't scale. If > freenet > > wanted to merge with equally sized networks, I > think > > you'd have to keep track on request/post messages > > which networks have already gotten the message. > So > > for example an insert might have flags for > {freenet, > > Grapevine, Entropy, GunNet, Freenet-China, MNet, > ect} > > and so that it doesn't get inserted into the same > > network repeatedly. > > I am not sure about that. If the networks are using > compatible FNPs, then > routing on it's own could be left up to the > implementation. For example, we > have nodes in Freenet that use the old routing and > we have others that have > NGR implemented. The same network still works for > both implementations. > Entropy, if it was compatible, could just hook into > Freenet, and use whatever > routing it has implemented, while the data storage > resources are merged. Think about it: say there are 10,000 FreeNet nodes and 10,000 CrazyNet nodes, and we want to work together. Say a request hits a boarder node. It sends off the thing into both networks (maybe parrallel :-) ). So it goes one hop in network A and then queries all of network B, then goes another hop in network A and again queries all of B. Do you see how this is bad? What should happen is that both networks should be exaustively queried once and only once. It seems all you have to do is put flags on the query <route A,route B>. If a node gets a query and can send it to A and B it forwards to A with the B turned off and vise versa. It still seems like you might need a mechanism to get a message from A to B. There's also a problem if A is ten times bigger than B, then every node in A will handle 10 times as many queries. This may not be too big of a problem if Inserts and DataReturns are way more expensive than queries. Insertions would just have to be balanced. Maybe you would only insert into your native net. Of coarse if both networks were relatively reliable, you could break up the global hash space 50-50 and know you'd only have to search one network. But this begs the question; the whole reason for doing this is that one network may be more reliable. > That would stimulate the nodes in the network to > pick the best nodes for > routing to/through. This would in effect, make the a > good testing tool for > finding what routing algorithm yields the best > performance in terms of data > retrievability and speed. The chances are that the > dominant implementation of > routing among the nodes in the routing table(s), > relative to the proportion > of deployment of each implementation, would be very > indicative of what the > best routing implementation is. Right, I agree with you about the plus side. __________________________________________________________________ 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
