Victor may answer the question in another way, but ... we've also had discussions about overlays that support too many nodes to realistically include all nodes as peers, so we would provide the services that each node needs without having every node join the overlay as a full peer.
Peer protocol traffic is likely to be SOME function of the number of nodes in the overlay. We can talk about what function that is, but I haven't seen anyone arguing that peer protocol traffic was independent of the number of peers. Sadly, we haven't had any discussions in a very long time about use cases/application scenarios, so either everything is "in scope" or we all just kind of know what the requirements are without discussing them. Neither extreme excites me. IMO. Spencer From: "Dan York" <[EMAIL PROTECTED]> > 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. > > 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. _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
