Re: QRP question (new Gnutella developer)

According to the QRP, which is one of the few proposals which is
documented quite well, the ENTRY_BITS field MUST be 4 or 8.
There is no client known to me that sends different ENTRY_BITS
values. Internal memory representation is a completely different
thing, Phex uses 1 bit tables internally too..

Gregor
 

--- In [email protected], "Philippe Verdy" <verdy_p@...> wrote:
>
> > 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).
>