Only Bearshare-UPs - why was vendor limiting dropped?

View: New views
5 Messages — Rating Filter:   Alert me  

Only Bearshare-UPs - why was vendor limiting dropped?

by Rossi-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hallo everyone,

I have noticed some time ago that I have (nearly) only bearshare
ultrapeers in my list, and limewire only as leaf nodes. I would like to
have a more broadly selection of UPs to communicate with; not to speak I
have never liked VF of bearshare.

Can anyone tell me how that comes?

I have also noticed I cannot anymore limit vendor slots (here: 0.96.5),
and on the gtk-gnutella homepage it is said this feature is no more
operational. Why is that so?

Best regards,
Christian

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gtk-gnutella-users mailing list
gtk-gnutella-users@...
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-users

Re: Only Bearshare-UPs - why was vendor limiting dropped?

by Christian Biere :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Rossi wrote:
> I have noticed some time ago that I have (nearly) only bearshare
> ultrapeers in my list, and limewire only as leaf nodes. I would like to
> have a more broadly selection of UPs to communicate with; not to speak I
> have never liked VF of bearshare.

Shut gtk-gnutella down.
Delete hosts, hosts.orig, ultras, ultras.orig from ~/.gtk-gnutella.
Restart gtk-gnutella.

> Can anyone tell me how that comes?
 
> I have also noticed I cannot anymore limit vendor slots (here: 0.96.5),
> and on the gtk-gnutella homepage it is said this feature is no more
> operational. Why is that so?

The feature is only disabled in so far that the default settings make
it ineffective. You can still use the feature by setting the values
appropriately.

--
1000 octets   = 1 ko = 1 kilooctet; 1024 octets   = 1 Kio = 1 kibioctet
1000^2 octets = 1 Mo = 1 megaoctet; 1024^2 octets = 1 Mio = 1 mebioctet
1000^3 octets = 1 Go = 1 gigaoctet; 1024^3 octets = 1 Gio = 1 gibioctet

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gtk-gnutella-users mailing list
gtk-gnutella-users@...
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-users

Re: Only Bearshare-UPs - why was vendor limiting dropped?

by Rossi-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Am Dienstag, 13. Mai 2008 schrieb Christian Biere:

First let me say you many thanks for your fast answer; I would not have
expected this, as the list seems to be a bit un-frequented in the last
times. I am glad to see this is not so!

> > I have noticed some time ago that I have (nearly) only bearshare
> > ultrapeers in my list, and limewire only as leaf nodes. I would like
> > to have a more broadly selection of UPs to communicate with; not to
> > speak I have never liked VF of bearshare.
> Shut gtk-gnutella down.
> Delete hosts, hosts.orig, ultras, ultras.orig from ~/.gtk-gnutella.
> Restart gtk-gnutella.

Done! And now I do not have anymore Bearshare 6.xx (which I have never
trusted), but a more diverse 'ökosystem' with mostly limewire (to be
exact: nearly only limewire). But I think I have to let it run for some
days again.

And I fear I have done such in the past, but I have only deleted hosts*,
not ultras* - sorry; I could have thought of that on my own.

> > I have also noticed I cannot anymore limit vendor slots (here:
> > 0.96.5), and on the gtk-gnutella homepage it is said this feature is
> > no more operational. Why is that so?
> The feature is only disabled in so far that the default settings make
> it ineffective. You can still use the feature by setting the values
> appropriately.

Again, sorry: I have not noticed this was set to defaults which had no
effect - but that little tip had done the trick, so to say. Question to
the list: Which values would be deemed correct to have a
diverse 'ecosystem'? I have set the threshold to 40%; too much or too
less, what do you think? And does this apply to '40% of a version of a
program' (for example: 40% say Limewire 4.16.6) or '40% of a vendor'?

Also the threshold '10% for gtk-gnutella' does not seem to have any effect
after 2h, but perhaps this amount of time is not enough - are
gtk-gnutella clients so seldom on the net? Has anyone client statistics
to point me to?

By the way I have noticed the german translation is not complete. If that
would be wanted I would gladly volunteer to fill in the missing
translations. Please let me know how I can do that - if wanted.

Best regards,
Rossi

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gtk-gnutella-users mailing list
gtk-gnutella-users@...
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-users

Re: Only Bearshare-UPs - why was vendor?limiting dropped?

by Christian Biere :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Rossi wrote:
> Am Dienstag, 13. Mai 2008 schrieb Christian Biere:
>
> First let me say you many thanks for your fast answer; I would not have
> expected this, as the list seems to be a bit un-frequented in the last
> times. I am glad to see this is not so!

Your observation is correct. It isn't really frequented.

> > > I have noticed some time ago that I have (nearly) only bearshare
> > > ultrapeers in my list, and limewire only as leaf nodes. I would like
> > > to have a more broadly selection of UPs to communicate with; not to
> > > speak I have never liked VF of bearshare.
> > Shut gtk-gnutella down.
> > Delete hosts, hosts.orig, ultras, ultras.orig from ~/.gtk-gnutella.
> > Restart gtk-gnutella.
>
> Done! And now I do not have anymore Bearshare 6.xx (which I have never
> trusted), but a more diverse 'ökosystem' with mostly limewire (to be
> exact: nearly only limewire). But I think I have to let it run for some
> days again.

I don't know what BearShare 6.xx is. Normally, 6.xx is neither BearShare
nor Gnutella at all but some iMesh mod on iMesh's own network.

> And I fear I have done such in the past, but I have only deleted hosts*,
> not ultras* - sorry; I could have thought of that on my own.
>
> > > I have also noticed I cannot anymore limit vendor slots (here:
> > > 0.96.5), and on the gtk-gnutella homepage it is said this feature is
> > > no more operational. Why is that so?
> > The feature is only disabled in so far that the default settings make
> > it ineffective. You can still use the feature by setting the values
> > appropriately.

> Again, sorry: I have not noticed this was set to defaults which had no
> effect - but that little tip had done the trick, so to say. Question to
> the list: Which values would be deemed correct to have a
> diverse 'ecosystem'? I have set the threshold to 40%; too much or too
> less, what do you think?

Anything between 30% and 50% should be fine. There aren't many different
vendors and 80% or more of all peers use LimeWire. This means you can enforce
very little diversity. It would actually be very unhealthy if all peers tried
to enforce it because it's simply not possible. It would cause an endless and
pointless churn.

> And does this apply to '40% of a version of a program' (for example: 40% say
> Limewire 4.16.6) or '40% of a vendor'?

The code compares the identification up to the first non-letter.

> Also the threshold '10% for gtk-gnutella' does not seem to have any effect
> after 2h, but perhaps this amount of time is not enough - are
> gtk-gnutella clients so seldom on the net? Has anyone client statistics
> to point me to?

My gut feeling tells me there are about 1-2 dozen gtk-gnutella ultrapeers and
maybe a hundred gtk-gnutella peers in the whole network.
 
> By the way I have noticed the german translation is not complete. If that
> would be wanted I would gladly volunteer to fill in the missing
> translations. Please let me know how I can do that - if wanted.

https://gtk-gnutella.svn.sourceforge.net/svnroot/gtk-gnutella/trunk/gtk-gnutella/doc/devguide/I18N

--
1000 octets   = 1 ko = 1 kilooctet; 1024 octets   = 1 Kio = 1 kibioctet
1000^2 octets = 1 Mo = 1 megaoctet; 1024^2 octets = 1 Mio = 1 mebioctet
1000^3 octets = 1 Go = 1 gigaoctet; 1024^3 octets = 1 Gio = 1 gibioctet

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gtk-gnutella-users mailing list
gtk-gnutella-users@...
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-users

Re: Only Bearshare-UPs - why was vendor?limiting dropped?

by Rossi-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Am Dienstag, 13. Mai 2008 schrieb Christian Biere:

> Anything between 30% and 50% should be fine. There aren't many
> different vendors and 80% or more of all peers use LimeWire. This means
> you can enforce very little diversity. It would actually be very
> unhealthy if all peers tried to enforce it because it's simply not
> possible. It would cause an endless and pointless churn.

Ok, then I will let this be at 40%, and simply wait, and sometimes kick a
specific vendor manually if I think it gets too mono-culturally.

> > And does this apply to '40% of a version of a program' (for example:
> > 40% say Limewire 4.16.6) or '40% of a vendor'?
> The code compares the identification up to the first non-letter.

Thanks; good to know!

> > Also the threshold '10% for gtk-gnutella' does not seem to have any
> > effect after 2h, but perhaps this amount of time is not enough - are
> > gtk-gnutella clients so seldom on the net? Has anyone client
> > statistics to point me to?
> My gut feeling tells me there are about 1-2 dozen gtk-gnutella
> ultrapeers and maybe a hundred gtk-gnutella peers in the whole network.

This cannot be! I have phoned some friends as I got curious, and six of
them are currently running gtk-gnutella as an ultrapeer right now, and I
have installed gtk-gnutella elsewhere more than 30 times, and I am not
the only one running linux here. And at least locally here gtk-gnutella
is the preferred servent (I took to that). I also cannot believe that our
little town here covers 25% of gtk-gnutella ultrapeers, so to say.

We wondered whether it would be nice to connect to each other as
ultrapeers and make a screenshot to please you and the developers, but
then we thought that would be of no point as our connection lists are
full and we deemed it unwise to kick other people just for a screenshot -
but we will do if that soothes the developers maybe.

No, I cannot believe your estimation.

> > By the way I have noticed the german translation is not complete. If
> > that would be wanted I would gladly volunteer to fill in the missing
> > translations. Please let me know how I can do that - if wanted.
> https://gtk-gnutella.svn.sourceforge.net/svnroot/gtk-gnutella/trunk/gtk
>-gnutella/doc/devguide/I18N

Thank you; tomorrow I will take a look and do some needed translations in
the next weeks. I am a bit busy right now.

Best regards,
Rossi

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gtk-gnutella-users mailing list
gtk-gnutella-users@...
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-users