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
