I think ReDiR is a good general-purpose service discovery algorithm. It auto-tunes based on server population, although I'm not entirely convinced it doesn't have bad behavior in avalanche restart, but there may be studies on that I'm not aware of. In steady state, I believe ReDiR to be robust.
The mechanism currently in reload should work well in deployments where server population is well known. I suspect that for wide-area overlays, for example, this is likely to be possible to measure in advance. It has the virtue of simplicity. I'm not sure what you mean by "pervasively supported mechanisms." Both of these techniques require no support beyond base STORE/FETCH. TURN is certainly not the only example. Conference bridges would be another. Bruce On Mar 10, 2008, at 5:54 PM, Joel M. Halpern wrote: > Let me try parsing this another way. > If the Service location is just a normal lookup, returning normal > responses, then it clearly needs no support from the P2P layer we are > defining. > If pure random probes suffice, then that's enough. > > However, if we want any pervasively supported mechanisms in order to > increase the robustness of the search, then we need a base mechanism > rather than just a usage. > > (Correspondingly, I would like to see some discussion of whether > TURN is > really the only service or this is a general issue. I have not been > able to discern the answer to that.) > > Yours, > Joel > > Bruce Lowekamp wrote: >> >> On Mar 10, 2008, at 1:44 PM, Victor Pascual Ávila wrote: >> >>> Hi Bruce, >>> >>> On Mon, Mar 10, 2008 at 6:28 PM, Bruce Lowekamp >>> <[EMAIL PROTECTED]> wrote: >>>> Fortunately, I think service discovery is something >>>> that can be built on top of the basic mechanism. >>> >>> Please, could you elaborate this? >>> >>> In SEP, three different service discovery mechanisms can be found in >>> Section 4.1. We plan to put more effort on this issue. >>> >> >> So I think the key question here (that we need to answer soon) is >> whether service discovery needs a new method like SEP's >> LookUpServicePeer method or whether it can simple use FETCH for a >> particular data type defined by a usage (as reload proposes). >> >> I do think that SEP's proposal is an intriguing possibility, but I'm >> personally not too enthusiastic about a method type that requires >> every >> intermediate peer to do processing---I really would like to see >> message >> routing being as low-overhead an operations as possible. >> >> Anyway, back to my original comment. Most of the service discovery >> algorithms just rely on FETCH, so there are no changes to the >> basic peer >> protocol at all. SEP has a custom method in the peer protocol. >> I'm not >> convinced that if you really want to have per-hop additions to a >> query, >> that you need a particular method for it or that service discovery is >> the only possible example of that behavior. But the next question is >> that if a custom method is needed for service discovery, can we at >> least >> build new service discovery algorithms on top of that beyond what are >> envisioned for the base draft? >> >> 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
