(sorry for multiple copies, if any) > 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? > - 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. Further, routing by destination lists breaks during churn. -s _______________________________________________ P2PSIP mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/p2psip
