Raphael Manfredi wrote:
> Quoting Christian Biere <[EMAIL PROTECTED]> from ml.softs.gtk-gnutella.devel:
> :Bill Pringlemeir wrote:
> :> qrt_build_query_target() has the following lines...
> :
> :> if (is_leaf) {
> :> /* Leaf node */
> :> if (rt == NULL) /* No QRT yet */
> :> continue; /* Don't send anything */> :This is actually wrong. Leaves that don't support query routing > :should always get the query. > Actually, the logic I favoured is: all leaves MUST support QRT (by definition > of a leaf node), and a leaf which has not send a QRT yet should not get > the query because: Maybe you favour this but it's not compliant to the specifications. According to those all queries should be forwarded to leaves that sent no QRP. Other vendors implement exactly that. If they are seemingly less clever, it would be a good idea to suggest them doing the same and modifying the specifications. It's bad to have an implementation that can be considered buggy when it's actually superior. > 1. This uses b/w at the UP level for slow leaves that have a huge QRT or > which send their QRT slowly. > 2. Buggy leaves which choose to not implement QRT may still connect and > search the network but they will get no query. Yes, this makes them > leaches, but the alternative is worse (see #1). If you want to save work and time, you can simply send a QRP with all slots filled. That will actually cause much more traffic and trouble when the Ultrapeer merges this with its QRT. -- Christian
pgphzVx87dFu0.pgp
Description: PGP signature
