Gnutella Forums  

Go Back   Gnutella Forums > Gnutella News and Gnutelliums Forums > General Gnutella Development Discussion
Register FAQ The Twelve Commandments Members List Calendar Arcade Find the Best VPN Today's Posts

General Gnutella Development Discussion For general discussion about Gnutella development.


Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old January 15th, 2002
Unregistered
Guest
 
Posts: n/a
Lightbulb Possible improved host cache idea

Suggestion for a possible improvement to gnutella protocol:

I have used various gnutella-compliant clients on both linux and windows platforms and it seems like a lot of the programs' resources are spent on locating other hosts. Perhaps an addition to the gnutella protocol could include some algorithm that would allow for the possibility of hosts that have been online for an extended period of time (say 5 minutes or more to cache their lists of hosts / hops / ping-time / timestamp to an array of not more than say the 64-128 most reachable hosts from their point online and "hand" (i.e. transfer) this array of cached hosts to neighboring hosts so they do not have to "discover" the hosts that have already been discovered by other hosts close by... I do not know if this idea has any merit but I would love to hear from the developers of gnutella appz if you decide to use it. My contact information can be easily found on my web site as I myself am a freelance computer consultant:
max.weissman.com
Reply With Quote
  #2 (permalink)  
Old January 16th, 2002
White Magician
 
Join Date: November 20th, 2001
Location: Hannover, Germany
Posts: 25
guido is flying high
Default

Have a look at this thread:
http://www.gnutellaforums.com/showth...&threadid=6006
Reply With Quote
  #3 (permalink)  
Old January 17th, 2002
Enthusiast
 
Join Date: November 18th, 2001
Location: Munich, Germany
Posts: 40
hermaf is flying high
Default

Just wanted to mention that qtella builds its PongCache like that. It is easy to addept to what your suggestions are. Just if you want to have a look at that ...
Reply With Quote
  #4 (permalink)  
Old January 17th, 2002
Connoisseur
 
Join Date: August 9th, 2001
Location: Philadelphia, PA, USA
Posts: 358
cultiv8r is flying high
Default

That's why I implemented the "X-Try" header a long time ago. It'll reduce the need for "ping/pongs" in order to find more hosts. On each connection, whether the other node accepts this node or not, the node will receive a number of new hosts to try.
Reply With Quote
  #5 (permalink)  
Old January 18th, 2002
Unregistered
Guest
 
Posts: n/a
Default Re: Possible improved host cache idea

I've got another idea.

You would need an algorithm to decide which are the fastest and best accessible Ultrapeers.

So every 30 Minutes or so, every ultrapeer sends the IPs of all peers it currently has outgoing connections to + a number of top ranked ultrapeers in his own host cache (I will explain later how that could be created) through all his incoming connections (including leaves).

The incoming/outgoing distinction is done, because we don't want peers, who don't allow incoming connections to profit of this algorithm.

When a servent receives such an host list, it adds them to its host cache and keeps counting which hosts his has been sent most often during the last 5 hours. If any servent wants to connect to a new host, it tries the first host on its list. If it fails (=the host is unreachable and NOT the host does not allow further incoming connections, for in that case it will send a number of hosts, ideally hosts it is currently connected to via X-Try), this host is deleted from the host cache.

Thus you will have a couple of good hosts throughout the gnutella network, which everyone would connect to. This would keep the network together tightly and might even allow the network to stay online easily if all big gnutella host cachers are being shut down.
Reply With Quote
  #6 (permalink)  
Old January 19th, 2002
Unregistered
Guest
 
Posts: n/a
Thumbs up

Yes, I like that idea, however I am unsure of the details of how it would be implemented. Some pseudo-code might help explain, perhaps.

In any case it sounds like your proposal would allow for any ultrapeer to promote itself to a de-facto "dns" of sorts (excuse the improper jargon) if it has a lot of good hosts cached and would therefore allow the network to truly function as a -pure- P2P rather than relying on a designated/centralized server for it's host cache but would still maintain the bennefits of having a centralized hosts cache this way.

Some details on a specific implementation would be next I suppose and I would think that it would be especially important to target low bandwidth (i.e. modem connections) for the main ones requiring assistance from this type of system as high-bandwidth connections would not have problems finding peer hosts, as much, to begin with.

- max
max.weissman.com
Reply With Quote
  #7 (permalink)  
Old January 19th, 2002
Unregistered
Guest
 
Posts: n/a
Default

Pseudo-code is ungood, since I'm not really a good programmer. But I will try to write it mathematically.

A,B,C,D,E,F be ultrapeers
In(A)={D,E} // incoming connections
Out(A)={B,C} // outgoing connections
Out(D)=Out(E)={F}
Out(D)=Out(E)={A}

I will assume that none of those ultrapeers fails.

A will receive F from B & C, so it will save F in his hostlist with a score of 2 for example

B->A = Out(B) = Out(C) = C->A

=> Hostcache(A) = {(F,2)}

To E & F, A will send Out(A) and the top ranked hosts from his hostlist.

A->F = A->E = Out(A) U max(Hostcache(A))

=> Hostcache(E) = Hostcache(F) = {(F,1), (B,1), (C,1)}

Another example: An Ultrapeer A is having 10 incoming Ultrapeer-Connections and no outgoing connections. Let's assume that each of the nodes connected to A are having 6 connections, of which one is going out to another node connected to A, one is coming in from another node connected to A, one is going out to A, and three are coming in from other ultrapeers. That means each node connected to A is sending on A's address and the address of another host connected to A.

An Ultrapeer that has two outgoing connections to hosts which are connected to A, will receive A's address two times, that means A will quickly advance to the top of the hostcache-ranking and thus A will be propagated further throughout the network.

Let's assume A was online 24/7, so it's address would never be deleted out of the hostcaches. A leaf-servent which was connected to the network a couple of days ago for the last time but knows the address of A can now easily (without needing the gnutella host cachers/routers) connect to A. A probably won't accept further incoming connections, so it sends a deny-message to the leaf-servent. This deny-message contains the addresses of other ultrapeers (as it is implemented in the gnutella 0.6 handshake-protocol), ideally those ultrapeers it is currently connected to.

If there are more hosts like A throughout the network which everyone knows, reconnecting is almost failsafe, even without connectX.gnutellanet.com. It would be impossible to shut gnutella down.
Reply With Quote
Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Improved browse host function Unregistered New Feature Requests 5 August 22nd, 2002 02:43 AM
gnutellanet.com Host Cache Unregistered General Gnutella Development Discussion 8 July 21st, 2002 12:15 PM
host cache Unregistered General Gnutella / Gnutella Network Discussion 3 March 30th, 2002 05:49 PM
host cache Jebus Newtella (Windows) 0 March 2nd, 2001 09:43 PM
host cache kas Gnotella (Windows) 1 August 4th, 2000 12:31 AM


All times are GMT -7. The time now is 06:59 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2025, vBulletin Solutions, Inc.
SEO by vBSEO 3.6.0 ©2011, Crawlability, Inc.

Copyright © 2020 Gnutella Forums.
All Rights Reserved.