RE: Re: QRP question (new Gnutella developer)

[email protected] wrote:
> Envoyé : mercredi 19 septembre 2007 09:39
> À : [email protected]
> Objet : [the_gdf] Re: QRP question (new Gnutella developer)
> 
> Quoting Philippe Verdy <[email protected]> from ml.gnutella.dev-forum:
> :> 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.

Ah! OK. But why did he use the terms "entry bits value"? We specified table
formats or "entry bit counts" or "entry formats"or "entry bit width".
 
> Also your reply did not make any sense.  Obviously, anything that is not
> infinity in the QRP table means that the query must be forwarded, as TTL
> is ignored in the QRP routing (excepted for last-hop QRP routing for
> Ultrapeers).

*Must* be forwarded? You're wrong. The fact that you'll forward or not a
query is the result of your own local policy. The QRP table is there as an
hint to help you make this choice. It indicates whever the remote peer
sending you’re the QRP has matching results within the expected distance he
accepts to forward searches.

I know that infinity means the absence: only infinity is a STRONG indication
that there's no chance to find something with this QRP entry, all other
values mean that there MAY be matching results, but different entry values
will possibly indicate other things to you, such as the expected distance
where these results will be forwarded.

May be this value is no more useful, because the dynamic querying has
replaced this differentiation, but if the remote peer still does not support
dynamic querying, it would be still good to honor at least its own policy,
instead of sending it too many queries.

Well it's true that if a peer has possible matches at a distance of 4 or 5
or locally, this does not seem to change a lot of thing for you, given that
you will still need to transmit it a query with at least this TTL value to
make sure you'll get some of these results. If you send it a query with a
lower TTL value, you don't know, from the QRP table, if you'll effectively
have matches because your query will not travel far enough to reach them.

With dunamic querying in application, note that you start by searching at
low TTL values. In that case the QRP table does not indicate you whever
ther's a chance to find it (the chance may be null if the only results are
further than the reduced distance, despite they are taking a non-INFINITE
slot in the QRP table).