>-----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.
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. 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. 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. >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf >Of Salman Abdul Baset >Sent: Monday, March 03, 2008 12:27 PM >To: Eric Rescorla >Cc: 'P2PSIP Mailing List' >Subject: Re: [P2PSIP] Extending the (inclusive) merge for P2PSIP > > >>> For scenarios where a node initially joins as a client and later >>> decides [upon inviation from another peer] to upgrade itself to a >peer, it >>> will need a mechanism to obtain the routing table of its connected >peer. >>> In such a scenario, a client needs to issue an UPDATE. >>> >>> A client may also like to maintain connections with multiple peers >incase >>> the peer it is connected to goes offline. Thus, it needs to send an >>> UPDATE to obtain a list of backup peers from its connected peers. If >a >>> client connects to multiple peers, does it need to advertise multiple >>> destination lists? >> >> I'm sorry, I don't understand your argument here. >> >> 1. You don't need do do an UPDATE to get the routing table of a >> peer. The ROUTE-QUERY command does this. > >According to the existing model, clients need to explicilty request the >connected peer (using ROUTE-QUERY) to transfer its routing table to >client >in an UPDATE message. Is there any particular reason why a client cannot > >request the routing table directly from its connected peer? > >> 2. The only case in which you need to use destination lists is >> you're connected somewhere other than the replica set for >> your own peer id. > >This will likely be the case for unstructured overlays. > > >>>> Note that a client can connect to peers at one of two places: >>>> >>>> - At the location indicated by its peer-id. >>>> - At a random location. >>>> >>>> In the first case, routing to the clients peer-id simpyly works, >>>> since it goes through the node responsible through that space, >>>> which is directly connected to the client. In the second case, >>>> the client can advertise a destination list [this is one use >>>> for this feature] consisting of the peer it is connected to >>>> and then itself. >>> >>> As I mentioned earlier, if a client connects to N peers to mitigate >>> against peer churn, it will need to advertise N destination lists >similar >>> to a multihomed router advertising N routes. This increases the >>> state/message complexity. >> >> Yeah, it only makes sense to choose a peer relay outside of your >> own replica set if you know specifically about that peer >> and know that it's stable. Otherwise, you should use one >> in your replica set. > > >>> Further, routing by destination lists breaks during churn. >> >> Well, sort of. >> >> The way that this works is that the client (with peer ID P) connects >> to peer X and advertises the destination list (X P). As long as X is >> reachable (no matter how much churn there is) then you should be >> reachable as well. Yes, this creates fate sharing with X. >> That's not necessarily bad. > >My Skype client, when acting as a ordinary node, does not have fate >sharing with its SN. > >-s >_______________________________________________ >P2PSIP mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/p2psip >_______________________________________________ >P2PSIP mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
