Why would a node send the "purpose of the connection" in it's Attach?
Attach is low level and hardly indicative of anything Overlay related.
The Attach clearly states the purpose of the connection outright, what
we do not is the reason for the Join and what role the joining node
wishes to assume.
jc
On Jul 10, 2009, at 4:10 PM, 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.
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
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
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
