Great, another jackass.

Here's the whole post for those who are wondering:

---

> Each time my Bearshare client connects to a new servent, it sends
off
> a query (even if I have an empty temp directory). The TTL of this
> packet will vary, and so will the query payload, but it is always
141
> bytes. What is going on here? And what is the format/meaning of
> this query criteria?

This is a proprietary message that BearShare uses for determining the
version number, newer versions, and measurement of the FreePeers
horizon in the Statistics page.

Due to historical reasons, the TTL on these messages in rather
limited and therefore the FreePeers horizon has never been
particularly accurate (it is always low).

You can identify these types of encoded queries by noting that the
high bit of each character in the string is set to 1. Proper handling
of these messages is to skip the comparison of the query keywords
against local files, and broadcast or expire the message as usuall
(decrementing the TTL by one of course).

You may also see Query Hits descriptors that contain similarly
encoded data. These Query Hits descriptors can be identified by file
names which have the high bit set in all characters of the null
terminated string. For these messages, you should route them just
like a regular query hits message. If your servent supports passive
monitoring of search results, do not perform the usual comparison of
outstanding queries against these query hits, as the data does not
refer to a requestable file.

The information contained in these messages is proprietary and
confidential.

There have been many reactons to this proprietary technique. One is
that it "breaks" the Gnutella protocol, or is not compliant with the
protocol. However, nothing in the protocol specifies that queries
have to be for files, or that search results must contain files.
The "protocol" only defines the format of the messages so that
applications may be interperable. I designed the encoding scheme so
that it is easy to identify and deal with.

Some developers and users have raised objections to these messages,
claiming that they 'fragment the network' or some other junk.
However, we must recognize that in order for Gnutella to grow we must
embrace creative implementations and thinking "outside of the box".

In fact, LimeWire active blocks and drops these proprietary messages
that BearShare sends out, even in the latest version (1.4). This
happens despite the fact that the TTLs are low, and the over-
utilization problem that was present in December has long since been
eradicated. LimeWire drops these queries in all cases, even if the
TTL is low, according to recent tests.

Fortunately, Gnutella was designed for exactly this type of attack,
and the filtering of BearShare binary messages by the LimeWire
servent has in no way reduced the effectiveness or usefulness of the
messages (partly due to BearShare's market dominance).

Let me remind all of the developers in the group that so far I have
refrained from 'retaliatory' features because I believe it is not in
the best interests of the Gnutella network.

This having been said, there are several issues which have been
bothering me lately, all related to the LimeWire servent:

- Low timeout on download retries in LimeWire servent (currently 20
seconds)

Although at first glance, it seems like a nice cheesy way to improve
the download success rate, it is bad overall for the Gnutella
network. LimeWire blocks BearShare's special messages because they
think they are doing whats best for the network. Should a new
BearShare now block uploads to LimeWire because the low retry timeout
is detrimental to modem users?

Despite me having raised this issue as a problem a long time ago, the
latest version of LimeWire (1.4b) has not corrected this defect. The
GDF has also been completely ineffective in becoming a standards body
for saying with the proper timeout SHOULD be.

Do I need to take matters into my own hands again, or can you
knuckleheads get your collective acts together?

- Dropping of proprietary messages by the LimeWire servent

In order for the network to grow in rich technology and innovation,
this type of behavior is simply unacceptable. Although the bandwidth
issues were resolved rather quickly by me, LimeWire has seen fit to
not only take technical steps to harm the BearShare servent, but also
political steps by labeling them as "Garbage Queries" in the release
notes.

Should the next version of BearShare automatically strip the LimeWire
metadata proposal information from query hits before passing them on?

From http://www.limewire.com/future.htm#openprotocol
>any company or person can use [Gnutella] it to
>send or respond to queries

Apparently, any company except BearShare, based on the behavior of
the LimeWire 1.4b servent.

- "Spyware-free" label in the Feature Comparison about the LimeWire
servent

Do we really want to go there, gentlemen? We all know who is visiting
my forum. Preying on the ignorance of users, spreading
misinformation, and flaunting the negative attention BearShare has
received from my attempts to build a company from ground zero without
outside investors, is in poor taste. I have restrained myself from
reacting as I normally would, out of respect for my peers.

I would be willing to bet I could do a far better job of critizing
other servents in poor taste than anyone else could. Should I
continue to show restraint or should I invest some time in this
direction?

---

> :
> : The information contained in these messages is proprietary and
> : confidential.
>
> It's not very reasonable to expect others to route your proprietary
> and confidential information without some sort of prior agreement.

Sure it is. Since there are commercial interests, it is very
important to remain impartial with respect to traffic. Or else we
would end up with a software war.

See my example about stripping meta-data from search results before
passing it on - would you want that? I never agreed to meta-data so
why should I route it.

> True enough. But any plan depending on others serving your peculiar
> interests without some sort of prior cooperative arrangement is
liable
> to fail on that dependency.

The only dependency is on proper functioning and handling of messages
as per the Gnutella protocol. I think this is the baseline agreement -
everything else like proprietary messages or custom features is fair
game.

However, flooding the network is not a good idea either, which was an
early problem with BearShare. There are two issues, one is
overutilization of bandwidth, and the other is developing proprietary
features.

> : [20 second retry timeout] is bad overall for the Gnutella network.
>
> Can you make this case, please?

Yes. I had been getting reports from many users that claimed LimeWire
servents were making frequent requests for files. I didn't believe
it, so I turned on upload reports and sure enough, the number of
average LimeWire requests over a 24 hour time period more than
quadrupled from its previous values!

So what would be the logical response on my part? I would change my
retry interval to 10 seconds, then BearShare would have a better
chance.

If EVERYONE did this, we would quickly end up with no timeout in a
big game of one-upsmanship. I refrained from playing with the timeout
because it is counter productive. LimeWire got away with it because
their market share is so small, but if I were to reduce my timout
value in BearShare then there would be a significant increase in the
amount of collective traffic. This is known as 'hammering', and if
you are familiar with FTP servers you know that if you hammer you
usually get your IP banned.

> : GDF has also been completely ineffective in becoming a standards
body
> : for saying with the proper timeout SHOULD be.
>
> My opinion: Barring some significant unforseen practical problem
> resulting from underspecification, it is inappropriate for the GDF
to
> act to specify features of the download protocol

The retry interval isn't part of the download protocol, and because
of the "tragedy of the commons" effect where all servent developers
would eventually reduce their retry interval, it is necessary in this
case to have a consensus, and make sure everyone sticks with it, to
prevent a greedy company from lowering their retry interval in an
attempt to make downloads in their servent more successful than
others.

> : Should I continue to show restraint ...?
>
> Please continue to show restraint. I think that your admirable
> energy, if unrestrained, might scorch a lot of productive earth:-)

Maybe you misunderstood me. I've been patiently waiting for these
issues to get resolved and my patience is wearing thin.

If something isn't done, then I will assume its OK to use the same
tactics with respect to dropping messages, retry intervals, servant
bias, and propaganda that I have seen elsewhere.