On Mon, Jul 27, 2009 at 7:08 PM, Eric Rescorla<[email protected]> wrote: > > > On Jul 27, 2009, at 9:54 AM, Bruce Lowekamp <[email protected]> wrote: > >> On Mon, Jul 27, 2009 at 6:47 PM, Eric Rescorla<[email protected]> >> wrote: >>> >>> However, it seems to me that this same effect could be achieved >>> simply by having the DAP actually be a TURN server. The client >>> could then connect to the TURN server and through it to the >>> RP. You get the same message paths, but there's no additional >>> protocol mechanisms required to tell anyone that this is >>> a client--everything just works. It also has the additional advantage >>> that because TURN servers have public IPs, you know you won't >>> have to send OAP-DAP messages through the overlay. >>> >> >> This doesn't work when peers can be behind NATs. There's no way to >> ensure that the responsible peer has a public IP and can be a TURN >> server. > > That's not what I said. The dap, which has no special node relationship with > the client, is the turn server.
The DAP was being selected for other criteria, such as having an existing bluetooth connection to the client. That doesn't make it a good candidate for a turn server, either. > >> I think the concept of allowing a client to be contacted by routing a >> message to the client's Node-ID regardless of whether it is directly >> attached or not is a very useful one. I think a couple minor changes >> might be needed to the base draft to allow an extension or usage to >> specify how to do/manage this behavior, but I believe it's definitely >> worth the effort. >> > 1. I'm unconvinced. The arguments presented so far seem weak > 2. The changes in this draft don't seem minor to me I think the changes needed to the base draft to support extensions/usages for client routing are minor. Managing it properly is more complicated, which I think is a good topic for this draft. Bruce _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
