On Friday 19 Sep 2003 13:42, Some Guy wrote: > --- 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.
That sounds like a horrible hack. I'd much rather be looking at integration of the way the data is stored and retrieved in the networks. That seems to be the best reason so far to look more closely at merging the Freenet and Entropy networks. Ideally, the implementations would be separate as they are now, but the FNP would be made compatible. > > 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. But if they use compatible FNP, then the routing shouldn't matter. > > > 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 :-) ). You are talking about bridgning networks. I was talking about _compatible_ networks. > 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. I was thinking about it by looking at Freenet and Entropy as different implementations of the same general protocol. Compatible FNP is in that case the fundamental building block, and everythins else can be variable, e.g. the data store format, routing implementation, etc. The advantage is that Freenet and Entropy nodes would be treated equally, and there wouldn't be two different networks to bridge at all, just one bigger network, with what is effectively two different node implementations. This would be roughly equivalent to some people using Lime Wire and other people using Bear Share, but both programs are just different Gnutella protocol nodes. The network, effectively, doesn't care about how the implementation works, as long as it obeys the protocol specification. Gordan _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
