On Fri, Oct 31, 2003 at 02:54:43PM +0000, Toad wrote: > On Fri, Oct 31, 2003 at 02:47:34PM +0000, Toad wrote: > > On Fri, Oct 31, 2003 at 02:41:35PM +0000, Toad wrote: > > > On Thu, Oct 30, 2003 at 04:39:22PM -0800, Tracy R Reed wrote: > > > > When a splitfile download finishes it often has a tendency to hang on "FEC > > > > decoding missing data blocks... this may take a while; please be patient." > > > > seemingly forever. I know this is a known bug to some but I'm not sure if > > > > everyone knows about it. > > > > > > > > When I try to cancel the download (usually while it is supposedly FEC > > > > decoding) so I can try again it takes forever and I have to shutdown the > > > > node to get it to stop so I can restart the download. > > > > > > > > An idea: I have 40G of ds only half of which is used after months of > > > > operation. I am on a DS-3 so my node doesn't lack for bandwidth and I > > > > always run the latest rev. This isn't good. Empty space in the ds is > > > > wasted space and hurts freenet performance. It would be helpful if there > > > > was something in fnp which allowed a node with a partially full ds to ask > > > > one of its peers to give it a key, preferably one in the requesting nodes > > > > area of specialization (isn't some specialiation info sent out in > > > > announcement requests?) but any data at all would be better than an empty > > > > datastore and having to poll keys and hope to get lucky in order to get > > > > the datastore to fill up. I don't think I have ever had pcaching kick in > > > > because I have never been able to fill my store. If everyone would fill > > > > their datastores when their node started up I bet our psuccess would > > > > increase significantly. > > > > > > You could spider Fredweb... There are security issues with a give me a > > > random file command. They were discussed some time ago... > > > > Actually, the obvious security issue is a hopsToLive problem, which is > > easily solved - just make the request drop randomly, with a fixed > > probability (say 0.05), and don't have a hopsToLive value. This makes > > the time taken by the request extremely variable, but this isn't a > > problem if it's only used to fill the store. However there may be more > > serious issues. Such a command would have been useful for certain > > whacky schemes involving XORing, that's why it was discussed last time. > > Anyway, the more serious issue: would it dilute the node's > > specialization? It probably would... Also, we may be trying to treat the > > symptoms here - what is your outgoing bandwidth? What is you maximum > > threads? What is your local and global query traffic and your psuccess? > > Maybe your node isn't getting much traffic? > > Another security issue: we probably don't want people to download all of > Freenet with sufficient bandwidth - it makes it far too easy to make > ubernodes.
Actually, we already have a mechanism to fetch keys near to a given key that could be used by an attacker to eventually download all of Freenet... announcement initial requests. An attacker would set up a node and repeatedly announce. Each time he gets a random keyspace area, and a bunch of keys in that area, and a bunch of references in other nodes' routing tables. Of course he'd have to constantly change his ID to make it work - but there are 65000 odd ports available on one IP connection, and he could recycle them; he might even be able to have multiple identities on the same port. So perhaps it would be useful to have a FindClosestKeys command, and not too dangerous? Of course then you need to figure out which keys would be useful - if you are trying to fill a node's datastore with keys useful to your perceived specialization you'd need to somehow figure out what it was. Announcement provides an initial specialization key, and a bunch of keys close to it to request; you could just request keys near that if you haven't had many requests; otherwise you could request keys near the peak on your global psuccess estimator... also could be used for wierd stuff like XOR encoding. Anyway, just a thought. Probably not a very practical one - but my earlier response to some suggestions as to how to fill the DS quickly on a new node not serving many requests with an empty DS made some false assumptions, I am clarifying them. -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
