How does the method in SEP work as service provider population grows or shrinks? I like some of the properties it has, but it seems like as server population drops, it's relying on random chance that a particular path will happen to traverse a neighbor of a service provider. As population drops, that probability goes down.
ReDiR handles this through its adaptation. Reload (assuming the population is predicted in advance), works, but if a peer being able to provide the service is very rare, may require the service providers to do a lot of STOREs to achieve the desired density of registrations. Bruce On Mar 10, 2008, at 2:43 PM, jiangxingfeng 36340 wrote: > 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
