On Fri, Jul 17, 2009 at 4:46 AM, Bruce Lowekamp<[email protected]> wrote: > > 1) rely on the clients to periodically Ping or Route_Query to ensure > they are connected to the correct peer. Unfortunately, this leaves an > obvious gap before the topology change is noticed. Unlike > sip-outbound, we don't have redundant connections to compensate for > temporary loss of reachability. > > 2) define a new method for this purpose that is generic, so > independent of overlay algorithm > > 3) retain the current use of Update, and specify that a client > receiving an Update that it cannot process (because it does not speak > the overlay algorithm) SHOULD perform a Route_Query to confirm it is > still connected to the proper peer. > > > My personal preference is option 3, because I dislike the performance > tradeoffs of option 1, and I think option 3 has all of the > functionality option 2 would have anyway. > > > On a slightly separate note, I'm a bit concerned about the ability to > establish a client's ability to establish a reliable connection with > its responsible peer. In Chord, for example, greater reliability > would be achieved by establishing a connection with the responsible > peer and n successors. If a peer receives a message routed to a node > for which it is responsible but has no connection, it could then > forward that message to its n successors to attempt to deliver it. > Currently the peer would drop the message silently. >
After thinking about it some more, I'm wondering if a better option might be to define a new method that allows a client to query for the replica set for a Resource-ID and for the peer to inform its connected non-overlay-topology nodes when the replica set for a Resource-ID changes. This would address both of these problems at the same time without requiring clients to speak the overlay algorithm. Bruce _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
