Gnutella Forums

Gnutella Forums (https://www.gnutellaforums.com/)
-   LimeWire Beta Archives (https://www.gnutellaforums.com/limewire-beta-archives/)
-   -   Solving the GnucDNA problem (in part) (https://www.gnutellaforums.com/limewire-beta-archives/24715-solving-gnucdna-problem-part.html)

et voilà March 23rd, 2004 02:06 PM

Solving the GnucDNA problem (in part)
 
Salut, everybody knows GnucDNA connects as UPs to Limewire UPs even if they are not real UPs with leaves. The clients include: Trustyfiles, Ayzoo, Webspider, Gnucleus (of course) and many others.

Here is my proposal:
-For the low outdegree clients, check the uptime header coming with GnucDNA clients: when the time is under 1 hour (could be 2), reject the UP slot as there is a 99% chance those UP aren't active one.

What do you think?

Ciao

stief March 23rd, 2004 03:02 PM

hmmm. Would limiting/kicking the hosts returning 0% in the QRP after 15 minutes do something similar?

et voilà March 23rd, 2004 03:30 PM

Salut Stief, voici ma réponse ;) : no because eliminating UPs with 0% QRP would eliminate even some LW ultrapeers as well as some legitimate UP not supporting high outdegree and QRP exchange like the ones of GTK-Gnutella.
Ciao

trap_jaw4 March 23rd, 2004 05:01 PM

Effectively, you won't ever see more than 3 connections from that kind of ultrapeers. Those three slots they may occupy are reserved for non LimeWire ultrapeers (and usually vacant). So, I don't think it is necessary to take any further measures against GnucDNA-based ultrapeers.

et voilà March 23rd, 2004 05:29 PM

Hi Trap Jaw, yes the problem is not really affecting LW with the 3 foreign UP policy, but my goal was to get some of the devs using GnucDNA to improve the Gnet part of it so they don't loose their users. I've done tests with the Gnucleus betas and 99% of the results in the first 15 seconds come from LW, after those seconds some RAZA results from G2 come in. The GnucDNA behavior is parasitic to LW, but of course that limit the number of GnucDNA clients, because the day GnucDNA clients take all foreign UP slots available, the new users will fly away from the GnucDNA because of the lack of results.... :p Time will tell.

Ciao

trap_jaw4 March 24th, 2004 01:20 AM

The GnucDNA dev (at the moment just John Marshall) is busy implementing Mike's Protocol and I don't think he will clean up his Gnutella implementation any time soon.

His implementation has been lacking for more than a year, - he never even so much as bothered resolving some of the issues with his software.

I think the more active Gnutella developers should simply move on to a new protocol version, breaking compatibility with the older servents.

et voilà March 24th, 2004 05:24 AM

Hmmm, I was talking about the devs of the apps that use GnucDNA, I know John only works on G2 since this summer. I saw yesterday a Openext.com (identifying as Gnucleus 1.8.4) that was advertising in his headers x-pong-catching 0.1 extension as well as x-query-routing 0.1... so maybe those devs are working on it....:eek:

À+

trap_jaw4 March 24th, 2004 06:04 AM

Quote:

Originally posted by et voilà
Hmmm, I was talking about the devs of the apps that use GnucDNA, I know John only works on G2 since this summer. I saw yesterday a Openext.com (identifying as Gnucleus 1.8.4) that was advertising in his headers x-pong-catching 0.1 extension as well as x-query-routing 0.1... so maybe those devs are working on it....:eek:

À+

Openext is just using Gnutella resources for its own file-sharing network. They are not sharing files with the rest of the Gnutella network and I don't think they are really trying to implement the latest Gnutella proposals.
I also believe they are also in violation of the GPL, - at least it is impossible to get any response from them, when requesting the source code which is only losely based on Gnucleus 1.8.4


All times are GMT -7. The time now is 10:59 PM.

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

Copyright © 2020 Gnutella Forums.
All Rights Reserved.