> > I think this issue should be split up: > > > > 1) should service discovery be part of the base protocol? > > There are two issues: > > 1) Should service discovery be a *usage* of base protocol? > I think yes.
I think service discovery should be part of the base protocol. But it does require the service discovery SHOULD be a usage. In unstructured network, making each node spread its capability information is a good method to do service discovery. So does in structured network. It may not conform to the usage concept in the base protocol. > > 2) Should service discovery mechanism as a usage be specified in > the base > protocol? > > > > If so, what > > service discovery algorithm should be specified? (the current > draft mentions > > ReDIR and describes a very simple mechanism for discovering TURN > servers, > > which should work well for a known density of TURN servers) > > Service discovery algorithm is tied to the overlay algorithm > (DHT/unstructured). ReDiR is a DHT(Bamboo)-specific approach for > service > discovery. Method in SEP making built-in overlay manitenance method is a general method, and it could work with different algorithms. Maybe I am missing something, but I have a question about ReDiR. As I know, ReDiR works with OpenDHT, which is a overlay being comprised of stable peers and whose goal is to support new service without modify core OpenDHT infrastructure. As for ReDir, it relies on the peer on the core OpenDHT infrastructure to store all information about clients( in OpenDHT terminology) to organize a tree to locate which peer could provide which kind servic e. It seems all work is done on a stable peer and does not fit in distributed situation like structured/unstructured algorithm? comments? > > The complexity of service discovery algorithm depends on the > underlying > scenario. ReDiR is a good solution for the case when there are > multiple > peers providing the same service. When this is not the case, > defaulting to > ReDiR for service discovery is inefficient. > > Also, if every node is a TURN server, discovering them is a non-issue. > This is so because a node can simply obtain the routing table of > any peer, > and every peer in the routing table is a TURN server. > > Due to above dependencies, I think it is best to leave service > discovery out of the base protocol. There could be a BCP > specifying > various mechanisms. > > > 2) should a mechanism for identifying the ability to be a TURN > server be > > specified? > > No. At best, it can be a BCP document. I think we should has a draft to give guidance to implementators on how to identify it. IMHO, bootstrap peer, TURN server, Relay Peer (proposed in SEP) have some requirements in common, for example, it should hava a public address and no firewall or behind address-independent firewall. We could work out a draft to address these commone requirement. comments? Regards! JiangXingFeng _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
