Re: QRP question (new Gnutella developer)

--- In [email protected], Raphael_Manfredi@... wrote:
> Have you tried with gtk-gnutella as well?  You may have issues with
> internationalization and UTF-8 representations.  Gtk-gnutella has the
> correct algorithm implemented to compute the QRP hash value, especially
> in the presence of surrogates.  (this is not documented in the original
> LimeWire specs -- look at the qrp_hashcode() function in src/core/qrp.c
> for a correct C implementation).

Thanks for your suggestions there!

I would like to test it with other clients, but LimeWire doesn't seem
to have as much control as I'd like. For a start  it's not possible to
force it to be a superpeer at startup (I know this is bad generally,
but it'd make testing much easier). I don't think there's a build of
gtk-gnutella for Windows or OS X, is there? I'd like to try this with
another client, but I can't find a suitable candidate. Suggestions
very welcome!

I suspected my hash function as well, so the first thing I did was
change the QRP generation function so that it returns an all-positive
table (i.e. every position in the table allows searches through). So,
if that table was being parsed and handled correctly on the other end,
searches should be coming through. But, they're not. If I pass a table
that consists entirely of (1 - infinity) entries, all searches should
be allowed, shouldn't they?

More suspicious is the fact that Phex reports it's dropping both
messages (reset and patch 1 of 1). If things were working as they
should be, it wouldn't be listing these two messages as dropped,
should it? However, the stream isn't losing sync, the connection
remains live, and is usable in every way other than transmitting
queries from Phex to my client. Would a malformed QRP message show
this behaviour?

I hope I can get this sorted out, apart from this one thing my
client's working really well!

Thanks,

Mike