According to the author the format is the following:

> Yep, Shareaza uses RAZA. I think I plugged it into their
> database.
>
> For anyone who is interested, the private EQHD is one byte
> long and the LSB represents P2P chat availability. That's exactly
> the same as LimeWire, which is why you can chat with
> Shareaza and LimeWire hosts. I think the whole chat thing has
> a lot more potential than what they've done so far, but its a
> start I guess. Shareaza's chat implementation allows IRC style
> nicknames and /me 's, but that's as far as I extended it.
>
> The public area contains the usual host flags and plaintext or
> deflated XML.

This quote is from their forum at www.shareaza.com.

__________________
Black Holes are where God divided by zero.

Hmm, OK, well, that's what I read somewhere. If this is true, then it's not AS BAD.

However, what about all the other things that I mentioned? You know.. the things that give you such great search results. Connecting to hundreds of UP's, changing the TTL and expire time to whatever you want, etc. These things are supposed to have limits! That's why no other Gnutella client today (I may be wrong, but no popular ones, anyway) let you change these values. Bearshare and Limewire, will let you change the number of UP's but they have LIMITS. The Bearshare 3.0.0 Betas had unlimited UP's for a long time. Last week, I mentioned in a post on Bearshare.net, how this could harm the network if it was left in upon release, and it was limited to 10 in the next Beta. I guarantee you, if Vinnie would have left the limits out of the release, there would be a hundred people here slamming him.

Now, imagine, if you will, a world where Shareaza is the predominant Gnutella client. The average leaf is connected to, oh, let's say 75 Ultrapeers at a time. Now, it may take 10 minutes or so, for newcomers to find an Ultrapeer to connect to, but that's OK, because everyone has "maximum exposure" on the network.

Now, I won't try to fool you. I don't know enough about how gnutella works to tell you how changing the TTL and expire time can harm the network, but what I do know, is that they're not supposed to be changed. That's why none of the other clients out there let you edit these values anymore. I'm prety sure it has something to do with flooding the network. Could someone else out there please explain?

TTL = Time To Live = expire time

If you sent the value to high and try to send it, most servants will (should?) either change the value or drop the packet.

I think a real problem is that it allows large packets to be passed around the network by default. This is really bad for modem users.


My experience with this client has not been so good.

1) Plenty of search results but the downloads seem to hang before they get started.

2) Have yet to upload anything after running it for 3 days in ( 1 day in normal mode, 1 in leaf mode and 1 in ultrapeer mode ).

3) Another rather stupid bug is the fact that the client will connect to itself multiple times through the local lookback address (127.0.0.1) if it has that address in its cache. I attached a screenshot if you want a good laugh (72k zip). Look at the packet
counts and times you can match the in/out connections

4) If you connect to a number of clients ( around 20 or so ) in normal mode and open the packet monitor then try to change the packet types the program seems to lock up.

5) The program also crashes almost every time I close it.

If 3, 4, and 5 were fixed or explained it would be a decent client, but as far as it being better than any other client I would have to disagree.

Attached Files

shareaza.zip (72.3 KB, 60 views)

@ Sanelson

About this TTL, AFAIK the GDF developers agreed to a highest TTL of 7 because higher values are not reliable but this doens´t mean that higher values harm the net!

Please correct me if I am wrong.

About the Ultrapeers, I can´t see here a problem either... how should it harm the net if you are connected to hundreds of Ultrapeers (if possible)?

Morgwen

__________________
patience is a virtue

It would take up otherwise "free" connection spots.

Lets assume that every node on the network have connected to four other nodes. Then, if you rise the TTL by one, your message will reach four time more nodes. If enough clients use too high TTL values, the network will be crippling because of too high traffic.

The more UPs you're connected to, the more queries and query replies you send to the network. If all users would be connected to least 50 UPs, the network would be crippling again because of too high traffic. It simply doesn't make sense to let people use too many UPs at once.

__________________
Some day I'll find peer and reset his connection.

Imagine you have 1000 clients connected to 100 ultrapeers each, let's further assume each ultrapeer is capable of holding 100 connections. - That means the overall ratio of ultrapeers to leaf nodes is 1:1, in which case you could as well stick to the classic gnutella scheme without any ultrapeers.

Yikes, thought you knew that one

The higher the TTL, the more clients it will reach, the more traffic it will generate, the more people will be complaning - usually in that order

Nevertheless, you can set the TTL to 255, but it won't get passed most modern Gnutella clients at around hop 6 or 7. The early version of NullSoft's Gnutella (0.54 i believe) had a bug in it, which it didn't lower the TTL. Messages just kept going on, causing the network to get really messed up.

__________________
Okay, so I've been gone a while - but hey, meanwhile online translators have gotten better:

Ce n'est pas ma faute. Blâmer vous-même.

----

Ne me blâmez pas. Blâment votre individu.

Tshdos, Kaapeli, and Taliban pretty much summed it up for me.

Like I said though, it's not the default setting that are hurting the network... It's the possiblilities...

Shareaza’s configurability is based on my philosophy that giving users as much control as possible is beneficial to everyone, and definitely the way to go on a “free” network like Gnutella.

The danger I see in “closed” systems such as FastTrack is that the parameters are determined by the organisation supporting it, and serve their goals rather than yours. For example, its not unusual for P2P clients to disrespect the user’s wishes in terms of the maximum number of uploads they are willing to serve, just to reduce the chances other users will get a busy signal. Making downloads more reliable is definitely a good cause, but that’s not the way to do it. Download queuing, source meshes, etc – those are much better solutions, and that’s the way the Gnutella network is innovating.

Yes, a malicious or perhaps selfish user could change Shareaza’s settings in a non-productive way if they so desire. But the great thing about Gnutella is that every node is autonomous, and performs an independent policing role. If someone sets Shareaza’s default TTL too high, the vast majority of good servents (including Shareaza) will drop it on the next hop. If you set a download retry delay too short, the host will disregard your requests. But by allowing users to change these types of settings, Shareaza lets everyone optimise their own performance – now, and in the future as the Gnutella network evolves. You’re not stuck with some settings that were forced on you “for your own good”.

I think on a free network like Gnutella it’s important to empower the people who are the network. Sure, some people might try to abuse this power, but that’s why servents take on a policing role too.

I haven't tried your client, but I use gtk-gnutella, and its authors have the exact same philosophy as you have.

All the things you described as being configurable in your client, I can configure in gtk-gnutella.

I can even define the maximum size of messages to accept and relay, but this is not a GUI settings, and must be done manually in the config file. I use it to limit queries to 128 bytes, in effect dropping all those verbose XML queries from LW.

Commenting!

-- Peer

You mean you are blocking the xml query replies, - LimeWire's xml queries usually don't reach that size.

__________________
Ich verabscheue euch wegen eurer Kleinkunst zutiefst.

I'm glad you feel that way, so you will be GPLing Shareazas source code soon I expect?
With open source your client will live forever and will get the benefit of a whole community of developers that will contribute more features and source code to it.
Users will be further empowered because they can easily change things they want to without waiting months for the change. Security will be assured when new anon protocols arrive through peer review of your code.
Another GPL client on Gnutella would be wonderful!
Yes, yes, yes!

He was talking about the protocol being open. FastTrack is a closed protocol (proprietary), owned by one company, licensed to other companies (like Kazaa).

__________________
Okay, so I've been gone a while - but hey, meanwhile online translators have gotten better:

Ce n'est pas ma faute. Blâmer vous-même.

----

Ne me blâmez pas. Blâment votre individu.

Thanks abaris

__________________
Okay, so I've been gone a while - but hey, meanwhile online translators have gotten better:

Ce n'est pas ma faute. Blâmer vous-même.

----

Ne me blâmez pas. Blâment votre individu.