Compared with other methods, the method proposed in SEP exploiting routing state to find service provider has the following advantages, IMHO,:
1. Less maintenance cost: the advertisement of the service capability is through the overlay maintenance mechanism which all P2P algorithm has; 2. Reflect the state change as soon as possible. Because the service capability is only distributed on hop further to its neighobr, so the peers could use keepalive message to update its status of the service capabilities what it supports timely. 3. It could be used in both structured P2P system and unstructure P2P system. more comments in line. Regards! JiangXingFeng > > 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. Yes, you are right. So we define a new method so that only this message will be handled by intermediate peers. For other messages, such as PUT,GET, etc, they are routed in the same way as before. > > 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? How do you define 'base' draft? Do you think service discovery is included in the base draft? For me, I think, requirements used to form the overlay should be included in the base draft. _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
