On Mar 14, 2008, at 6:16 AM, Dan York wrote: > Victor, > > Two thoughts: > > 1. If a node is a "client", why would it be offering STUN/TURN > services? > > The use case suggested so far for a "client" is primarily an > underpowered device such as a mobile device which is not becoming a > peer because it does not have the capabilities to do so. It may not > have enough processing power, storage capacity or bandwidth. Given > that, it is not clear to me how the client would be able to provide > STUN or especially TURN services. >
Obviously in such a situation, you don't want the client to do too much work. > I guess the exception could be some overlay configuration where > only a certain # of nodes are allowed to be full peers and so some > perfectly capable nodes are relegated to client status... But I > don't see this as a usual config. > Actually, this is very common. In global-scale p2p overlays (like skype), it's typical to have a requirement that only public (at least non-filtered) nodes can become peers, and it is also quite common to limit the number of peers because if the storage requirements of the overlay aren't that great, allowing the number of peers to grow unbounded only serves to increase the average path length. I highly recommend reading draft-pascual-p2psip-clients-01 for its very long list of why a node might not be a peer. > 2. If (per #1) client nodes are not running STUN/TURN services, it > is not clear to me how another client behind a NAT would *find* > another client node to act as a relay - but maybe I need some more > caffeine to think that through.... > Broadcast/multicast is probably the easiest way to find another device. Also, STUN and TURN are very different. Every node has to run STUN to support ICE. TURN is entirely another matter.... Bruce > Interesting idea, though, > Dan > -- > Dan York, CISSP, Director of Emerging Communication Technology > Office of the CTO Voxeo Corporation [EMAIL PROTECTED] > Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > > Bring your web applications to the phone. > Find out how at http://evolution.voxeo.com > > > > -----Original Message----- > From: "Victor Pascual Ávila" <[EMAIL PROTECTED]> > > Date: Fri, 14 Mar 2008 03:52:37 > To:"P2PSIP Mailing List" <[email protected]> > Subject: [P2PSIP] Client as relay > > > Up to now we've considered the client protocol -independently of its > functions- to be the protocol used between a client and its associated > (one, few, many) peers. What I'd like to discuss is: May clients be > able to connect each other using the p2p layer? e.g. if a client is > behind a non-friendly NAT, it could use other clients (providing > STUN/TURN services) to reach its associated peer. > > Does it make sense for you? > > Cheers, > -- > Victor Pascual Ávila > Research Engineer > Tel. +34 93 542 2906 > Fax. +34 93 542 2517 > > Research Group on Network Technologies and Strategies (NeTS) > Universitat Pompeu Fabra (UPF) > Pg. de Circumval·lació, 8 > Office 358 > 08003 Barcelona (Spain) > http://nets.upf.edu/ > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
