At Tue, 04 Mar 2008 20:07:55 +0800, Song Yongchao wrote: > > >-----Original Message----- > >From: Bruce Lowekamp [mailto:[EMAIL PROTECTED] > >Sent: Monday, March 03, 2008 10:14 PM > >Song, > > > >Again, what protocol features do you believe are not supported by > >reload-03? > > Bruce, > > 1. First, I think a Notify message should be supported. A peer or client can > Notify its neighbors with its current status(e.g. busy) when needed, so that > an upstream peer can route around busy downstream peers when necessary. When > a client has multiple associated peers, it can also choose which one to be > the best service peer upon it receives the Notify message with current > status from these associated peers. A Notify message is sent only when one's > status changes. Are you happy with this? I'm sorry if I miss some text in > Reload-03 about it.
I think it's a mistake to have this be a RELOAD mechanism rather than a DHT mechanism. Different DHTs provide a variety of levels of information about their state and the state of their connection tables (for instance Chord vs. Bamboo) and use that information differently to make routing decisions. Rather than having a generic message, that tries to predict all possible values, I'd prefer to allow new DHTs to specify the kinds of information they think is appropriate. This is done in RELOAD by having the UPDATE message be defined by the DHT. So, a DHT which knew how to make use of this information would define an UPDATE mesage that provided it. > 2. Second, a general service discovery mechanism should be supported. I > would like to let every peer keep the service capability (e.g. TURN server) > of its neighbors. A LookUpServicePeer request should be added to collect the > service peers along the overlay, when the service peers are found, a > response with the service peers information is sent back. Both clients and > peers can issue this request. With this method, the service capability can > refresh timely. However, TURN server discovery method in Reload-03 needs to > calculate the turn density, and every turn server publishes as many replicas > as the turn density to the overlay. Do you think it is too complicated and > hard to maintain? I agree that a general service discovery mechanism is something that we should have. The one in SEP has some interesting features. I'd very much like to see thw WG have a discussion on the best service discvery approach. -Ekr _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
