Hi Evgeny, On 15.10.2018 at 09:56 Evgeny wrote: > 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.
No, your successor should answer the request, as one should ping own ID+1. This seems to be inconsistent with the RFC: "P SHOULD then send a Ping for its own Node-ID routed through B." Own Node-ID would not work and the initial join procedure in sec. 10.5 says "JN SHOULD send an Attach request to the Admitting Peer (AP) for Resource-ID n+1" So Michael already filed an errata. > 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? The originator of the reply message can be found in the identity part of the signature block. >> 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. > Regards, Roland _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
