At Mon, 3 Mar 2008 12:09:28 -0500 (EST), Salman Abdul Baset wrote: > > > Well, one of the nice features about RELOAD, IMHO, is that very > > little explicit support for clients is needed. Basically, a client > > is a node which connects to other nodes but does not issue JOINs > > or UPDATEs. Therefore: > > 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. 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. > > - The peers it is explicitly connected to can route to it > > directly. > > - It is in their neighbor table but not their route table so > > it never routes packets. > > - Because it doesn't JOIN it never stores data. > > > > > > 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. -Ekr _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
