Yes, You are right. These methods are trying to avoid the shortcomings which is in the method, just simply put the information under the service-id got by hashing the standard service name.
> > On Mar 10, 2008, at 6:48 PM, jiangxingfeng 36340 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. > > Right. If the standard service name method works in all cases, > > there is no need to develop new methods. But in some cases, this > > > method has some shortcomings: > > 1. if too much peers providing the same service, and also > publish > > the information to the responsible peer fo the service-id gotten > by > > hashing the standard service name. So the responsible peer has > to > > store so much <key, value> pair; > > > > 2. the other shortcoming is if the service is a popular service, > > > all query will go to the responsible peer. It may overload the > > responsible peer. > > This isn't how the service discovery algorithms work (either > reload, > redir, or any of the others I can think of). ReDiR, in > particular, > is adaptive. In ReDiR, the service providers and the queriers > gauge > the population density of the service and use that to select where > to > search for the service. There isn't overload on a single > responsible > peer. > > In the technique in reload, the data is stored at random locations > > and random queries are used to search, so again, there is no > overload > on a single peer. > > > > > > > >> If pure random probes suffice, then that's enough. > > Maybe we need collect some experiemental data to see whethere > > random probes could work in most cases. I mean, if the service > > providers could be got within two or three transactions, IMHO, > it > > is a reasonable latency. > > > > The technique in reload works fine if you can reasonably > accurately > predict the server population. If you can't, it won't work very well. > > Bruce > > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
