>> 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
