>> -A node may join the overlay as a client. Later, it may be invited by a >> peer to upgrade itself to the overlay. A client may also decide to upgrade >> itself to a peer. >> >> -A node's attempt to join as a peer may be defered by a peer because >> it has not been up for certain time. The peer can then ask the node to >> join as a client. > > I don't see the point of either the peer refusing to let you join > as a peer or asking you to join as one. The client knows its > own properties better than the peer does and the peer has no > special standing--it just happens to ahve a peer-id > close that of the client.
A peer may refuse to let a node join as a peer because a node is considered 'abusive' by the admitting peer or does not meet desired security properties. For unstructured networks, client-ID and peer-ID have no closeness meaning. >> -A client may not be a 'dumb terminal' hanging from a peer. It can provide >> TURN service. However, it cannot process incoming STORE, FETCH, and FIND >> messages. >> >> -A client may be connected to multiple peers for fault tolerance purposes. >> A client can connect to multiple peers in an overlay (DHT) protocol >> [in]dependent manner. A client may also maintain a list of other peers >> without necessarily connecting to all of them. >> >> -Peers need a mechanism to balance the number of clients connected to a >> peer. > > I think this depends on whether clients attach to peers as a service, > as in RELOAD-03 with explicit routing, or simply as a peer that > doesn't JOIN, as in the non-explicit RELOAD client mode. Unless I've > missed something, this doesn't impose more load on the adjacent > peers (provided that the client creates a robust set of fingers > as it should) than if the client were a peer. > For DHTs it is easy to understand that such a load balancing happens implicitly. However, this is not the case for unstructured overlays. -s _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
