I'd support this as well. I think this would be quite useful. Vidya
> -----Original Message----- > From: Hardie, Ted > Sent: Friday, July 10, 2009 4:25 PM > To: Bruce Lowekamp > Cc: Eric Rescorla; Narayanan, Vidya; [email protected] > Subject: Re: [P2PSIP] Client operation in RELOAD > > 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
