Subject: Re: [Anima] GRASP issue 46

From: Brian E Carpenter <[email-masked]>
Date: Thu, 4 Feb 2016 13:35:58 +1300

Having heard no objection, I'm going to assume we can make this change
and close issue 46 in the next version.

Regards
   Brian

On 28/01/2016 13:49, Brian E Carpenter wrote:
>>    o  46.  The 'initiator' field in DISCOVER, RESPONSE and FLOOD
>>       messages is intended to assist in loop prevention.  However, we
>>       also have the loop count for that.  It would be simpler to remove
>>       the initiator, making message parsing more uniform.  Is that OK?
> 
> We added this in version -02 in response to Joel Halpern's observation
> that a session_id might (with very low probability) be ambiguous, so it
> needs to be associated with the address of the node that created it.
> 
> That remains true. However, the 'initiator' field only matters for disambiguating
> multicast Discovery messages that have been relayed between LANs, so that responses
> go back to the correct host in the end. In all other cases, the node that receives
> a message and needs to make use of the session_id automatically knows who sent
> the message.
> 
> When debugging my code for relaying Discovery and Flood messages, I realised that
> I could make this problem go away very simply: by creating a *new* Discovery or Flood
> message with a new session_id. For example, if A says discover("C") and this is
> received by relay B, then B says discover("C") on its other interface, waits for
> the response, caches it, and then responds to A with a Divert option. The two
> discovery processes are independent. Not only does it solve the problem above,
> it's also simpler to code.
> 
>   Node A
>   __|____________________
>                     |
>                   Node B
>               ______|___________________
>                              |
>                            Node C
> 
> If the WG agrees, the fix would be:
> 
> 1. Abolish the 'initiator' field in DISCOVER, RESPONSE and FLOOD.
> 2. Change the descriptions of the relay actions (for Discover and Flood)
> to require that the relayed messages have a *new* session_id. But they
> still decrement the loop count.
> 3. Simplify the loop detection text.
> 
> My prototype code works this way and it works well. I've tested loop
> prevention using the loop count mechanism, and it works too.
> 
>     Brian
>