RE: qrp and hops flow warning

Zlatin Balevsky wrote:
> please make sure that you do not include a leaf's QRP table in the
> combined table if the leaf sends a hops flow message with value less
> than 3.  We've noticed that happening on a lot of connections, and it
> has a nasty side effect of increasing the traffic to the ultrapeer.

Does this mean that a leaf can't reply to a remote peer that is 2 hops way
(i.e. one hop away from the ultrapeer)?

Or does this mean that it can reply only by sending the hops to at least 3
even if the querying peer is 2 hops away?

(If the querying peer is just &hop away, this is the ultrapeer to which the
leaf is connected, so the reply is direct and not broadcasted.)

But then, how can an ultrapeer decide to include a leaf's QRP table, given
that it is just 1 hop way, and can't predict how many hops will be the
queriers that the leaf will reply to?

I'm a bit puzzled by your remark, given that leaf nodes are always below
this threshold... So they should not be included (as well as the ultrapeer's
own local QRP table.)

If servents do that, the only data that could fit in the combined QRP table
would be the data from other remote ultrapeers connected to the local
ultrapeer. But then these wouldbeempty too, and there's no way to initiate
the process, as the system will always be in starvation.

I think that no matter of the hops count used by leaf nodes, their QRP
tables are always part of the combined table. Your remark should only
concern the decision to include or not the QRP tables from other remote
ultrapeers.

Did you mean instead:

"Please make sure that you do not include a leaf's QRP table in the combined
table if the leaf sends a hops flow message with value *more*
than 3"

Philippe.