Hi, > 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).
What if the JP would, before contacting other nodes, first send an Attach to the AP (possibly after sending a Ping to the AP first). Then, it could send the RouteQueryReq over the resulting direct connection to the AP (without routing the request across the overlay; I am assuming that in the text above, the RouteQueryReq is sent across the overlay). The AP would also send the Update carrying its neighbor table to the JP over the direct connection. Thus, there would be no need to worry about populating the destination list (because neither the RouteQueryReq nor the the Update are sent across the overlay). Just a thought, I might be missing something here. Cheers, Jouni 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). > > Bruce > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
