Based on some of the list discussion, we (mostly ekr) tried to improve some of the text surrounding clients in the draft. I hope this clarifies some of the intent of how clients are supported by the base protocol.
I also added some text to send Update requests to all nodes in the Connection Table when a peer's responsible ID range changes. The intention of this change was to provide a mechanism where a node attaching to a peer because it is responsible for a particular ID be notified if the peer is no longer responsible for the desired ID. This change also doesn't require the peer to determine why a particular connection is established, which preseves the generality of the current approach. Unfortunately, the implication of sending Updates to clients is that clients are required to process Updates. This is in conflict with the goal that clients don't need to implement the overlay algorithm used by the overlay (since Update's content is defined by the overlay algorithm). I see a few solutions to this problem: 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. My current feeling is that such a feature should be left for an extension. Bruce _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
