Sorry definitely not anymore in this forum. Hope someone else can help you.

Does this mean you're leaving us again? Or are you just looking for yet another farewell party?

that's the gnutella family life, harmony & joy.

It's incorrect that the *.gnutellanet.com host caches and that all of the *.bearshare.net host caches drop 0.4 handshakes. I did several 0.4 handshakes with a gnutellanet and a bearshare.net host cache a few minutes ago and got replies from both. I wrote the code myself and was watching it with tcpdump as well as within the code so I'm 100% certain of this. I'm not sure that they all handshake only 0.6 all of the time, and that they always will, but I do know that both gnutellanet.com and bearshare.net still respond to 0.4 handshaking on some basis.

Their host cache is Java based, and has some problems handling more than 100 to 200 connections per second, this is why they closed it off.

I believe they are close to releasing a new client which doesn't rely on host caches at all, although I am very wary of this feature because it opens the network to more attacks.

AFAIK they released it, the new beta 2.5 is out but I didn´t test it yet...

And why it opens the network to more attacks, you should explain your statements!

Morgwen

Not at all, it works rather well. BearShare clients who enter the BearShare-rich portion of the network benefit from more files with hashes and Keep-Alive support.

Morpheus only added users to the Gnutella network, it did not take any away. Fortuntately, BearShare's clumping feature isolated our users from the many bugs in the Morpheus implementation of Gnucleus.

Rather doubtful. If anything, Shareaza will cause client developers to build in defenses against this client, since it allows users to have practically no limits on the number of Ultrapeers, download retries, etc...

Not forward thinking, and rather unfriendly to the network if you ask me.

Qtrax anyone?

Yes you are right its easier to block the clients instead of talking to them...

Morgwen

I believe their scheme hinges on sending GGEP-ed pongs with uptime information. The idea is that higher uptime addresses will be preferred over shorter uptime, to speed the connection process.

The problem with this scheme, is that a hostile entity can flood the network with bogus GGEP-ed pongs that claim very high uptimes. If the pongs have random IP addresses, it will greatly increase the bootstrap procedure and users will leave the network (or choose a different client).

On the other hand, our "anchor heartbeat" message is digitally signed, cannot be faked, and contains the addresses of known connectible Ultrapeers whose identities are secured. Fortunately, we are making the format of this message available to everyone so that even the open source servents can benefit.

This message, and others, are detailed by me in the GDF:
http://groups.yahoo.com/group/the_gdf/message/8222

You're welcome in advance, you can thank me for pushing Gnutella forward later (maybe around BearShare 5.0.0 or 6.0.0).

Have you talked to them? I don't see them in the GDF.

Comments like that, Morgwen, expose your bias against BearShare and your penchant for criticism over substance.