>> >-----Original Message----- >> >It seems UPDATE and ROUTE-QUERY are some of the main reasons why the >> >client protocol differs from the peer protocol in P2PP. Are there any >> >other? >> > >> >Am I missing something? >> > >> First, when a client has multiple associated peers. I think the client >> should get the status of its associated peers for the choice of sending >> requests and avoid sending requests to a congested/busy associated peer. In >> SEP client protocol, a Notify message is used for the notification. I think >> this must be merged for client protocol. > >As with the ordinary peer protocol, I think this should be done with >UPDATE at the DHT layer.
I don't think Client has the "DHT layer". >> Second, a client must know the departure of its associated peer. Does the >> peer also send Leave message to its associated clients? My answer is YES. If >> people agree, we should clarify it in the merged client Protocol. > >Section 7.3.2 already implies this: > > The LEAVE_Q message is used to indicate that a peer is exiting the > overlay. The peer SHOULD send this message to each peer with which > it is directly connected prior to exiting the overlay. > >"peer" in this case (in fact, throughout RELOAD) refers to both >client peers and non-client peers. However, I agree that this >could be clearer. We need a clear rather than an obscure draft for the implementation. >> Third, I'd like the service that is provided by the associated peer to its >> associated clients to be the general service in the overlay (just like TURN >> server service). We mustn't compel each peer to provide that service. > >It's not clear to me why this is true. It's not significantly more >effort to be a peer attached to a client than it is to be a peer >attached to another peer, provided that clients aggressively >set up finger tables like any other peer. (This is less clear than >it should be in S 3.2.3.) It's true that the client is free riding >on the ring as a whole, but that's a different question. >> A >> general service discovery mechanism that we will make a consensus can also >> be used for this service. I want to know if there are other people who have >> special thought on this point. > >Well, as I was discussing with Salman, it's highly desirable for >a client to be connected to peers in the overlay as if it were >a peer, since that means all the ordinary routing mechanisms >work correctly. If you don't do this, the client needs to >advertise destination lists that explicitly reference the small >number of peers it is connected to, and that indeed is a service >that should be advertised. > >-Ekr I think the roles and responsibilities are different for clients and peers. If a peer is not willing to be acting as an associated peer, he can also discard messages received from the client. Any other people have thoughts on this? -Song _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
