This thread is going into a blatant Limewire commercial.

The technical things become mixed up, at the end it looks like Limewire never had or never lied about Spyware/Scumware, clustering of Limewire-only-clients is needed because of a over-complex less-efficient Superpeer concept (which Ultrapeers are IMHO), the commercial vendors do have a friendly politics and do not disadvantage other. Best rumours I heard this week. Gnutellaforums become as controlled as GDF is, I'm sorry that technical skilled developers do not speak up. Even if the pro speaker flood with more posts....

...you can't ignore Gnutella development is snail slow, inefficient and you can't ignore users and developers are unpleased about Bearshare/Limewire, which causing a spilt in Gnutella.

This thread reminds me so much to Microsoft. First every new competitor will be ignored, when it grows it will be badmouthed, then tryed to be blocked and finally flooded with wrong information and propaganda. Making windows non-modular so the MS midware is a must have, is like creating an unnecesary strange superpeer concept so you need to cluster your own clients (even old clip2 reflector showed you don't). Well, with a big enough market share you can try to dominate with such politics, but this is not the Gnutella idea. I learned from MS/Unix, fighting against comercial propaganda makes less sense... instead we have to show it can be done better, more efficient and with more technical inovations.

Join a open source project and fight the greed.
Do not cooperate with Bearshare and Limewire, make Gnutella a fair place.

Have fun, Moak
--
"As I would not be a slave, so I would not be a master. This expresses my idea of democracy." (Abraham Lincoln)
"Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." (Aurelius Augustinus)

New thread to talk about Ultrapeers at
http://www.gnutellaforums.com/showth...threadid=10357
Morgwen, thanks but it's easy to just start a new thread.
Moak & Nosferatu, keep up the good work, thanks.
Adam, "They are constantly pushing us to add things like user registration, and we have repeatedly refused."
But you and the others may not always be there, and then corporate greed types will jump on the chance and we all get screwed.
I hope you can find a new, real job soon.

Moak, you've stated on IRC in no uncertain terms that you will not cooperate with anyone who disagrees with you. You've shown your unwillingness to even tolerate others speech by accusing Adam of flooding when he was just responding to your attempts to demonize Limewire.

You have a lot to learn about what it means to be part of a community. If you ever plan on participating in a group you're going to find very few people who agree with you on everything, and the few you're left with will be a rather boring group at that.

If you can't learn to accept diversity then you're better off starting your own proprietary network where you get to call all the shots.

It's been made clear by you and others that opensourcep2p isn't about freedom for people on the network. It is about the attempts of an ethically challenged few to splinter gnutella. You say it's about freedom of choice when what you mean is freedom for YOU to make the choices for other people. I heard a wonderful analogy on the #gnutelladev IRC channel about this idea of freedom of choice, "you can choose any color you want, as long as that color is blue."

Please explain further the analogy you are trying to make. It eludes me. Are you talking about developers' choice? Users' choice? What choice are we trying to make, and for whom?

Are you saying we are trying to force people not to use BearShare? Did you know BearShare 2.5.0 does not support connections to/from 0.4 level clients? Would you like me to list the 0.4 clients available and in use?

Do you want to know the reason I am even here?

I was happily using gnut for about 3 months. Then I stopped getting searches and downloads with gnut.

Now I know why. LimeWire it seems is not a lot better (than BearShare) - they still allow 0.4 clients to connect - up to 4 of them to an ultranode, with UltraNodes making up 1 in 80 LimeWire clients .. so in fact you get <I>up to</I> <B>one 0.4 connection to every 20 LimeWire clients on the network</B> .. and that is if they can't fill up their slots with other LimeWire clients. (In fact, this goes for 0.6 clients as well, anything which doesn't yet have Ultrapeer support).

Why even design the 0.6 handshake to be backwards compatible? They could have saved the time and just launched a completely new network and let us get on with it. Instead my gnut client spends all its time hammering at the door of LimeWire and BearShare clients which won't let it connect.

Sorry, but we are forced into this position, not us forcing 'the users' to do something. I am a user. I don't think any of you 'developers' had heard of this guy who launched the opensourcep2p idea before had you? Because he is a user.

We just got the sh*ts with the existing 'developer "community"' and the way it is 'growing' the 'gnutella' network. Growing on the gnutella network is more like it.

Nos

Nice try of mobbing, show me your IRC logs please.
I have helped the Gnutella community as long as it was fun & fair. What have you done?

Sorry guys, some of you are leaving the path of seriousity. I need to do some coding, that's more fun, yeah. You find a lot of infomation in this thread, I tried my best to show you an alternative sight about the raising commercial Bearwire-Gnutella-propaganda and how bad things run in Gnutella development.

I can't waste my time with fighting, there is no love, fun or improvement in it. Take some time (and your favourite cafeein) and judge on your own. Oh and do something (alter-na-tives), don't get paralyzed from all the greed, create something better and improve things! Btw Xolox will come back soon... *g*

Stay informed and happy sharing. Moak

[update] PS: Join our mailinglist or meet independend developers on IRCnet #gnutelladev [/update]

This is not true mrgone! He said he don´t want to spent his time in a project he don´t like!!!

I think its Ok when he search for a GOOD project to support, its his free choice to find a project that fits him!

Morgwen

You have to understand that this is the sanest thing to do for an Ultrapeer-enabled client. By aggregating to Ultrapeer-capable hosts, you not only get to see files from 1 but to 50, or 100, or even 200 hosts: the ultrapeer's own files plus all its leaves.

What does it mean? It means clients not supporting ultrapeers will become marginal. So just implement ultrapeers.

I don't believe LW is segregating. It will allow 4 slots for other ultrapeers and 2 to "legacy" clients. This allows to bridge the older clients, but does not leave much room for older clients to connect.

Yes, it's a shame. Do you have a better strategy to offer?

i agree with Raphael that noone seems to listen to anyone else. there are so many misunderstandings in this thread that you will hardly ever come to a conclusion. the best thing a moderator could do was to close this thread. but mr. unregistered would take that as just another proove of how corporate greed ignores freedom of speech. so perhaps some of these misunderstandings can be made clear.

First of, all there ARE misunderstandings on the Ultrapeer concept (from now on, i will use the term "old client" for a client that does not implement the ultrapeer/QRP proposal), which is in part due to LimeWire's terminology. I will try to explain some basics, i hope that Adam will correct me if i am wrong about something.

1) from the ultrapeer point of view, an "old client" is an ultrapeer node without leaves. it is NOT a leaf node without an ultrapeer. Indeed, an old client can never ever become a leaf node because leaf nodes have to use the QRP (Query Routing Proposal). QRP reduces bandwidth usage to ~10%. that means, if leaf nodes use QRP, ultrapeers can handle 10 times as many leaves, which indeed scales the visible horizon by a factor of 10. it would be ineffective as hell if "old clients" would be accepted as leaf connections. at the moment, Lime is the only servent that implements Ultrapeer/QRP proposal, that means that only Limes can become leaf nodes and only Limes can become Ultrapeers.

2) An Ultrapeer, however, can maintain as much connections to old clients as it wants, because an old client is, once again, nothing but an ultrapeer without leaves. about statistics, in a perfectly structured network, the whole network would consist of ultrapeers only, and every ultrapeer would shield up to 500 leaves, thereby multiplying the visible horizon by 500 (yes, that means that the users get 500 times more search results!). but gnutella will never be perfectly structured, as there are a lot of old 0.4/0.6 clients out there and as these clients cannot become leaves, they reduce the effect of ultrapeer scaling just as an ultrapeer would if it didn't accept leaves.

3) the critical issue about ultrapeer clustering is therefore the following: How many ultrapeer connections should go to other ultrapeers, and how many ultrapeer connections should go to old clients? in other words, what should be the ratio of Ultrapeer vs. Old connections? Adam has pointed out that a Lime Ultrapeer will maintain at least two connections to old clients no matter what. An Ultrapeer generally has about 6 Ultrapeer connections and, at the moment, 80 Leave connections. so at least one third of a Lime Ultrapeer's connections go to older clients. And at this point, i do agree with moak: One Third seems to be a bit low for that ratio. IMHO the ratio should be One Half. A clustering ratio of One Half would give an old client and a new client exactly the same possibility of connecting to an ultrapeer.

4) about how clustering might be selfish and how clustering might be beneficial: a clustering ratio of one half treats newer and older clients equally and seems to be a fair strategy to me.
a lower ratio would mean that newer clients can profit much more from ultrapeers than older clients can, as they are preferred over the others. for the end user, this means that Lime users get more search results than other users (others would also if they implemented Ultrapeers).
however, older clients would never get less results than they would without ultrapeers, it is just that a ratio below 0.5 helps the users of newer clients more than it helps the users of older clients. this is what Lime is doing, as their ratio is 0.33. Our marxist friend, Mr. Unregistered, calls that selfish, greedy and unethical. I disagree. Limewire put a lot of work (marxist key word) into developing and implementing ultrapeers, and now their users are the first to profit from it. as soon as other clients implement it, they are going to profit just as much as Lime does. This sounds fair to me. Furthermore, older client's searches ARE improved by ultrapeers, as the ratio is far from zero. it is just that newer one's searches are improved two times as much (0.66 vs. 0.33).

5) Last, i'd like to mention that Gnucleus does not have an ultrapeer system at the moment. Swabby announced that Gnucleus 1.7 will have one, but 1.7 has not been released, not even a beta version. So Lime is actually the only ultrapeer-supporting client for the time being.

Adam, I count on you correcting me if i got anything wrong, it has been some time since i read the ultrapeer and qrp proposals. note also that all this applies to LimeWire only and in no way to the clustering of Bearshare, which is a totally different story.

Swapper supports Ultrapeers, by the way.

-- Mike

PS: Where is this topic going? I can't make heads or tails!

it was deperatly needed. good luck with a surprising inefficient ultrapeer network. Gnutella wants to be the slowest filesharing system the next 12 months again, advantage RIAA will find better targets.