At 1:23 PM -0700 7/10/09, Eric Rescorla wrote:
>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.
So, my personal preference is for "client" to be closer to a first
class concept, so that this behavior is explicit. That might take
the form of a different message after attach. That's largely a
style, thing, though, and I agree that the behavior you describe
works. But see below.
>
>
>> 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.
My concern here is that without an explicit step, some set of
implementations may treat long post-Attach periods without
joins or updates as indicative that the relationship to the
attached node is not healthy. That might take the form of timeouts
or something similar.
You can retain the current theory and avoid that ambiguity by
making the theory you've articulated in this email explicit in the
text. That would require some additional verbiage, but it should
not require anyone to actually change code. For the folks who
implement post-WG discussion, that kind of breadcrumb will be
pretty important.
My two cents,
Ted
>
>-Ekr
>_______________________________________________
>P2PSIP mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
