>-----Original Message----- >From: Eric Rescorla [mailto:[EMAIL PROTECTED] >Sent: Tuesday, March 04, 2008 11:11 PM >> 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.
I think the information containing in the Notify message may also be generic, such as the busy status. DHTs can use this information for their routing choices. Further more, a client which doesn't run DHT, also needs to know the status of its associated peers to avoid sending requests to the congested associated peer. So, UPDATE message is used for routing table maintenance, but for status notification we need another message. >> 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
