Hi,

Am I correct in assuming that this model is fairly much independent of the
routing algorithm used, or am I missing the point completely?   I understand
that with your proposal a node needs to have sufficient trust to be able to route
but I am not clear how you decide to route to a node.

Ed 

On November 30, 2003 10:29 am, [EMAIL PROTECTED] wrote:
> Nodes A,B,C,D all have 15 ecounds of trust in each other.
> A wants some data.
> Routs it to B with TTL of 10.
> B docks A 14.14 trust.
> 1 secound passes.
> B routes to C with a TTL of 9.
> C docks B 12.73 trust.
> 1 secound passes.
> C routes to D with TTL of 8.
> D docks C 11.31 trust.
> 1 secound passes.
> D returns the data.
> D adds .04428 Trust back into C's account.
> C passes the data allong to B.
> C adds .158117 Trust back into B's account.
> B passes the data allong to A.
> B adds .3218 trust back into A's account.
> A adds 13.82 Trust into B's account.
>
> A gets the Data in 3 secounds when it asked for 10.
>
> *The Formula for Trust is (2*TTL^2-ReturnTime^2)^.5
> *Every node In the chain has a net Trust gain.
> *The Requeter has to pay for it's request.
> *No node gives out more trust than it receives.
> *Nodes are greedy and accept querrys on the baisis of personal profit.
> *The faster a node can fetch data above the rest of the nodes on the
> network the more it profits. *Returning Data from your store is very
> profitable.
> *The more Greedy the network becomes the faster it routes.
> *All data will be fetched in 1.414 * TTL time or fail.
> *Nobody can launch a DOS attack.
> *If a node rejects your request it indicates that it cannot fetch that key
> in that TTL profitable. So you learn about specilization even if you don't
> get the data. *You keep retrying nodes to see if anyone will take the
> request untel it would not be profitable to you even if they returned in
> TTL time. Then you reject. *A request for data that is not in the network
> uses the maximum ammount of resources, and costs the requester the maximum
> ammount. *No intermediate node can be cheated, unless they drop data, or
> dirmaticaly slow it down on the return path.
>
> Please read my proposial for more details. It still need review. Also think
> of ways of injecting trust in the first place. I have 2 but more couldn't
> hurt.
>
> > [EMAIL PROTECTED] wrote:
> > > LOL, yeah. This is exactly what you and Toad were talking about, plus
> > > lots of other goodies thrown in. I was so busy writing this that I
> > > wasn't reading my email, now as I look back through, I see the two of
> > > you were descussing many of the issues that I struggled to sort out
> > > to write this. It was realy a let down to see that this wasn't going
> > > to be totaly unexpected.
> > >
> > > Anywho, It ammounts to killing querys baised on time, not HTL. It
> > > makes Freenet a positive trust baised network, (read the archives) I
> > > bleeve I responded to you a few times talking about some of the
> > > implications of this. It eliminates pDNF entirely, which I had come
> > > to the conclusion was causing NGrouting to fail. It eliminates
> > > vunerability to Black Hole nodes, which I did not know existed, when
> > > I wrote this. It impliments proportional querry rejecting. (see the
> > > archives where I post sample data talking about a split lifo/fifo
> > > system.) It also enables QRing baised on key, etc.
> > >
> > > Toad: Please give this a very thourough look over. But I think this
> > > should be a general solution to most network problems / flooding
> > > attacks.
> >
> > It would still help if you could give an illustration of how your system
> > works.
> >
> > -Martin
> >
> >
> > _______________________________________________
> > Devl mailing list
> > [EMAIL PROTECTED]
> > http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
> _______________________________________________
> Devl mailing list
> [EMAIL PROTECTED]
> http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to