Michael, I understand the discovery of Node-ID's by Resource-ID's. You are stating that you connect to a bootstrap node and start sending Attach requests however there is a problem. Where do you obtain the Node-ID's or Resource-ID's to send the Attach requests to?
This is a technical impossibility. You MUST have at least another Node-ID or Resource-ID other than that of the bootstrap node. You MUST learn at least a single Node-ID or Resource-ID from the bootstrap node. Julian On Nov 22, 2009, at 2:34 PM, Michael Chen wrote: > Julian, > > Please revisit section 5.1.1, particularly the last paragraph. The nuance is > that for any request (including Attach), the last Destination entry in the > destination-list can be either a Resource-ID or a Node-ID. Normally, an > Attach to a known peer uses a Node-ID Destination. > > However, the example in Section 11 demonstrates sending an Attach that uses a > Resource-ID to discover an **unknown** peer (JP's successor s0, s1 and finger > nodes). This is a clever use of Attach. Since it is sent to the bootstrap > node (or other known peer, e.g. use s0 to find s1), there is no need to use > Ping. Like I said, Section 11 is sound as it is. > > Thanks > > --Michael > -------- Original Message -------- > Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work > From: jc <[email protected]> > Date: Sat, November 21, 2009 10:47 pm > To: "Michael Chen" <[email protected]> > Cc: [email protected] > > > On Nov 21, 2009, at 11:16 PM, Michael Chen wrote: > > > Julian, > > > > Section 9.4 1. already established that JP has a connection to the > > bootstrap node. Function-wise, I think the example in Section 11 is > > sufficient to join the overlay. > > Right. > > > > > As for 9.6.1, when a peer lost all its successors, the overlay may have > > been partitioned (the ring is broken). Whether it uses Ping or Attach to > > re-join makes no difference. > > The logical ring wouldn't be broken if it were partitioned. You would have N > overlays that aren't communicating with one another. So the logic from > 9.6.4.4. would be used in that case which states sending a Ping not an Attach. > > > > > Actually, I made a couple of mistakes in my text. In the paragraph after > > step 8, "Node-ID" should be "Resource-ID". The original text of draft-06 is > > correct per section 5.1.1 last paragraph. > > The problem I see is: > > 1. JP MUST connect to its chosen bootstrap node. > 2. JP SHOULD send a series of Attach requests to discover and connect.... > > In order to perform 2 you need to know "some" Node-ID's in your neighbor > table. So you MUST send a Join on connection to the bootstrap node and then > you can start forming your Attach requests. > > It should read something like: > > 1. JP MUST connect to its chosen bootstrap node (AP). > 2. JP Sends a Join request to JP announcing its intention to join. > 3. AP sends a Join response. > 4. AP does a sequence of Stores to JP to give it the data it will need. > 5. AP does Updates to JP to tell it about its own routing table. > 6. JP SHOULD send a series of Attach requests to form connections to peers > that make up its neighbor table as well as the desired 16 finger table > entries. > > Julian > > > > > --Michael > > > > -------- Original Message -------- > > Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work > > From: jc <[email protected]> > > Date: Sat, November 21, 2009 11:16 am > > To: Michael Chen <[email protected]> > > > > Attach messages are routed through the overlay where pings are not. > > > > A ping actually tests the path while Attach does not. > > > > Also the wording changes break further 9.* sections. For instance 9.6.1 > > states "this peer should behave as if it is joining the network and use > > pings to find a peer and send it a Join". > > > > It's clearly not defined correctly as is however. A ping is error prone > > unless you've already Attached due to possible NAT. While an Attach will > > reach any node that is inside the ring a ping will not. > > > > Julian > > > > Sent from my iPhone > > > > On Nov 21, 2009, at 12:42 PM, "Michael Chen" <[email protected]> > > wrote: > > > >> Hi, > >> > >> Draft-06 Section 9.4 is dated and needs work. > >> > >> 2. JP SHOULD use a series of Pings to populate its routing table. > >> 3. JP SHOULD send Attach requests... > >> 4. JP MUST enter all the peers it has contacted into its routing > >> table. > >> > >> Section 11 provided a better method in which Attach requests are used > >> (instead of Ping) to discover and populate the routing table. There is > >> no need to use Ping. Suggest using the following text: > >> > >> 1. JP MUST connect to its chosen bootstrap node. > >> 2. JP SHOULD send a series of Attach requests to discover and connect > >> to peers that make up its neighbor table as well as the desired 16 > >> finger table entries. Note that this does not populate their > >> routing tables, but only their connection tables, so JP will not > >> get messages that it is expected to route to other nodes. > >> 3. JP MUST enter all the peers it has contacted into its routing > >> table and connection table. > >> 4. JP SHOULD send a Join to its immediate successor, the admitting > >> peer (AP) for Node-ID n. The AP sends the response to the Join. > >> 5. AP MUST do a series of Store requests to JP to store the data > >> that JP will be responsible for. > >> 6. AP MUST send JP an Update explicitly labeling JP as its > >> predecessor. At this point, JP is part of the ring and > >> responsible for a section of the overlay. AP can now forget any > >> data which is assigned to JP and not AP. > >> 7. AP MUST send an Update to all of its neighbors with the new > >> values of its neighbor set (including JP). > >> 8. JP SHOULD send Updates to all the peers in its routing table. > >> > >> In order to populate its neighbor table, JP n sends an Attach via the > >> bootstrap node directed at Node-ID n+1 (directly after its own Node-ID). > >> This allows it to discover its own successor. Call that node s0. It > >> then sends an Attach (via the bootstap peer or s0) to s0+1 to discover > >> its second successor (s1). This process can be repeated to discover as > >> many successors as desired. The predecessors of JP will be found at a > >> later stage when JP receives an Update. > >> > >> In order to set up its finger table entry i, JP simply sends an Attach > >> to peer (n+2^(numBitsInNodeId-i). This will be routed to a peer in > >> approximately the right location around the ring. > >> > >> The joining peer MUST NOT send any Update message placing itself in > >> the overlay until it has successfully completed an Attach with each > >> peer that should be in its neighbor table. > >> > >> > >> Thanks > >> > >> --Michael > >> > >> > >> _______________________________________________ > >> P2PSIP mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/p2psip >
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
