Bruce Lowekamp wrote:
On Wed, Dec 9, 2009 at 3:35 AM, Ari Keranen <[email protected]> wrote:
Page 99, Section "9.4 Joining"
"In order to populate its neighbor table, JP sends a Ping via the
bootstrap node directed at Resource-ID n+1 (directly after its own
Resource-ID). This allows it to discover its own successor. Call that
node p0. It then sends a ping to p0+1 to discover its successor (p1).
This process can be repeated to discover as many successors as desired."
Could the AP send a copy of its neighbor table (e.g., in an Update
message) to the JP? The JP could then initialize its neighbor table
using the received entries and there would be no need to send Ping requests.
I think this could be accomplished if JP sends AP a RouteQueryReq with
send_update set to true. The complication is that AP would have to
use the via-list of the received RouteQueryReq to populate the
destination list since JP isn't in the overlay yet. I think this
would be the first place in the protocol where a peer is required to
do on behalf of another node, except for obtaining a destination list
through a usage (none of which have defined doing that to the best of
my knowledge so far).
I'm curious what people feel about this change? Keep in mind that
there may be significantly more than 3 successors/predecessors in the
neighborhood table (which is also being clarified in response to other
comments Jouni and Ari made in their review).
IMHO, considering the advantages, this seems like a reasonable change.
Cheers,
Ari
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
