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
