At Thu, 6 Mar 2008 12:19:50 -0500 (EST), Salman Abdul Baset wrote: > > > 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.
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 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. -Ekr _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
