----- Original Message ----- From: "Tom Kaitchuck" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, August 05, 2003 4:14 AM Subject: Re: [Tech] freenet not suited for sharing large data
> On Monday 04 August 2003 06:16 pm, Nick Tarleton wrote: > > On Sunday 03 August 2003 05:49 pm, Gabriel K wrote: > > > Well, I think a protocol should guarantee to find the data, much like > > > ACHORD. > > > > AFAIK, THIS IS NOT POSSIBLE without sending a request through the entire > > network and placing ridiculous total load on it. > > > > > So it seems to me that the original FreeNet lacks features that they are > > > trying to put there now...? > > > Such as shorter proxy paths, and optional upload of data? :) > > > > There is something called 'path shortening' that may be what you want - I'm > > not sure. Optional upload is already there: just insert with HTL 0, and > > it'll stay on your node until someone requests it. Of course, there will be > > some trouble _finding_ it. > > I do have an idea for a better optional-upload system that, combined with > > NGRouting, would work well. It's really a specialization of Frost's system. > > The uploader inserts a small announcement for the file, containing basic > > information and its CHK, at a high HTL. The requesting client gets that, > > and then tries to retrieve the file a couple times. If that fails, it then > > inserts a small KSK (with a name containing the CHK of the file). The > > uploader is constantly requesting this KSK. When it's recieved, the file is > > inserted. > > NGRouting's high-probability-of-finding would be required for it to work > > well, obviously. > > I have a better idea for upload on demand. Gabriel, this may be what you are > looking for so listen up. > > When you insert new data, insert the manifest first. This should have a bit on > it that identifies it as such. When a node stores this data, it creates a > list of the last few people to have requested it. Then when someone requests > it, they get a proxy (ala the anonymity filter), and have it make the > request. The proxy will add it's IP and public key to the request. Then when > the node that has the manifest, gets the request, it returns it as usual. > However _IF_ there is a IP/public key attached, it adds the proxy's IP/public > key to the list. Then it gets a proxy (ala the anonymity filter) and has the > proxy send the list to the requester's proxy, encrypted with a session key > that was attached to the end of the manifest file when it was returned. > > Then the node can download form all the people on the list, and they can > download form it. Of course both the requesters would be using the anonymity > filter, so there would always be proxies in between. All parties are kept > anonymous and it would help requests going across the network too. If a > request for any of the chunks of the file happened to go through the node > that stored the manifest, or any of the proxy nodes (the ones that know the > data, but not the transmiter), it would immediately be forwarded to someone > with the data. > > A node would not have to upload the entire file initially, because after they > insert the manifest, they can request their own file, so they'll be the only > one on the list for a time. Although it would be preferable if it was > inserted normally, so the nodes could have something to fall back on. Of > course the same effect would occur when the nodes inserted healing blocks. > > Any thoughts? This is way to abstract for me.. especially since english is not my maternal language. It would be so much easier if you had some illustrations to go with it, and NAME things A, B, C... One thing though.. it seems like an approach that is "statefull". I don't like statefull :) Btw, isn't freeNet statefull when you make a request? /Gabriel _______________________________________________ Tech mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/tech
