[email protected] 写于 2009-07-28 15:43:26: > At Mon, 27 Jul 2009 19:17:01 +0200, > Bruce Lowekamp wrote: > > > > 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. > > Well, you don't actually need to be a full TURN server, just one > good enough to do ordinary connections. > > But that said, I don't find this Bluethooth special case very > compelling. If you're going over Bluetooth, this is much more like > having a split client and much less like having a client with an > IP connection to some DAP. >
I think there are two scenarios where the client should not always connect to the OAP: 1. For traffic localization purpose, the client attaches to a geographically nearer peer. 2. To keep the service more reliable, the client connects to two or more peers. Russell Wang > -Ekr > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
