At 4:10 PM -0700 7/10/09, Bruce Lowekamp wrote:
>ekr already mentioned that AppAttach is supposed to come into the next draft.
>
>What if we have a 16 bit field in Attach and AttachLite that specifies
>role/purpose of the connection? No normative purpose in the base
>draft, but for use with future extensions. Specify maybe five values
>for neighbor, routing table, peer optimization, client responsible
>peer attachment, and client optimization, and allow for future code
>points.
In general, this sounds like a useful way forward.
>That would allow future extensions that want to specify/control client
>behavior more carefully to do so, but not make the base any more
>complicated or restrict its behavior.
>
>Possibly rather than a simple 16 bit field, this should be more like a
>Forwarding Option so that if additional data is required, it can be
>included.
>
>Bruce
>
I don't have a strong opinion on whether to go with a fix-length
field or a Forwarding Option, and I think the general idea could
work either way.
regards,
Ted
>On Fri, Jul 10, 2009 at 6:04 PM, Ted Hardie<[email protected]> wrote:
>> 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
>>
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
