[Sis-ams] 'reconnect' timer?

[Scott Burleigh]

Ray, Timothy J. (GSFC-583.0) wrote:
>
> Dear WG members,
>
>  
>
> 4.2.7.4.2  specifies that a node shall (in response to imputing the 
> death of its registrar) query the configuration server to determine 
> the network location of the restarted registrar, and then send a 
> 'reconnect' message to the new registrar (and the registrar shall 
> respond with either a 'reconnected' or 'you-are-dead').  Good so far.  
> But what if the node does not receive a response from the registrar?  
> I don't think our spec covers this situation.
>
>  
>
> In my opinion, AMS should require the node to start a timer when it 
> sends the 'reconnect' message.  AMS should also specify the action to 
> be taken if the timer expires.
>
Tim, good point; the spec is not as clear on this as it should be.  The 
intent is that:

a)   The immediate response of a node to the imputed death of a 
registrar should be simply to note that the registrar is no longer 
running, nothing more.  (The same is true, really, of the effect on a 
registrar of the imputed death of a configuration server.)

b)   At the expiration of any heartbeat period, the node is supposed to 
send a heartbeat to the registrar.  If it knows that the registrar is 
running (at a known network location), great.  If not, the node is 
supposed to try to determine the new location of the restarted 
registrar, by interrogating the configuration server, and then -- if 
that attempt was successful -- send a reconnect message to the restarted 
registrar at its new location.

c)   If there's no response (reconnected or you_are_dead) to the 
reconnect message, no problem.  At the expiration of the next heartbeat 
period, the node will do step (b) again and this will result in (at 
most) transmission of another reconnect.

That is, the reconnect cycle is "soft state"; in effect, the heartbeat 
cycle functions as the timer on reconnect messages.

I like this approach, as it is pretty simple and at this point I think 
we want to avoid introducing any more complexity (such as another timer) 
into the spec if we can possibly help it.  But what I have written here 
is really hard to infer from the current text of 4.2.7, so I need to do 
some serious reworking of this text.  I'll try to do that this week, 
unless we don't agree that this approach is okay.  What do you think?

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sis-ams/attachments/20080825/67f8edfd/attachment.htm