Quoting mikeyv_b <[email protected]> from ml.gnutella.dev-forum:
: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?
I can't comment on Phex, but gtk-gnutella will apply a "pass through"
function that is filtering queries randomly when the table is getting
full. For instance, if it's 100% full, it will filter out 99% of the
queries, but if it's only 5% full, it will not filter anything. The
curve is somehow quadratic inbetween.
: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?
You should really test it with gtk-gnutella. It's been ported to OS X
I think. Just try to build it there. All you need is a GTK+ devel
library (along with glib), the xml2 and zlib libraries and a C compiler...
: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?
Gtk-gnutella will send you a suitable BYE message if the QRP patches
are malformed, along with a proper error message. Just make sure you
display the BYE message in your connection status.
Raphael
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.