RE: Re: QRP question (new Gnutella developer)

> De : [email protected] [mailto:[email protected]] De la part
> de Gregor K.
> Envoyé : mardi 18 septembre 2007 10:42
> À : [email protected]
> Objet : [the_gdf] Re: QRP question (new Gnutella developer)
> 
> Hi..
> 
> Phex drops QRP messages in case, the host is not reporting to support
> QRP in the handshake or if the message appears to be invalid e.g. when
> the messages are not in the right sequence, the patch data failed to
> inflate correctly or the entry bits value is not 4 or 8.

When the entry bits are not 4 or 8, this should not happen. The recipient
just need to adjust the entry bits value with a LOWER one.

* If the entry is between 2 and 3, it should then be interpreted as 1
(meaning that the file will be seeked only on the next connected peer but
not forwarded to its other peers).
* If the entry is between 5 and 7, Phex should interpret it as if it was 4.
* If the entry bits is 9 or higher, it should be interpreted as if it was 8.

Different implementations have different way to limit their searches and
forwarding. The idea is not to extended these search to higher hops when
forwarding but adjusting it to a value acceptable by each peer.

For me a QRP table entry with entry values of 7 is perfectly valid. (Phex
should accept it as if it was 4, if this maps to its own local policy...).
In other words, the QRP tables received must be rewritten, and not used as
is. Some peers will convert these tables to other internal formats using
more or less bits per entry. There may even be some peers rewriting QRP
tables using 1 bit formats to reduce the memory footprint, where a bit is
set for the value 4, and a bit is not set for the value 1 (immediate peer
has a file) or 0 (no file present for this entry).

Note that it is not necessary to store the value 1, given that searches can
still be sent directly to the immediate next peer with a TTL=1, and that
remote peer can even be browsed directly in a single request without having
to send many searches to it (so a peer can build a local separate 1bit QRP
table from the browse results and forward the incoming searches using
separate strategies when the remote peer is actually sharing that file
directly or acting as a proxy for its other remote connections).