--- In the_gdf@y..., "jbt00000" <junkmail@j...> wrote:
> Are you only including members in the mesh whose Hashes match, or
> any that Bearshare deems equivalent?

Any that BearShare deems equivalent. Note that 2.5.0 groups files
into two categories: those with hashes, and those without. Therefore
hash files will always list sources that promise a hash.

You can tell if a requestor obtained the mesh information via hashes,
since the requestor will provide the X-Gnutella-Content-URN header.

You can tell if the provider's alternate locations refer to hashed
content by the presence of the X-Gnutella-Content-URN header in the
HTTP response.

> If it is the latter, how are you handling servents that don't
> support url encoding (i.e. Limewire). I would suggest not inluding
> them in the mesh, as servent using the mesh data wouldn't have
> enough hints to make those uri's work.

I don't see a problem. LimeWire doesn't support URL encoding in the
HTTP request. But then again, no one supports the reading and parsing
of the X-Gnutella-Alternate-Location header.

When someone implements the handling of the header, they will have to
url decode the URI and submit a non url-encoded HTTP request to the
appropriate servent.

The separate problem of not handling url encoded URIs on HTTP
requests is solved by first releasing widespread support for url
encoding (BearShare already supports it, and LimeWire will soon),
then making the change at the request level.

> What versions of Bearshare supports the proper Base-32 alphabet?

BearShare 2.4.2 and later support the Base-32 alphabet described in
HUGE 0.93

In case you didn't know, this is the format of the packed private
data block in BearShare query hits:

struct GnutellaQueryHitsTrailerPrivate // vendor-specific
{
enum Flags
{
flagWebServer =0x08
,flagWebSearch =0x10
};

unsigned char flags;
unsigned long version;
unsigned long uptime; // in minutes

//...
};

The version would be 0x00020402 for BearShare 2.4.2.

Our solution to the problem of having two Base-32 formats is to first
try to identify the Base-32 version by looking at the characters
used. This can produce only positives and false negatives. If it is a
negative then we resort to checking the version number. If there is
no version number (i.e. not a BearShare servent) we assume it is HUGE
0.93 (since no one else is sending hashes yet).