On Mon, Oct 15, 2018 at 10:13 AM, Bless, Roland (TM)
<[email protected]> wrote:
Yes, the last hop forwarding the answer will be B, but the originating
node from the other end (i.e., the one answering the ping request) is
a
different node than P's current successor.
"the one answering the ping request"? But this will be my node
answering the ping request.
Ok, I'm lost. Let's consider the PingReq path:
my_node -> boot_node -> ... -> node_X -> my_node
The corresponding PingAns will be:
my_node -> node_X -> ... -> boot_node -> my_node
So the idea is to check if node_X is the successor of my_node, right?
In this case I don't understand how to get that node from the answer:
forwarding nodes
are not required to maintain Via lists, or they can just hide the path
by OpaqueID.
Should I maintain some state on my node to do these checks?
That may be best understood by looking at Figure 1 on page 139 and/or
section 10.5.
The Joining Node sends an AttachReq to its own ID+1 (this process
is probably denoted as "Attaching"). The Admitting Peer (AP) and
responsible peer are the same in this case, it will be the successor
of the newly joining node. Does this make sense?
Yes, this makes sense, and this is trivial, but it's hard to understand
from that phrase.
Whatever, thanks for the clarification.
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
