Hi, AFAIK, there are at least three proposals, P2PP-1, RELOAD-2, SEP-00, deal with how to discover TURN service which could be provided by peers in the overlay. SEP is trying to get a general solution to discover service, not only limited to the TURN service. Of course, P2PP-1 and RELOAD-2 also could be revised to be a general one.
P2PP proposes four methods to do the discovery, i,e, standard service name, random ID, ReDir and random walk. The first three methods, in my opinion, is try to use common overlay lookup mechanism which is based on resource-ID to get the response from the responsible peer. The value stored in the responsible peer is often stored by publishing operation, for example, PublishObject in P2PP and STORE in reload-2 and PUT in SEP. The last one, random walk, tries to get the service peers from its neighbors, or neighbors of its neighbors, recursively. It will be processed by all intermediate peers until one peer gives a response. RELOAD TURN usage first estimates the turnDensity and get a seed by concatenating its peer ID and d which is a random number between 1 and turnDensity. The peer will put the resource ID by applying hash function the seed. Peers can find other servers by selecting a random Resource-ID and then doing a FIND request for the appropriate server type with that Resource-ID. The FIND message will be only processed by the peer who is responsible for the Resource-ID. In SEP, each peer's routing states intends to keep its neighbors' service capability, i,e, which kinds of service its neighbors could provide. Then we could think the service capability information is advertised through the overlay maintenance mechanism. If a peer wants to get a peer of a specific service, it would try to select a random resource ID and send a LookupServicePeer which includes service type, how may service peers the requesting peer needs. The LookupServicePeer message will be processed in every intermediate peer who will check its routing state to find whether its neighbor peers support the indicated service. In the end, the destination will return the response to the source per by carrying service peers' information in the response. The original idea was proposed in the draft-jiang-p2psip-stun-turn-discovery-00. ( http://tools.ietf.org/html/draft-jiang-p2psip-stun-turn-discovery-00 ) So I think, we could classify the service discovery method into two categories: The first one is based on the common PUT/GET operations; the other one is trying to relying on the most of peer's knowledge to find the suited peer. The first three methods in P2PP and the method in RELOAD-2 belong to the first category; The random work in P2PP and method proposed in SEP belong to the second one. For the second category, since it relies on each peer the request will traverse to find the service peer, we could make the intermediate peer not only check the routing states of each peer, but also tries to find them in the following data source: 1. The Peer's client service capability; 2. Using Standard Service Name to lookup <resource ID, value> pair. 3. Other data source which emerges in the future. By doing this extension, it will improve the success rate of the lookup operation. How about your opinions? Comments are appreciated. BTW: Chinese New Year is around the corner. Happy New Year to all guys. Regards! -- Jiang XingFeng _______________________________________________ P2PSIP mailing list [email protected] http://www.ietf.org/mailman/listinfo/p2psip
