At Sat, 15 Nov 2008 17:31:16 -0800, Narayanan, Vidya wrote: > > > In order to support it either as a better topology plugin > > to be proposed in the future or as part of the default DHT, > > what we need is the capability in the protocol to request the > > neighbor list of a targeted finger entry and receive it. > > > > > > I concur with your concern about not adding complexity. > > However, I would argue that locality selection does not add > > much complexity to the system. A peer gets a list of peers in > > a ID neighborhood, pings those peers, and chooses the one > > with the lowest RTT as a finger. The draft would need to > > support the ability for a peer to give another peer a list of > > its id space neighbhors. A ping message is already supported, > > so no additional change is required for that. The exact > > details of how many neighbors to ping, how many pings to > > send, etc. can be left to the implementation to reduce the > > complexity of the base draft. > > > > > > > That's fine. It requires no changes to the current draft > > other than for the draft to recommend a basic way to select > > finger table entries but allow that other methods are > > acceptable as long as the finger table entries are valid for > > that range. The RouteQueryReq already handles probing for > > the existing neighbors. > > > > Unless I'm missing something about the RouteQuery messages, I don't > think this is enough. This message will return the next hop towards > the destination. If a particular resource id maps to itself, it is > not going to return its neighbors from what I can tell.
No. 5.3.2.4.1 A RouteQueryReq message indicates the peer or resource that the requesting peer is interested in. It also contains a "send_update" option allowing the requesting peer to request a full copy of the other peer's routing table. -Ekr _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
