>-----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. 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? >So, as far as the general discussions in section 4, sure, reload-03 >supports clients. > >Of the two specific functions proposed in section 5: > >- storage provided by clients: You could certainly build this >functionality on top of reload-03, with the peer exchanging STORE/ >FETCH messages with its clients (or through other mechanisms). So >the underlying routing mechanism is there. But at ietf-70, the wg >voted to not focus on solving this problem in the immediate future. I will be glad to see that Reload-03 supports the function of storage provided by clients, if we consider various applications upon p2p layer in the future: ) >- p2p relay: I'm not completely clear on this section. If it is a >proposal to have clients able to act as TURN servers, there is no >restriction in reload-03 that the turn servers are peers, clients, or >even members of the overlay. So I don't think there's any issue here. I have clarified the p2p relay concept in another email. -Song _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
