Gnutella protocol to sloppy?
 

Well first of all i would like to know something about TTL, what value is the standart (the mostly used) when you send a msg?
Why is TTL usefull? I did some thinking and i have a question, when one recieves a Ping what shoul one do? Decrement the TTL, increase the Hop pass it on to others then reply to sender a Pong is that right? well if i put a TTL=255 then with all the replies to the first ping isn't that just an expense of bandwith? Why don't you just send TTL=1 and make a new type of MSG where in the payload you put your address and the servents wich are connected to you, the reply to this message is the same and after one get's the reply it connects to all the servents that the other node is connected to, thus creating a MESH (logic) topology where all the nodes are connected to each other, so no one passes on msgs it just reacts to the connected node, i think that this would dramaticly decrease the bandwith usage but also the way gnutella works...
I don't know how much right am i so please reply, someone that knows how all this works could explain me. I think i understood all wrong, yet here's just one idea (wich is by far explained).
Waiting for a reply:

I sort of understand it myself, but not enough to comment with any such accuracy.

Have you thought about the connection issues? I mean like instead of TTL=51 and 5 connections, having TTL=1 and 255 connections, gnutellas size varies in the hundreds of thousands, can the average users system handle connecting to that many nodes at one time, what happens if several of these nodes send data at once, what happens to the bandwidth then? What about firewalls and routing in VPNs? And right now Gnutella allows you to specify the number of connections (where you connect to others) and the number of allowed connections (allow others to connect to you). If you look at limewires network size graphs...

http://www.limewire.com/index.jsp/size

You will see that around 1/8th accept incoming connections, that means if they connect to 8 hosts, they allow only 1 host to connect to them on average.

I'm getting the impression that you are looking to have computers cache their connections list and then send them instead of passing along pongs...

Clip2 also has something called a reflector... A reflector acts as a super node which passes info along to computers below it... the only problem is that you would always need some central computers that would have higher TTL's inorder for someone out there to have any sort of cache...

What really should be done is query caching that would reduce the network traffic alot... limewire has a proposal on their site about this... I don't think that caching IP's would help because then you would be sending larger pongs less frequently instead of smaller pongs more frequently... and the you'd only be saving some of the header info for bandwidth...

As for standard I think most clients come with them set TTL = 7, some like Limewire have the nice option of keeping others below a certain TTL... so you don't get outragoeus TTL's from some people...

In regards to the connections vs. TTL basically TTLs give you exponential growth on the network and connections are more or less linear... a quick example...

Connection = 5
TTL = 4

Assuming every node has the same settings you would see 5^4 nodes or 625 nodes...

Increase the connection to 6

Connection = 6
TTL = 4

Once again assume all nodes on the network have the same settings this would give you 6^4 or 1296 nodes

now instead increase the TTL to 5 and keep the connections the same

Connection = 5
TTL = 5

Assuming all nodes have the same config... now you see 3125 nodes... increasing the TTL gives you far more of a horizon...

from the example... Connection = 255 and TTL = 1 would give you only 255 people to search from.... a TTL = 51 and 5 connections would give you 4.4 * 10^35 connections... that's more connection than are possible on the current network...

the graph dictates which clients can accept new incoming connections... ie: if you have a Gnucleus it gives you a min and a max connection numbers... the min is how many people Gnucleus will proactively connect to... the max is how many open connections you will accept at one time... so lets say you set min = 5 and max = 7... gnucleus will connect it self to 5 people... then after those are set up it will accept 2 more... once those are full gnucleus stops accepting incoming connections... and then the person running the program drops off the "accepts incoming connections" graph... so really it's not a count of how many people have incoming connections its a count of how many people will accept "new" incoming connections... some other people in the other portion of the graph may have only incoming... after about 1/2 hour most of my connections are incoming anyways...

TTL is the standard way of putting a limit on the number of hops a packet can be passed. Setting a TTL to 7 sets your Horizon to 7 hops.

This means that you can't "see beyond" 7 host hops. If we did not have a TTL or similar mechanism every packet would be passed on forever.

This would result in an everincreasing number of packets on the internet. If no packets were ever discarded the number of packets would very quickly shutdown every router on the internet.

Hope this helps :cool: