On Fri, Jul 10, 2009 at 4:23 PM, Eric Rescorla<[email protected]> wrote: >> Even if it is, I don't understand how a node >> differentiates a client from another neighbor, because treating the >> client as a neighbor and sending updates to all other neighbors will >> create an incorrect view of the DHT for the other nodes. If you are >> saying that all of this is implicit in the fact that an Attach was >> received without a Join, it seems setting up for issues. I think it >> is better off to explicitly join as a client to avoid any ambiguity. > > A node doesn't know that an adjacency is a client or not. What it > knows is that it's a node that hasn't sent any Updates and therefore > shouldn't be advertised to other nodes in the overlay. It could > be a client or it could be a node which just hasn't sent any > Updates or Joins yet (but will eventually). It doesn't matter. This is > a feature of the design, not a bug.
I agree that a feature of the design is that Attach doesn't require a specification of what it's being used for---which allows an implementation to Attach to the responsible peer as an optimization for resource refreshes, for example, without a change in the spec to allow it. The same feature can also be used by clients to support their operation. But I think it's also true that there is relatively little support should any of these Attaches need to migrate to another peer, regardless of whether the Attaching node is a client or peer. I think that making sure we have this feature (or ensuring that it works appropriately via sending Updates to all Attached nodes) would help both client and peer operation. That seems like it's useful in the base spec. More details of how clients might work I think should be in another draft. For example, client might achieve reliable connections via maintaining a link with their responsible peer and its two successors, then conduct appropriate maintenance on these in the event of topology changes. I would like for the base draft to allow the features to implement this, but would rather not make the base draft any more complicated by adding details of how to manage such support. I could see an argument for different ways of handling clients using the same basic mechanisms. Bruce _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
