On Thursday 14 August 2003 10:10 am, Niklas Bergh wrote: > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Some Guy > > Sent: den 14 augusti 2003 14:44 > > To: [EMAIL PROTECTED] > > Subject: Re: [freenet-dev] (no subject) > > > > > Okay now my question is, how do you prevent node D > > > from sending the query back > > > to node C, thus wasting everyone's bandwidth and not > > > getting any closer to the > > > data, which is actually on node F? > > > > Oh ok, that's easy just store a small hash table of > > "key X request already processed" (actually it's > > message X), you'll only have to store a few entries in > > the table since a query should resolve in a "few" > > seconds and you can only recieve so many a second > > (bandwidth) anyway. When a node get's a request it > > has processed before it returns back a "failed" > > message which shouldn't decrement HTL. > > Isn't this what is called the 'failure table' (which is present in the > code already)?
Yes, the failure table does hold a list of keys that have recently come back DNF. But it's not for that reason, as, docs aside, freenet nodes do _not_ send requests down alternate paths when they fail. The only place this can happen is at the client. Nodes will, of course, send a request elsewhere if they fail to forward a request entirely (up to 40 times), but a request will never follow more than one path. Whether this is optimal or not is arguable, but after a little thought, I think it's close. --hobbs
pgp00000.pgp
Description: signature
