On Friday 19 Sep 2003 11:52, Some Guy wrote:
> --- Tom Kaitchuck <[EMAIL PROTECTED]> wrote:
> > I have tried Freenet, Grapevine, Entropy, GunNet,
> > and even Chord. Although I
> > don't know the details of all their implementations,
> > they are all good. So in
> > effect, all three projects suffer form not doing one
> > thing that the others
> > do, and not having a large network.
> >
> > I think all three projects could benefit if a single
> > suffocation could be
> > produced that all three could work towards, that
> > would allow the networks to
> > interoperate.
>
> Yeah, I've been daydreaming about this. If the
> different networks could handle each other's data,
> people would be free to use thier own
> routing/connectivity. Also it might be possible to
> have different versions of freenet being tested in
> their own subnetwork, but still being live.
This is vaguely similar to what I mentioned here a while ago. You have a
"border" node that separates nodes on private IPs from the big network. But
the routing inside the private network is freely available. The internal
nodes can only route out through the "border" node, though.
But, because the private routing is really fast, the border node could accept
requests from the outside network, and then ask it's internal nodes to fulfil
the request, then forward the response back or onward elsewhere on the
external network.
It's sort of like clustering nodes.
> > There are a lot of things that are easy to reach a
> > general consensis on.
> > (Encryption / routing etc.) Then for splitfiles FEC
> > is the logical choice,
> > because it is much more sophisticated then anything
> > the other projects use.
> > However it might be nice to have files that did not
> > need to be part of the
> > data store, like in GnuNet.
>
> 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.
> > However the hard part would be comming up with a
> > standard for communications
> > and metadata. Ideally the protocol would not care
> > about firewalls / nats and
> > utilize the underlying network as best as possible.
> > I understand Jrand0m has
> > some ideas in this aria. One would probably want to
> > include some sort of
> > simplistic search and flooding resistance, borrowed
> > form GnuNet, and TUKs
> > included in the metadata ala Grapevine.
>
> Yeah, it does seem hard. If Jrand0m or anyone else
> has ideas I'd be interested.
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.
> > If someone could even produce a preliminary outline
> > of what this should look
> > like and submit it to the other projects, I'm sure
> > they would cooperate and
> > try to come up with improvements. The important
> > thing to remember is this is
> > not just 'Here's how we do it', but rather an ideal
> > network, even if it
> > contains elements that you don't know how to
> > implement yet.
>
> Convincing other people may be hard too.
>
> I've got an idea that would work for small
> experiemntal networks with just a few nodes. Maybe
> they could emulate a single super freenet node. In
> other words let freenet be the "Mother Network".
>
> Say I've got 100 test nodes, and it takes 1 or 2 hops
> to get to data. Could I give them all the same NodeId
> and rotate the IP around when introducing myself?
> This would let the network learn our specialization
> just once. I could use the subnetwork as a giant
> datastore and be free to experiment with whatever
> routing I choose.
That sounds similar to what I described above...
> 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.
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.
Gordan
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
