At Thu, 06 Mar 2008 10:09:47 +0800, Song Yongchao wrote: > > >-----Original Message----- > >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > >Henry Sinnreich > >Sent: Thursday, March 06, 2008 2:06 AM > >(changed to Client protocol) > > > >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. > 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. > 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 _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
