Re: [P2PSIP] RFC6940: Detecting Partitioning

["Bless, Roland (TM)" <[e-mail]>]

Hi Evgeny,

Am 14.10.2018 um 21:04 schrieb Evgeny:
> I have hard time understanding the mechanism described in 10.7.4.4
> (Detecting Partitioning) [1]:
> 
>> P SHOULD then send a Ping for its own Node-ID routed through B.
>> If a response is received from peer S', which is not P's successor,
>> then the overlay is partitioned
> 
> How is it even possible? Given the Symmetric Recursive Routing, the Ping
> answer will always come from node B.

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.

> I tried to grasp through the RFC about special routing rules of Ping
> answers, but I didn't find anything special
> except the statement in 6.1.2 (Other ID) [2] which I *fail* to understand:
> 
>> The node MUST implement support for
>> returning responses to a Ping or Attach request made by a Joining
>> Node Attaching to its responsible peer
> 
> "made by a Joining Node At taching to its responsible peer"? What does
> that mean exactly? Why is "Attaching"
> with a capital letter?

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?

Regards,
 Roland