The client discussion has received much discussion. Below, I want to summarize what I think are the requirements for a client which have been previously deliberated but not necesarily put together.
I will define client as a peer subentity that does not process incoming STORE, FETCH, and FIND messages. -Like a peer, a client has an ID. A client obtains its ID in the same manner as a peer. -Over its life time, a node may not be permanently designated as a client or a peer. Although, for certain low-end mobile devices this distinction may be permanent. -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. -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. -Does a client need to be overlay (DHT) protocol aware (RELOAD-03)? How to upgrade/downgrade from a client to peer and vice versa? -Metrics such as uptime, ewma_bytes_sent[rcvd], and estimation of number of peers in the overlay play a role. -s _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
