![]() |
|
Register | FAQ | The Twelve Commandments | Members List | Calendar | Arcade | Find the Best VPN | Today's Posts | Search |
General Gnutella Development Discussion For general discussion about Gnutella development. |
![]() |
| LinkBack | Thread Tools | Display Modes |
| |||
![]() 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 |
| |||
![]() Have a look at this thread: http://www.gnutellaforums.com/showth...&threadid=6006 |
| |||
![]() 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. |
| |||
![]() 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. |
| |||
![]() 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 |
| |||
![]() 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. |
![]() |
| |
![]() | ||||
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 |