At Thu, 9 Jul 2009 14:03:08 -0700, Narayanan, Vidya wrote: > > I'm not sure I understand what you are saying. Are you saying that > an Attach request without a preceding Join is indicative of joining > as a client?
No, I'm saying that "client" isn't a first class concept in RELOAD. The generic procedures defined in RELOAD make peers handle client nodes correctly automatically. So, all that's required is that nodes which wish not to be part of the routing fabric and storage fabric not send the messages that would make them so. > If so, a client finds a bootstrap peer and sends an > Attach request to its own node id, in order to find the node that it > is supposed to attach to? Yes. > AFAICT, this doesn't seem to be described > in the draft. That's because there is no new normative behavior. Clients simply don't send Join or Update. > 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. -Ekr _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
