Re: [Anima-signaling] GRASP issue 51: Flooded objectives

[Brian E Carpenter <[e-mail]>]

Hi Michael,

Hope you had a good vacation.

On 30/08/2016 20:56, Michael Behringer (mbehring) wrote:
> Sorry for long silence. Yes, vacations and business travel... 
> 
>> Actually this gets back to something I was beating Michael (Behringer) up
>> about. I would love it if the ACP could do this. From a coding point of view it
>> would be nicest if the ACP could catch packets sent to a LL multicast socket
>> (by behaving like a virtual link) but that's a detail.
>> It would be OK too if the ACP simply provides functions to call instead of
>> sendto(msg,0,(ALL_GRASP_NEIGHBOR_6, GRASP_LISTEN_PORT)) and the
>> matching recvfrom().
> 
> Hesitating here. Our current pre-standard implementation is not implemented as a node-wide service, but as a set of interfaces. It's pure plumbing, essentially. In that, you'd send a packet to the ACP interface to node x, rather than to "the ACP" as a whole. That doesn't mean we couldn't provide an API that does what you describe, of course. 
> 
> Bottom line, the translation from the high-level "send packet to all neighbors" to mapping to specific interfaces needs to happen somewhere. We could create a more "clever" ACP which hides the actual interface and provides a higher level interface. But then we'd have two "clever" state machines, one for GRASP, one for the ACP. 
> 
> Wouldn't it be easier if GRASP could map to specific interfaces, such that we only have one such beast? And that the ACP could remain just "plumbing"?  

Just to be clear, my implementation (and I suspect any implementation) figures
out which interfaces exist and sets up a socket for multicasting to each one. That scales
if you have a reasonable number of interfaces. How many interfaces do you expect an ACP user
to see in a typical case?

> 
>> ...
>>> What happens with a node newly rebooting. How does it get those
>>> existing flood objectives ?
>> ...
>>> Aka: periodic, low-frequency broadcast is a proven stable solution.
>>> Its not the nicest. It may not be the only one we want in GRASP, but
>>> i'd feel a lot safer if we could make that option work.
>>
>> Yes, and it's easy - because the sending ASA can just do it, at a frequency that
>> suits the particular objective. Also, a node that doesn't want to wait for the
>> next flood can do a standard GRASP unicast synchronize action.
>  
> Just to be sure I understand: You're essentially saying GRASP shouldn't deal with issues like rebooting, but an ASA needs to understand that it just got re-started, and if required, ask specifically its neighbors for current state? That would make sense to me. 

Yes (either ask, or simply wait for the next flood, according to the semantics of
the particular autonomic function).

GRASP needs to do a few things after a restart, like repeat the determination of
which interfaces it has, what its own IP address is, etc., and I'm sure the ACP will
need to do the same sort of thing. We do need to emphasise for ASA writers that
they have to write robust code - however robust we make GRASP and the ACP, the ASAs
must be written to a high standard too.

Regards
   Brian