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
