The concept in section 11.3 of reload-03 is explicitly based on the assumption that the server density is something that can be estimated in advance (as explained in the Note on page 91). ReDiR from OpenDHT is mentioned in the p2pp draft, and is a bit more complicated, but it attempts to dynamically adjust to the density of the service in the overlay.
I think it's clearly an open issue what type of service discovery is required. In particular, what level of service discovery should be considered for part of the base draft and what should be regarded as an extension? Fortunately, I think service discovery is something that can be built on top of the basic mechanism. Bruce On Mar 10, 2008, at 12:58 PM, Joel M. Halpern wrote: > In reading the various drafts, I notice that several of them propose > that to find something that you need, but that is not directly > registered in the DHT (a "service", ala TURN or something else) the > requester randomly probes the DHT to see if they can find what they > need. > > This make sense if you assume that most nodes are providing the > service > in question. But if service providing nodes are sparse, that seems to > be a very bad idea. > And none of the drafts talk about the assumed density of service > availability. > Don't we at least need that information? > > Yours, possibly very confused, > Joel > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
