[Sis-ams] minor heartbeat-related issue

[Scott Burleigh]

Edell, David J. wrote:
> I ran into a similar issue when finishing my implementation. 
>  
> I believe the intent was for the reply method to be inferred from the 
> transport service in that case--meaning that this is a piece of data 
> missing in the AMS content itself.  In my case, I think the node-id 
> was included which I used in the absence of TS specified context to 
> infer the reply address in the APL implementation for unregistered 
> nodes (which uses a direct mapping). I don't remember if/how I had 
> addressed this for an unregistered registrar.
David's answer is right, and I realize this may not be wholly 
satisfactory.  There's an implicit expectation that the receiving entity 
can figure out the MAMS endpoint name of the sender in a 
transport-specific way that is left as an implementation issue.  For 
example, if you're using UDP as the transport for MAMS traffic then when 
you receive the heartbeat you can get the IP address and port number of 
the sending socket from the recvfrom() parameters and send the 
you_are_dead message back to that socket.  You'd have similar 
information if you used, say, the DTN Bundle Protocol as your MAMS 
transport protocol.  This is one of the main reasons that TCP, for 
example, is not a particularly good choice as a MAMS transport protocol: 
the asymmetry of connect/accept makes this kind of echoing complex to 
implement.

At minimum (I now realize), this implementation responsibility ought to 
be made explicit somewhere -- probably in 4.2.7.4.4 and 4.2.7.4.5, 
although I guess a case could be made for documenting it in the Green 
Book instead.

Alternatively, we could modify the heartbeat message to carry MAMS 
endpoint name.  I am not real comfortable with this, as I think it would 
be perceived as adding a lot of bandwidth consumption that would be 
needed only in two edge cases.

A third alternative, though, might be simply to ditch the transmission 
of you_are_dead messages in these cases, i.e., just ignore the 
heartbeats.  The only downside of this would be that the unregistered 
entity wouldn't receive such prompt notification that it is not 
currently registered.  But eventually it would drop back into imputed 
termination logic and go through the relevant re-registration procedure, 
so there's no real harm done.

On reflection, I like this third alternative pretty well.  What do you 
all think?

Scott
> ------------------------------------------------------------------------
> *From:* sis-ams-bounces at mailman.ccsds.org 
> [mailto:sis-ams-bounces at mailman.ccsds.org] *On Behalf Of *Ray, Timothy 
> J. (GSFC-583.0)
> *Sent:* Wednesday, July 09, 2008 2:51 PM
> *To:* sis-ams at mailman.ccsds.org
> *Subject:* [Sis-ams] minor heartbeat-related issue
>
> Dear WG members,
>
>  
>
> (Scott:  thanks for posting the latest specs, and for keeping them 
> up-to-date.)
>
>  
>
> Here's another issue that I've run into.  Perhaps I am missing something?
>
>  
>
> 4.2.7.4.4 - If a server receives a 'heartbeat' from an unregistered 
> registrar, it is supposed to send back a 'you-are-dead'.  In order to 
> do that, it will need to know how to contact the registrar (i.e. its 
> mams-endpoint-name).  That name is not included in the 'heartbeat'.  
> How can a server send an MPDU to an unregistered registrar?
>
>  
>
> 4.2.7.4.5 - Same as previous, but registrar receives a heartbeat from 
> an unregistered node.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sis-ams/attachments/20080710/fd2bf7c3/attachment.htm