----- Original Message ----- From: Bruce Lowekamp <[EMAIL PROTECTED]> Date: Friday, March 14, 2008 7:48 pm Subject: Re: [P2PSIP] Client as relay
> > 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. > I fully agree with Bruce. > > 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. > Bruce > I think a bootstrap peer can help a client to find another client node to act as a relay when it joins the overlay. > > > > 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 > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
