In Section 9.4, you're right that there's no reason for the PINGs to
be there. Right now the first three steps are:
1. JP MUST connect to its chosen bootstrap node.
2. JP SHOULD use a series of Pings to populate its routing table.
3. JP SHOULD send Attach requests to initiate connections to each of
the peers in the neighbor table as well as to the desired 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.
Propose a change to make it:
1. JP MUST connect to its chosen bootstrap node.
2. <deleted, renumber the rest>
3. JP SHOULD send Attach requests to the resource IDs
necessary to populate each of the peers in its
neighbor table as well as to the desired 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.
....
Then after the list, change:
In order to populate its neighbor table, JP sends a Ping via the
bootstrap node directed at Resource-ID n+1 (directly after its own
Resource-ID). This allows it to discover its own successor. Call
that node p0. It then sends a ping to p0+1 to discover its successor
(p1). This process can be repeated to discover as many successors as
desired. The values for the two peers before p will be found at a
later stage when n receives an Update.
to
In order to populate its neighbor table, JP sends an Attach via the
bootstrap node directed at Resource-ID n+1 (directly after its own
Resource-ID). This allows it to discover and Attach to its own
successor. Call
that node p0. It then sends an Attach to p0+1 to discover its successor
(p1). This process can be repeated to discover as many successors as
desired. The values for the two peers before p will be found at a
later stage when n receives an Update.
Bruce
2010/10/26 <[email protected]>
>
> I'm sorry, it is error in my last e-mail. It should be section 9.4 rather
> than section 9.5 which is inconsistent with section 11.
>
>
>
>
>
> Bruce Lowekamp <[email protected]>
>
> 2010-10-27 01:47
>
> 收件人
> [email protected]
> 抄送
> Frederic-Philippe Metz <[email protected]>, [email protected],
> [email protected]
> 主题
> Re: [P2PSIP] 答复: Re: 答复: Clarification of initial attach procedure
>
>
>
>
> Yes, using PING first introduces some corner failure cases that simply
> routing the ATTACH to the resource-id of JP does not.
>
> Section 9.5 doesn't actually conflict with the notion that the initial
> attach is routed to the JP's resource-id, though. 9.5 simply says that if
> peer A learns of peer B through peer C, it needs to send the ATTACH through
> peer C. This is simply because A may not have connectivity with B other than
> through peer C, such as when an overlay has been partitioned and is now
> healing. The initial ATTACH is essentially handled the same way, because it
> is routed via the BP.
>
> Bruce
>
> On Mon, Oct 25, 2010 at 6:56 PM, <[email protected]> wrote:
>
> Yes, these methods are also ok.
> It appear to be inconsistent between section 9.5 and section 11. I think the
> method in section 11 is more efficient.
>
>
>
> Frederic-Philippe Metz <[email protected]>
> 发件人: [email protected]
>
> 2010-10-25 15:36
>
> 收件人
> [email protected]
> 抄送
> 主题
> Re: [P2PSIP] 答复: Clarification of initial attach procedure
>
>
>
>
>
>
> Ok. So JP either can
> a) Send a ping to the resource id+1 (as the node_id of JP) to get the node-id
> (in the RELOAD message signature of the Ping answer) to then perform an
> attach to this node_id (this is mentioned in 9.4) or
> b) directly form a resource-id+1 (as JP's node_id) and send an attach.
>
> Do you agree ?
>
> Cheers,
> Frederic
>
> On Mon, Oct 25, 2010 at 9:04 AM, <[email protected]> wrote:
>
> I think JP is correct. The Node of JP is as Resource-ID in Attach. Before
> Attaching, a Ping message is redundant.
>
> There is the description above the second dirgram in the draft:
> "It sends an Attach to the Resource-IP AP+1, which gets routed to NP."
>
> "Resource-IP" should be "Resource-ID".
>
>
> Frederic-Philippe Metz <[email protected]>
> 发件人: [email protected]
>
> 2010-10-23 15:31
>
> 收件人
> [email protected]
> 抄送
> 主题
> [P2PSIP] Clarification of initial attach procedure
>
>
>
>
>
>
>
>
> Hi all,
>
> I've got a question resp. page 123:
>
> The first attach in the call flow diagram states JP as the
> destination. I think it should be AP ? JP has got the node-id of AP
> from a previous ping, right ? If that assumption is not right, the
> attach to node-id JP will fail, because 5.5.1 states that the attach
> to a node-id which isn't reached will fail.
>
> Cheers,
> Frédéric
> _______________________________________________
> P2PSIP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/p2psip
>
>
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is
> solely property of the sender's organization. This mail communication is
> confidential. Recipients named above are obligated to maintain secrecy and
> are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed. If
> you have received this email in error please notify the originator of the
> message. Any views expressed in this message are those of the individual
> sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
>
> _______________________________________________
> P2PSIP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/p2psip
>
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
>
>
> _______________________________________________
> P2PSIP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/p2psip
>
>
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
