RE: Re: QRP question (new Gnutella developer)

Different values do not mean invalidity, just difference of local policies
about the queries a servent accepts to forward. If this value is 4 or 8, it
indicates different local policies about the diameter of searches that it
will accept to forward. Given that there's already a choice, this diameter
is already variable, meaning that the QRP table is indicating more thanjust
a table of QRP entries that are supposed to have results. You are free to
ignore this indication if you choose to store it locally with 1 bit tables,
but this does not invalidate the table in my opinion, which remains usable.
Forinteroperability (and future enhanced implementations that would compute
QRP tables with variable distances indicated within the same table, I don't
see why you wouldreject these tables, because in that case you will ignore
the QRP table and will then apply a much worse policy than expected, as if
the servent was not supporting QRP, so you will send it too many queries.
I don't see the advantage you gain by discarding completely these QRP
tables, when you can adapt to them very simply.

> -----Message d'origine-----
> De : [email protected] [mailto:[email protected]] De la part
> de Gregor K.
> Envoyé : mercredi 19 septembre 2007 09:51
> À : [email protected]
> Objet : [the_gdf] 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).
> >
> 
> 
> 
> 
> 
> Yahoo! Groups Links
> 
> 
> 
>