On Monday 15 Sep 2003 11:29, Some Guy wrote:
[routing]
> One solution that was proposed to do this was to do
> "light insertions" or "inverse passive requests". The
> idea is to make a new insertion message which says the
> sender has a trail to key X. This message follows
> the regular routing path for a normal HTL. Every node
> on the way stores the key and from which node it got
> the message. When a request comes along it has a good
> chance of finding a node which knows about the trail.
> Such a node forwards the request back along the trail
> to your "read only node".
Unless I am mistaking, this would completely destroy anonymity. If there is a
trail from a file to the inserting node, then a file can be conclusively
associated with the node that is believed to have inserted it, and anonymity
is nullified.
> 1) This may not be implemented for some time. Toad
> wrote:
> "We may do something like this, but not exactly like
> this ("inverse passive requests") after 1.0."
> -- Wed, 6 Aug 2003 17:37:24
This would not be request based. It would be a polled solution. You would
insert a request file saying "please upload this". The client application
polls for such requests and inserts the files. It's more like automated mail
bots than anything else. It is at best a near-line protocol.
> 2) There may be securtiy issues like an adversary
> inserting of "advertisements" but refusing to deliver
> actual the data.
I think Frost WOT already handles that problem adequately. Just mark the
advertiser as bad and ignore them. Sure, lots of requests for non-existant
files are bad for the network, but that cannot really be helped.
Unfortunately, there are already "legacy standards" used that provide active
links to "future" editions, which is will fail most of the time, because the
data isn't there. This already needlessly floods the network with useless
requests.
IMHO, any form of dead-linking should be avoided. Unfortunately, it is not
easily possible to enforce that. Even worse 404 type errors are not final
with the current network design. Trying again may well retrieve the file.
Unfortunately, I don't think there is a good and obvious way around it.
Probabalistically caching 404 results for keys for a while may be a reasonably
effective hack-solution, but it would not be perfect, e.g. the node could say
"I received X requests for key Y in the past time interval Z. If X(Y)==404,
then remember that for a while, and don't try to forward, just immediately
say 404 without bothering other nodes. However, I am not sure what that would
do to routing, especially with the new NG routing implementation.
> 3) Somebody may have some neat ideas of how to link
> this design into a design to do streaming broadcasts
> or another messaging system like NIM.
NIM and broadcasts already fit perfectly with the design of Freenet. If an
entity wants to help Freenet, they can run a full relay node. If they don't
want to help, they can just insert the data, hope for the best, and re-insert
frequently using a transient node. I don't see the possible benefits to
Freenet of having read-only nodes. It is pointless at best and
counter-productive at worst. It doesn't fit with the network topology and
doesn't fit with the design goals.
It strikes me that the solution to the problem you are describing is frequent
re-insertions or insertions with slightly higher HTL.
> Personally I think the idea has promise.
I still don't understand why it is useful.
> It may help
> the system lend itself more to file sharing, since big
> data doesn't need to be transfered <average hops> to
> sit around and hope to get found, just small pointers.
If the routing is working correctly, the inserts will end up on nodes where it
WILL get found, when requested. You put keys in the network, not tell the
network where to find the keys. The network is self-organizing.
> It may also help with rarer data which gets inserted
> all the time but rarely retrieved before it expires.
I don't think the capacity of the network is anywhere near it's limits. If the
storage space is running out, then then correct solution is to add more
space/nodes or see if there are further optimizations to be made to routing,
not breaking the network design.
> Right now though there are higher priorities. Someone
> that would want to run a few of these "read only
> nodes" could just run a regular node and insert
> repeatedly possibly to different nieghbors (in case
> they don't route to the same place).
Precisely my point. Correct tool for the job.
> I think the big
> problem you'll have is getting people to run a freenet
> node just to install something.
People will do it if there is no other medium that makes the content available
in their part of the world. For everyone else, there are other solutions such
as BitTorrent or Gnutella. In the long term, Freenet might replace
BitTorrent-like applications, but that is quite some way off...
Gordan
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
