[p2p-hackers] infinite loops

[Lucas Gonze]

I fiddled around with a fuzzy TTL technique where you mask your own ID 
into a bloom filter that travels along with the message, the idea being 
that you stop if you see your ID in there.  As the message propagates 
the filter is more and more densely populated, so that eventually the 
likelihood of a false positive is high enough that you have the same 
effect as with a TTL. 

What I was trying to produce was a way for nodes to recognize messages 
without spending memory and without increasing the size of the message.

...this was not incredibly productive, given that a real TTL does the 
same thing with a less complication, but maybe it is an idea that will 
inspire a better one.

- Lucas

Lemon Obrien wrote:

> the problem is, how long do you keep the message in the cache....you 
> can only genereate so many ids, and there are bound to be 
> conflicts...memory and how many messages per second is the node 
> recieving...each message needs to be stored.
>
> */Matthew Kaufman <matthew at matthew.at>/* wrote:
>
>     1. Your approach assumes that you want the message delivered as far as
>     possible within the network. In some networks this cache technique
>     is used
>     to reduce looping and redelivery *along with* TTL in order to
>     deliberately
>     limit the message delivery horizon.
>
>     2. Your approach assumes that originators can generate unique
>     message Ids.
>     This is easy to approximate but non-trivial to guarantee if you're
>     trying to
>     save memory or computation time. Consider the case of IP... What
>     would you
>     use as the "unique message ID"?
>
>     3. Your approach uses more memory in the client no matter how long the
>     message ID storage needs to be. The longer the potential message
>     lifetime,
>     the more memory it uses. The higher the message rate, the more
>     memory it
>     uses. The longer the message IDs, the more memory it uses. The
>     more complex
>     the lookup data structure, the more memory it uses. Also, doing
>     that lookup
>     is more computationally expensive, especially as the memory
>     utilization
>     grows.
>
>     In summary, if you want messages delivered as widely as possible,
>     and the
>     clients can generate unique message IDs, and the message rate is
>     low enough
>     that the CPU and memory requirements created at each client are
>     reasonable,
>     then sure, this works fine.
>
>     Matthew Kaufman
>     matthew at matthew.at
>     www.amicima.com
>
>     _______________________________________________
>     p2p-hackers mailing list
>     p2p-hackers at zgp.org
>     http://zgp.org/mailman/listinfo/p2p-hackers
>     _______________________________________________
>     Here is a web page listing P2P Conferences:
>     http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences
>
>
>
> You don't get no juice unless you squeeze
> Lemon Obrien, the Third.
>
> Discover Yahoo!
> Get on-the-go sports scores, stock quotes, news & more. Check it out! 
> <http://us.rd.yahoo.com/evt=32661/*http://discover.yahoo.com/mobile.html>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>p2p-hackers mailing list
>p2p-hackers at zgp.org
>http://zgp.org/mailman/listinfo/p2p-hackers
>_______________________________________________
>Here is a web page listing P2P Conferences:
>http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences
>  
>