(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? Thanks, Henry -----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
