Yes, I agree - I would like to see BOTH SIDES of the coin, if it doesn't harm the network, then prove it, if it does, prove it.

Sanelson,

what do mean exatly? Shareaza has no auto-queries like Qtrax...

I ask already some people to check this client!

Morgwen

EQHD
 

What's the EQHD format? Or at least, what's the vendor ID?

Hey,
Shareaza is REALLY good indeed.
Finally there's a program where I still have
some control and where I know what is going on.
Shouldnt we open a forum especially for Shareaza too
since its a gnutella client?

Moak suggested this already:

http://www.gnutellaforums.com/showth...threadid=12722

Morgwen

Re: EQHD
 

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.

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 :D

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.

@ 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

It would take up otherwise "free" connection spots.